Section 1.3. Windows NT Architecture

   

---

1.3 Windows NT Architecture

Windows NT has been designed with a modular, layered architecture that allows for efficiency and extensibility. The architecture allows for easy addition of support for new devices or new functionality, such as encrypting file systems. The architecture also allows for adding support for applications based on a different operating system ”for example, OS/2 or POSIX. Of course, both of these have been historically more important than they currently are, but they are still good examples of the modular extensible architecture.

Figure 1.2 shows the high-level architecture of Windows NT. As explained in the Introduction, the term Windows NT is used in a generic sense to refer to all versions of the operating system based on the NT code, which includes Windows NT 3.X, Windows NT 4.0, Windows 2000, Windows XP, and also Windows Server 2003.

Figure 1.2. Windows NT Architecture

Sections 1.3.1 through 1.3.6 explain the various entities in Figure 1.2, from the bottom up. Note the line dividing kernel and user modes in Figure 1.2. The importance and meaning of the two modes have already been explained earlier in this chapter.

Kernel mode hosts all privileged processes running at ring 0 of the Intel x86 architecture. Windows NT kernel mode consists of three primary subsystems:

1. Hardware abstraction layer

2. Windows NT kernel

3. Windows NT Executive

Sections 1.3.1 through 1.3.3 look at each of these in turn .

1.3.1 Hardware Abstraction Layer

The hardware abstraction layer ( HAL ) provides protection by controlling access to hardware resources. This is the sole part of Windows NT that has hardware-dependent code (or processor-dependent code) and possibly some assembly language code as well. In general, the HAL provides an abstraction for the purposes of the higher-level components so that they can be shielded from hardware-dependent details. The functionality that the HAL provides includes

• A timer service interface shielding the Windows NT Executive from the specifics of the underlying timer hardware.

• I/O support in terms of bus and DMA (direct memory access) operation support. The HAL translates between external bus and Windows NT addressing information, and it provides support for bus configuration information.

• Interrupt support by mapping the external interrupts to Windows NT interrupt request (IRQ) levels and providing masking/unmasking services for interrupts.

1.3.2 Windows NT Kernel

The Windows NT kernel is the next layer above the HAL and provides functionality that enables the Windows NT Executive (described in Section 1.3.3), as well as other subsystems. Here are the main services provided by the kernel:

• Synchronization assistance

• Scheduling of threads and processes

• Handling of interrupts and exceptions

• System recovery from exceptions ”for example, a power failure

The kernel always resides in memory; it is never paged out to disk as user applications' memory may sometimes be. The kernel cannot be preempted, meaning that execution of code in the kernel can never be suspended in favor of other code unless the kernel voluntarily yields to enable other code to run. The kernel is built as an object-oriented system that uses two classes of objects:

1. Dispatcher objects , which dispatch threads and processes and also synchronize different threads and processes. Dispatcher objects include mutexes, semaphores, and timers. Mutexes are synchronization objects that provide synchronization between two entities. ( Mutex is short for "mutual exclusion.")

2. Control objects , such as asynchronous procedure calls (APCs) and interrupt service routines (ISRs), both of which are described in more detail in Section 1.5.

1.3.3 Windows NT Executive

The Windows NT Executive provides very important functionality, including APIs that enable threads in Windows NT user mode to communicate with the Windows NT kernel to request services. Like the Windows NT kernel, the Windows NT Executive cannot be paged out of memory. The Executive manages multiple operations, including I/O, security, interprocess communication, memory, processes, Plug and Play support, power management, file systems, objects, and graphical devices. All of the Windows NT Executive is located within a single file called ntoskrnl .exe. The Executive creates very few threads to accomplish its work. Typically, a user mode process will request some system services, and the Executive will simply be invoked in the context of this process. One example of a thread created for the Executive is the lazy writer thread that flushes pages to disk.

The Windows NT Executive itself consists of the following components:

• Object Manager

• Security Reference Monitor

• Process Manager

• Plug and Play subsystem

• Power Manager

• Virtual Memory Manager

• Cache Manager

Each of these is described in Sections 1.3.3.1 through 1.3.3.7.

1.3.3.1 Object Manager

The Windows NT Object Manager provides services to the rest of the Windows NT operating system, including the Windows NT Executive (of which it is a part). The Object Manager provides services to name , create, destroy, manipulate, and share objects. The Object Manager interacts heavily with the Security Reference Monitor as a means of ensuring that only authorized processes and users are allowed appropriate access to appropriate objects. The qualifier appropriate refers to the fact that even when access is granted, it is enforced as a type of access, such as read-only access. Every object created by the Object Manager has an associated access control list (ACL). An ACL is really a group of objects specifying what rights are explicitly or implicitly granted to a particular user or group ; the ACL may also have objects specifying what rights are denied .

