Windows 3.11 Virtual Memory on Stacker Drives

During the MS-DOS and Windows 3.11 era, third-party disk compression utilities like Stac Electronics' Stacker were widely used to double hard drive capacity. However, Windows 3.11's 386 Enhanced Mode relied heavily on virtual memory swapping, creating an architectural conflict with compressed filesystems. Windows 3.11 managed virtual memory swapping alongside Stacker by either redirecting raw, contiguous permanent swap files to the uncompressed host partition or relying on DOS-level temporary swap files within the compressed drive itself.

Permanent vs. Temporary Swap Files

Windows 3.11 supported two types of swap files: permanent and temporary.

  • Permanent Swap Files (386SPART.PAR): Provided superior performance because Windows bypassed the MS-DOS filesystem entirely. It wrote directly to physical, contiguous disk sectors using low-level disk routines or 32-bit Disk Access (FastDisk).
  • Temporary Swap Files (WIN386.SWP): Handled disk allocation dynamically through standard MS-DOS interrupts (INT 21h), creating and resizing a normal file that did not require contiguous clusters.

Because Stacker stored entire compressed drives inside a single massive Compressed Volume File (CVF) on a physical disk, the cluster addresses presented to the operating system did not map directly to predictable physical sectors. Consequently, Windows 3.11 could not place a permanent swap file directly on a Stacker-compressed drive.

The Host Drive Strategy

The standard and recommended method for configuring virtual memory with Stacker was to place the permanent swap file on the uncompressed "host" drive.

When Stacker initialized at boot, it swapped drive letters so that the compressed volume became drive C: while the physical host partition became drive D: (or another secondary letter). To establish a permanent swap file:

  1. Stacker utilities (such as SDEFRAG) reserved an uncompressed portion of physical space on the host drive.
  2. The user configured Windows 3.11's Virtual Memory Control Panel to target the uncompressed host letter rather than the compressed drive letter.
  3. Windows 3.11 claimed direct, contiguous blocks on the physical drive, enabling optimal swap throughput without interfering with Stacker’s compression engine.

Swapping Directly to the Compressed Drive

If space on the uncompressed host drive was insufficient, users were forced to use a temporary swap file located inside the compressed Stacker filesystem.

Under this configuration:

  • Windows created WIN386.SWP inside the compressed filesystem using standard MS-DOS read and write calls.
  • Stacker intercepted these DOS calls via its device driver (STACKER.COM), compressing the memory pages on the fly and writing the compressed data into the CVF.
  • This approach incurred a noticeable CPU overhead, as the processor had to compress virtual memory pages upon swapping out and decompress them upon swapping in.
  • 32-bit Disk Access could not be enabled for the swap file, forcing Windows to drop into real-mode DOS to execute swap reads and writes.

Driver Integration and VxDs

As Stacker evolved to versions 3.0 and 4.0, Stac Electronics developed dedicated Windows 386 Enhanced Mode virtual device drivers (VxDs), such as STACVOL.VXD and custom FastDisk-compatible components. These drivers integrated directly into the SYSTEM.INI configuration.

By running alongside Windows 3.11's memory manager, Stacker's VxDs eliminated the risk of data corruption, notified the user if swap settings conflicted with compressed drives, and coordinated low-level I/O to ensure stable virtual memory operation.