Windows 95 Architecture Components

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 Windows 95 architecture to assist you in understanding how the key operating system components function and interrelate.

Windows 95 features a new device driver model, a new file system, a new 32-bit graphics engine, and new 32-bit print, communications, and multimedia subsystems. Windows 95 is a 32-bit operating system with built-in connectivity support. It provides high performance, robustness, and complete backward compatibility.

All of these features are supported by the modular design shown in the following diagram.

This chapter describes the key components that make up the Windows 95 architecture beginning with its central information store, the Registry, and proceeding from bottom to top.

Summary of Improvements over Windows 3.1

Although its architectural design is based on Windows version 3.1, Windows 95 includes several improvements over the earlier operating system:

• A fully integrated 32-bit, protected-mode operating system, which eliminates the need for a separate copy of MS-DOS.

• Preemptive multitasking and multithreading support, which improves system responsiveness and offers smooth background processing.

• 32-bit installable file systems including VFAT, CDFS, and network redirectors. These support better performance, use of long filenames, and an open architecture to support future growth.

• 32-bit device drivers, available throughout the system, which deliver improved performance and intelligent memory use.

• A complete 32-bit kernel, including memory management and process scheduling and management.

• Improved system-wide robustness and cleanup after an application ends or fails. This delivers a more stable and reliable operating environment.

• More dynamic environment configuration, which reduces the need for users to adjust their systems.

• Improved system capacity, which allows multiple applications and system tasks to run well concurrently.

Windows 95 Registry

The central information database for Windows 95 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 (except 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 you can 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 95 is to serve as a central repository for hardware-specific information for use by the hardware detection and Plug and Play system components. Windows 95 maintains information about hardware components and devices that have been identified through an enumeration process in the hierarchical structure of the Registry. (This process is "Configuration Manager" later in this chapter.) When new devices are installed, the system checks the existing configuration in the Registry to determine the hardware resources (for example, IRQs, I/O addresses, DMA channels, and so on) that are not being used, so the new device can be properly configured without conflicting with a device already installed in the system.

Windows 3.1 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 remedies this situation by providing a single location for a computer's configuration information. The following table shows other difficulties or limitations caused by using INI files that are overcome by using the Registry.

Problems using INI files	Solutions using the Registry
INI files are text-based, and are limited to 64K in total size.	The Registry has no size restriction and can include binary and text values.
Information stored in INI files is non-hierarchical and supports only two levels of information (specifically, section headings with a list of key names under each).	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. For more information, see Chapter 6, "Setup Technical Discussion."
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 (which are stored as Registry values) can be downloaded from a central server each time a new user logs on. For more information, see Chapter 15, "User Profiles and System Policies," and Chapter 16, "Remote Administration."

When you upgrade from Windows 3.1 to Windows 95, system-specific information such as the static reference to loading virtual device drivers is moved, as appropriate, from the SYSTEM.INI file to the Registry.

For backward compatibility, Windows 95 does not ignore AUTOEXEC.BAT, CONFIG.SYS, and INI files, because many Win16-based applications still use them. For example, Windows 95 allows Win16-based applications to use INI files for the parameters, device drivers, and so on, that the applications need to run. In addition, Windows 95 continues to examine the [386Enh] section of SYSTEM.INI at startup to check for virtual device drivers.

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 95 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 95 remote administration, industry management mechanisms such as Simple Network Management Protocol (SNMP) can easily be integrated into Windows 95, simplifying the management and support burden of the network administrator. For more information, see Chapter 16, "Remote Administration."

Device Drivers

Windows 95 provides improved support for hardware devices and peripherals including disk devices, display adapters, mice and other pointing devices, modems, fax machines, and printers.

In Windows 3.1, device drivers were, for the most part, monolithic and complex to develop. Windows 95 uses a universal driver/mini-driver architecture that makes it easier for hardware vendors to provide device-specific code for their hardware.

A universal driver includes most of the code necessary for devices in a particular class of devices (such as printers or modems) to communicate with the appropriate operating system components (such as the printing or communications subsystems). A mini-driver 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.)

A virtual device 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 virtual device driver—the x represents the type of device driver. For example, a virtual device driver for a display device is known as a VDD, a virtual device driver for a timer device is a VTD, a virtual device driver for a printer device is a VPD, and so forth.

With Windows 3.1, VxDs were statically loaded and took up a lot of memory space. However, Windows 95 dynamically loads VxDs — only those that are needed at any given time are loaded into memory. In addition, the new VxDs don't 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. If the state of the hardware device can be disrupted by switching between multiple applications, the device must have a corresponding virtual device and VxD. The virtual device keeps track of the state of the device for each application and ensures that the device is in the correct state whenever an application continues.

Although most virtual devices manage hardware, some manage only installed software, such as an MS-DOS device driver or a TSR program. 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.

(Windows 95 virtual device driver files have a filename extension of .VXD; Windows 3.1 drivers used an extension of .386.)

Configuration Manager

