Retro Computing: Windows 95 faced the challenging task of maintaining compatibility with 16-bit DOS software, 16-bit Windows 3.x programs, and newer 32-bit Win32 applications. Microsoft developers leveraged this complex architecture to include hidden optimizations that could make the OS restart faster, although the system would occasionally crash as a result.
Raymond Chen recently shared another interesting tidbit about the inner workings of Windows 95. The original 32-bit consumer operating system had a "secret" fast-restart feature, which users could activate by holding the Shift key while restarting through the OS GUI. If everything worked as intended, the system would restore a working desktop slightly faster than usual.
According to the Microsoft veteran, the fast-restart process relied on the EW_RESTARTWINDOWS flag passed to the 16-bit ExitWindows function. Windows 95 inherited this function from Windows 3.1, as documented in Microsoft's official resources. Chen explained that the function triggered a chain of events: it shut down the 16-bit Windows kernel, then the 32-bit virtual memory manager, and finally returned the CPU to real mode.
Real mode is the basic operating mode of all x86-compatible CPUs, including modern multi-core Intel and AMD processors. Windows 95 and other 32-bit operating systems switch 32-bit-compatible CPUs from real mode to protected mode, which adds memory management and security features. Modern 64-bit operating systems operate in long mode, enabling access to 64-bit CPU instructions and registers.
Intel once tried – and ultimately failed – to eliminate 16-bit real mode and other backward-compatibility features with the now-defunct x86S ISA. According to Chen, once the ExitWindows function puts the CPU in real mode, control returns to the win.com executable. This will then attempt to restart Windows 95 without going through the complex hardware checks required during a cold boot.
The fast-restart feature was likely useful in many scenarios, especially during an era when computers needed several minutes to start up complex, GUI-based operating systems. I had completely forgotten about this functionality, having jumped from MS-DOS straight to Windows ME and XP on a "powerful" Pentium 4 system.
I tried to replicate the fast-reboot process on my PCem virtual machines, with mixed results. The feature didn't work at all on Windows 95 OSR 2.5, but it worked as expected on Windows 98 SE.
Chen explained that the win.com program was written in Assembly and designed to perform additional memory management tasks. Specifically, it attempted to release all available conventional memory so that a single, large contiguous block could be reserved for loading Windows 95 in protected mode. If this procedure failed for any reason, conventional memory would remain fragmented, and win.com would have to fall back to a full reboot. Such was the messy and fascinating nature of the Win9x beast.