Skip Headers
Oracle® Outside In Content Access Developer's Guide
Release 8.3.7

Part Number E12846-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

2 Windows Implementation Details

Content Access is delivered as a set of DLLs. 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.

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 three versions of this package (x86, x64, and IA64) 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, vcredist_x64.exe, or vcredist_IA64.exe. The required version of each of these downloads is the 2005 SP1 Redistributable Package.

The redistributable module that Outside In requires is msvcr80.dll.

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 compiled executables of the sample applications.
\sdk\lib Contains the library (.lib) files for sccca.dll, sccta.dll, sccra.dll, sccda.dll and sccfi.dll.
\sdk\resource Contains localization resource files. For more information, see Section 2.6, "Changing Resources."
\sdk\samplecode Contains the source code for the sample application.
\sdk\samplefiles Contains sample files designed to exercise the technology.

2.1.1 NSF Support

Notes Storage Format (NSF) files are produced by the Lotus Notes Client or the Lotus Domino server. The NSF filter is the only Outside In filter that requires the native application to be present to filter the input documents. Due to integration with an outside application, NSF support will not work with redirected I/O, when an NSF file is embedded in another file, or with IOTYPE_UNICODEPATH. Either Lotus Notes version 8 or Lotus Domino version 8 must be installed on the same machine as OIT. On Windows, SCCOPT_LOTUSNOTESDIRECTORY should be set to the directory containing the nnotes.dll. NSF support is only available on the Win32 platform, Linux x86-32, and Solaris Sparc 32.

2.2 Libraries and Structure

Here is 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.

File Description
sccca.dll Content Access module (provides organized chunker data for the developer)
sccda.dll Data Access module
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.
sccta.dll Text Access module (provides straight text data for the developer)

Support DLLs

File Description
sccch.dll Chunker (provides caching of and access to filter data for the display engine)
sccfa.dll Filter Access module
sccfmt.dll Formatting module (resolves numbers to formatted strings)
sccfut.dll Filter utility module
sccind.dll Indexing engine
scclo.dll Localization library (all strings, menus, dialogs and dialog procedures reside here)
sccole.dll OLE rendering module
sccut.dll Utility functions (including IO subsystem)
wvcore.dll The GDI Abstraction layer

Filter DLLs

File Description
vs*.dll Filters for specific file types (there are more than 150 of these filters, covering more than 500 file formats)
oitnsf.id Support file for the vsnsf filter.
ltscsn10.dll

lwpapin.dll

ltscsd13.tlb

lwpapipn.dat

Support files for the vslwp filter

Premier Graphics Filters

File Description
i*2.flt 30 .flt files (the import filters for premier graphics formats)
isgdi32.dll Interface to premier graphics filters

Additional Files

File Description
adinit.dat Support file for the vsacd2 filter
cmmap000.bin Tables for character mapping (all character sets)
cmmap000.sbc Tables for character mapping (single-byte character sets). Located in the common directory.
cmmap000.dbc Identical to cmmap000.Bin, but renamed for clarity (.dbc = double-byte character). This file is located in the common directory.

2.3 The Basics

All the steps outlined in this section are used in the sample applications provided with the SDK. Looking at the code for the simple sample application is recommended for those wishing to see a real-world example of this process.

For detailed information about all sample applications included with this product, see Chapter 10, "Sample Applications."

2.3.1 What You Need in Your Source Code

Any source code that uses this product should #include the file sccca.h (for Content Access) and/or sccta.h (for Text Access) and #define WINDOWS and WIN32 or WIN64. For example, a Windows application might have a source file with the following lines:

#define WINDOWS         /* Will be automatically defined if your
                           compiler defines _WINDOWS */
#define WIN32
#include <sccca.h>      /* If using ContentAccess */
#include <sccta.h>      /* If using Text Access */

The developer's application should be linked to the Content Access (and/or Text Access) and Data Access DLLs through the provided libraries (sccta.lib, sccca.lib and sccda.lib).

2.3.2 Options and Information Storage

One set of information is created by the technology, the default options. In the Windows implementation, this is built by the technology as needed, usually the first time the product is run. You do not need to ship this list with your application. The list is automatically regenerated if corrupted or deleted.

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 will be created automatically by the technology. The files are automatically regenerated if corrupted or deleted.

The file is:

*.d = Display engine lists

Note:

Some applications and services may run under a local system account for which there is no user's "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 \sdk\samplefiles\win.

2.4 Character Sets

This section provides information about character sets.

2.4.1 Default API Character Set

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

2.4.2 Double-Byte Character Set Mapping

Please note that to optimize performance on systems that do not require DBCS support, a second character mapping bin file, that does not contain any of the DBCS pages, is now included. The second bin file will give additional performance benefits for English documents, but will not be able to handle DBCS documents. To use the new bin file, replace the cmmap000.bin with the new bin file, cmmap000.sbc. For clarity, a copy of the cmmap000.bin file named cmmap000.dbc has also been included. Both the cmmap000.sbc and cmmap000.dbc files are located in the \sdk\common directory of the technology.

2.5 Runtime Considerations

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

2.6 Changing Resources

Outside In Content Access ships with the necessary files for OEMs to change any of the strings in the technology as they see fit.

Strings are stored in the lodlgstr.h file found in the resource directory. The file can be edited using any text editor.

Note:

Do not directly edit the scclo.rc file. Strings are saved with their identifiers in lodlgstr.h. If a new scclo.rc file is saved, it will contain numeric identifiers for strings, instead of their #define'd names.

Once the changes have been made, the updated scclo.dll file can be rebuilt using the following steps:

  1. Compile the .res file:

    rc /fo ".\scclo.res" /i "<path to header (.h) files folder>" /d "NDEBUG" scclo.rc
    
  2. Link the scclo.res file you've created with the scclo.obj file found in the resource directory to create a new scclo.dll:

    link /DLL /OUT:scclo.dll scclo.obj scclo.res
    

    Note:

    Developers should make sure they have set up their environment variables to build the library for their specific architecture. For Windows x86_32, when compiling with VS 2005, the solution is to run vsvars32.bat (in a standard VS 2005 installation, this is found in C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\). If this works correctly, you will see the statement, "Setting environment for using Microsoft Visual Studio 2005 x86 tools." If you do not complete this step, you may have conflicts that lead to unresolved symbols due to conflicts with the Microsoft CRT.
  3. Embed the manifest (which is created in the \resource directory during step 2) into the new DLL:

    mt -manifest scclo.dll.manifest -outputresource:scclo.dll;2
    

If you are not using Microsoft Visual Studio, substitute the appropriate development tools from your enviroment.

Note:

In previous versions of Outside In, it was possible to directly edit the SCCLO.DLL using Microsoft Visual Studio. Outside In DLLs are now digitally signed. Editing the signed DLL is not advisable.