Jeff Prosise
THINK ABOUT MICROSOFT CORP.'S WINDOWS NT, AND security, stability, and reliability quickly come to mind. Ask people who use it on a daily basis, and they'll tell you Microsoft Windows NT systems that crash are about as common as 286-based machines running Windows 1.0 are today.
It's natural for users to be concerned when fundamental changes are made to Windows NT in order to increase performance and reduce memory requirements. That Windows NT 4.0 is a leaner operating system than its predecessors is an indisputable fact. The question is whether the architectural changes responsible for the improvements threaten to compromise the operating system's legendary reliability. Some say Microsoft made a pact with the devil in an effort to fit Windows NT on the desktop. Microsoft insists that Version 4.0 is every bit as reliable as its predecessors and faster, too. So who's right? Is Windows NT 4.0 as stable as previous versions? More important, does upgrading to Version 4.0 pose a risk if your company's mission-critical servers are currently running Windows NT 3.51?
The Old Windows NT Architecture
Versions of Windows NT up to and including Version 3.51 use the "modified microkernel" architecture shown in Figure 1 of "Windows NT 4.0: Rebuilt for Speed." Core operating system services used for thread scheduling, multiprocessor synchronization, and other low-level tasks are implemented in the microkernel. Virtual memory management, process management, and other operating system services are implemented in a separate layer on top of the microkernel, and the microkernel itself is insulated from the physical characteristics of timers, interrupt controllers, and other hardware devices by services in the Hardware Abstraction Layer (HAL). Together, these modules form the Windows NT Executive.
Modern microprocessors allow threads of execution--paths taken through code stored in memory--to run at various privilege levels. Code running at a high privilege level can access data at lower privilege levels, but code running at a low privilege level can't access data in memory marked with higher privilege levels. The NT Executive runs in kernel mode, which is the highest privilege level that the processor offers. On Intel x86 processors, which support four privilege levels referred to as rings 0 through 3, kernel mode is synonymous with ring 0. Applications run in user mode (ring 3 on Intel CPUs), so the protection mechanisms built into the processor protect the NT Executive from application programs.
Each application hosted by Windows NT constitutes one process, and each process runs in a separate address space where it is physically isolated from other processes. Before transferring control from one process to another, the operating system alters the processor's page tables so that each process sees only its own code and data. It's not possible for one process to access code or data belonging to another process.
One of the most remarkable aspects of Windows NT's architecture is that portions of the operating system--the subsystems--run in user-mode processes alongside application processes. The subsystems provide the environments in which applications run. The Win32 subsystem provides the application program interface (API) services that Win32 applications call to do useful things such as create windows and open files. The Posix and OS/2 subsystems provide similar API services to character-mode Posix and OS/2 applications. (Of course, all OS/2 applications that anyone cares to run are graphical.) Applications and subsystems enjoy a client/server relationship in which the applications are the clients and the subsystems are the servers. One of the benefits of this architecture is that you can include support for other types of applications (Unix applications, for example) to Windows NT simply by adding subsystems.
Much of Windows NT's renowned stability is a direct result of the operating system's architecture. Applications can't interfere with one another because they run in separate address spaces. Operating system code and data in the subsystems is protected from applications because subsystems, too, reside in their own address spaces. The Windows NT Executive shares address space with running processes, but it's protected by the wall between kernel mode and user mode. It's impossible for an application to corrupt code or data stored in the Windows NT Executive because the processor notifies the operating system of or prevents invalid memory accesses before they occur.
Ultimately, an operating system's reliability and resistance to application-induced crashes is a function of how effectively it guards itself and the processes it hosts from other processes. Windows NT excels in this regard because of the high level of protection it provides both to the operating system and to its application programs.
But reliability doesn't come for free. When a Windows application calls an API function in the Win32 subsystem (as might happen several hundred times per second), the operating system has to perform a context switch from the calling process to the subsystem process and then back again. Context switches are costly in terms of performance. So are the ring transitions--shifts from one privilege level to another--that are incurred when ring 3 code calls code in ring 0. Ring transitions occur because applications running in user mode use the Windows NT Executive's kernel-mode Local Procedure Call (LPC) Facility to communicate with the subsystems, and also because the subsystems must call into kernel mode to invoke services in the Windows NT Executive.
Why Windows 95 Is Faster
Windows NT's architects included a number of optimizations to reduce the number of ring transitions and minimize the impact of context switches. But even at its fastest, Windows NT runs slower than Windows 95, which trades reliability for performance by placing most of its operating system code and data in ring 3, in the same address spaces in which processes run. This increases performance by reducing the overhead associated with API functions (calling an API function requires neither a context switch nor a ring transition), but it compromises reliability by exposing portions of the operating system to applications. Though Windows 95, which runs processes in separate address spaces, is more crashproof than Windows 3.1, a buggy application can still overwrite parts of the operating system, causing a system crash. In Windows NT, an application can crash itself, but it can't bring down the operating system, because it can't access memory containing Windows NT code and data.
Another drawback to placing API services in subsystems that run apart from applications is that extra memory is required to pass data between application processes and subsystem processes. For every application thread that calls a window manager or Graphics Device Interface (GDI) API function, the system creates a matching server thread in the Win32 subsystem as part of a high-performance interprocess communication mechanism called Fast LPC. Paired threads boost performance, but they also require memory. To make matters worse, each thread pair is accompanied by a shared memory buffer--a region of memory visible to two processes--that serves as a window for passing data. It's not uncommon for 100 or more server threads to be extant in a Windows NT 3.x system at once, with memory requirements exceeding 1MB. That's one reason Windows NT requires more memory than Windows 95, which neither uses Fast LPC nor requires shared memory for its API functions.
The New Windows NT Architecture
In order to boost performance and reduce memory requirements, the designers of Windows NT 4.0 decided to move many of the operating system's API services out of the Win32 subsystem and into the operating system kernel. Figure 2 of "Windows NT 4.0: Rebuilt for Speed" shows the effect on the operating system's architecture. The new Win32K Executive houses three important elements of the operating system: the window manager, the GDI, and the graphics device drivers that render GDI output on screens and printers. In Windows NT 3.x, these components were part of the Win32 subsystem (see Figure 3 of "Windows NT 4.0: Rebuilt for Speed"). In Windows NT 4.0, they're part of the Windows NT Executive, where, like other kernel-mode services, they can be accessed in the context of calling processes.
The new architecture promises to deliver dramatic increases in performance, particularly in the execution of graphics. All output to the screen is performed through function calls to the GDI. Now that the GDI is part of the kernel, applications can call GDI functions directly and avoid costly context switches, video drivers can get to the hardware more quickly, and Win32 API services can call services in the Windows NT Executive without incurring ring transitions.
Calling GDI and window manager services from a ring 3 application still forces ring transitions, but once again Microsoft has instituted some clever optimizations to maximize performance. One example: If several GDI functions are called in rapid succession, they're queued up in user mode and "batched" to kernel mode as a group to minimize the number of ring transitions. According to Microsoft, the new GDI architecture should allow graphics-intensive applications such as PowerPoint to draw images 15 to 20 percent faster. Though our informal tests with PowerPoint did not support that assertion, we did see improved performance with 3D Pinball, Microsoft's graphically intensive pinball game.
Performance in other areas is improved, too. Moving the window manager to the kernel eliminated a key bottleneck that limited bandwidth between the window manager and application programs that call window manager services.
And what about memory? Now that the bulk of the code and data implementing the operating system's Win32 API services is mapped into the address of every process, there's no longer a need for server threads and shared memory buffers. Consequently, the system's appetite for memory is reduced. The savings are roughly offset, however, by the enlarged footprint of the user interface shell. So while it's truethat Windows NT 4.0 uses memory more efficiently than did Version 3.x, it's also true that you'll still need at least 16MB of RAM to achieve minimally acceptable performance.
Reliability and Security
The big question that looms over Windows NT 4.0 is what, if any, impact the architectural changes will have on reliability and security. Will improvements made in the name of performance make a Windows NT server or workstation more likely to crash? And will the new architecture diminish the operating system's vaunted security, which allows a properly configured system to comply with the U.S. government's Class C2 security standards?
Only time will tell for sure, but the answer to the question of whether the changes will affect stability is a cautious no. Operating system code moved from the Win32 subsystem to the Windows NT executive is no less protected now than it was before, although it's now protected in a different way. Critics point out that a buggy video or printer driver may now be able to crash the kernel, whereas before it could only crash the Win32 subsystem. Microsoft argues--correctly--that both Windows NT 3.x and 4.0 are only as stable as the device drivers one uses with them. That's why Microsoft tests device drivers for Windows NT, including those written by third parties, and certifies only the ones that pass muster. If the quality of Windows NT 4.0 graphics drivers meets or exceeds the quality of Version 3.x graphics drivers, there's no reason Windows NT 4.0 can't be every bit as reliable as 3.x. On the other hand, installing an uncertified graphics driver in a Windows NT 4.0 system is theoretically riskier than installing the same driver in a 3.x system, because Windows NT 4.0 graphics drivers operate in the CPU's privileged kernel mode.
As for security, Windows NT 4.0 is built to meet Class C2 security standards, just as its predecessors were. The architectural changes do not affect the security subsystem, which like the other subsystems runs in a separate user-mode process.
The subtle changes to Windows NT's architecture in Version 4.0 reflect a new attitude on the part of its designers. Originally, Windows NT was envisioned to be an "equal opportunity" operating system that could run other operating systems' applications as easily as its own. But now that the Win32 API has assumed center stage, Windows NT has been optimized to run Win32 applications faster than ever before. Windows NT 4.0 performs noticeably faster than its predecessors, and it apparently does so without compromising the qualities that made Windows NT famous. All things considered, its users could hardly ask for more.