How Windows 3.11 Used 32-Bit File Access Drivers

Microsoft Windows for Workgroups 3.11 dramatically improved operating system performance and stability by replacing real-mode MS-DOS disk and file routines with 32-bit protected-mode drivers. By introducing 32-bit File Access, Windows 3.11 implemented an Installable File System Manager (IFSMGR.386) and a 32-bit FAT driver (VFAT.386) that hooked DOS interrupts directly in protected mode. This architecture prevented the CPU from constantly dropping back to 16-bit real mode for input/output operations, establishing a layered, 32-bit virtual device driver (VxD) pipeline from application requests down to physical storage hardware.

The Problem with 16-Bit Real-Mode I/O

Prior to Windows for Workgroups 3.11, Windows operated as an environment on top of 16-bit MS-DOS. Even though Windows 3.1 could run in 386 Enhanced Mode—which utilized the 32-bit protected mode of Intel 80386 and 80486 processors—every file system request required an expensive context switch.

When a program requested file access via Interrupt 21h (the MS-DOS API), the CPU had to switch from protected mode to Virtual 8086 (V86) mode or real mode. MS-DOS processed the file structures and issued Interrupt 13h BIOS calls to access disk sectors, which executed in real mode before switching back to protected mode. Windows 3.1 introduced 32-bit Disk Access (FastDisk or WDCTRL.386), which intercepted Interrupt 13h calls to talk directly to Western Digital-compatible IDE controllers. However, this only solved the bottom half of the pipeline; the top half (file allocation, directory parsing, and file handle management) still required dropping to 16-bit DOS via Interrupt 21h.

The 32-Bit File Access Architecture

Windows for Workgroups 3.11 solved this performance bottleneck by introducing 32-bit File Access (32BFA). This subsystem replaced the core file-handling duties of MS-DOS using a stack of Ring 0 protected-mode Virtual Device Drivers (VxDs):

  1. Installable File System Manager (IFSMGR.386): The entry point that managed file system requests and routed them to appropriate file system drivers.
  2. Virtual FAT (VFAT.386): A fully 32-bit implementation of the FAT16 file system running entirely in protected mode.
  3. Virtual Cache (VCACHE.386): A dynamic, 32-bit disk caching driver that replaced the 16-bit real-mode SMARTDRV.EXE.
  4. Block Device Driver (*BLOCKDEV): An interface coordinating I/O between the file system driver and the physical disk controller drivers (such as INT13.386 or WDCTRL.386).

Hooking the File System

The primary mechanism for managing these drivers was protected-mode interrupt hooking. During startup in 386 Enhanced Mode, IFSMGR.386 hooked Interrupt 21h at the processor level using the Interrupt Descriptor Table (IDT).

When a 16-bit Windows application, Win32s application, or DOS prompt running inside Windows issued an INT 21h call to open, read, write, or close a file, the CPU did not transition to V86 mode. Instead, IFSMGR.386 intercepted the vector immediately within Ring 0.

IFSMGR.386 evaluated the target path and file request:

  • If the request targeted a standard FAT volume and 32-bit File Access was enabled, IFSMGR.386 directed the call to VFAT.386.
  • VFAT.386 parsed the File Allocation Table, clusters, and directory records in 32-bit protected memory.
  • If the requested sectors were present in cache, VCACHE.386 fulfilled the request immediately.
  • If the data required reading from disk, VFAT.386 converted the file request into sector-level block requests and sent them directly to *BLOCKDEV.
  • *BLOCKDEV forwarded the requests to the 32-bit disk controller driver (WDCTRL.386), which executed hardware I/O instructions (IN/OUT) directly to the IDE controller.

Through this chain of hooks, file operations completed entirely in 32-bit protected mode without executing a single instruction of MS-DOS code.

Managing Compatibility and Real-Mode Fallbacks

Because Windows 3.11 still shared host machines with real-mode software, its 32-bit hooks had to accommodate legacy drivers and Terminate-and-Stay-Resident (TSR) programs.

During initialization, Windows inspected the Interrupt 21h and Interrupt 13h interrupt chains. If an unsupported real-mode driver (such as third-party disk compression, non-standard SCSI drivers, or security software) hooked INT 21h or INT 13h prior to Windows loading, Windows 3.11 could not safely bypass the real-mode stack. In those cases, IFSMGR.386 disabled 32-bit File Access and routed calls down through the V86 mode reflect hooks to the original MS-DOS and BIOS routines.

When compatible drivers were present, Windows for Workgroups 3.11 successfully decoupled disk operations from MS-DOS, setting the architectural foundation for the fully integrated 32-bit VFAT and IFS manager that later defined Windows 95.