Windows 98 features a layered file system architecture that supports multiple file systems, including the virtual file allocation table (VFAT), CD-ROM file system (CDFS), and UDF.
The new file system architecture makes the computer easier to use and improves file and disk I/O performance. Features of the new file system architecture include long file name support and a dynamic system cache for file and network I/O.
Long file name support improves ease of use because users no longer need to reference files by the MS-DOS 8.3 file name. Instead, users can specify names of up to 255 characters to identify their documents. In addition, file names seem less cryptic and easier to read, because Windows 98 hides the file name extensions from users.
Windows 98 features 32-bit, protected-mode code for reading information from — and writing information to — the file system and the disk device. It also includes 32-bit dynamically sizable caching mechanisms, and a full, 32-bit code path is available from the file system to the disk device. Moreover, it includes an open file system architecture for future system support.
Figure 28.8 shows the file system architecture used by Windows 98.
Figure 28.8 Windows 98 file system architecture
The Windows 98 file system architecture is made up of the following components:
The following sections describe these components.
In Windows 98, the key to access of disk and redirected devices is the Installable File System (IFS) Manager. The IFS Manager arbitrates access to file system devices and other file system device components.
Under MS-DOS and Windows 3.1, INT21 provided access to the file system for reads and writes to a file-storage device. In order to support redirected disk services, such as a network drive, system components such as a network redirector would "hook," or intercept an INT21 function call, so that this redirector could determine whether the INT21 request was intended for it, or for the base file system. Although this "hooking" method allowed multiple device drivers to examine the INT21, some of these add-on components ran improperly, and at times, would not pass on the request for other drivers to examine it.
Another problem with the MS-DOS-based file system was the difficulty in loading multiple network redirectors to provide concurrent access to different network types. Windows for Workgroups provided support for running the Microsoft Windows Network redirector at the same time as an additional network redirector, such as Novell NetWare or Banyan VINES; however, support for running more than two network redirectors at the same time was not provided. In Windows 98, the network redirectors are implemented as file systems under IFS Manager, so an unlimited number of 32-bit redirectors can be used.
With Windows 98, file system drivers are Ring 0 components of the operating system. Windows 98 includes support for all of the following file systems (others can be added by other vendors):
For more information about network redirectors, see Chapter 29, "Windows 98 Network Architecture."
The 32-bit VFAT driver provides a protected-mode code path for manipulating the file system stored on a disk. Because it is reentrant and multithreaded, it provides smoother multitasking performance.
The 32-bit VFAT driver interacts with the block I/O subsystem to provide disk access to more device types than were supported by Windows 3.1. Windows 98 also supports mapping to any installed real-mode disk drivers. The combination of 32-bit file access and 32-bit disk access drivers results in significantly improved disk and file I/O performance.
Benefits of the 32-bit file access driver over MS-DOS-based driver solutions include the following:
Both MS-DOS and Windows 3.1 used 16-bit real-mode code to manipulate the file allocation table (FAT) and to read to and write from the disk. In Windows 3.1, most disk accesses still required the use of MS-DOS routines. This data manipulation required several processor mode-switches, from protected mode, reset to real mode to allow MS-DOS to access the disk, and a switch back to protect mode. The constant activity consumed many clock-cycles, and affected potential file access performance drastically. However, Windows 98 manipulates the disk file system from protected mode, which removes or reduces the need to switch to real mode to write information to the disk through MS-DOS, thus resulting in faster file I/O access.
The 32-bit VFAT works with a 32-bit, protected-mode cache driver (VCACHE). This driver replaces the 16-bit, real-mode SMARTDrive disk cache software provided with MS-DOS and Windows 3.1. The VCACHE driver features better caching algorithms than SMARTDrive, to cache information read from or written to a disk drive. The VCACHE driver also manages the cache pool for the Universal Disk Format File System (UDF) and the 32-bit network redirectors provided with Windows 98.
Another big improvement in VCACHE over SMARTDrive is that the memory pool used for the cache is dynamic and is based on the amount of available free system memory. Users no longer need to allocate a block of memory as a disk cache. The system automatically allocates or deallocates memory used for the cache, based on system use.
For example, as you perform a large number of activities on the network, Windows 98 increases the size of the cache. As network activity decreases and more applications are started, Windows 98 decreases the cache size.
Another improvement made to VCACHE in Windows 98 is the ability of VCACHE and the memory manager to execute applications that are present in the cache, directly out of the cache memory. This is referred to as cache mapping and improves the efficiency of memory utilization.
The 32-bit, protected-mode CDFS implemented in Windows 98 provides improved CD-ROM access and performance over the real-mode MSCDEX driver in Windows 3.1. (CDFS conforms to the ISO 9660 standard.) The CDFS driver cache is also dynamic, requiring no configuration or static allocation on the part of the user. For more information about the CD-ROM cache, see Chapter 26, "Performance Tuning."
Benefits of the new 32-bit CDFS driver include the following:
Note
Because of the 32-bit CDFS, MSCDEX is no longer necessary under Windows 98, and is automatically removed from memory and from Autoexec.bat by Setup. It is possible that a legacy CD-ROM drive, using proprietary access methods might require the use of MSCDEX, along with its real-mode drivers. Such a configuration should still work under Windows 98.
The 32-bit, protected-mode UDF file system in Windows 98 is implemented according to Revision 1.02 of Universal Disk Format Specification by Optical Storage Technology Association (OSTA). It provides read-only access to UDF-formatted media, such as DVD discs. The UDF file system uses VCACHE and is dynamic, requiring no configuration or static allocation on the part of the user.
Figure 28.9 shows the block I/O subsystem in Windows 98. It improves on 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.
Figure 28.9 Block I/O subsystem
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 IOS also provides asynchronous notification of file system events to drivers. This component is described further in "Input/Output Supervisor and Driver Loading" later in this chapter.
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 98 – 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 98, 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, which is also part of this system, provides the compatibility support for using Windows NT miniport drivers.
Miniport driver.
The Windows 98 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 needs only to create a miniport driver tailored to the vendor’s own disk device. The Windows 98 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. Therefore, they will not perform well on Windows 98.
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, so 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 may create a bottleneck, because all I/O must be serialized. Also, because all these VxDs must be page-locked, the working set used by the operating system increases.
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 98. 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 98.
The I/O Supervisor was first implemented in Windows 3.x as BLOCKDEV, and in Windows 98 it also provides BLOCKDEV services for older 32-bit disk access drivers. New responsibilities for the I/O Supervisor include:
Windows 98 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 virtualization drivers, such as APIX and INT 13, so clients and virtualization 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 file name extensions shown in Table 28.3.
Table 28.3 File name extensions for drivers in System\IOSubsys
| File name 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 virtualization 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 on the same order 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.