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.
