Windows 95 vs Windows 3.1 Memory Management
The transition from Windows 3.1 to Windows 95 represented a fundamental shift in memory management, moving from a fragile 16-bit cooperative model to a more robust 32-bit preemptive architecture. While Windows 3.1 forced all applications to share a common, segmented memory space where a single fault could crash the entire operating system, Windows 95 introduced flat linear addressing, private virtual memory spaces for 32-bit programs, and dynamic paging, drastically improving system stability and multitasking capability.
16-Bit Segmented vs. 32-Bit Flat Memory Model
Windows 3.1 relied on the x86 architecture's 16-bit segmented memory model. Memory addresses were composed of a selector and an offset, restricting continuous memory blocks to 64 KB segments. Developers had to use complex pointer arithmetic (near, far, and huge pointers) to manage data larger than 64 KB, leading to frequent performance bottlenecks and coding errors.
Windows 95 implemented a 32-bit flat memory model using the paging features of the Intel 80386 processor and newer. Instead of dealing with segments, 32-bit applications addressed a continuous, flat 4 GB virtual address space. This eliminated the 64 KB segment barrier, simplifying memory access and improving execution speed.
Shared Address Space vs. Process Isolation
In Windows 3.1, all running programs and the operating system itself shared a single address space. Because there was no memory protection between applications, a buggy program could write directly to memory owned by another program or the operating system core, triggering fatal General Protection Faults (GPFs) that required a full system reboot.
Windows 95 introduced memory protection for 32-bit applications (Win32). Each Win32 process was assigned its own private 2 GB virtual address space (mapped from 4 MB to 2 GB). One application could not read or overwrite the private memory of another. If a 32-bit application crashed, the operating system terminated only that process, preserving the stability of the rest of the system. However, for backward compatibility, 16-bit Windows 3.1 applications (Win16) still ran within a single, shared address space between 2 GB and 3 GB, meaning unstable 16-bit software could still destabilize other 16-bit tasks.
Virtual Memory and Dynamic Paging
Both operating systems supported virtual memory via swap files, but their implementations differed:
- Windows 3.1: Virtual memory required either a temporary swap file or a contiguous, permanent swap file configured to a fixed size by the user. If the system ran out of swap space, applications simply failed to allocate memory.
- Windows 95: Introduced dynamic virtual memory
management using 4 KB demand-paged memory blocks. Windows 95 dynamically
expanded and shrunk the swap file (
WIN386.SWP) on the fly based on current system demands and available disk space, requiring virtually no manual user configuration.
GDI and USER Resource Heaps
One of the most common issues in Windows 3.1 was the exhaustion of "System Resources," even when megabytes of physical RAM remained free. This occurred because internal graphical user interface components—specifically the Graphics Device Interface (GDI) and USER modules—stored tracking handles, menus, and window objects in fixed 64 KB local heaps.
Windows 95 alleviated these bottlenecks by moving many of the GDI and USER structures into 32-bit heaps capable of holding thousands of elements instead of hundreds. While some structures remained 16-bit for backward compatibility, the limits were increased substantially, largely eliminating the random out-of-memory errors that plagued heavy multitaskers on Windows 3.1.