2 Windows Implementation Details

Under Windows, File ID is implemented as entry points in a DLL.

The File ID DLL can either be linked with the developer's application using the library provided (sccfi.lib) or the developer can use LoadLibrary, LoadLibraryEx and GetProcAddress to load it dynamically.

For a list of the currently supported platforms, see:

http://www.oracle.com/technetwork/indexes/documentation/index.html#middleware

Click on Outside In Technology, then click the Certification Information PDF.

This chapter includes the following sections:

Section 2.1, "Installation"
Section 2.2, "Libraries and Structure"
Section 2.3, "The Basics"

2.1 Installation

To install the demo version of the SDK, copy the contents of the ZIP archive (available on the web site) to a local directory of your choice.

This product requires the Visual C++ libraries included in the Visual C++ Redistributable Package available from Microsoft. There are two versions of this package (x86 and x64) for each corresponding version of Windows.

These can be downloaded from www.microsoft.com/downloads, by searching on the site for the packages vcredist_x86.exe or vcredist_x64.exe. The required version of each of these downloads is the 2005 SP1 Redistributable Package.

Outside In requires the msvcr80.dll redistributable module.

The installation directory should contain the following directory structure.

Directory	Description
\docs	Includes release notes and HTML and PDF versions of the manual you are reading right now. The release notes contain information that is potentially more up-to-date than that found in this user guide and should therefore be read before you install the technology.
\redist	Contains a working copy of the Windows version of the technology.
\sdk\common	Contains the C include files needed to build or rebuild the technology.
\sdk\demo	Contains the compiled executable of the sample application.
\sdk\lib	Contains the library (.lib) file for sccfi.dll.
\sdk\resource	Contains localization resource files.
\sdk\samplecode	Contains the source code for the sample application.
\sdk\samplefiles	Contains sample files designed to exercise the technology.

2.2 Libraries and Structure

This section provides an overview of the files contained in the main installation directory for this product.

API DLLs: These DLLs implement the API. They should be linked with the developer's application. LIB files are included in the SDK.
- sccfi.dll: File Identification module (identifies files based on their contents). The File ID Specification may not be used directly by any application or workflow without it being separately licensed expressly for that purpose.
Support DLLs:
- sccfut.dll: Filter utility module
- scclo.dll: Localization library (all strings, menus, dialogs and dialog procedures reside here)
- sccut.dll: Utility functions (including IO subsystem)
- wvcore.dll: The System Call Abstraction layer

2.3 The Basics

This section describes some basic information required for installation and usage.

2.3.1 Source Code

Any source code that uses File ID should #include the file sccfi.h, and #define WINDOWS and #define WIN32. For example, a Windows application might have a source file with the following lines:

#define WINDOWS
   #define WIN32
   #include <SCCFI.H>

Note:

These instructions are Win32-specific, but are essentially the same for Win64. If you are compiling for 64-bit Windows, simply read "Win32" or "Win32V" as "64" in the following instructions.

2.3.2 Options and Information Storage

The software creates a default list of persistent option files (*.opt). They are built as needed, usually the first time the product runs. You do not need to ship these files with your application.

The files used to store this information are stored in a .oit subdirectory in the following location:

\Documents and Settings\user name\Application Data

If an .oit directory does not exist in the user's directory, the directory is created automatically by the technology. The *.opt files are automatically regenerated if corrupted or deleted.

Note:

Some applications and services may run under a local system account for which there is no users "application data" folder. The technology first does a check for an environment variable called OIT_DATA_PATH. Then it checks for APPDATA, and then LOCALAPPDATA. If none of those exist, the options files are put into the executable path of the UT module.

These file names are intended to be unique enough to avoid conflict for any combination of machine name and install directory. This allows the user to run products in separate directories without having to reload the files above. The file names are built from an 11-character string derived from the directory the Outside In technology resides in and the name of the machine it is being run on. The string is generated by code derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm.

2.3.3 Structure Alignment

Outside In is built with 8-byte structure alignment. This is the default setting for most Windows compilers. This and other compiler options that should be used are demonstrated in the files provided with the sample applications in samples\win.

2.3.4 Character Sets

The strings passed in the Windows API are ANSI1252 by default.

2.3.5 Runtime Considerations

The files used by this product must be in the same directory as the developer's executable.

2.3.6 Changing Resources

Outside In ships with the scclo.rc file in the resource directory so that OEMs can change any of the menus or strings in the technology as they see fit.

In some of the newer development environments, these strings can be edited directly in the compiled DLL file. For this reason, scclo.dll has been compiled with all resource strings. It was built using Microsoft Developer Studio 8.0. If you are using Microsoft Developer Studio, the best way to edit the strings in this file is to edit the lodlgstr.h file in the resource directory. Once you've made your changes, save the scclo.rc file as a binary resource (.res) file, which can be used to compile scclo.dll. Microsoft Developer Studio users should not directly edit the .rc files when using this method as this would in effect place all resource strings directly in the scclo.rc file, thus rendering the lodlgstr.h file irrelevant.

If you are not editing in Developer Studio, the resource file (scclo.rc) available in the SDK can be edited directly using any text editor. This file can then be compiled and linked into the DLL. Typically, this means compiling the resources into a .res file and linking them into the already compiled scclo.dll. Methods for doing this vary depending on the compiler used.