Windows 95 Swap File Management on Low Disk Space

Windows 95 marked a major architectural shift by replacing the rigid, fixed-size swap files of Windows 3.1 with a fully dynamic virtual memory manager. Rather than requiring users to manually reserve a permanent block of contiguous storage, the operating system dynamically expanded and contracted a single hidden file—WIN386.SWP—in response to application demands. This article explains the technical mechanisms Windows 95 used to allocate virtual memory under tight storage conditions, how it prevented disk exhaustion, and how it handled system limits when physical drive space ran out completely.

The Shift to a Dynamic Swap File

In Windows 95, virtual memory was governed by the 32-bit Virtual Memory Manager (VMM), a core component of VMM32.VXD. Unlike its predecessor, which favored permanent, contiguous swap files for performance reasons, Windows 95 used 32-bit protected-mode file system drivers (VFAT) that made accessing non-contiguous clusters significantly faster.

As applications allocated memory using Win32 or Win16 APIs, the VMM committed physical RAM pages first. When commit requests exceeded physical memory, the VMM created pages on the hard drive by expanding WIN386.SWP. Because it supported fragmented allocation, the file could grow across whatever clusters were free, eliminating the requirement for large, uninterrupted spans of disk real estate.

Swap Expansion and Low Disk Space Detection

The dynamic nature of the swap file created a risk: an aggressive application could consume all remaining disk space, starving both other programs and the file system itself. To balance memory demand against storage limits, Windows 95 employed specific allocation heuristics:

  • Threshold Monitoring: The system constantly tracked the unallocated cluster pool via VFAT. When available drive capacity fell to low margins, the VMM became conservative with expansion, allocating only the minimum number of clusters required to satisfy immediate page-commit demands rather than growing in larger, preemptive blocks.
  • Non-Contiguous Growth: If free space was scattered across a fragmented drive, Windows 95 stitched together disjointed clusters to keep the swap file expanding as long as free sectors existed anywhere on the volume.
  • Contraction Delay (Hysteresis): To prevent disk thrashing—repeatedly allocating and deallocating disk space—the VMM did not immediately shrink WIN386.SWP the moment an application released memory. However, if the drive was critically low on free space, the system reclaimed uncommitted swap pages more aggressively to return storage capacity to the file system.

Failures and Out-of-Memory Handling

When a drive ran completely out of free space, the swap file could no longer grow. Windows 95 handled this limit through a tiered failure process:

  1. System Warning Dialogs: The operating system generated an alert notifying the user that the system was running low on disk space or virtual memory, prompting them to close applications or delete files to free up drive capacity.
  2. Page Commit Refusals: When a program requested additional memory via functions like VirtualAlloc or GlobalAlloc, and no physical RAM or expandable swap space was available, the API call failed, returning an out-of-memory error (ERROR_NOT_ENOUGH_MEMORY or NULL).
  3. Application Termination vs. OS Stability: Well-behaved applications handled allocation failures gracefully by aborting tasks or displaying warning dialogs. Poorly written software often crashed with illegal operation errors (General Protection Faults). Despite individual application crashes, Windows 95 prevented the total collapse of the file system by strictly denying swap file growth beyond the physical boundary of the drive.

User Overrides and Manual Constraints

Because dynamic allocation could occasionally compete with file storage, Windows 95 allowed users to override automated management. Through the System Properties > Performance > Virtual Memory control panel, users could establish manual boundaries:

  • Minimum File Size: Ensured a baseline amount of swap space was reserved at boot, preventing other files from claiming it.
  • Maximum File Size: Placed a hard cap on WIN386.SWP, guaranteeing that the virtual memory system would never expand beyond a specific ceiling, thereby safeguarding remaining free disk space for document storage and application caching.