How MS-DOS 6.22 EXPAND Unpacks Installation Files

This article provides an overview of how the MS-DOS 6.22 EXPAND.EXE utility unpacks compressed system files from original distribution media. It covers the underlying SZDD compression scheme, the structure of compressed file headers, the mechanics of the sliding-window decompression algorithm, and the process the utility uses to restore truncated filenames to their original, usable states.

File Identification and the Naming Convention

During the creation of MS-DOS 6.22 installation disks, files were packed to save space on standard 1.44 MB floppy disks. Microsoft denoted these compressed archives by replacing the final character of a file extension with an underscore (for example, KERNEL.SY_, COMMAND.CO_, or FORMAT.CO_). When a user or the SETUP.EXE program ran EXPAND.EXE, the utility analyzed the compressed source file, decompressed its payload, and reconstructed the original file extension.

The SZDD Archive Format

Files packed for MS-DOS 6.22 typically utilize Microsoft’s proprietary SZDD format, which predated the multi-file Cabinet (.CAB) architecture introduced broadly in Windows 95. An SZDD file begins with a fixed 14-byte header containing essential metadata required by EXPAND.EXE:

  1. Magic Bytes: The first 4 bytes contain the file signature 0x88 0xF0 0x27 0x33 (often represented by the ASCII characters SZDD).
  2. Compression Type: A byte defining the compression algorithm used (character A or 0x41, representing standard Lempel-Ziv variants).
  3. Missing Character: A byte storing the original last character of the file extension (e.g., M for an input file named FILENAME.CO_).
  4. File Sizes: 32-bit little-endian integers indicating the uncompressed size of the target file.

When EXPAND executes, it reads this header first. If the file lacks the SZDD signature, the utility assumes the file is uncompressed and performs a direct binary copy to the destination.

The Decompression Algorithm

The core decompression mechanism in EXPAND is a custom variant of the LZ77 (Lempel-Ziv 1977) lossless data compression algorithm.

  • Ring Buffer: The utility maintains a sliding window buffer, typically 4,096 bytes (4 KB) in size, initialized with empty space characters (0x20).
  • Bitstream Parsing: The decompressor reads the input data as a stream of control flags and symbols. A control byte provides 8 individual 1-bit flags determining how subsequent data should be processed:
    • Literal Flag (1): The next byte in the stream is read directly and written to both the output file and the sliding ring buffer.
    • Match Flag (0): The decompressor reads an offset and a length (packed together in two bytes). The offset references previously decompressed data inside the 4 KB ring buffer, and the length defines how many bytes to duplicate.
  • Stream Termination: The algorithm continuously tracks the number of bytes written to disk against the uncompressed size declared in the SZDD header. Once the exact target byte count is reached, decompression stops.

Execution and File Restoration

At the command prompt, the utility is called using the following syntax:

EXPAND A:\COMMAND.CO_ C:\DOS\COMMAND.COM

If the destination parameter does not include a target filename, EXPAND inspects the byte at offset 0x08 of the header to restore the truncated extension automatically. The utility creates the destination file, writes the decompressed byte stream into place, verifies that the final size matches the header specification, closes the file handle, and terminates.