How Windows 95 Handled 32-Bit Floppy Disk I/O

Windows 95 modernized disk operations by replacing traditional 16-bit real-mode MS-DOS and BIOS routines with a modular, 32-bit protected-mode storage subsystem. This article details how Windows 95 processed floppy drive access requests through its layered disk architecture, following the execution path from high-level API calls through the Installable File System Manager, the I/O Supervisor, and down to the hardware-level floppy port driver.

The Storage Subsystem Hierarchy

To bypass the overhead and instability of dropping into 16-bit real mode via ROM BIOS interrupt INT 13h, Windows 95 employed a layered architecture for handling disk requests. The floppy drive subsystem consisted of several core components operating in protected mode:

  1. Installable File System (IFS) Manager (IFSMGR.SYS): Intercepted all file and disk access requests originating from Win32, Win16, or virtual MS-DOS applications.
  2. File System Driver (VFAT.386): The 32-bit Virtual FAT driver that interpreted directory structures, file allocation tables, and cluster mappings for FAT12 filesystems commonly used on standard 3.5-inch and 5.25-inch floppy disks.
  3. I/O Supervisor (IOS.386): The central control layer responsible for queuing requests, tracking physical devices, allocating memory buffers, and dispatching tasks to device drivers.
  4. Port Driver (HSFLOP.PDR): The High-Speed Floppy Port Driver, a 32-bit flat-model device driver designed specifically to interface directly with standard PC floppy disk controllers (FDCs).

Step-by-Step Request Processing

When an application initiated a read or write operation to a floppy drive (typically A: or B:), the request traversed the operating system through the following sequence:

1. Request Interception and File Mapping

The application executed an I/O function, such as a Win32 ReadFile call or an INT 21h MS-DOS interrupt. The IFS Manager intercepted this call, determined the target drive letter, and routed it to VFAT.386. VFAT translated the logical file path into raw sector coordinates (cylinder, head, and sector) based on the disk's FAT12 layout.

2. IOP Generation in the I/O Supervisor

Once the target logical block addresses were determined, VFAT passed the request down to IOS.386. The I/O Supervisor packaged the operation into an internal structure known as an I/O Request Packet (IOP). This packet contained all necessary parameters, including the target drive ID, transfer direction (read/write), buffer pointers, and sector offsets.

3. Execution via the Floppy Port Driver

IOS.386 evaluated its registry of disk drivers and directed the IOP to HSFLOP.PDR. Because the standard PC architecture utilized a uniform NEC µPD765-compatible controller, HSFLOP.PDR handled the physical hardware interaction directly:

  • Motor Control: It toggled the Digital Output Register (DOR) at I/O port 0x3F2 to spin up the floppy drive motor and select the drive.
  • DMA Setup: It configured Direct Memory Access (DMA) Channel 2 to transfer data between system RAM and the controller without consuming continuous CPU cycles.
  • Command Dispatch: It sent seek, read, or write command bytes directly to the Floppy Disk Controller data register at port 0x3F5.

4. Hardware Servicing and Completion

When the physical disk read or write completed, the controller raised Interrupt Request 6 (IRQ 6). Windows 95 intercepted IRQ 6 within protected mode. HSFLOP.PDR inspected the controller's status registers, verified that no CRC or track errors occurred, and flagged the transfer as successful.

The driver then signaled IOS.386, which released the DMA buffers, marked the IOP as complete, and returned control up through VFAT.386 and IFSMGR.SYS to deliver the data to the calling application.

Real-Mode Fallback Handling

If a computer utilized a non-standard floppy controller, or if an incompatible real-mode device driver or TSR was loaded in CONFIG.SYS or AUTOEXEC.BAT, Windows 95 could not safely use HSFLOP.PDR. In these scenarios, the I/O Supervisor bypassed the 32-bit port driver and routed the IOP to the Real-Mode Mapper (RMM.PDR). The system then temporarily switched the processor from protected mode to Virtual 8086 mode to execute standard BIOS INT 13h interrupts, ensuring compatibility at the expense of transfer speed and multitasking performance.