The Windows NT System Design Model

As you’ve probably heard before, a picture is worth a thousand words, so I’m going to put that to the test. Figure 1.1 is a basic picture of the Windows NT system design model, and it illustrates several of the more important features. I like to think of Windows NT as a mainframe operating system that has been scaled down a bit to run on your desktop. And as such, it includes many of the features of a mainframe operating system. Specifically, I want you to note that, like a mainframe operating system, Windows NT incorporates a split in the process hierarchy. This split includes a kernel mode (ring 0, on Intel CPUs), where the core operating system executes, and a user mode (ring 3, on Intel CPUs), where your applications, the environmental subsystems, and services execute. Now let’s begin our exploration of the Windows NT system design with a closer look at the kernel-mode components and the user-mode components.

Figure 1.1  The Windows NT system design model.

Kernel-Mode Components

The split architecture is utilized to keep an errant application from bringing down the operating system. And just like a mainframe operating system, a split architecture cannot protect you from design flaws in the kernel, including poorly written device drivers. Any error in the kernel is trapped, and if possible, an error handler will execute to maintain system integrity. However, if a device driver or other kernel component has an unrecoverable error, then Windows NT will display a kernel core dump. I, and many others, often refer to this as the blue screen of death because what you will see on the screen is a blue background with white characters. This dump includes an error code, a device driver listing with address location, and a stack dump of the offending driver(s). Just to ease your mind a bit, core dumps are very infrequent with Windows NT Server. And if you use supported hardware and software, there is a good chance you will never see one.

---

WARNING:  Development tools, such as Visual C++, interrelate with the operating system at very low levels during the build and debug stages. And it is possible during one of these actions to hang the Win32 subsystem or the complete operating system. Therefore, if you are developing applications for Windows NT Server, never do so on a production server. Always create a stand-alone network (server and workstations) for your development efforts to avoid any potential server downtime.

---

Continuing our discussion of kernel components, take a closer look at Figure 1.1. Notice that the core operating system component is called the Executive and includes many subcomponents. From left to right and top down, these subcomponents are:

•  Object Manager—This component is responsible for basic object management, as the name implies. These objects include the object name space (used to resolve an object name to an object handle for use by an application), resource sharing, some security related usage, and user visible events (like windows, processes, events, and files). Everything in Windows NT is an object, although Windows NT is not an object-oriented operating system. And the object is the key to the security features provided by Windows NT.

•  Security Reference Manager—his component is used in conjunction with the object manager to determine if a user or process has sufficient privilege to access or create an object. As an object is created, it is assigned a security descriptor which can later be used to limit access to the object. If no security descriptor is explicitly assigned, then the owner’s (the person who created the object) security descriptor will be applied.

•  Configuration Manager—This item is used to access the registry. We will talk more about the registry and registry editors in Chapter 13, “Tuning The Registry.” For now, you can consider the registry as the INI file replacement for Windows 3.x. It is the storehouse for all configuration data for Windows NT.

•  Process Manager—This component is responsible for managing (creating, terminating, suspending, and resuming) processes and threads executing on the system.

•  Local IPC Manager—This component is the heart of the message-passing mechanism, which enables Windows NT to be such a good distributed computing operating system. It includes a fast and efficient mechanism, based on the industry standard remote procedure call (RPC) interface, to facilitate interprocess communication (IPC). This IPC mechanism is used to pass messages between the various clients (MS-DOS, Win16, Win32, POSIX, and OS/2) and the environmental subsystem servers (Win32, POSIX, and OS/2) as well as between the environmental subsystems and the executive. Building on this same interface provides the ability to communicate between remote computers and provide full client/server functionality across the entire network.

---

Note:  One of the interesting features produced by this mechanism is the ability to convert an RPC-enabled application to an LPC-enabled application. An LPC application is an application that has both the client and the server applications executing on the same computer, instead of on two computers. Simply changing the server name in the communication linkage to a single period will enable LPC instead of RPC for the transport mechanism. And LPC executes the same action faster than RPC. For instance, if you are using SQL Server on your computer for testing a new database design before you implement it on the server, you could create a named pipe with the format \\ServerName\Pipe\SQL\Query and use RPC, or you could use a pipe with the format \\.\Pipe\SQL\Query and use LPC.

---

•  Virtual Memory Manager—This component is responsible for all memory manipulation, including, but not limited to, the virtual to logical to physical memory address translation, shared memory between processes, and memory-mapped files. It also includes the management of your paging files as this is where your virtual memory, memory-mapped files (by default, although memory-mapped files can use a different file name if the application supports it), and stop-event debugging information are read/written.

•  I/O Manager—This component is special because it contains several subcomponents, unlike all the other components, which only manage one object type. These subcomponents are all I/O (input/output) related but have different tasks to accomplish. The I/O manager subcomponents include the file system drivers (NTFS, FAT, HPFS, CDFS, and any third-party additions), cache manager (which hooks in the file systems to cache all file access, including network access), device drivers (used to access system resources), and network device drivers.

•  Kernel—This small component (about 60K) is responsible for all process and thread scheduling, multiprocessor synchronization, and managing all exceptions (software generated) and interrupts (hardware generated). It is nonpagable (which means it is always resident in physical memory), nonpreemptive (no other thread of execution has a higher priority), and is interruptible (so it can handle hardware-generated interrupts).

•  Hardware Abstraction Layer (HAL)—The HAL is designed as the major interface to the hardware on a computer system. It is designed to isolate hardware-dependent code and is written in Assembly language (unlike the other components, which are written in C) for maximum performance. Most executive components access the system hardware through interfaces provided by the HAL, but the kernel and I/O manager can access some hardware resources directly.

And that pretty much takes care of the kernel-mode components aside from the Graphics Device Interface (GDI). In earlier versions of NT, the GDI was executed in the user-mode context. With NT Server 4.0, however, the GDI executed in kernel mode. This provides improved graphics performance at the expense of system reliability. It also required that all video device drivers be rewritten by their respective manufacturers. Now, let’s review the user-mode components.