How Windows 3.11 Used FastDisk for 32-Bit Disk Access

Windows 3.11 achieved a major performance breakthrough by introducing 32-Bit Disk Access, a mechanism powered by low-level "FastDisk" virtual device drivers. By bypassing real-mode MS-DOS and standard ROM BIOS routines, FastDisk allowed the operating system to communicate directly with hard disk hardware while keeping the processor in 32-bit protected mode. This architecture dramatically reduced CPU overhead, prevented system-wide execution stalls during storage operations, and laid the groundwork for modern protected-mode storage subsystems in later versions of Windows.

The Real-Mode Bottleneck

Prior to FastDisk, Windows relied on the underlying MS-DOS operating system and PC BIOS to read from and write to hard drives. When an application requested data, Windows had to route the call through MS-DOS (Interrupt 21h), which in turn called the BIOS disk services (Interrupt 13h).

Because the PC BIOS ran in 16-bit real mode, an 80386 or 80486 processor running Windows in 32-bit protected mode was forced to switch execution modes for every single storage operation. Switching between protected mode and real mode was an expensive operation that flushed the processor pipeline and halted multitasking. While the BIOS waited for physical disk platters to spin and heads to move, the entire operating system froze, preventing background tasks from executing.

How FastDisk Bypassed the BIOS

FastDisk solved this bottleneck by replacing the real-mode BIOS interrupt handler with a 32-bit protected-mode Virtual Device Driver (VxD). The default implementation in Windows was *WDCTRL, a driver built into WIN386.EXE designed for Western Digital 1003 and compatible IDE/ST-506 hard drive controllers.

When Windows loaded in 386 Enhanced Mode, FastDisk managed low-level access through a streamlined process:

  1. Interrupt Interception: The driver hooked Interrupt 13h at the protected-mode level. Whenever an application or MS-DOS issued a disk read or write command, the FastDisk driver intercepted the call before it could reach the 16-bit BIOS.
  2. Direct Hardware Control: Instead of executing ROM BIOS firmware, FastDisk directly addressed the IDE controller's hardware registers via I/O ports (typically base address 0x1F0 through 0x1F7).
  3. Protected-Mode Execution: Because the driver code executed entirely in 32-bit protected mode, the CPU never dropped back into real mode to manage standard read/write tasks.
  4. Hardware Interrupt Handling: When the disk controller signaled that data was ready by triggering an IRQ (typically IRQ 14 on primary IDE controllers), the FastDisk driver caught the interrupt in protected mode and transferred the sectors directly into system memory.

Multitasking and Performance Benefits

By managing disk operations entirely within protected mode, FastDisk enabled non-blocking disk input/output. While the hard drive performed physical seeks and data transfers, the CPU was free to switch execution contexts to other running virtual machines or Windows applications. Background processes, such as file downloads, print spooling, or spreadsheet recalculations, could continue uninterrupted while large files were read from disk.

Additionally, FastDisk eliminated the need for Windows to translate protected-mode memory addresses into real-mode conventional memory buffers (double-buffering) for disk transfers, which drastically lowered CPU utilization and improved raw data throughput.

Synergy with 32-Bit File Access in Windows 3.11

While Windows 3.1 introduced FastDisk for disk hardware communication, Windows for Workgroups 3.11 completed the chain by adding 32-Bit File Access (VFAT.386) and a dynamic protected-mode cache (VCACHE.386).

In this combined setup, VFAT intercepted high-level MS-DOS file system calls (Interrupt 21h), VCACHE managed caching in extended memory, and FastDisk translated those requests directly into low-level controller commands. This end-to-end protected-mode pipeline completely eliminated both MS-DOS and the BIOS from the storage path during standard operation.

Compatibility Requirements and Limitations

FastDisk required strict hardware compatibility. Because *WDCTRL spoke directly to standard Western Digital 1003-compatible controller interfaces, it did not work natively with early proprietary SCSI controllers, non-standard ESDI drives, or PCMCIA storage cards without dedicated, third-party VxDs supplied by the hardware manufacturer.

Furthermore, early FastDisk implementations struggled with drives that used proprietary BIOS translation schemes to exceed the 528 megabyte (504 MiB) ATA storage limit. If the controller registers did not strictly match the expected register map, enabling 32-Bit Disk Access could cause system instability or data corruption, leading Windows to include automatic validation checks in the Control Panel before allowing users to permanently enable the feature.