Windows CE installation cabinet (.CAB) file format

Table of Contents

• About the format
• Overall cabinet file format
• Cabinet file contents
• Format of the .000 file
  • The fixed size header
  • The APPNAME string.
  • The PROVIDER string.
  • The UNSUPPORTED multi string.
  • The STRINGS section
  • The DIRS section
  • The FILES section
  • The REGHIVES section
  • The REGKEYS section
  • The LINKS section
• Appendix A: a list of processor architectures
• Appendix B: a list of %CEn% shortcuts

About the format

The Windows CE installation cabinet format was designed by Microsoft make it easy to create packaged software for the Windows CE platform. After generating all his executable programs, data files, help files and so on, a developer can then write an "installation script" which lists the name of the software package, where each file should be installed on the target device's filesystem, registry entries to make on the target system's Windows Registry, and so on. A tool called "CabWiz" takes the installation script and produces a single CAB file with a special control file stored in it. On the target Windows CE device, a program called WCELOAD.EXE will read cabinet files, install them, register them as installed packages, set their registry entries, and so on.

The Cabinet format was previously developed by Microsoft for creating a simple archive format for packaged software, from entire operating systems down to ActiveX Web plugins. They also intended to displace Sun's JAR format for packaging Java software, but this did not succeed.

Overall cabinet file format

Firstly, the overall file format of a Windows CE installation cabinet is the standard Microsoft Cabinet file format. This was originally documented in the Microsoft document CABFMT.DOC as part of the Microsoft Cabinet SDK (CAB-SDK.EXE), it is now documented in the Windows Installer documentation. The format can also be gleaned from open source tools and libraries such as cabextract and libmspack. Windows CE installation cabinets typically use no compression (the NONE compression method in the cabinet specification), sometimes MSZIP compression.

Cabinet file contents

The filenames of the files in the cabinet use the MS-DOS "8.3" convention, where the first eight characters in the filename come from the "true filename", and are followed by a period and three numeric digits. The digits form a decimal number from 000 to 999. The name part before the period is currently always 8 characters (shorter names are padded on the left with "0"), but this shouldn't be relied upon. Only the numeric extension should be used to identify the file. There should not be more than one file in the cabinet with the same numeric extension. As an example:

The order of these files within the cab file is important. The first file in the cabinet should be the ".000" file. It should then be followed by all other files in descending numerical order of their extensions.

These original filenames are not recoverable, they are not stored anywhere. The only names available are the target filenames given in the FILES section of the .000 file.

All installation data is contained in the .000 file. If a .999 file exists, it is an "application specific Setup.DLL"; a Microsoft standard Dynamic Link Library that will be loaded and executed after installation by the installation program. All other files are files for installation on the Windows CE device, and the three digits should be resolved into an integer "file number".

Format of the .000 file

All multi-byte integers are little-endian. Values given in this document are in decimal, unless otherwise specified. The overall file format of the .000 file is as follows:

• A fixed size header at file offset 0.
• The APPNAME string.
• The PROVIDER string.
• The UNSUPPORTED multi string.
• The STRINGS section.
• The DIRS section.
• The FILES section.
• The REGHIVES section.
• The REGKEYS section.
• The LINKS section.

Only the fixed size header has a fixed file offset, all other strings and sections may be at any file offset, in any order. They are typically in the order given above. Each file offset is given in the fixed size header.

The fixed size header

The .000 file begins at file offset 0 with a fixed size header of exactly 100 bytes. The format of this header is as follows:

The APPNAME string

This is a null-terminated ASCII string that gives the name of the packaged application.

The PROVIDER string

This is a null-terminated ASCII string that gives the name of the author or publisher of the packaged application.

The UNSUPPORTED multi string

If this string has more than zero bytes length according to the fixed size header, then this is a sequence of consecutive null terminated ASCII strings. The sequence always terminates with an empty string. Each string is the ASCII name of a Windows CE platform where this software is not supported and will not run. Platforms seen in this sequence include "PALM PC", "HPC", "JORDAN", "PALM PC2" and "POCKETPC".