In addition, the Object Manager assigns a handle to every object it creates. It ensures the uniqueness of handles and can internally transform a handle into a reference to a unique object. However, Object Manager clients (which use the services of the Object Manager) treat the handle simply as an opaque token without any structure. Some examples of the types of objects that the Object Manager deals with include file, directory, port, process, thread, semaphore, and event objects.

1.3.3.2 Security Reference Monitor

The Security Reference Monitor performs access checking and logging for resources. The access checking is done at a highly granular level, including not only whether access is permitted, but also what type of access is permitted ”for example, read-only or read/write access. The functionality of the security subsystem is enabled by the object-oriented nature of Windows NT. When an object is accessed, the Security Reference Monitor simply checks the ACLs associated with the object against the security token of the process before deciding to allow or disallow the access. ACLs are of two types: one that implicitly or explicitly allows a particular access, and another that implicitly or explicitly disallows a particular type of access. The Security Reference Monitor is heavily used by other Executive subsystems, such as the Object Manager.

The Security Reference Monitor also provides similar services for user mode applications. It provides a facility to generate a token (per process) that can be used for security and access checking, as well as for generating audit logs.

1.3.3.3 Process Manager

The Process Manager facilitates creation, deletion, and manipulation of processes and threads. It does not maintain a hierarchy; for example, it does not track parent “child process relationships. That is left to the entity that creates a process. As an analogy, think of a file manager that provides a facility to create a file, but the user of the file manager is responsible for linking the file into a directory structure. The Process Manager uses the services of the Object Manager, as well as the security subsystem, to accomplish its goals. For every process that is started, there are at least two calls to the Process Manager ”the first one to create the process, and the second one to create a thread within the process because every process must have at least one thread.

1.3.3.4 Plug and Play Subsystem

Figure 1.2 shows the power management and Plug and Play (PnP) subsystems in a single box. This is simply to keep the figure from becoming too complicated. In fact, the two subsystems are distinct, though closely related .

Plug and Play is a term used to describe functionality implemented by hardware and software that allows a Windows-based system to dynamically recognize hardware and provide the software support that is needed to operate the device properly. In particular, this software support is responsible for

• Correctly detecting the hardware identity.

• Correctly detecting when hardware is dynamically plugged in or removed.

• Allocating and configuring resources to operate hardware properly.

• Correctly locating and loading the proper device drivers.

• Providing a notification mechanism to detect the arrival and removal of hardware; this notification mechanism can be used by both kernel mode software and user mode software.

The PnP subsystem consists of both user mode and kernel mode components. The user mode component provides applications with a way to accomplish device management, including a registration mechanism by which they can be notified about device arrival and removal.

The PnP subsystem plays an extremely important role in device discovery, device enumeration, device initialization, and device addition/removal. In particular, the PnP subsystem is responsible for generating an important IRP (I/O request packet) called IRP_MN_QUERY_DEVICE_RELATIONSHIPS and sending it to bus drivers. This IRP is often referred to as QDR in Microsoft presentations. This QDR functionality is important because it is used to enumerate devices and build a device stack. Filter drivers are sometimes written to watch for QDR functionality and modify the device list being reported . As will be described in Chapter 6, the Partition Manager is a filter driver that exhibits such functionality.

1.3.3.5 Power Manager

The Power Manager plays an extremely important role in providing power-saving features such as spinning down disks, CD-ROM and DVD drives , and video monitors . Obviously the Power Manager is more important in notebook computers than on servers, but even on servers, the Power Manager has a role to play with hot-swap devices and with monitoring the management of standby power supply devices for servers. The Power Manager also provides APIs for the benefit of higher-level applications.

1.3.3.6 Virtual Memory Manager

The Virtual Memory Manager (VMM) provides memory functionality so that processes can use larger amounts of memory than the amount of physical memory in a system. Application requests for memory allocation are checked by the Virtual Memory Manager. If insufficient memory is left, the VMM tries to move other pages of memory to disk in order to make room for the new allocation to succeed. If an application tries to access a page of memory that is not physically present, the VMM makes room in physical memory before moving the requested pages back from disk to RAM. This functionality is commonly referred to as paging .