To support Plug and Play functionality, Windows 95 architecture includes a new 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.. (A bus is the mechanism that allows information to be transferred between the computer and the device.) 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 the following illustration, 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 IRQ, I/O port addresses, and other resources without conflict with other devices.

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 95 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. The following is a graphical representation 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.)

For each device, a driver is loaded. 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 95 provides arbitrators for the standard I/O, memory, hardware interrupt, and 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 PCMCIA card. For more information about Plug and Play, see Chapter 18, "Introduction to System Configuration."

Virtual Machine Manager

Just as Configuration Manager provides for all resources needed by each device on the computer, another component, Virtual Machine Manager, provides for 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 of the resources available on the physical computer that an application needs to run. The Virtual Machine Manager provides each application with the system resources it needs. Virtual Machine Manager replaces WIN386.EXE in Windows 3.1.

Windows 95 has a single VM called the System VM, in which all system processes run. In addition, all Win32-based and Win16-based applications run in this VM. Each MS-DOS – based application runs in its own VM. (For information on VMs, see "Core System Components" later in this chapter.)

The Virtual Machine Manager is responsible for three key areas of services:

• Process scheduling

• Memory paging

• MS-DOS Mode support for MS-DOS – based applications that must have exclusive access to system resources

The following sections discuss 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 95 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 frequently would effectively "hog" CPU time and prevent the user from switching to another application. For compatibility reasons, Windows 95 cooperatively multitasks Win16-based applications.

Windows 95 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 95 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 95, threads of execution allow code to be smoothly processed in the background.

A good illustration of this is the Windows 95 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 back-ground operations such as spelling checking or paginating, and while a third thread spools a document to the printer in the background.

Note: Some Win16-based applications may have provided functionality similar to this; however, because Windows 3.1 didn't 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 95 makes it easy for application vendors to add asynchronous processing of information to their applications.

Memory Paging

Windows 95, similar to 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 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 refers to 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.

The Memory Pager maps virtual addresses from the process's address space to physical pages in the computer's memory. In doing so, it hides the physical organization of memory from the process's threads. This ensures that the thread can access its process's memory as needed, but not the memory of other processes. Therefore, as shown in the following illustration, a thread's view of its process's virtual memory (as depicted on the left) is much simpler than the real arrangement of pages in physical memory.

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 64K in size, and both applications and the operating system suffer a performance penalty for accessing information across segments.

Windows 95 addresses this issue by using the 32-bit capabilities of the 80386 (and above) 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 95 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, which is large enough to support even the largest desktop application.

Support for MS-DOS Mode

While most MS-DOS – based applications run well in Windows 95 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. In this case, it is the Virtual Memory Manager that creates this exclusive operating environment for the application called MS-DOS Mode. When an MS-DOS – based application runs in MS-DOS Mode, no other applications or processes are allowed to compete for system resources — all resources are at the exclusive access of the MS-DOS – based application. For related information, see Chapter 22, "Application Support."

Installable File Systems

Windows 95 features a layered file system architecture that supports multiple file systems, including VFAT and CDFS.

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 filename support and a dynamic system cache for file and network I/O.

Long filename support improves ease of use because users no longer need to reference files by the MS-DOS 8.3 filename structure. Instead, users can specify up to 255 characters to identify their documents. In addition, filenames seem less cryptic and thus easier to read because Windows 95 hides the filename extensions from users.

Windows 95 I/O performance is dramatically improved over Windows 3.1. This is because Windows 95 features 32-bit protected-mode code for reading information from and writing information to the file system, and for reading information from and writing information to 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.

Windows 95 includes an open file system architecture for future system support. It also provides disk device driver compatibility with Windows NT.

The following figure shows the file system architecture used by Windows 95.

The Windows 95 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 95, 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, INT 21 provided access to the file system to manipulate file information on a disk device. To support redirected disk devices (for example, a network drive or a CD-ROM drive), other system components such as the network redirector would hook the INT 21 function so that it could examine the file system request to determine whether it should handle the file I/O request or let the base file system handle it. Although this mechanism provided the ability to add more device drivers, some add-on components ran improperly and interfered with other installed drivers.

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 supported. In Windows 95, 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 3.1, file system drivers were supported by MS-DOS. With Windows 95, file system drivers are Ring 0 components of the operating system. Windows 95 includes support for all of the following file systems (others can be added by other vendors):

• 32-bit FAT (VFAT) driver

• 32-bit CD-ROM file system (CDFS) 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 information about network redirectors, see Chapter 32, "Windows 95 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 are supported by Windows 3.1. Windows 95 also supports mapping to any real-mode disk drivers that might be installed. 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 (real-mode SMARTDrive has been replaced)

• Better multitasking when accessing information on disk

• Dynamic cache support

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. Being able to manipulate the disk file system from protected mode removes or reduces the need to switch to real mode to write information to the disk through MS-DOS, thus resulting in a performance gain for 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 CD-ROM File System (CDFS) and the 32-bit network redirectors provided with Windows 95.

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 95 increases the size of the cache. As network activity decreases and more applications are started, Windows 95 decreases the cache size.

