Extensions to the Base Operating System
The Executive components of Windows NT present a fairly neutral face to the world. They don’t implement a user interface nor do they define any external policies like security. They don’t even offer a programming interface since the Executive’s system service calls are not publicly documented. The base kernel-mode components simply provide a generic operating system platform.
Defining the look and feel of the operating system — both to users and programmers — is the job of some extended components known collectively as protected subsystems. Rather than dealing directly with the Executive, users and programmers of Windows NT interact with these subsystems.
In the original architecture of Windows NT, protected subsystems were implemented entirely as a group of privileged user-mode processes. This rather elegant design made it possible to extend the base operating system without risking any damage to the underlying kernel-mode components. For performance reasons, Windows NT 4.0 has moved away from this pure user-mode model and shifted some subsystem components into kernel mode.
Depending on the kind of work they do, all protected subsystems can be divided into two major categories. The following subsections describe each category in more detail.
Integral subsystems — An integral subsystem performs some necessary system function. The responsibilities of these subsystems actually cover quite a lot of territory. The following are just a few examples of what they do:
Together with the Security Accounts Manager and the Logon process, the Local Security Authority defines security policy for the system.
The Service Control Manager loads, supervises, and unloads trusted system components like services and drivers.
The RPC Locator and RPC Service processes give support to distributed applications that use remote procedure calls.
Environment subsystems — The other kind of protected subsystem is called an environment subsystem. The job of an environment subsystem is to provide a programming interface and execution environment for application programs native to some specific operating system. Currently, Windows NT provides the following subsystems:
The Win32 subsystem implements the native-mode programming interface for Windows NT. A more detailed description of this subsystem appears below.
The Virtual DOS Machine (VDM) subsystem allows 16-bit MS-DOS applications to run under Windows NT. Unlike other subsystems, the VDM software is actually part of the process where the MS-DOS application is running.
The Windows on Windows (WOW) subsystem supports the execution of 16-bit Windows applications. The default behavior of the WOW subsystem is to run all 16-bit Windows applications as separate threads within the address space of a single VDM process. This helps to mimic the 16-bit Windows environment more closely.
The POSIX subsystem provides API support for programs conforming to the POSIX 1003.1 source-code standard. Because POSIX 1003.1 is not a binary standard, applications must be compiled and linked on Windows NT in order under this subsystem.
The OS/2 subsystem creates an execution environment for 16-bit OS/2 applications. This subsystem is available only for the 80x86 version of Windows NT.
A given application is always tightly coupled to one specific subsystem and can use only the features of that subsystem. For example, a POSIX application can’t make calls to Win32 API functions. Also keep in mind that applications running under any subsystem other than Win32 will experience some performance degradation. These other subsystems are provided mainly for compatibility.
More about the Win32 Subsystem
All environment subsystems are not created equal. In particular, the services provided by the Win32 subsystem are crucial to the operation of Windows NT. The duties of this subsystem include the following:
As the owner of the screen, keyboard, and mouse, it manages all console and GUI I/O for the entire system. This includes I/O for other subsystems as well as user applications.
The Win32 subsystem implements the GUI seen by programmers and users. As the screen and window manager for Windows NT, it defines GUI policy and style for the whole system.
It exposes the Win32 API that both application programs and other subsystems use to interact with the Executive.
Because of its special status, the Win32 subsystem is implemented in a different way from any of the others. Figure 1.3 shows the organization of the Win32 subsystem.
Unlike its counterparts, the Win32 subsystem doesn’t run entirely in user mode. Instead, it consists of both user- and kernel-mode components. To understand how it all fits together, you need to know a little bit about the organization of the Win32 API itself. Broadly speaking, you can divide Win32 functions into three categories:
The USER functions manage GUI objects like menus and buttons.
The GDI functions that perform low-level drawing operations on graphical devices like the displays and printers.
The KERNEL functions manage such things as processes, threads, synchronization objects, shared memory, and files. They map very directly onto the system services provided by the Executive.
In the original design of Windows NT, one of the goals was to confine all GUI policy-making code to the Win32 server process, CSRSS. The developers believed this would make the system more robust and easier to modify. As a result, calls to many USER and GDI functions required some interaction with the CSRSS process. This is a rather expensive operation since it involves a process context switch between the Win32 client and the CSRSS server. By comparison, KERNEL functions could be handled in the context of the calling process. Their only overhead was the transition to and from kernel mode.
This architecture has been replaced in Windows NT 4.0 because of the performance limitations it put on graphically based Win32 programs. Now, a new kernel-mode component called WIN32K.SYS has taken over most of the work formerly done by CSRSS. With this approach, calls to USER and GDI functions can execute in the context of the calling process. The result is that the speed of graphically intensive applications improves significantly.
This shift from user- to kernel-mode graphic support also had implications for the architecture of video and printer drivers under Windows NT. The next section of this chapter will provide some more details on this subject.
KERNEL-MODE I/O COMPONENTS
Here we’re going to take a look at the general layered driver model used by the kernel-mode portions of Windows NT. We’ll also be examining variations on this architecture that support specific kinds of I/O devices.
Design Goals for the I/O Subsystem
In addition to the general Windows NT design goals, there were several additional requirements that the I/O subsystem had to satisfy:
Ease of development — It shouldn’t take unreasonable amounts of work to provide support for a new device.
Portability — It should be relatively easy to move drivers to new platforms. In the best case, this would mean simply compiling and linking the driver.
Extendibility — It should be easy to add support for new devices and file systems without breaking anything that already works.
Robustness — The I/O architecture should offer clean, well-defined interfaces and minimize the use of backdoor mechanisms.
Security — It must be possible to allow or deny various kinds of access to I/O objects on a user-by-user basis.
Multithreaded operation — Drivers should be able to handle overlapping requests from multiple threads, even if the threads are running simultaneously on multiple CPUs.
Performance — I/O throughput must be consistent with the needs of large-scale client-server applications.
As if all this isn’t enough, the I/O architecture has to work with all the legacy devices that people have been attaching to PCs for the last decade. Some of these devices have characteristics that don’t blend well with modern, large-scale operating systems.
Layered Drivers in Windows NT
In most operating systems, the term driver refers to a piece of code that manages some peripheral device. Windows NT takes a more flexible approach which allows several driver layers (shown in Figure 1.4) to exist between an application program and a piece of hardware. This layering permits Windows NT to define a driver in much broader terms that include file systems, logical volume managers, and various network components as well as physical device drivers.
Device drivers — These are the drivers that manage actual data transfer and control operations for a specific type of physical device. This includes starting and completing I/O operations, handling interrupts, and performing any error processing required by the device.
Intermediate drivers — Windows NT allows you to layer any number of intermediate drivers on top of a physical device driver. These intermediate layers provide a way of extending the capabilities of the I/O system without having to modify the drivers below them. For example, the fault-tolerant disk driver in Windows NT Server is implemented as a layer that sits between the file system and the drivers for any physical disks.
Another use for intermediate drivers is to separate hardware-specific operations from more general management issues. In this kind of arrangement, the intermediate driver is referred to as a class driver and the hardware driver is called a port driver. For example, the keyboard class driver handles general keystroke processing while the keyboard port driver worries about the details of specific keyboard controllers. The use of separate class and port drivers makes it easier to target a wider range of hardware since only the port driver needs to be rewritten.
File-system drivers (FSDs) — This kind of driver is generally responsible for maintaining the on-disk structures needed by various file systems. For design reasons, some other system components are implemented as file-system drivers, even though they aren’t file systems as such. Microsoft currently supplies the following FSDs:
FAT — Windows 95 extended MS-DOS file system
NTFS — Windows NT high reliability file system
HPFS — OS/2 high performance file system
CDFS — ISO 9660 CD-ROM file system
MSFS — Mailslot file system
NPFS — Named pipe file system
RDR — LAN Manager redirector
Unfortunately, you can’t develop file-system drivers using the standard NT DDK. Microsoft released a beta version of a file system developer’s kit at a conference in 1994, but at the time of this writing, they hadn’t committed to any release date for the final version of this kit.
Critical Challenges of ESI & Email Retention Are you storing too much electronic information? Get expert legal advice and better understanding of what you are required to do as an IT professional.
Rev Up Your IT Know-How with Our Recharged Magazine! The improved Windows IT Pro provides trusted IT content with an enhanced new look and functionality! Get comprehensive coverage of industry topics, expert advice, and real-world solutions—PLUS access to over 10,000 articles online. Order today!
Get It All with Windows IT Pro VIP Stock your IT toolbox with every solution ever printed in Windows IT Pro and SQL Server Magazine plus bonus Web-exclusive content on hot topics. Subscribe to receive the VIP CD and a subscription to your choice of Windows IT Pro or SQL Server Magazine!
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Windows IT Pro
Register