The area on disk used to hold pages that do not fit in physical memory is called a swap file . The operating system creates and protects this swap file automatically. An administrator can change the size of the file. This file is also sometimes referred to as a paging file because memory is moved to and from the file in multiples of pages.

With Windows NT 4.0, the total addressable space of 4GB is evenly divided between 2GB in user mode and 2GB in kernel mode. The top 2GB is allocated to Windows NT kernel mode and the bottom 2GB to user mode. With Windows 2000 Advanced Server, a boot-time switch can reallocate the addressable space into 1GB for the kernel mode and 3GB for the user mode. The user mode applications need to be rewritten to take advantage of this extra 1GB of virtual memory. Of course, with 64-bit versions of Windows NT, this restriction does not apply.

The Virtual Memory Manager provides APIs for allocating and freeing memory, as well as for locking down and unlocking memory. Locking down memory refers to functionality that prevents the memory that is being manipulated from being swapped out to disk. This functionality is often mistaken to mean that the physical address of the memory cannot change. Although this is true in the present Windows NT implementation, it may not remain true in future versions of Windows NT. Drivers directly use this API and request pageable or nonpageable memory depending on the particular need.

1.3.3.7 Cache Manager

The Cache Manager is an integral part of the I/O subsystem and works closely with file system drivers and the Virtual Memory Manager. The Windows NT Cache Manager is file system oriented and thus closely coordinated with the file system drivers. This is a change from the Windows 95 caching strategy, which was disk sector oriented. The Cache Manager handles all file systems, local as well as remote, using a single pooled cache. The Cache Manager can cache multiple data streams per file. Data streams are a feature of the NT file system (NTFS) and are explained in Chapter 6, the file systems chapter.

All file I/O appears to be paging I/O because of how the interaction between the Cache Manager and the Virtual Memory Manager is designed. When a file I/O operation is requested, the file system first checks with the Cache Manager to see if the Cache Manager has the required data. If the Cache Manager finds that the requested data is not available, it calls the file system driver to read the data. This is really a circular loop, since the file system asked the Cache Manager for the page and the Cache Manager asked the file system for the page. The difference is that the Cache Manager marks the I/O differently, causing the file system driver to read the data and not bother checking for cached data a second time.

1.3.4 I/O Subsystem

The I/O subsystem is responsible for handling all input/output requests and is designed to accomplish the following:

• Provide extremely fast I/O response on single- and multiprocessor systems.

• Provide asynchronous I/O. Synchronous I/O is actually done as an asynchronous I/O request followed by a blocking wait for that I/O to complete.

• Support multiple file systems ”for example, CDFS, NTFS, UDFS.

• Provide a modular architecture that supports addition of new file systems and devices.

• Provide for devices (and their associated drivers) to come and go, on the fly, without requiring a reboot (really implemented in Windows 2000 and subsequent Windows NT products).

• Provide for advanced features such as caching and memory-mapped files. Memory-mapped files are a feature that offers the ability to have a file's contents mapped into a specified memory location in the process address space. To access or modify the contents of the file, the application simply reads or writes from the specified address space.

• Provide for protection of resources that are shared across various processes.

To achieve these goals, the I/O system is built as a modular system (like the rest of Windows NT) consisting of the following modules:

• I/O APIs

• I/O Manager

• File system drivers

• Other drivers (such as disk drivers or keyboard drivers)

These modules are described in Sections 1.3.4.1 through 1.3.4.3.

1.3.4.1 I/O APIs

The term I/O APIs refers to functionality provided by the I/O Manager for the benefit of upper layers of Windows NT, as well as kernel mode components to accomplish I/O Manager “related operations. All the I/O API names are in the form "IoXXXX," where "XXXX" is a string followed by parameters. (See the Driver Development Kit for complete details.) Some good examples of APIs involved here include

• IoCreateDevice , to create a new device object. Device objects are described in Section 1.4.2.

• IoCallDriver , to send an I/O request packet to a driver (I/O request packets are described in Section 1.4.3).

1.3.4.2 I/O Manager

The I/O Manager is part of the core NT kernel Executive and provides a variety of functions, including the following:

• Building I/O request packets (IRPs) and directing them to the appropriate driver, as well as routing IRPs between drivers.

• Deleting or freeing IRPs when the I/O operation is complete.

• Interfacing with the Cache Manager and other parts of the NT Executive system.

• Interfacing with the Virtual Memory Manager to provide memory-mapped I/O for file systems.

• Keeping track of which file systems are loaded and invoking them as needed.