The STRINGS section

The STRINGS section is a number of common ASCII strings that may be used in the installation data. In other sections, strings from the STRINGS section are referred to by their string ID. The total number of entries in this section is given in the fixed size header. There is no padding between string entries. The format of each STRING entry is as follows:

• 2 bytes: An integer string ID.
• 2 bytes: The length of the string, including the null terminator byte.
• X bytes: the string itself, for the length given above.

As an example, the hexadecimal byte stream 04 00 09 00 53 6F 66 74 77 61 72 65 00 decodes to "ID=4 (04 00), length=9 (09 00), string=Software". The hexadecimal byte stream 05 00 0A 00 4D 69 63 72 6F 73 6F 66 74 00 decodes to "ID=5 (05 00), length=10 (0A 00), string=Microsoft".

The DIRS section

The DIRS section is a list of directory paths used in the installation. In other sections, paths from the DIRS section are referred to by their directory ID. The total number of entries in this section is given in the fixed size header. There is no padding between directory entries. The format of each directory entry is as follows:

• 2 bytes: An integer directory ID.
• 2 bytes: The length of the following directory specification, in bytes.
• X bytes: A directory specification. This is simply an array of 16-bit (2 byte) numbers, where each number is a string ID. The final number is always 0, which terminates the list.

For example, the hexidecimal byte stream 01 00 0A 00 01 00 02 00 03 00 04 00 00 translates "dir ID=1 (01 00), length=10 (0A 00), specification={1, 2, 3, 4}". Assuming string ID 1 is "foo", string ID 2 is "bar", string ID 3 is "baz" and string ID 4 is "quux", the specification translates from {1, 2, 3, 4} to "foo\bar\baz\quux".

The directory specification may begin with a path member of the form "%CEn%", where n is a decimal integer from 1 to 17. This is an abbreviation for one of the CE standard directories, as listed in Appendix B.

The FILES section

The FILES section is a list of files to be installed on the target device. All files in the list should be installed. In other sections, files from the FILES section are referred to by their file ID. The total number of entries in this section is given in the fixed size header. There is no padding between file entries. The format of each file entry is as follows:

• 2 bytes: An integer file ID. The file for installation is the file in the cabinet which has this integer as a three digit file extension.
• 2 bytes: The directory ID for where this file should be installed.
• 2 bytes: Unknown purpose, usually the same as the file ID.
• 4 bytes: File flags. A 32-bit integer. The following bits are known:
  

  Flag	Description
  Bit 31 (0x80000000)	If bit is set, this file is a reference-counting shared file. It is not deleted at uninstall time unless its reference count is 0.
  Bit 30 (0x40000000)	If bit is set, ignore file date (stored in the cabinet file) and always overwrite target (on CE device). Mutually exclusive with bit 29.
  Bit 29 (0x20000000)	If bit is set, do not overwrite target if target is newer. Mutually exclusive with bit 30.
  Bit 28 (0x10000000)	If bit is set, self-register this DLL.
  Bit 10 (0x00000400)	If bit is set, do not copy this file to the target unless the target already exists. Mutually exclusive with bit 4.
  Bit 4 (0x00000010)	If bit is set, do not overwrite target if it already exists. Mutually exclusive with bit 10.
  Bit 1 (0x00000002)	If bit is set, do not skip this file.
  Bit 0 (0x00000001)	If bit is set, warn the user if this file is skipped.

  All other bits are unknown.
• 2 bytes: the length of the installed file's filename, including the null terminator.
• X bytes: the installed file's filename, with the length given above. A null terminated ASCII string.

The REGHIVES section

The REGHIVES section is a list of hives in the Windows Registry. These hives are then used in the REGKEYS section for actual registry entries. In other sections, hives from the REGHIVES section are referred to by their hive ID. The total number of entries in this section is given in the fixed size header. There is no padding between hive entries. The format of each hive entry is as follows:

