Windows 98 Memory Management for Heavy Applications

Microsoft Windows 98 handled memory overhead under heavy workloads through a hybrid 16-bit/32-bit architecture centered on the Virtual Memory Manager, dynamic paging, and dynamic disk caching. While the operating system provided a 4 GB virtual address space and flexible swap file sizing to prevent immediate crashes during heavy application use, it also faced systemic bottlenecks due to legacy 16-bit resource heaps and unconstrained disk cache behavior.

The Virtual Memory Manager and Paging

Windows 98 utilized a 32-bit Virtual Memory Manager (VMM) operating at Ring 0 of the CPU architecture. The VMM divided memory into uniform 4-kilobyte blocks known as pages.

Each 32-bit application was assigned its own flat, private 4 GB virtual address space. This address space was bifurcated:

  • Lower 2 GB (0x00000000 to 0x7FFFFFFF): Dedicated to the private process space, where the application code, data, and heap resided.
  • Upper 2 GB (0x80000000 to 0xFFFFFFFF): Reserved for shared system components, Ring 0 core services, Virtual Device Drivers (VxDs), and legacy 16-bit modules.

When a resource-heavy application requested more memory than physically available in RAM, the VMM utilized demand paging. Inactive 4 KB pages were swapped out of physical memory and committed to the hard drive, freeing physical RAM for the active application’s working set.

Dynamic Swap File Sizing (WIN386.SWP)

Unlike Windows 3.x, which often required a permanent, fixed-size swap file, Windows 98 featured dynamic paging file management. The swap file, named WIN386.SWP, expanded and contracted automatically on the storage drive based on the real-time demands of running applications and available disk space.

When an intensive application loaded large datasets (such as high-resolution image editing or complex 3D gaming), the VMM expanded WIN386.SWP sequentially to prevent out-of-memory faults. However, dynamic resizing introduced latency: the CPU had to interrupt program execution to allocate new disk clusters and update the file allocation table (FAT), often resulting in severe disk thrashing when physical RAM was low.

Disk Caching with VCACHE

To accelerate input/output operations, Windows 98 included a 32-bit protected-mode caching driver called VCACHE. VCACHE replaced the legacy DOS SMARTDrive utility and dynamically adjusted the amount of RAM reserved for caching file read/write operations from the disk.

Under resource-heavy workloads, VCACHE frequently created overhead issues rather than solving them. VCACHE was designed to aggressively claim unallocated physical RAM to cache file data. When an intensive program suddenly required large blocks of memory, VCACHE did not always release memory fast enough. Consequently, the VMM was forced to push the application's active working pages into the swap file instead of purging the disk cache, causing severe system slowdowns. Users and administrators frequently mitigated this by manually configuring MinFileCache and MaxFileCache limits inside the SYSTEM.INI configuration file.

The 16-Bit System Heap Bottleneck

The primary structural limitation of Windows 98 when managing heavy workloads was not the total physical RAM, but the architecture of the USER and GDI (Graphics Device Interface) heaps.

To maintain backward compatibility with 16-bit Windows 3.1 software, Windows 98 retained several critical 64 KB memory heaps:

  • GDI Heap: Stored graphical resources such as fonts, bitmaps, brushes, and device contexts.
  • USER Heap: Stored window handles, menus, dialog boxes, and user interface controls.

Even if a system had 256 MB or 512 MB of physical RAM and a multi-gigabyte swap file, heavy applications that generated thousands of UI components or graphical elements could easily exhaust these 64 KB heaps. Once either heap reached 100% capacity, Windows 98 would return "Out of Memory" errors or lock up entirely, regardless of how much free physical RAM or virtual swap space remained unallocated.

Page Discarding and Code Execution

To optimize overhead, Windows 98 differentiated between "dirty" pages and "clean" (discardable) pages:

  • Data Pages (Dirty): Memory containing modified user data had to be explicitly written to WIN386.SWP before the physical RAM page could be reassigned.
  • Code Pages (Clean): Executable code pages loaded directly from an application's .EXE or .DLL files were designated as discardable. If physical RAM was constrained, the VMM simply discarded these code pages without writing them to the swap file. When the application needed to execute that segment of code again, the VMM fetched it directly from the original executable file on the disk.