Creating A CABINET.DLL Interface (
Page 1 of 4 )
Reading and Writing CAB Files from .NET, Part 1: Although Microsoft publishes a Cabinet SDK with C header files, documentation, and examples, if you want to interface to these compressed files from .NET you're on your own. Or you were -- until now. Jim Mi
Microsoft uses cabinet files almost exclusively for product distribution, including Windows installation, ActiveX component downloads, and Microsoft Installer packages. A cabinet file (also known as a cab file) is a compressed collection of multiple files, similar in concept to a zip file.
Windows XP and later versions can view cabinet files directly, just as they can view files created with WinZip and similar file compression utilities. Operating system versions since at least Windows 98 (and possibly Windows 95) include a DLL, called CABINET.DLL, containing functions that programs use to read and write cabinet files. Most installation programs assume that CABINET.DLL exists on the computer and will fail if it's not there.
Although you can use cabinet files for general-purpose compression as you would WinZip or similar programs, there is no widely available user program for doing so. Cabinet files seem to be reserved for installation purposes. For developers, Microsoft
publishes a Cabinet SDK that contains C header files, documentation, and example programs (again, written in C) that show how to interface with CABINET.DLL functions. Microsoft has not published any information on accessing CABINET.DLL from .NET. As I needed to create cabinet files from a C# program, I decided to tackle this
one myself.
A Quick Tour of the Cabinet File Interface
The cabinet file interface implemented in CABINET.DLL actually consists of two separate groups of functions: the File Compression Interface (FCI) and the File Decompression Interface (FDI). Although obviously related and very similar to each other in operation, these two interfaces operate independently. When you're creating a cabinet file, you call FCI functions exclusively, and when decompressing you call FDI functions exclusively. The functions in each interface are briefly described in Tables 1 and 2.
Table 1: File Compression Interface functions
|
Function Name
|
Description
|
|
FCICreate
|
Creates an FCI context.
|
|
FCIAddFile
|
Adds a file to the cabinet under construction.
|
|
FCIFlushCabinet
|
Completes the current cabinet.
|
|
FCIFlushFolder
|
Completes the current folder and starts a new folder.
|
|
FCIDestroy
|
Destroys an FCI context.
|
Table 2: File Decompression Interface functions
|
Function Name
|
Description
|
|
FDICreate
|
Creates an FDI context.
|
|
FDIIsCabinet
|
Determines if a file is a cabinet, and returns information about the cabinet if so.
|
|
FDICopy
|
Extracts files from a cabinet.
|
|
FDIDestroy
|
Destroys an FDI context.
|
The interfaces also define a handful of structures that control cabinet creation and decompression, and a group of callback functions that clients must implement in order to respond to cab file compression and decompression events.
FCI and FDI make heavy use of callback functions. Client programs must implement 13 different callback functions to create cabinet files, and nine different callbacks to extract files.
Most of the callback functions are used to allocate and deallocate memory and to access files. FCI and FDI rely on the client program to provide these functions. This makes it possible to use the interfaces in a much wider range of applications. Since the client provides file I/O and memory allocation, it's much easier to support the cabinet interface on nontraditional devices like diskless workstations and mobile devices. The drawback to this
design is that it creates some headaches for implementers of client programs, especially if those client programs are written in a language other than C.
