Chapter 28 - Windows 98 Architecture
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
This chapter provides a brief review of the Microsoft Windows 98 architecture to help you understand how the key operating system components function and interrelate.
- For more information about the Win32 Driver Model (WDM) and hardware device classes, see Chapter 30, "Hardware Management."
Overview of Windows 98 Architecture Components
Microsoft Windows 98 is a 32-bit operating system that provides built-in Internet connectivity, Plug and Play hardware support, high performance, robustness, and backward compatibility with Windows 95. Windows 98 enhancements to Windows 95 include more sophisticated power management, multiple video display support, and integrated support for the latest hardware. Also included is support for the new Win32 Driver Model (WDM), allowing a WDM device to run under both Windows 98 and future versions of Windows NT using the same driver.
These features are supported by the components shown in Figure 28.1.
Figure 28.1 Windows 98 components
Like Windows 95, Windows 98 is derived from the Windows 3.1 platform and includes the following features:
A complete 32-bit kernel, including memory management, and preemptive multitasking and multithreading support.
A fully integrated 32-bit, protected-mode file system, which eliminates the need to rely on a separate copy of MS-DOS once the system boots up.
32-bit installable file system drivers supporting FAT, FAT32, ISO 9660 (CD-ROM), ISO 13346 (Universal Disk Format/Digital Video Disc [UDF/DVD]), network redirection, and high performance. These file system drivers also support the use of long file names and an open, modular architecture to handle future expansion.
WDM support, which allows a WDM-supported device to run under both Windows 98 and future versions of Windows NT using the same driver.
Improved system-wide robustness and "cleanup" after an application or driver fails. This delivers a more stable and reliable operating environment.
A dynamic hardware and environment configuration, which reduces the need for users to adjust and restart their systems manually.
This chapter describes the key components that make up the Windows 98 architecture, beginning with its central information store, the registry, and proceeding from bottom to top.
Windows 98 Registry
The central information database for Windows 98 is called the registry. This hierarchical database both simplifies the operating system and makes it more adaptable. The registry simplifies the operating system by eliminating the need for Autoexec.bat, Config.sys, and INI files, however, Windows 98 still supports the use of these files when legacy applications require them. It makes the operating system more adaptable by storing user-specific and configuration-specific information so you can share one computer among multiple users and have more than one configuration (such as in-the-office and on-the-road configurations) for each computer.
A primary role of the registry in Windows 98 is to serve as a central repository for hardware-specific information for use by the hardware detection and Plug and Play system components. Windows 98 maintains information about hardware components and devices that have been identified through an enumeration or detection process, in the hierarchical structure of the registry, as described in "Configuration Manager" later in this chapter. When a new device is installed, the system checks for an existing configuration in the registry. If none is found, Windows 98 then searches all available media for the driver that best matches the device. Once the driver is found, it is added to the registry alongside the settings for the device.
Improvement over INI Files
Earlier versions of Windows* *used initialization (INI) files to store system-specific or application-specific information on the state or configuration of the system. For example, the Win.ini file stored information about the appearance of the Windows environment, the System.ini file stored system-specific information on the hardware and device driver configuration of the system, and various INI files (such as Msmail.ini and Winword6.ini) stored application-specific information.
The registry alleviates the issues of dealing with multiple INI files by providing a single location for the computer's configuration information. Table 28.1 illustrates other issues or limitations using multiple INI files, along with the solutions that are provided by using the registry.
Table 28.1 Registry solutions for problems with INI files
INI files are text-based, limited to 64 KB in total size.
The registry has no size restriction and can include both binary and text values.
Information stored in INI files is nonhierarchical and supports only two levels of information.
The registry is hierarchically arranged.
Many INI files contain a myriad of switches and entries that are complicated to configure or are used only by operating system components.
The registry contains more standardized values.
INI files provide no mechanism for storing user-specific information, thus making it difficult for multiple users to share a single computer or for users who move around on the network to have access to their user-specific settings.
The HKEY_USERS key stores user-specific information.
Configuration information in INI files is local to each system, and no API mechanisms are available for remotely managing configuration, thus making it difficult to manage multiple computers.
The registry can be remotely administered, and system policies (stored as registry values) can be downloaded from a central server each time a new user logs on. For more information, see Chapter 7, "User Profiles," Chapter 8, "System Policies," and Chapter 23, "System and Remote Administration Tools."
When you upgrade from Windows 3.1 to Windows 98, system-specific information, such as the references to the loading of static virtualization drivers (VxDs), is moved (as appropriate) from the System.ini file to the registry.
For backward compatibility, Windows 98 supports the Autoexec.bat, Config.sys, and INI files, because many Win16-based applications still use them. For example, Windows 98 allows Win16-based applications to use INI files for their program settings, parameters, device drivers, and so on that the applications need to run. In addition, Windows 98 continues to scan the [386Enh] section of System.ini at startup to check for virtualization drivers to ensure that they are loaded.
Network Access to Registry Information
One advantage of the registry for Win32-based applications is that many of the Win32-based registry APIs can be used remotely through the remote procedure call (RPC) mechanism in Windows 98 to provide access to registry information across a network. This means that network administrators can use system management tools to access the contents of the registry for any computer on the network. (Of course, the remote computer must be configured to allow remote administration and must have user-level security.)
With Windows 98 remote administration, such industry management mechanisms as Simple Network Management Protocol (SNMP) can easily be integrated into Windows 98, lightening the network administrator's management and support burden. For more information, see Chapter 23, "System and Remote Administration Tools."
Windows Management Infrastructure
The Windows Management Infrastructure collects a wealth of information about the entire system as well as device configuration. This information is stored in the registry and made available through extensions to the registry API. This software is the foundation of Microsoft's support for Desktop Management Interface (DMI) and will provide device and system information to OLE Management Services (OLE MS) and Simple Network Management Protocol (SNMP) in the future.
For more information about the registry, see Chapter 31, "Windows 98 Registry."
Understanding Device Drivers
Windows 98 provides improved support for hardware devices, including disk devices, display adapters, pointing devices, modems, fax machines, and printers.
In Windows 3.1, device drivers were, for the most part, monolithic and complex to develop. In this case, monolithic means that the driver had to provide all services, user interfaces, API functions, and hardware-access services to operate under Windows 3.1. Starting with Windows 95, and continuing with Windows 98, we provide a universal driver/minidriver architecture that makes driver development easier for hardware vendors. By having the operating system provide basic device services for a given hardware class natively, the vendor is required to provide only device-specific code for their particular hardware. In addition, Windows 98 uses the WDM architecture, which provides a common set of I/O services understood by both Windows 98 and future versions of Windows NT. With WDM, developers can write a single device driver for both operating systems.
The Universal Driver
A universal driver includes most of the code necessary for devices of a particular class (such as printers or modems) to communicate with the appropriate operating system components (such as the printing or communications subsystems). A minidriver is the relatively small and simple driver that contains any additional instructions needed by a specific device. In many cases, however, the universal driver for a particular category of devices also includes the code needed to operate devices designed to the most common standard for that category. (For example, the Unimodem driver works with all modems supporting AT commands.) The universal driver architecture is shown in Figure 28.2.
Figure 28.2 Universal driver architecture
The Virtualization Driver
A virtualization driver (VxD) is a 32-bit, protected-mode driver that manages a system resource, such as a hardware device or installed software, so that more than one application can use the resource at the same time. VxD refers to a general virtualization driver; the x represents the type of device driver. For example, a virtualization driver for a display device is known as a VDD, a virtualization driver for a timer device is a VTD, a virtualization driver for a printer device is a VPD, and so forth.
Windows 98 dynamically loads VxDs —albeit only those that are needed at any given time are loaded into memory. In addition, the new VxDs do not require all of their memory to be page-locked, thereby further increasing the available memory in the system.
VxDs support all hardware devices for a typical computer, including disk controllers, serial and parallel ports, keyboard and display devices, and so on.
While the VxDs dynamically support device drivers, the virtual device keeps track of the status of the device for any application that uses the specific device. Within the Windows 98 environment the ability to switch between multiple applications is commonplace. Each application being used can interrupt the use of a device being used by another open application. Because this interruption can lead to problems with the use of an application trying to access the device, the virtual device checks and manages the state of the device for applications. Furthermore, the virtual device ensures that the device is in the correct mode of operation whenever an application continues. Although most virtual devices manage hardware, some, such as an MS-DOS device driver or a TSR program, manage only installed software. Such virtual devices contain code to emulate the software or ensure that the software uses data that applies only to the currently running application. Also, VxDs are often used to improve software performance.
Note Windows 98 and Windows 95 virtualization driver files have a file name extension of .vxd; Windows 3.1 drivers used the .386 file name extension.
Win32 Driver Model Drivers
A Win32 Driver Model (WDM) driver can run under Windows 98 and future versions of Windows NT. WDM uses a layered architecture in which each layer isolates portions of the services required of a device driver. This design also allows hardware vendors to contain all hardware-specific functionality in a single file. Before WDM, device drivers had to include hooks for a particular operating system in addition to the elements necessary to interact with a specific piece of hardware. This nonlayered approach prevented device drivers from being supported across multiple operating systems.
The WDM layered architecture is shown in Figure 28.3.
Figure 28.3 WDM layered architecture
The components of the WDM layered architecture are defined in the following sections.
Device Class Drivers
Device class drivers provide interfaces between different layers of the WDM architecture. The lower layer of a device class driver communicates with the class-specific interface exposed by a device minidriver. The upper edge of the device class driver is specific to the operating system. Device class drivers have the following attributes:
They contain class functions (such as enumeration) not specific to hardware or buses.
They are dynamically loaded and unloaded.
They expose a single class-specific interface to multiple-client layers.
An example of a device class driver is Hidclass.sys. This is the generic layer for such input devices as keyboards, mouse devices, and joysticks.
For more information about device drivers, see Chapter 30, "Hardware Management."
Bus Class Drivers
Bus class drivers perform the same function as device class drivers but facilitate the communication between the hardware layer and bus minidrivers. Under Windows 98, WDM supports bus class drivers for the Universal Serial Bus (USB) and the IEEE 1394 bus. An example of a bus class driver is Usbd.sys, for the USB.
For more information about bus drivers, see Chapter 30, "Hardware Management."
Minidrivers were implemented under Windows 95 in the classes of small computer system interface (SCSI) and network adapters. With Windows 98, the concept of minidrivers has been widened to include support for USB, the IEEE 1394 bus, digital audio, DVD players, still imaging, and video capture. Minidrivers either communicate directly with hardware or form the "glue" between two class drivers.
Hardware minidrivers have the following attributes:
They are source-compatible and binary-compatible across platforms, allowing the minidriver to be used in Windows 98 as well as Windows NT.
They are dynamically loaded and unloaded.
They contain only hardware-specific functionality.
They can expose multiple class interfaces. This functionality is very important in respect to multifunction (or composite) cards. Audio and video hardware are typical examples of multifunction devices.
Minidrivers that connect class drivers have the following attributes:
They are source-compatible and binary-compatible across platforms, allowing the minidriver to be used in Windows 98 as well as future versions of Windows NT.
They are dynamically loaded and unloaded.
They indirectly control hardware through a specific bus class driver.
An example of a "bridging" minidriver is Hidusb.sys. This Human Interface Device (HID) class minidriver translates HID I/O into request packets that are understood by the USB class driver (Usbd.sys).
For more information about HID, see "Human Interface Device Drivers" later in this chapter and Chapter 30, "Hardware Management."
Legacy Virtualization Drivers
Though non-portable, virtualization drivers occasionally have a place in the WDM layer, Windows 98 virtualization drivers can allow legacy hardware interfaces to be used with WDM devices. For example, an MS-DOS-based game running on an MS-DOS virtual machine (VM) under Windows 98 might attempt to read a joystick's position by directly accessing the I/O ports associated with the legacy game port controller. The virtualization driver for HID joystick support would trap these requests and redirect them into the HID class driver. Another use for a VxD is to act as a "mapper" between the Windows 98 VxD architecture and the WDM architecture. For example, Joyhid.vxd forwards HID class driver information on to Vjoyd.vxd. For a detailed example of VxDs in the WDM stack, see "Human Interface Device Drivers" later in this chapter.
For more information about virtualization drivers, see "The Virtualization Driver" earlier in this chapter.
The Win32 Driver Model is implemented in Windows 98 by adding a new layer to the existing device driver architecture. Kernel Services handles device driver access for Windows NT, whereas Ntkern.vxd handles device driver access for Windows 98. Ntkern.vxd abstracts the Windows 98 architecture to look like the Windows NT architecture. This abstraction allows vendors to develop one driver for both operating systems.
For more information about WDM, see Chapter 30, "Hardware Management."
Human Interface Device Drivers
Windows 98 supports the Human Interface Device (HID) class, the standard for input devices, such as keyboards, mouse devices, joysticks, and game pads. Support is based on the HID specification developed by the USB Implementers' Forum. A HID-compliant device is self-describing, returning function, layout, and usage information. The HID architecture for Windows 98 (implemented with WDM drivers) is shown in Figure 28.4.
Figure 28.4 HID architecture
HID support is provided for USB keyboards, mouse devices, joysticks, and game pads. HID support for USB comes from the HID class minidriver (Hidusb.sys) provided by Microsoft. Game applications can communicate with USB devices by using the Microsoft DirectInput 5.0 COM interfaces.
The following HID modules are shown in Figure 28.4:
Hidclass.sys is the HID class driver. It sends and receives HID reports to and from its minidrivers. Hidclass.sys also provides input queues so several processes can have handles open on the same device.
Hidusb.sys is the USB HID class minidriver. It sends and receives HID reports over the USB bus.
Hid.dll and Hidparse.sys are parsing services. Hid.dll is a User-mode parsing service. Hidparse.sys is a Kernel-mode parsing service. These modules aid User-mode applications and Kernel-mode drivers in parsing HID reports.
Figure 28.5 shows the Windows 98 HID keyboard implementation alongside the USB stack. In this example, the USB controller may be based on either the OpenHCI standard (Openhci.sys) or the Universal HCI standard (Uhci.sys). The system has two keyboards attached, one USB, another PS/2.
Figure 28.5 HID keyboard architecture example (with USB stack)
The WDM layered architecture and the role of "mapper" virtualization drivers (VxDs) is illustrated by considering how Windows 98 keeps the LED states of both keyboards consistent.
When CAPS LOCK is pressed on the USB keyboard:
A HID report containing the CAPS LOCK HID Usage is passed across the USB bus and progresses up the USB stack. It crosses over to the HID stack through Hidusb.sys and is presented to any driver or application that has the keyboard device open with the HID class driver, Hidclass.sys. In this case, Kbdhid.vxd is listening and translates the HID Usage into a legacy PS/2 SCAN CODE, and injects it into the legacy Vkd.vxd driver for routine processing by User.exe. User.exe eventually will cause Vkd.vxd to transmit a SET LED command to the PS/2 keyboard. Kbdhid.vxd hooks this service and also issues a HID report with the CAPS LOCK LED Usage set. This report propagates down through Hidclass.sys, Hidusb.sys, and the USB driver stack to the keyboard. In the meantime, Vkd.vxd sets the LED on the PS/2 keyboard in its usual way.
When CAPS LOCK is pressed on the PS/2 keyboard:
In the usual way, the PS/2 SCAN CODE propagates up from Vkd.vxd to User.exe. Eventually, User.exe sends a command to Vkd.vxd to set the LED. This command is noticed by Kbdhid.vxd, because it has the service hooked. It creates a HID report with the CAPS LOCK LED Usage set and writes it to Hidclass.sys, and the report propagates down through Hidusb.sys and the USB driver stack to the keyboard. In the meantime, Vkd.vxd sets the LED on the PS/2 keyboard in its usual way.
Hidvkd.sys does much the same as Kbdhid.vxd, only Hidvkd.sys is looking for the power key scan codes available on newer PS/2 keyboards.
Just as Kbdhid.vxd is needed to connect HID keyboard support with the VxD keyboard subsystem (Vkd.vxd), similar mapping VxDs (as shown in Table 28.2) are needed to enable support for HID mouse devices, joysticks, and so on.
Table 28.2 Virtualization drivers that support HID class devices
Windows 98 mapping driver
Windows 98 core driver
For more information about HID, see Chapter 30, "Hardware Management."
Virtual Machine Manager
The Virtual Machine Manager manages resources needed for each application and system process running on the computer. Virtual Machine Manager creates and maintains the virtual machine environments in which applications and system processes run.
A virtual machine (VM) is an environment in memory that, from the application's perspective, looks as if it is a separate computer, complete with all the resources available on the physical computer that an application needs to run. The Virtual Machine Manager, shown in Figure 28.6, provides each application with the system resources it needs.
Figure 28.6 Virtual Machine Manager
Windows 98 has a single VM called the System VM, in which all system processes run. In addition, each Win32-based application runs in its own VM, whereas Win16-based applications share a single Win16 VM. Each MS-DOS- based application runs in its own VM.
Note Windows NT has the ability to run each Win16-based application in its own VM.
The Virtual Machine Manager is responsible for three key areas of services:
MS-DOS Mode support (for MS-DOS-based applications that must have exclusive access to system resources).
The following sections describe these three areas of service.
Process Scheduling and Multitasking
The Process Scheduler is the component responsible for providing system resources to the applications and other processes you run, and for scheduling processes to allow multiple applications to run concurrently.
The Process Scheduler also schedules processes in a way that allows multiple applications and other processes to run concurrently. Windows 98 uses two methods for concurrent process scheduling — cooperative multitasking and preemptive multitasking.
With Windows 3.1,* *applications ran concurrently through a method known as cooperative multitasking. Using this method, the operating system required an application to check the message queue periodically and to relinquish control of the system to other running applications. Applications that did not check the message queue would effectively "hog" CPU time and prevent the user from switching to another application. For compatibility reasons, Windows 98 cooperatively multitasks Win16-based applications.
Windows 98 uses preemptive multitasking for Win32-based applications. This means that the operating system takes control away from or gives control to another running task, depending on the needs of the system.
Unlike Win16-based applications, Win32-based applications do not need to yield to other running tasks to multitask properly. Win32-based applications can take advantage of multithreading, a mechanism that Windows 98 provides to facilitate the ability to run applications concurrently. A Win32-based application running in the system is called a process in terms of the operating system. Each process consists of at least a single thread of execution that identifies the code path flow as it is run by the operating system. A thread is a unit of code that can get a time slice from the operating system to run concurrently with other units of code, and must be associated with a process. However, a Win32-based application can initiate multiple threads for a given process to enhance the application for the user by improving throughput, enhancing responsiveness, and aiding background processing. Because of the preemptive multitasking nature of Windows 98, threads of execution allow code to be smoothly processed in the background.
A good illustration of this is the Windows 98 shell itself. Although the shell is a Win32-based process, each folder window that opens is a separate thread of execution. As a result, when you initiate a copy operation between two, shell folder windows, the operation is performed on the thread of the target window. You can still use the other windows in the shell without interruption, or you can start a different copy in another window.
In another example, a word processing application (a process) can implement multiple threads to enhance operation and simplify interaction with the user. The application can have a separate thread that responds to keys typed on the keyboard by the user to place characters in a document, while another thread performs background operations, such as spelling checking or paginating, and a third thread spools a document to the printer in the background.
Note Some Win16-based* applications may have provided similar functionality; however, because Windows 3.1 *did not provide a mechanism for supporting multithreaded applications, it was up to application vendors to implement their own threading schemes. The use of threads in Windows 98 makes it easy for application vendors to add asynchronous processing of information to their applications.
Windows 98, like Windows NT, uses a demand-paged virtual memory system. This system is based on a flat, linear address space, accessed using 32-bit addresses.
Each process is allocated a unique virtual address space of 2 gigabytes (GB). The upper 2 GB is shared, while the lower 2 GB is private to the application. This virtual address space is divided into equal blocks, or pages.
Demand paging is a method by which code and data are moved in pages from physical memory to a temporary paging file on disk. As the information is needed by a process, it is paged back into physical memory on demand.
The Memory Pager maps virtual addresses from the process address space to physical pages in computer memory. In doing so, the Memory Pager hides the physical organization of memory from the process threads. This ensures that the thread can access the memory of its process as needed, but not the memory of other processes. Therefore, as shown in Figure 28.7, the virtual memory of a thread process is much simpler than the real arrangement of pages in physical memory.
Figure 28.7 Memory mapping with Memory Pager
To support a 16-bit operating environment including Windows 3.1 and MS-DOS, the Intel processor architecture uses a mechanism called a segment. Segments reference memory by using a 16-bit segment address, and a 16-bit offset address within the segment. A segment is 64 KB in size, and performance of both applications and the operating system suffer for accessing information across segment boundaries. Windows 98 supports this memory model for backward compatibility to Win16-based applications that were written for it by providing emulation by the Win16 subsystem.
For the support of Win32-based applications and features, Windows 98 uses the 32-bit capabilities of the 80386 (and later) processor architecture to support a flat, linear memory model for 32-bit operating system functionality and Win32-based applications. A linear addressing model simplifies the development process for application vendors and removes the performance penalties imposed by the segmented memory architecture.
With this addressing model, Windows 98 allows full use of the 4 GB of addressable memory space for all 32-bit operating system components and applications. Each 32-bit application can access up to 2 GB of addressable memory space, enough to support the largest desktop application.
Support for MS-DOS Mode
Although most MS-DOS- based applications run well in Windows 98 and can run concurrently with other Win32-based and Win16-based applications, a small number of MS-DOS- based applications require exclusive access to system resources to run. The Virtual Memory Manager that creates for the application this exclusive operating environment, called MS-DOS Mode. When an MS-DOS-based application runs in MS-DOS Mode, no other applications or processes may compete for system resources — all resources are at the exclusive access of the MS-DOS- based application. For related information, see Chapter 25, "Application Support."
Installable File Systems
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:
Installable File System (IFS) Manager. The IFS Manager is responsible for arbitrating access to different file system components.
File system drivers. The file system driver layer includes access to FAT-based disk devices, CD-ROM file systems, and redirected network device support.
Block I/O subsystem. The block I/O subsystem is responsible for interacting with the physical disk device.
The following sections describe these components.
Installable File System Manager
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.
File System Drivers
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):
32-bit Universal Disk Format (UDF) file system driver
32-bit network redirector (for connectivity to Microsoft network servers, such as Windows NT Server, along with a 32-bit network redirector to connect to Novell NetWare servers).
For more information about network redirectors, see Chapter 29, "Windows 98 Network Architecture."
VFAT File System
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:
Dramatically improved performance and real-mode disk caching software.
No conventional memory used.
Better multitasking when accessing information on disk.
Dynamic cache support.
More efficient utilization of memory for 32-bit applications (cache mapping).
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.
CD-ROM File System
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:
No conventional memory used.
Improved performance over MS-DOS-based MSCDEX and real-mode cache.
Better multitasking when accessing CD-ROM information .
Dynamic cache support to provide a better balance between providing memory to run applications and providing memory to serve as a disk cache.
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.
Universal Disk Format File System
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.
Block I/O Subsystem
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.
Input/Output Supervisor and Driver Loading
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:
Routing and queuing I/O requests, and sending asynchronous notifications to drivers as needed.
Providing services that drivers can use to allocate memory and complete I/O requests.
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
Port drivers (such as SCSIPORT, ESDI_506, and NEC)
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.
To support Plug and Play functionality, Windows 98 architecture includes a component called Configuration Manager, which orchestrates the configuration process. This process might involve many bus and device architectures coexisting on a single system, with more than one device type using the same bus architecture, yet with each device having a separate set of configuration requirements. For example, a mouse and a keyboard can both use the same keyboard controller bus; a CD-ROM drive and a hard disk drive might both use the same SCSI bus.
As shown in Figure 28.10, Configuration Manager works with a number of subcomponents to identify each bus and each device on the system and to identify the configuration settings for each device. Configuration Manager ensures that each device on the computer can use an interrupt request (IRQ), I/O port addresses, and other resources without conflict with other devices.
Figure 28.10 How Configuration Manager works in Windows 98
Configuration Manager also helps monitor the computer for changes in the number and type of devices present, and manages the reconfiguration of the devices, as needed, when changes take place. As these events occur, Configuration Manager communicates the information to applications.
To perform its role, Configuration Manager (implemented as part of the Virtual Memory Manager [VMM32]) calls on the bus enumerators to identify all the devices on their specific buses and their respective resource requirements.
Bus enumerators are new drivers that are responsible for creating the Windows 98 hardware tree. A hardware tree is the hierarchical representation of all the buses and devices on a computer. Each bus and each device is represented as a node. Figure 28.11 graphically represents a hardware tree.
Figure 28.11 Example of a hardware tree
During the device enumeration process, the bus enumerator locates and gathers information from either the device drivers or the BIOS services for that particular device type. For example, the SCSI bus enumerator calls the SCSI drivers to gather information. (Some bus enumerators may instead check the hardware directly.)
A driver is loaded for each device. When loaded, the driver waits for Configuration Manager to assign specific resources (such as IRQs) to the device. Configuration Manager calls on resource arbitrators to allocate resources for each device.
Resource arbitrators resolve conflicts among devices that request identical resource assignments. Windows 98 provides arbitrators for the standard I/O, memory, hardware interrupt, and direct memory access (DMA) channel resources. (The arbitrators are separate components, rather than a part of Configuration Manager, to ensure extensibility to new types of resources, such as power allocation or automatic SCSI IDs.)
To complete the configuration process, Configuration Manager informs the device drivers about the device configuration. This process is repeated when the BIOS or one of the other bus enumerators informs Configuration Manager about an event that requires a change to the system configuration, such as the removal or insertion of a Plug and Play–compliant PC Card.
For more information about Plug and Play, see Chapter 24, "Device Management."
Win32 Driver Model Driver Manager
Win32 Driver Model (WDM) support is implemented in Windows 98 by adding a new layer to the existing VxD device driver architecture that mimics the Windows NT kernel. Ntkern.vxd exposes this interface for WDM drivers, allowing vendors to develop one driver for both Windows 98 and future versions of Windows NT.
For more information about the WDM driver architecture, see "Win32 Driver Model Drivers" earlier in this chapter.
For more information about WDM in general, see Chapter 30, "Hardware Management."
Core System Components
Windows 98 includes a core composed of three components — User, Kernel, and Graphics Device Interface (GDI) — as shown in Figure 28.12.
Figure 28.12 Windows 98 core system components
Each of these components includes a pair of dynamic-link libraries (DLLs) (one 32-bit and one 16-bit) that provide services for the applications you run. Windows 98 is designed to use 32-bit code wherever it significantly improves performance without sacrificing application compatibility. Windows 98 retains existing 16-bit code where it is required to maintain compatibility or where 32-bit code would increase memory requirements without significantly improving performance. All the Windows 98 I/O subsystems (such as networking and file systems) and device drivers are 32-bit, as are all the memory management and scheduling components, including the Kernel and Virtual Memory Manager.
As shown in Figure 28.13, the lowest-level services provided by the Windows 98 Kernel are implemented as 32-bit code to ensure a high-performance core. Most of the remaining 16-bit code consists of hand-tuned assembly language, delivering performance that rivals some 32-bit code used by other operating systems.
Figure 28.13 Windows 98 core services
Many functions provided by the GDI — which are mostly complex, CPU-intensive functions — have been rewritten as 32-bit code to improve performance. Much of the window management code in the User components (small, fast functions) remains 16-bit, thus retaining application compatibility.
Windows 98 also improves on the MS-DOS and Windows 3.1* *environments by implementing many device drivers as 32-bit, protected-mode code. Virtualization drivers in Windows 98 assume the functionality provided by many real-mode, MS-DOS-based device drivers, eliminating the need to load them in MS-DOS. This results in a minimal conventional memory footprint, improved performance, and improved reliability and stability of the system over real-mode device drivers.
The following sections describe the services provided by these core components.
The User component manages input from the keyboard, mouse, and other input devices and output to the user interface (windows, icons, menus, and so on). It also manages interaction with the sound driver, timer, and communications ports.
Windows 98 uses an asynchronous input model for all input to the system and applications. As the various input devices generate interrupts, the interrupt handler converts these interrupts to messages and sends the messages to a raw input thread area, which in turn passes each message to the appropriate message queue. Although each Win32-based thread can have its own message queue, all Win16-based applications share a common one.
The Kernel provides base operating system functionality, including file I/O services, virtual memory management, and task scheduling. When a user wants to start an application, the Kernel loads the EXE and DLL files for the application.
Exception handling is another service of the Kernel. Exceptions are events that occur as a program runs and that require software outside the normal flow of control to be run. For example, if an application generates an exception, the Kernel is able to communicate that exception to the application to perform the necessary functions to resolve the problem.
The Kernel also allocates virtual memory, resolves import references, and supports demand paging for the application. As the application runs, the Kernel schedules and runs threads of each process owned by an application.
The Kernel provides services to both 16-bit and 32-bit applications by using a translation process called thunking to map between 16-bit and 32-bit formats. Thunking converts a 16-bit value to its 32-bit equivalent.
Virtual Memory Management
Virtual memory refers to the fact that the operating system can actually allocate more memory than the computer physically contains. Each process is allocated a unique virtual address space, which is a set of addresses available for the process's threads to use. This virtual address space appears to be 4 gigabytes (GB) in size: 2 GB reserved for program storage and 2 GB for system storage.
Figure 28.14 illustrates where Windows 98 system components and applications reside in virtual memory.
Figure 28.14 Windows 98 virtual memory structure
From top to bottom, here is where system and application components reside in virtual memory:
All Ring 0 components reside in the address space above 3 GB.
The Windows 98 core components and shared DLLs reside in the shared address space between 2 GB and 3 GB. This makes them available to all applications.
Win32-based applications reside between 4 megabytes (MB) and 2 GB. Each Win32-based application has its own address space, which means that other programs cannot corrupt or otherwise hinder the application, or vice versa.
Windows 98 Swap File
The Windows 98 virtual memory swap file implementation addresses problems and limitations imposed in Windows 3.1.
Under Windows 3.1, users had to decide whether to use a temporary swap file or a permanent swap file, how much memory to allocate to the swap file, and whether to use 32-bit disk access to access the swap file. One of the benefits of a temporary swap file is that the swap file did not need to be contiguous; Windows allocated space on the hard disk when the user started Windows and freed up the space when the user exited Windows. A permanent swap file provided better performance; however, it required a contiguous block of space on a physical hard disk and was static, so it remained as a hidden file, taking up space, on the hard drive when the user exited Windows.
The swap file implementation in Windows 98 simplifies the configuration task for the user and combines the best of temporary and permanent swap files because of improved virtual memory algorithms and access methods. The swap file in Windows 98 is dynamic; it can shrink or grow, based on the operations that are performed on the system. The swap file can also occupy a fragmented region of the hard disk with no substantial performance penalty. The swap file can also reside on a compressed volume.
You can still adjust the parameters used for defining the swap file in Windows 98; however, the need to do this is reduced by using system defaults. For more information about swap file configuration options, see Chapter 26, "Performance Tuning."
Graphics Device Interface
The Graphics Device Interface (GDI) is the graphical system that manages what appears on the screen. It also provides graphics support for printers and other output devices. It draws graphic primitives, manipulates bitmaps, and interacts with device-independent graphics drivers, including those for display and printer output device drivers.
The graphics subsystem provides graphics support for input and output devices.
For reliability and better performance, Windows 98 uses a 32-bit graphics engine, also known as the device-independent bitmap (DIB) engine. This engine directly controls graphics output to the screen, providing more reliable system performance. It also provides a set of optimized generic drawing functions for monochrome (1-bit), 16-color (4-bit), 256-color (8-bit), 65,535-color (16-bit), and 16,777,215-color (24-bit) graphic devices and supports Bézier curves and paths.
Windows 95 introduced Image Color Matching (ICM) for better color-matching between display and color output devices. Microsoft has enhanced the capability of ICM to provide increased functionality and performance in Windows 98. ICM 2.0 supports more color spaces beyond RGB to CMYK, to device-independent color spaces such as CIELAB, a theoretical color space defined by the Commission Internationale de L'Eclairage (CIE), as well as support for additional colors for processes such as HiFi Color. See Chapter 11 "Printing, Imaging, and Fonts" for more information on ICM.
As with other parts of the operating system, the Windows 98 graphics subsystem includes a universal driver/minidriver model. As illustrated in Figure 28.15, display drivers for Windows 3.1 included hardware-specific instructions, in addition to general instructions for the operating system. Now, all instructions about drawing to the screen or output device are included in the universal display driver. Minidrivers for Windows 98 define only hardware-specific instructions. Minidrivers are available for most leading Super VGA adapters and graphics accelerators, including S3, ATI, Tseng, Paradise, Western Digital, and Cirrus Logic.
Figure 28.15 The 16-bit and 32-bit graphics subsystem driver models
Tip Problems can result when Windows 98 assumes that a display adapter can support certain functionality that, in fact, it cannot. If this occurs, the side effects might be anything from small display irregularities to system lockup.
To determine whether any performance problems might be related to the display adapter, you can progressively disable enhanced display functionality using the System option in Control Panel. For information, see Chapter 26, "Performance Tuning."
The 32-bit Windows 98 printing subsystem provides performance through smoother background printing and faster return-to-application time. By using background thread processing, the Windows 98 spooler passes data to the printer, as the printer is ready to receive more information.
Windows 98 spools enhanced metafile (EMF) format files rather than raw printer data to ensure quick return-to-application time (up to twice as fast as with Windows 3.1). When spooled, the EMF information is interpreted in the background, and the output is sent to the printer.
The printing subsystem supports Point and Print. When users browse the network to choose the printers they want to use, Windows 98 automatically installs the appropriate printer driver from the Windows 98 or Windows NT server.
Another feature of the Windows 98 printing subsystem is deferred printing. If no printing device is available, the user can still "print" the job. Windows 98 generates the print job and then saves it for output to a print device when one is available. Then, when the user docks the portable computer after returning to the office, the print job that was "printed" begins generating pages at the print device.
The printing subsystem also provides system-level support of bidirectional communication protocols for printers adhering to the Extended Communication Port (ECP) printer communication standard, developed by Microsoft and Hewlett-Packard. This capability allows printers to send unsolicited messages to Windows 98 and to applications. For example, the printer might send an "out of paper" or "printer offline" message. Bidirectional communication enables much more detailed status reporting on a wider variety of information, such as information about a low toner condition, details about a paper jam, instructions related to maintenance needs, and so on. For more information on printing, see Chapter 11 "Printing, Imaging, and Fonts."
Windows 98 features a new 32-bit user interface that unifies information access into one utility to universally view local, network, intranet, and Internet data. This new shell contains several desktop tools, including Network Neighborhood, the selectable Active Desktop interface, and the selectable Active Channel interface. As shown in Figure 28.16, these tools run at the same architectural level as other Win32-based, Win16-based, and MS-DOS-based applications.
Figure 28.16 Windows 98 user interface shell
All applications and tools can take advantage of the common controls offered by the shell, such as common dialog boxes, tree views, and list views.
Windows 98 supports Win32-based, Win16-based, and MS-DOS-based applications.
As illustrated in Figure 28.17, Win32-based and Win16-based applications run in the System VM. Win32-based applications each run in a separate address space, while Win16-based applications run together in a shared address space. Each MS-DOS-based application runs in its own VM.
Figure 28.17 Windows 98 support for Win32-based and Win16-based applications
For more information about using Win32-based, Win16-based, and MS-DOS-based applications in Windows 98, see Chapter 25, "Application Support," and Chapter 29, "Windows 98 Network Architecture."
For more information about VMs, see "Virtual Machine Manager" earlier in this chapter.