• Providing support for synchronous and asynchronous I/O. Asynchronous I/O is particularly important for storage applications; for example, a backup application will want to use asynchronous I/O to queue multiple requests so that it can keep the tape device busy.

• Managing buffers for an I/O operation.

1.3.4.3 File System Drivers

Windows NT implements file system functionality using kernel mode drivers. Windows NT ships with the following file system drivers:

• NTFS (NT file system)

• UDFS (universal disk file system)

• CDFS (CD-ROM file system)

• FAT (file allocation table)

Network file system drivers are covered in Chapter 3. File system drivers are implemented via the Windows NT DDK and an add-on product that Microsoft sells, called the Windows NT Installable File System Kit . This kit documents the various APIs needed to write file system drivers and also contains sample code that implements a FAT and a UDFS file system.

File system drivers behave like other drivers in the sense that they interact with the I/O Manager and deal with I/O request packets. File system drivers are logical drivers in that they do not directly deal with hardware; for example, a file system does not care whether it is getting data from a SCSI disk or an ATA (also referred to as IDE) disk. However, file system drivers are also different from other drivers. Here are some of the differences:

• File system drivers are always called in the context of the thread that requests the I/O operation.

• File system drivers interact heavily with the Cache Manager and the Virtual Memory Manager, simply using these two modules to implement its data buffering. For example, the file systems use the Cache Manager services to cache file system metadata such as locations of files or directories on disk to avoid generating a heavy overhead of repeatedly fetching the same metadata.

• File system drivers are the only drivers that implement a method of I/O that is not IRP based. This method is called Fast I/O and consists of some entry points within the driver. The I/O Manager calls these entry points to do an I/O operation in the hope that the data is cached and can be handled quickly. The file system driver can make the call fail if appropriate, and the I/O Manager will simply reissue the same I/O request using the regular IRP method.

Closely associated with the notion of file systems is the notion of file system filter drivers. File system filter drivers are used to implement a wide range of important functionality, such as encrypting file systems and Remote Storage Services. The different types of functionality are discussed in the appropriate chapters.

1.3.5 Graphical Subsystem

Given that the focus of this book is enterprise storage, Figure 1.2 depicts the graphical subsystem in kernel mode even though a portion of it is also in user mode. Windows 2000 moved a considerable amount of graphical subsystem code from user mode to kernel mode primarily to improve performance. For the purposes of this book, the graphical subsystem can be thought of as containing all the code that pertains to windowing and using video devices, scanner devices, printer devices, and so on.

1.3.6 Win32 Subsystem

The Win32 subsystem is one of the most important elements of Windows NT, especially for programmers. It provides the Win32 APIs for the benefit of the programmer. The Win32 APIs are also the platform upon which other subsystems, such as the POSIX subsystem, build.

The Win32 API set can be broadly divided into three categories:

1. Windowing and window messaging APIs are implemented in a dynamic link library called user32.dll. This DLL is then linked with applications that use any API exported by this file. Multiple applications that link with this file and are running will share a single copy.

2. Graphical drawing APIs are implemented in a dynamic link library called gdi32.dll, which is then linked with applications that call any API exported by this library. In Windows NT versions prior to Windows 2000, gdi32.dll acted as a client and contacted the Win32 server process (described later) because the functions were implemented in the Win32 server process. The Win32 server would then call on the kernel mode component of the graphical subsystem as needed. In Windows 2000, gdi32.dll directly calls the kernel mode graphical subsystem as needed.

3. Base functionality APIs such as APIs to open a file (CreateFile), read a file (ReadFile), and write a file (WriteFile) are implemented in a dynamic link library called ntdll.dll. This library makes a call to the kernel mode Executive as needed. To make this call, the library uses one of the 256 interrupts defined by the Intel x86 architecture. In particular, it uses the interrupt 46 (decimal 46, hexadecimal 0x2E). The interrupt handler ^[2] validates the API requested (by a simple table lookup) and the parameters passed for that API. If all parameters pass validation tests, the handler then calls the appropriate Executive subsystem to perform the requested operation.

   ^[2] Strictly speaking, this is not just an interrupt handler, but the details are not relevant here and hence it is referred to as simply an interrupt.

Applications are written with the Win32 APIs and other support mechanisms described in the software development kit (SDK). In some senses, even the POSIX subsystem is an application tool, developed to support UNIX applications. Although the POSIX subsystem is not as important as it once was, it still provides a good example of the Windows NT modular and extensible architecture.

---

Top