Evaluating the Change

Several features of the Windows NT operating system simplified this change from user mode to kernel mode:

• The modularity and extensibility of Windows NT Executive made it possible to add new components without disrupting existing ones.

• Application program interfaces are linked dynamically at run time, so code within the functions could be changed without recompiling all applications that used them. Also, no function calls or returns were changed, so these revisions of the Windows NT 4.0 architecture should be transparent to applications and users. Only user-mode printer and display drivers must be rewritten to run in kernel mode.

• Shifting the graphics functions into the Executive also simplified the operating system code and the process applications use to access Executive services. When an application calls a USER or GDI function now, the entry point executes a single kernel-mode trap call to switch the thread to kernel mode, eliminating the need for shared memory buffers and paired threads. After the thread transition is complete, application threads can run in the Executive and Microkernel code directly without further kernel-mode transitions or context switches. The savings is especially apparent in repeated, resource-intensive activities, such as high-frequency and high-bandwidth interactions with video hardware.

Although the new architecture eliminates many thread and process transitions, the kernel-mode transitions still take time and memory. Accordingly, GDI batching and caching have been retained to offset the effect. With batching, graphics calls are saved until a certain number (the default is ten) accumulate in a queue, and then the whole queue is sent to GDI in a single transition. With caching, read-only properties and data structures are stored near the application after they are retrieved, allowing subsequent retrieval to be nearly instantaneous.

Pure vs. Modified Microkernel Architecture

Along with the benefits comes a cost: Windows NT 4.0 is moving farther away from pure microkernel architecture.

Pure microkernel systems satisfy two criteria: They are modular, and they keep the number of the components running in kernel mode to a minimum. The ideal is to have only the hardware-manipulating segments of the operating system and the Microkernel running in kernel mode. The remaining operating system functions would run in user mode.

But the appeal of pure microkernel systems pales upon examination of their costs: They are inherently slow and inefficient, with every function requiring several process and thread transitions, memory buffers, and context switches.

Windows NT is completely modular. Each function is managed by just one component of the operating system. The rest of the operating system and all applications access that function through the responsible component using well-defined, secure interfaces. Data is encapsulated and hidden and there are no alternative routes to it. Modules can be upgraded, removed, and replaced without rewriting the entire system or its standard APIs.

However, Windows NT has always had a modified microkernel architecture: Its high-performance subsystems run in kernel mode where they interact with the hardware and each other without thread and process transitions. The Windows NT I/O Manager, Object Manager, Process Manager, Virtual Memory Manager, Security Reference Monitor, and Local Procedure Call facilities have always been part of the Windows NT Executive. Even segments of the graphics handling system, such as video ports, class drivers, and file systems drivers, have always run in kernel mode. So, the movement of USER, GDI, and graphics device drivers to the Executive simply completes this trend.