Windows 3.11 Swap Files on Compressed Drives

During the MS-DOS and Windows 3.11 era, disk compression utilities like DoubleSpace, DriveSpace, and Stacker were widely used to maximize limited hard drive capacity, but they presented a fundamental conflict with virtual memory management. Windows 3.11 relied on swap files to simulate additional RAM, yet its highest-performing virtual memory mechanisms bypassed the operating system to talk directly to hardware. Because compressed volumes dynamically altered data and sector locations, Windows 3.11 could not place high-performance permanent swap files directly on a compressed drive, requiring specific workarounds involving uncompressed host partitions or slower temporary files.

To manage virtual memory, Windows 3.11 offered two types of swap files: temporary and permanent. A temporary swap file (WIN386.SWP) was created when Windows started and deleted upon exit. It used standard MS-DOS file system calls (INT 21h) to read and write data. Because it relied on DOS, a temporary swap file could safely reside inside a compressed volume. However, routing virtual memory operations through DOS introduced severe performance bottlenecks.

A permanent swap file (386SPART.PAR) provided significantly better performance. It required a completely contiguous block of physical disk space and bypassed DOS entirely using 32-Bit Disk Access (FastDisk), communicating directly with the Western Digital–compatible hard disk controller.

Software compression utilities worked by creating a single, massive file on a physical drive—known as a Compressed Volume File (CVF)—which was then mounted as a separate virtual drive letter. Inside this volume, data was compressed and allocated dynamically. This architecture broke the requirements of a permanent swap file in two ways: sectors were not physically contiguous on the actual drive platters, and direct controller access could not be used without corrupting the compression mapping table managed by the compression driver.

Windows 3.11 managed this incompatibility through detection and redirection via the Virtual Memory settings in the Control Panel:

1. Volume Detection: When configuring virtual memory, Windows 3.11 inspected the target drive. If it detected that the drive letter corresponded to a compressed volume (such as a DoubleSpace or Stacker drive), it explicitly blocked the creation of a permanent swap file on that drive letter.
2. Host Drive Allocation: To use a permanent swap file with a compressed drive setup, users were required to place the file on the uncompressed "host" drive. When a drive was compressed, the software typically left a small portion of the physical disk uncompressed (often designated letters like H:) to store system boot files and the CVF itself. Users had to ensure this host drive had sufficient free, uncompressed, contiguous space reserved specifically for 386SPART.PAR.
3. Fallback to Temporary Swap: If the host drive lacked adequate space or if the user chose to keep all space allocated to the compressed drive, Windows 3.11 forced the use of a temporary swap file located on the compressed volume. While functional, 32-Bit Disk Access was disabled for the swap file, trading system performance for storage efficiency.