The block I/O subsystem in Windows 95 improves upon the 32-bit disk access "FastDisk" device architecture used in Windows 3.1 to enhance performance for the entire file system and provides a broader array of device support.
As shown in the preceding diagram, the block I/O subsystem includes the following components.
Input/Output Supervisor (IOS).
This component provides services to file systems and drivers. The IOS is responsible for the queuing of file service requests and for routing the requests to the appropriate file system driver. The I/O Supervisor also provides asynchronous notification of file system events to drivers. This component is described further in the following section.
Port driver.
This is a monolithic, 32-bit, protected-mode driver that communicates with a specific disk device such as a hard disk controller. This driver is Windows 95-specific and resembles the 32-bit disk access driver used in Windows 3.1 (for example, WDCTRL for Western Digital™-compatible hard disk controllers). In Windows 95, the driver that communicates with IDE or ESDI hard disk controllers and floppy disk controllers is implemented as a port driver. A port driver provides the same functionality as the combination of the SCSI manager and the miniport driver.
SCSI layer.
This component applies a 32-bit, protected-mode, universal driver model architecture for communicating with SCSI devices. The SCSI layer provides all the high-level functionality common to SCSI and similar devices, and then uses a miniport driver to handle device-specific I/O calls. The SCSI Manager is also part of this system and provides the compatibility support for using Windows NT miniport drivers.
Miniport driver.
The Windows 95 miniport driver model makes it easier for a hardware disk device vendor to write a device driver. Because the SCSI stub provides the high-level functionality for communicating with SCSI devices, the hardware disk device vendor only needs to create a miniport driver tailored to the vendor's own disk device. The Windows 95 miniport driver is 32-bit protected-mode code, and is binary-compatible with Windows NT miniport drivers. However, older miniport drivers written for Windows NT do not include Plug and Play information and, therefore, will not perform well on Windows 95.
In addition to these other layers, the Block I/O subsystem provides a real-mode mapping layer. This layer provides compatibility with real-mode, MS-DOS – based device drivers for which a protected-mode counterpart does not exist. This layer allows the protected-mode file system to communicate with a real-mode driver as if it were a protected-mode component.
The layers above the Block I/O and the real-mode mapper are protected-mode code, and the real-mode mapper translates file I/O requests from protected mode to real mode, such that the MS-DOS – based device driver can perform the appropriate operation to write or read information to or from the disk device. For example, the real-mode mapper is used when real-mode disk compression software is running and a protected-mode disk compression driver is not available.
Note
Using MS-DOS – based device drivers can be a potential bottleneck because all I/O must be serialized. Also, because all of these VxDs must be page-locked, this increases the working set used by the operating system.
The I/O Supervisor is a required system VxD that carries out all control and management tasks for the protected-mode file system and block device drivers in Windows 95. The I/O Supervisor loads and initializes protected-mode device drivers and provides services needed for I/O operations.
The I/O Supervisor receives requests from VFAT and CDFS file systems and loads the drivers for accessing local disk devices and drives, including SCSI and IDE. It supports WD1003-compatible drivers, takes control of real-mode drivers, and provides a mapper for real-mode drivers.
The real-mode mapper in the I/O Supervisor provides compatibility with real-mode MS-DOS device drivers for which protected-mode counterparts do not exist. For example, the real-mode mapper goes to work when real-mode disk compression software is running and a protected-mode disk compression driver is not available. This component ensures binary compatibility with existing MS-DOS – based disk device drivers in Windows 95.
The I/O Supervisor was first implemented in Windows 3.x as *BLOCKDEV, and in Windows 95 it also provides *BLOCKDEV services for older 32-bit disk access drivers. New responsibilities for the I/O Supervisor include:
Windows 95 loads and initializes the I/O Supervisor as specified in a device= entry in SYSTEM.INI. The I/O Supervisor is initialized before clients and virtual device drivers such as APIX and *INT13, so clients and virtual device drivers can call services in the I/O Supervisor to register and carry out tasks.
To load and initialize port drivers, miniport drivers, and value-added drivers, the I/O Supervisor requires the files for these drivers to be stored in the SYSTEM\IOSUBSYS directory with the following filename extensions.
Filename extension | Description |
PDR | Port drivers, such as SCSIPORT, ESDI_506, and NEC |
MPD | Miniport drivers |
386 or VXD | Value-added drivers, such as the volume tracker and vendor-supplied drivers |
The SYSTEM\IOSUBSYS directory is reserved for device drivers specifically designed to be used with the I/O Supervisor. Other clients or virtual device drivers should be stored in other directories and explicitly loaded using device= entries in SYSTEM.INI.
The I/O Supervisor initializes device drivers (as described in the following sections) from the bottom layer upwards, so port drivers are initialized before vendor-supplied drivers, vendor-supplied drivers before type-specific drivers, and so on. Value-added drivers are initialized in groups, layer by layer, with all drivers in one layer initialized before drivers in the next layer. The initialization order within a layer is not defined, so you cannot depend on the drivers in a group being initialized in a specific order or even that the order remains between startup operations.
For Plug and Play detection, the I/O Supervisor loads a specific port or miniport driver only if Configuration Manager requests that the driver be loaded after hardware detection locates an adapter.