• 2 bytes: An integer hive ID.
• 2 bytes: The hive root, an integer from 1 to 4:
  1. HKCR: HKEY_CLASSES_ROOT
  2. HKCU: HKEY_CURRENT_USER
  3. HKLM: HKEY_LOCAL_MACHINE
  4. HKU: HKEY_USERS
• 2 bytes: Unknown purpose, usually 0.
• 2 bytes: Length of the registry hive specification to follow, in bytes.
• X bytes: A registry hive specification. This is simply an array of 16-bit (2 byte) numbers, where each number is a string ID. The final number is always 0, which terminates the list.

The REGKEYS section

The REGKEYS is a list of registry entries -- key / data pairs -- to be added to the Windows Registry upon installation. All entries in the list should be added. The total number of entries in this section is given in the fixed size header. There is no padding between entries. The format of each entry is as follows:

• 2 bytes: An integer key ID.
• 2 bytes: The hive ID of the hive to store this entry in.
• 2 bytes: A Boolean value, either 1 if variable substitution should be performed or 0 if not. The entry data should have substrings such as %InstallDir% or one the %CEn% values.
• 4 bytes: The type of entry data, and flags.
  

  Flag	Description
  Bit 16 set, bit 0 set (0x00010001)	This key is of type TYPE_DWORD, a 32-bit integer.
  Bit 16 clear, bit 0 clear (0x00000000)	This key is of type TYPE_SZ, a null terminated ASCII string.
  Bit 16 set, bit 0 clear (0x00010000)	This key is of type TYPE_MULTI_SZ, a list of null terminated ASCII strings.
  Bit 16 clear, bit 0 set (0x00000001)	This key is of type TYPE_BINARY, raw binary data in no particular format.
  Bit 1 (0x00000002)	This is the only known flag, NOCLOBBER. If this bit is set, the registry entry should not be overwritten if it already exists in the registry.

  All other bits are undefined.
• 2 bytes: The length of entry data to follow, in bytes.
• X bytes: Registry entry data. This begins with a null terminated ASCII string, giving the name of the registry key. If the empty string is used here, this is the default key for the given hive. Immediately following the null byte of the string is the data for the registry entry, whose format depends on the entry type given in the flags:
  • TYPE_DWORD: four bytes, giving a single 32-bit integer.
  • TYPE_SZ: a single null terminated ASCII string.
  • TYPE_MULTI_SZ: a sequence of consecutive null terminated ASCII strings. The sequence always terminates with an empty string.
  • TYPE_BINARY: no specific format, just raw data.

The LINKS section

The LINKS section is a list of symbolic links to be made in the standard installation directories, to link to installed directories or files. The total number of links in this section is given in the fixed size header. There is no padding between links. Each link has the following format:

• 2 bytes: An integer link ID.
• 2 bytes: Unknown purpose.
• 2 bytes: The base directory where the link will be stored, either 0 to indicate "%InstallDir%", the default directory where the application is installed, or a number from 1 to 17 to indicate "%CEn%", one of the standard installation directories as defined in Appendix B. The link specification, given below, should be added to this base directory, to get the full name of the link.
• 2 bytes: Integer ID of the file or directory that the link should point to. It is either a file ID, or a directory ID, depending on the link type. If it is a directory ID, the ID 0 can be used to refer to %InstallDir%.
• 2 bytes: The link type. This is 0 if the link target is a directory, or 1 if the link target is a file.
• 2 bytes: The length of the link specification in bytes.
• X bytes: The link specification. This is simply an array of 16-bit (2 byte) numbers, where each number is a string ID. The final number is always 0, which terminates the list.

Appendix A: a list of processor architectures

Appendix B: a list of %CEn% shortcuts

First, for a Handheld PC:

For a Pocket PC version 1.0 or 2.0, as per Handheld PCs, except

For a Pocket PC version 3.0, as for 1.0 or 2.0, except