CD-ROM File System

The 32-bit, protected-mode CDFS implemented in Windows 95 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 information about the CD-ROM cache, see Chapter 17, "Performance Tuning."

Benefits of the new 32-bit CDFS driver include the following:

• No conventional memory used (real-mode MSCDEX has been replaced)

• 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 versus providing memory to serve as a disk cache

MSCDEX is no longer necessary under Windows 95, and is automatically removed from memory and from AUTOEXEC.BAT by Setup, and the 32-bit CDFS driver is used instead.

Block I/O Subsystem

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.

I/O 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 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:

• Registering drivers

• 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 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.

Core System Components

Similar to Windows version 3.1 and Windows for Workgroups version 3.1, Windows 95 includes a core composed of three components — User, Kernel, and graphical device interface (GDI).

Each of these components includes a pair of DLLs — one 32-bit and one 16-bit — which provide services for the applications you run. Windows 95 is designed to use 32-bit code wherever it significantly improves performance without sacrificing application compatibility. Windows 95 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 95 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 the following illustration, the lowest-level services provided by the Windows 95 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.

Many functions provided by the GDI — which are mostly complex, CPU-intensive functions — are now rewritten as 32-bit code to improve performance. Much of the window management code in the User components— which are small, fast functions — remains 16-bit, thus retaining application compatibility.

Windows 95 also improves on the MS-DOS and Windows 3.1 environments by implementing many device drivers as 32-bit, protected-mode code. Virtual device drivers in Windows 95 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.

User

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 95 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 message queue.

Kernel

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 of 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 is a term that 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 GB in size — 2 GB reserved for program storage and 2 GB reserved for system storage.

The following diagram illustrates where Windows 95 system components and applications reside in virtual memory.

From top to bottom, here's where system and application components reside in virtual memory:

• All Ring 0 components reside in the address space above 3 GB.

• The Windows 95 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 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 95 Swap File

The Windows 95 virtual memory swap file implementation addresses the 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. Users benefited from a temporary swap file in 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 did not free up space when the user exited Windows.

The swap file implementation in Windows 95 simplifies the configuration task for the user and combines the best of temporary and permanent swap files, due to improved virtual memory algorithms and access methods. The swap file in Windows 95 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 95; however, the need to do this is reduced by using system defaults. For information about swap file configuration options, see Chapter 17, "Performance Tuning."

Graphical Device Interface

The Graphical 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.

Graphics Subsystem

The graphics subsystem provides graphics support for input and output devices.

To gain reliability and better performance, Microsoft developed a new 32-bit graphics engine (also known as the Device Independent Bitmaps, or DIB, engine). This engine directly controls graphics output to the screen, which results in more reliable system performance. It also provides a set of optimized generic drawing functions for monochrome, 16-color, 16-bit high color, 256-color, and 24-bit true color graphic devices, and supports Bézier curves and paths.

The graphics subsystem supports Image Color Matching for better color-matching between display and color output devices. With Image Color Matching in Windows 95, users can see a better match between the colors displayed on the screen and the colors printed on a color printing device. Image Color Matching is implemented as a service within Windows 95. Applications can use the corresponding APIs and DLL to take advantage of Image Color Matching features.

As with other parts of the operating system, the Windows 95 graphics subsystem includes a universal driver/mini-driver model. As illustrated in the following, 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. Mini-drivers for Windows 95 define only hardware-specific instructions. Mini-drivers are available for most leading Super VGA adapters and graphics accelerators, including S3, ATI, Tseng, Paradise, Western Digital, and Cirrus Logic.

Tip Problems can result when Windows 95 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 17, "Performance Tuning."

Printing Subsystem

The 32-bit Windows 95 printing subsystem improves performance through smoother background printing and faster return-to-application time. The Windows 95 spooler passes data to the printer as the printer is ready to receive more information, by using background thread processing.

Windows 95 spools enhanced metafile (EMF) format files, rather than raw printer data, to ensure quick return-to-application time (as much as two times faster than 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 95 automatically installs the appropriate printer driver from the Windows 95 or Windows NT server.

Another feature of the Windows 95 printing subsystem is deferred printing. If no printing device is available, the user can still "print" the job. Windows 95 generates the print job, then saves it for output to the 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 95 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.

User Interface

Windows 95 features a 32-bit user interface shell, based on Windows Explorer. This shell contains several desktop tools, including Network Neighborhood. As shown in the following figure, these tools run at the same level as other Win32-based, Win16-based, and MS-DOS – based applications.

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.

Application Support

Windows 95 supports Win32-based, Win16-based, and MS-DOS – based applications.

As illustrated here, 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.

For details about using Win32-based, Win16-based, and MS-DOS – based applications in Windows 95, see Chapter 22, "Application Support." For more information about VMs, see "Virtual Machine Manager" earlier in this chapter.