2 Windows Implementation Details

This chapter describes the implementation of the File ID SDK on the Windows platform. Under Windows, File ID is implemented as an 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 Outside In Technology and click links under Certified Platforms and Supported Formats.

This chapter includes the following sections:

Note:

For installation steps, see Installation section.

2.1 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.2 The Basics

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

2.2.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.2.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.2.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.2.4 Character Sets

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

2.2.5 Runtime Considerations

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

2.2.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.