Windows 95 Real-Mode Driver Loading Explained

Windows 95 bridged legacy 16-bit MS-DOS software with a modern 32-bit protected-mode architecture by beginning its boot sequence as an updated MS-DOS environment (version 7.0). During this initial boot phase, the operating system processed CONFIG.SYS in 16-bit real mode to preserve backward compatibility for legacy hardware and software drivers. This article explains how the underlying kernel initialized hardware, parsed configuration directives, managed real-mode memory, and eventually transferred control to the 32-bit Virtual Machine Manager.

The Role of IO.SYS

The boot process began when the system BIOS executed the Master Boot Record, which located the partition boot record and executed IO.SYS. In Windows 95, IO.SYS was a consolidated binary combining the responsibilities of the legacy MS-DOS IO.SYS and MSDOS.SYS (the latter being repurposed into an INI-style text file containing boot flags like BootGUI=1).

Before reading CONFIG.SYS, the Windows 95 IO.SYS automatically loaded a baseline set of system drivers directly into real-mode memory. These built-in defaults included:

  • HIMEM.SYS: Extended memory (XMS) management.
  • IFSHLP.SYS: Installable File System Helper, required for the transition to 32-bit file systems.
  • SETVER.EXE: Program version table management.
  • DBLSPACE.BIN / DRVSPACE.BIN: Disk compression drivers (if present on the drive).

Users could override these automatic behaviors using specific directives in MSDOS.SYS or CONFIG.SYS, but by default, IO.SYS handled these to reduce the user's configuration burden.

Parsing CONFIG.SYS

Once the baseline real-mode kernel was resident, IO.SYS parsed CONFIG.SYS sequentially from top to bottom. It looked specifically for driver-loading directives:

  • DEVICE=: Instructed the kernel to load a specified driver binary into conventional memory (the first 640 KB of address space).
  • DEVICEHIGH=: Instructed the kernel to load the driver into Upper Memory Blocks (UMBs, between 640 KB and 1 MB), provided an expanded/upper memory manager like EMM386.EXE was loaded previously in the file.

When IO.SYS encountered a driver entry (such as an optical drive driver like OAKCDROM.SYS or a legacy sound card driver), it allocated the necessary real-mode memory structure, loaded the executable binary from disk, and invoked the driver's initialization routine via an interrupt call. The driver reported back the memory footprint it required to remain resident (Terminate and Stay Resident, or TSR) and hooked the relevant software and hardware interrupts (such as INT 13h for disk access or INT 21h for DOS services).

Hardware Initialization and State Retention

Because these drivers operated strictly in real mode, they communicated directly with the physical hardware ports and base memory addresses. The driver established its interrupt handlers directly inside the real-mode Interrupt Vector Table (IVT) located at address 0000:0000.

At this stage, Windows 95 operated purely as MS-DOS 7.0. Once CONFIG.SYS completed, the system processed AUTOEXEC.BAT, loading 16-bit TSRs, environment variables, and helper utilities (such as MSCDEX.EXE for CD-ROM extensions).

The Hand-off to Protected Mode

After processing AUTOEXEC.BAT, the system executed WIN.COM to bootstrap the 32-bit environment. WIN.COM loaded the Virtual Machine Manager (VMM32.VXD) and various virtual device drivers (VxDs) specified in the registry and SYSTEM.INI.

At this junction, the real-mode drivers loaded via CONFIG.SYS faced one of two outcomes:

  1. Supersession by 32-bit Protected-Mode VxDs: If a 32-bit protected-mode driver existed for a device (such as a 32-bit IDE/ESDI driver or protected-mode CD-ROM file system driver), Windows 95 disabled or bypassed the real-mode driver. The VxD took over the physical hardware registers and intercepted the interrupt lines, effectively sidelining the 16-bit driver to prevent performance bottlenecks.
  2. Fallback to MS-DOS Compatibility Mode: If no 32-bit VxD existed for the hardware, Windows 95 retained the real-mode driver. Through the Real-Mode Mapper (RMM.D32) and Virtual 8086 (V86) mode, the 32-bit OS transitioned the processor back to real/V86 mode whenever disk or hardware I/O was required. While this maintained universal compatibility with legacy hardware, it resulted in a known performance penalty and triggered the "Compatibility Mode Paging" warning in the Windows 95 Device Manager.