Chapter 5 - Windows NT 4.0 Workstation Architecture

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

When you first look at Microsoft Windows NT 4.0, you'll notice the popular, functional interface introduced with Microsoft Windows 95. But, beneath that pretty face is the robust, preemptive multitasking, 32-bit operating system Microsoft designed for high-end users. This version was founded upon the same design principles as previous versions, and it maintains their most important advances.

Windows NT 4.0 continues to be compatible with many other operating systems, file systems, and networks. It runs on both complex instruction set computers (CISC) and reduced instruction set computers (RISC). Windows NT also supports high-performance computing by providing kernel support for symmetric multiprocessing.

The major architectural change in this version of Windows NT is the move of the Window Manager, Graphics Device Interface (GDI), and higher-level device drivers from the Win32 environment subsystem into the Windows NT Executive as an executive service. The first section of this chapter describes that change.

Other changes include:

• Support for Distributed Component Object Model (DCOM) applications. For more information on DCOM see "Distributed Applications and Windows NT" in Chapter 1 of the Windows NT 4.0 Server Networking Guide and "Sharing DCOM Applications" in Chapter 4 of Windows NT 4.0 Concepts and Planning.

• Support for DirectDraw™, DirectSound™, and DirectPlay™, components of DirectX™, the Windows 95 high-performance interface for games and other interface intensive applications. For more information, see "DirectX" later in this chapter.

This chapter provides an overview of the architecture. Other chapters in this book provide details about particular components such as the Windows NT security model, integrated networking features and connectivity options, Windows NT file systems, and the printing system.

What's Changed for Windows NT 4.0

In this release of Windows NT, the Window Manager (USER) and Graphics Device Interface (GDI) have been moved from the Win32 subsystem to the Windows NT Executive. Win32 user-mode device drivers, including graphics display and printer drivers, have also been moved to the Executive. These changes are designed to simplify graphics handling, reduce memory requirements, and improve performance.

An illustration of the architecture of Windows NT 3.51 and an illustration of the architecture of Windows NT 4.0 appear on facing pages on the inside back cover of this book.

Graphics Handling: Before and After

Previous versions of Windows NT included the following elements:

• Console, which provides text window support, shutdown, and hard-error handling.

• Window Manager (USER), which controls window displays, manages screen output, collects input from keyboard, mouse and other devices, and passes user messages to applications.

• Graphics Device Interface (GDI*),* a library of APIs for graphics output devices. It includes functions for line, text and figure drawing and graphics manipulation. The Window Manager calls these APIs, but user-mode applications can call them directly.

• Graphics Device Drivers, which collect and format data for hardware-dependent drivers in the Executive. The graphics display drivers, printer drivers, multimedia drivers, and video display drivers were part of the Win32 subsystem and ran in user mode. These drivers then call kernel-mode drivers in the Executive which interact with the hardware.

• Miscellaneous environment functions, special functions for 32-bit Windows applications, like those for creating and deleting processes. 

The following figures show how the contents of the Win32 subsystem have changed from Windows NT 3.51 to Windows NT 4.0.

 

Figure 5.1 Contents of the Win32 Subsystem under Windows NT 3.51 

 

Figure 5.2 Contents of the Win32 Subsystem under Windows NT 4.0 

In Windows NT 4.0, the Window Manager, GDI, and Win32 Graphics Device Drivers have been incorporated into the Windows NT Executive. The user-mode portions of Window Manger and GDI, Gdi32.dll and User32.dll, remain in user mode, along with the Console and miscellaneous environment functions. They run in the process created by the Client Server Runtime Subsystem, Csrss.exe, which once included all graphics functions in Win32. The server side functions of GDI and Window Manager, previously known as Winsrv.dll, have been incorporated into the Executive as Win32k.sys.

For a complete description of these components, see the section on the Windows NT Executive, later in this chapter.

Kernel Mode and User Mode

The most significant aspect of this change is that graphics services, which used to run in user mode like applications, now run in kernel mode like most of the operating system. The idea behind kernel mode and its alternative, user mode, is to separate applications from the operating system. Applications run in user mode; operating systems run in kernel mode.

Kernel mode is a highly privileged mode of operation where the code has direct access to all memory, including the address spaces of all user-mode processes and applications, and to hardware. Processes running in kernel mode have access to advanced CPU features for I/O and memory management. However, operating system memory is strictly protected and this protection is enforced by the processor. Applications cannot directly access hardware or the memory of any kernel-mode service. Kernel mode is also known as supervisor mode, protected mode, and Ring 0.

Note In earlier documentation, the terms kernel and microkernel were used interchangeably. In this document, kernel refers to a highly privileged mode of processing. The Microkernel is a component of the core operating system that provides basic operating system functions, like thread dispatching, interrupt handling, and multiprocessor synchronization.

Applications run in user mode. They have access only to their own address space and must use established interfaces to obtain other system services. This protects the operating system and improves its performance.

Environment subsystems, like those supporting Win32, POSIX, and OS/2, and integral subsystems, like Security, run in user mode but have protected address spaces. Each subsystem is a separate process and the operating system protects its memory from other subsystems and applications.

Communication between Processes

The logical boundary that separates user-mode and kernel-mode processes is designed to make the system robust by preventing direct access to hardware and protecting the core operating system from bugs and unauthorized access by user-mode processes. A failing application will not interfere with the operating system or its support of other applications.

To cross this boundary, user-mode processes must use well-documented application program interfaces (APIs) to switch their threads from user mode to kernel mode. Such a conversion is called a kernel-mode transition. Kernel-mode threads can use Executive services but must be switched back to user mode to return control to the application.

Accessing an environment subsystem involves several kernel/user mode transitions and consumes substantial memory and processor time. This is an example of a graphics call in previous versions of Windows NT. It demonstrates that interprocess communication can be quite complex, even when optimized:

• The application uses an API to make a graphics call to a user-mode dynamic link library. The component that implements the call makes a kernel-mode trap call to the Executive to switch its thread and copy its call parameters from its user mode stack to its kernel mode stack. Then, the processor's stack register is switched to point to kernel mode. Now the thread can run in the Executive.

• Applications communicate with protected subsystems by using local procedure calls (LPC), an application-independent method of communication between components on the same computer. After the thread is switched to kernel mode, the Microkernel schedules the LPC for delivery.

• Using Fast LPC, an optimized communication method, the Microkernel recognizes that the call from the application involves a thread in the environment subsystem. It considers the calling application thread and the receiving subsystem thread to be paired. The receiving thread can now use the unexpired time from the sending thread.

• The graphics call parameters are passed to the receiving subsystem thread. The receiving thread switches back to user mode to fulfill the graphics request.

• The subsystem completes its task and then returns control to the waiting calling thread in the application by the same method.

• The calling thread (from the DLL) is switched back to user mode before returning control to the application.

Microsoft operating-system engineers also used the concept of a shared memory window to speed up communication. Data is placed in a temporary shared memory window administered by the Process Manager in the Executive. This lets the application see into the subsystem's memory and share data without using LPCs. However, because the application thread must still run in the Executive, kernel/user mode transitions and thread switches are still required.

Why Change?

When Windows NT was first designed, the Win32 environment subsystem was designed as a peer to the environment subsystems supporting applications in MS-DOS, POSIX, and OS/2. However, applications and other subsystems needed to use the graphics, windowing, and messaging functions in the Win32 subsystem. To avoid duplicating these functions, the Win32 subsystem was used as a server for graphics functions to all subsystems.

This design worked respectably for Windows NT 3.5 and 3.51, but it underestimated the volume and frequency of graphics calls. Having functions as basic as messaging and window control in a separate process generated substantial memory overhead from client/server message passing, data gathering, and managing multiple threads. It also required multiple context switches, which consume CPU cycles as well as memory. The volume of graphics support calls per second degraded the performance of the system. It was clear that a redesign of this facet in Windows NT 4.0 could reclaim these wasted system resources and improve performance.

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.

Performance and Memory

Making USER and GDI into Executive service components decreases their size and improves graphics performance. It eliminates shared memory buffers, reduces code size and complexity, and reduces thread transitions and context switches. For example, accessing GDI from the Win32 server on an Intel Pentium 90 takes at least 70 microseconds while accessing it in kernel mode takes 4 to 5 microseconds. When users are waiting for complex screen changes, these difference are noticeable. Graphics-dependent applications like Microsoft PowerPoint® run 15 to 20% faster on Windows NT 4.0.

Windows NT 4.0 is also much more efficient in its use of memory. It is estimated to save from 256K on machines running single applications to 1MB for users who have several applications running simultaneously. Some of this savings comes from simplifying the code needed to access graphics functions, but most comes from eliminating the 64K shared memory window used to optimize graphics performance in earlier versions of Windows NT.

These marked improvements allow us to incorporate new functionality, like the Windows 95 interface, with no net loss in performance or increase in memory requirements. Overall, the memory use and performance of Windows NT 4.0, should be very close to that of Windows NT 3.51.

Windows NT Design Goals

Windows NT 4.0 adheres to the design goals established for all versions of Windows NT and extends them.

Compatibility

Compatibility is apparent in the integration of the popular Windows 95 interface, continued support for the FAT file system, for MS-DOS, OS/2, Windows 3.x and POSIX applications and for a wide variety of devices and networks.

Scalability and Portability

Portability means that Windows NT runs on both CISC and RISC processors. CISC includes computers running with Intel 486 or higher processors. RISC includes computers with MIPS R4000or Digital Alpha AXP, or PowerPC processors.

Scalability means that Windows NT 4.0 takes full advantage of symmetric multiprocessing hardware. It allows the Microkernel to execute on any processor and allows the processors to run any thread. It does this, in part, by allowing the Microkernel to preempt lower priority threads and requiring all code to be reentrant, even in the Executive.

Incorporating Win32 graphics functions into the Executive significantly improves the scalability of Windows NT because graphics calls no longer involve context switches. Context switching requires systemwide spinlocks which limit the efficacy of multiple processors. The simple kernel mode thread transitions now involved in graphics calls do not require spinlocks.

In addition, although the Window Manager and GDI now run in kernel mode, these threads are all still scheduled and preemptible and all code is reentrant. In fact, only Microkernel code which, technically, does not run on a thread, is not preemptible.

Also, the threads of the GDI still run asynchronously; that is, they do not wait for the threads of other applications and do not require application threads to wait for them. On multiprocessor computers, multiple threads can run in Window Manager and the GDI simultaneously. GDI synchronizes with applications only when they need access to the same device. This allows the threads of the GDI, and of the applications that call its functions, to run on any available processor.

Windows NT 4.0 applications now use a single thread to get graphics services from the Executive. Previous versions required two paired threads; one in the application and one in the Win32 subsystem. Ironically, Windows NT 4.0 is not losing the efficiency of running parallel threads simultaneously, just because it never had it. Even on symmetric multiprocessing systems, almost all calls to Win32 run synchronously. Each thread each waits for the other to finish before proceeding. However, even this single-threaded system runs more efficiently on multiprocessor systems than the double-threaded model because costly context switches are eliminated. Also, less memory is required when graphics services run in the context of a single thread, instead of paired thread stacks.

Security

Windows NT has a uniform security architecture designed to provide a safe environment to run mission-critical applications as judged by government security standards. Windows 3.5 has been evaluated by the United States National Computer Security Center as meeting the requirements of C2 level security. Windows NT 4.0 with networking is currently undergoing this evaluation.

Windows NT 3.51 is being evaluated in the UK and Germany for a F-C2 / E3 security rating. Windows NT 4.0 will be subject to the same standards.

The Windows NT 4.0 architectural changes do not affect the integral security subsystem or the Security Reference Monitor in the Executive. They are not expected to affect the U.S. or European security evaluations of Windows NT 4.0.

For more information about Windows NT Workstation security, see Chapter 6, "Windows NT Security." For more information about the C2 Evaluation of Windows NT, see the Windows NT Administrator's Security Guide. (It is available from Microsoft. Refer to Part #236-074-495.)

Distributed Processing

Distributed processing means that Windows NT is designed with networking built into the base operating system. Windows NT also allows for connectivity to a variety of host environments through its support of multiple transport protocols and high-level client-server facilities including named pipes, remote procedure calls (RPCs), and Windows Sockets.

Reliability and Robustness

Reliability and robustness mean that the architecture must protect the operating system and its applications from damage. In Windows NT 4.0, as in earlier versions, applications run in their own processes and cannot read or write outside of their own address space. The operating system data is isolated from applications. Applications interact with the kernel indirectly using well-defined user-mode APIs. Each call requires a kernel mode thread transition that is managed by the Windows NT Executive.

Kernel-mode operations are now more vulnerable to failures in the graphic user interface. As a user mode process, the graphics subsystems could not bring down the operating system but, as components of the Windows NT Executive, they can. This is mainly an issue for servers and peer-to-peer workstations. If a single workstation interface no longer responds to the user, it hardly matters that the operating system is still up and running. In fact, the USER and GDI are so critical that Windows NT has always been designed to shut down if they fail.

A more serious concern is that the USER, GDI, and device drivers can potentially overwrite the data structures of core operating system components. However, this threat is not new. Hardware drivers, like video ports, network card drivers, and hard disk drivers, have always run in kernel-mode. Microsoft offers technical assistance to manufacturers to ensure that their drivers are reliable.

Localization

Localization means that Windows NT is offered in many countries around the world, in local languages, and that it supports the International Organization for Standardization (ISO) Unicode standard.

Extensibility

Extensibility refers to the modular design of Windows NT, which, as described in the next section, allows Microsoft to add new modules to all levels of the operating system. As the industry advances, new features can be added without compromising the stability of the operating system. The new Windows NT 4.0 architecture demonstrates that modules can be moved within the operating system without disturbing existing components.

Windows NT Architectural Modules

Windows NT has a modular architecture, meaning that it comprises separate and distinct components, each having sole responsibility for its functions. This chapter introduces the modules in Windows NT 4.0 and then provides a detailed description of each, from the lowest level, nearest to the hardware, to the highest, nearest to the user applications.

Windows NT 4.0 architecture is divided into two main sections: user mode and kernel mode:

• Kernel mode is a highly privileged mode of operation in which the code has direct access to all hardware and all memory, including the address spaces of all user-mode processes. The part of Windows NT 4.0 running in kernel mode is called the Windows NT Executive. It includes the Hardware Abstraction Layer (HAL), the Microkernel, and the Windows NT Executive Service modules.

• User mode is a less privileged processor mode with no direct access to hardware. Code running in user mode acts directly only in its own address space. It uses well-defined operating system application program interfaces (APIs) to request system services. The environment and integral subsystems run in user mode.

Figure 5.3 shows the new Windows NT 4.0 architecture.

Figure 5.3 Windows NT 4.0 Modular Architecture 

Note In earlier documentation, the terms kernel and microkernel were used interchangeably. In this document, kernel refers to the entire Windows NT Executive. The Microkernel is a component of the Windows NT Executive. Kernel mode refers to a highly privileged processing mode.

Hardware Abstraction Layer

The Hardware Abstraction Layer (HAL) is a kernel-mode library of hardware-manipulating routines provided by Microsoft or by the hardware manufacturer. It lies at the lowest level of the Windows NT Executive between the hardware and the rest of the operating system.

This software layer hides, or abstracts, the characteristics of the platform behind standard entry points so that all platforms and architectures look alike to the operating system. It enables the same operating system to run on different platforms with different processors. For example, it allows Windows NT to run on single or multiprocessor computers and enables higher-level device drivers, such as graphics display drivers, to format data for different kind of monitors.

A HAL is installed during setup. Different processor configurations often use different HAL drivers. The HAL routines are called by other components of the Windows NT Executive, including the Microkernel, and by higher-level device drivers.

Microkernel

Working very closely with the HAL is the Microkernel, the heart of Windows NT. The Microkernel schedules threads, and handles interrupts and exceptions. If a computer has multiple processors, it synchronizes activity among the processors to optimize performance. The Microkernel can run simultaneously on all processors in a multiprocessor configuration.

The role of the Microkernel is to keep the processors as busy and productive as possible. To do so, the Microkernel schedules or dispatches threads for the processor in order of priority. It enforces the processor scheduling policy implemented by the Windows NT Executive. The Microkernel also interrupts or preempts threads of lower priority in favor of higher-priority threads. It can force context switches, directing the processor to drop one task and pick up another. Therefore, code operating in this system must be reentrant, that is, able to be interrupted and resume unharmed and be shared by different threads executing different lines of the same code on different processors.

Although the Microkernel dispatches and preempts threads of application and operating system code, the Microkernel's own code does not, technically, run in threads. Hence, it is the only part of the operating system that is not preemptible or pageable. With few exceptions, the remainder of threads running in Windows NT 4.0, including those in the Executive, are preemptible and fully reentrant for maximum efficiency.

The Microkernel also synchronizes the activities of the Windows NT Executive Services, such as the I/O Manager and the Process Manager. The Executive components also rely on the Microkernel for higher levels of abstraction, called Microkernel objects, some of which are exported within user-level application programming interface (API) calls.

Scheduling and Priorities

The Microkernel schedules ready threads for processor time based upon their dynamic priority, a number from 1 to 31 which represents the importance of the task. The highest priority thread always runs on the processor, even if this requires that a lower-priority thread be interrupted. In Windows NT, priorities are organized in a hierarchy. Each level of the priority hierarchy establishes a range within which the lower level priorities can vary:

• The base priority class of a process establishes a range for the base priority of the process and of its threads. In Windows NT 4.0, the base priority classes are Idle, Normal, High, and Real-Time, each representing a numeric range of base priorities that sometimes overlap at the extremes. The base priority class is set in the application code. The operating system does not change the base priority class, but it does vary the base priority within the class to improve the response of processes to the user.

• The base priority of a process varies within the range established by its base priority class. When a user interacts with a process (the process window is at the top of the window stack), Windows NT boosts the base priority of the process to maximize its response. 

• The base priority of a thread is a function of the base priority of the process in which it runs. Except for Idle and Real-Time threads, the base priority of a thread varies only within +/–2 from the base priority of its process. 

• The dynamic priority of a thread is a function of its base priority. Windows NT continually adjusts the dynamic priority of threads within the range established by its base priority. This helps to optimize the system's response to users and to balance the needs of system services and other lower priority processes to run, however briefly.

  Tip You can change the base priority class of a process while it is running by using Task Manager and other tools. These changes are effective only as long as the process runs. When it is restarted, it reverts to its original base priority class. You can also adjust the amount by which the base priority foreground processes (those the user is interacting with) is boosted by using the Control Panel systems applet Performance tab. (Right-click My Computer, select Properties, then select the Performance tab.) For more information, see "Measuring and Tuning Priority" in Chapter 13, "Detecting Processor Bottlenecks."

Most applications started by users run at Normal priority. Table 5.1 lists the Windows NT thread priority classes and priorities. The higher the base number, the higher the priority.

Base	Priority class	Thread priority
31	Real-time	Time critical
26	Real-time	Highest
25	Real-time	Above normal
24	Real-time	Normal
23	Real-time	Below normal
22	Real-time	Lowest
16	Real-time	Idle
15	Idle, Normal, or High	Time critical
15	High	Highest
14	High	Above normal
13	High	Normal
12	High	Below normal
11	High	Lowest
10	Normal	Highest
9	Normal	Above normal
8	Normal	Normal
7	Normal	Below normal
6	Normal	Lowest
6	Idle	Highest
5	Idle	Above Normal
4	Idle	Normal
3	Idle	Below normal
2	Idle	Lowest
1	Idle, Normal, or High	Idle

Several tools can help you monitor process and thread priority: two are Performance Monitor and Task Manager, which are built into Windows NT 4.0. See Part 3, "Optimizing Windows NT Workstation," for more information.

Symmetric Multiprocessing

The Windows NT Microkernel takes maximum advantage of multiprocessor configurations by implementing symmetric multiprocessing (SMP) and soft affinity.

Symmetric multiprocessing allows the threads of any process, including the operating system, to run on any available processor. Furthermore, the threads of a single process can run on different processors at the same time.

The Windows NT Microkernel allows processors to share memory and assigns ready threads to the next available processor or processors. This assures that no processor is ever idle or is executing a lower priority thread when a higher priority thread is ready to run. Allowing the operating system to run on multiple processors has significant advantages, especially when it is running processor-intensive applications. Server processes can now respond to more than one client at a time.

The Windows NT Microkernel also uses soft affinity in assigning threads to processors: If all other factors are equal, it tries to run the thread on the processor it last ran on. This helps reuse data still in the processor's memory caches from the previous execution of the thread. Applications can restrict threads to run only on certain processors (this is called hard affinity), but this is rare. In addition, Task Manager, a tool built into Windows NT 4.0 Workstation and Server, lets you determine which processor runs a process.

Microkernel Objects

The Microkernel manages two types of objects:

• Dispatcher objects have a signal state (signaled or nonsignaled) and control the dispatching and synchronization of system operations. Dispatcher objects include events, mutants, mutexes, semaphores, threads, and timers.

• Control objects are used to control the operation of the Microkernel but do not affect dispatching. Control objects include asynchronous procedure calls, interrupts, processes, and profiles.

  Note The terms mutex and mutant are often confused. In the Windows NT Executive, mutexes are used only in kernel mode. Mutants are used in the Win32 subsystem to implement Win32 API mutexes. For example, the access control object used in the Win32 API, Create Mutex(), is actually a mutant.

Table 5.2 describes how the Executive uses each type of dispatcher object.

Object type	Description
Event	Event objects record the occurrence of system and application events and synchronize events with other actions. They enable threads to stop executing until an anticipated event, like an asynchronous file operation, occurs then resume.
Mutant	Mutants control access to code to make sure that only one thread is executing a line of code at a time. Mutants are generally used in user-mode but can also be used in kernel mode.
Mutex	Mutexes also control access to code to make sure that only one thread is executing a line of code at a time. Unlike mutants, mutexes can be used only in kernel mode.
Semaphore	Semaphores are like traffic signals that let through only as many threads as a resource can support. If a resource is fully occupied, the semaphore signals that it is full. When the resource becomes available again, the semaphore signal changes to let more threads in. Semaphores make it possible for resources to be shared. If semaphore objects are named when they are created, they, too, can be shared by multiple processes.
Thread	Threads are the parts of a process that execute program code. The Microkernel schedules threads to run on processors. The process in which the thread runs determines the virtual address space mapping for the thread and accumulates its run time. A process can have one or many threads. Multiple threads are required for parallel processing, in which different threads of a process run simultaneously on different processors in a single address space.
Timer	Timers record the passage of time and end operations for which time has expired.
Section	Sections represent areas of memory that can be viewed as a contiguous sequence of addresses.

Table 5.3 describes how the Executive uses each type of control object.

Object type	Description
Asynchronous Procedure Call	Used to break into the execution of a specified thread and to cause a procedure to be called in a specified processor mode.
Interrupt	Used to connect an interrupt source to an interrupt service routine by means of an entry in an Interrupt Dispatch Table (IDT). Each processor has an IDT that is used to dispatch interrupts that occur on that processor.
Process	Used to represent the virtual address space and control information necessary for the execution of a set of thread objects. A process object contains a pointer to an address map, a list of ready threads containing thread objects while the process is not in the balance set, a list of threads that belong to the process, the total accumulated time for all threads executing within the process, a base priority, and a default thread affinity. A process object must be initialized before any thread objects that specify the process as their parent can be initialized.
Profile	Used to measure the distribution of run time within a block of code. Both user and system code can be profiled.

The third and most intricate module that runs in kernel mode is the Executive. The next several sections describe the functions of the Executive and its components.

Windows NT Executive Services

The Windows NT Executive Services consist of a set of common services available to all components of the operating system. Each group of services is managed by one of these separate components of the Executive:

• I/O Manager 

• Object Manager 

• Security Reference Monitor (which, along with the Logon and Security protected subsystems, makes up the Windows NT security model) 

• Process Manager 

• Local Procedure Call Facility 

• Virtual Memory Manager 

• Window Manager 

• Graphics Device Interface 

• Graphics Device Drivers 

The thin top layer of the Executive is called the System Services. The System Services shown in Figure 5.1 (and on the inside back cover of this book) are the interface between user-mode environment subsystems and kernel mode. The following sections describe the role of each Executive component.

I/O Manager

The I/O Manager manages all input and output for the operating system. A large part of the I/O Manager's role is to manage communications between drivers. The I/O Manager supports all file system drivers, hardware device drivers, and network drivers and provides an appropriate environment for each them. The I/O manager includes a formal, uniform interface that all types of drivers can call. This enables the I/O Manager to communicate with all drivers in the same way, without any knowledge of how the devices they control actually work.

The Windows NT I/O model uses a layered architecture that allows separate drivers to implement each logically distinct layer of I/O processing. For example, drivers in the lowest layer manipulate the computer's physical devices. Other drivers are then layered on top of the device drivers. These higher-level drivers do not know any details about the physical devices. With the help of the I/O Manager, higher-level drivers simply pass logical I/O requests down to the device drivers, which access the physical devices on their behalf. The Windows NT installable file systems and network redirectors are examples of high-level drivers that work in this way.

This scheme allows easy replacement of file system drivers and device drivers. It allows multiple file systems and devices to be active at the same time while being addressed through a formal interface.

Asynchronous I/O

Drivers communicate with each other using data structures called I/O Request Packets (IRPs). The drivers pass I/O request packets to the I/O Manager which delivers them to the target drivers using the drivers' standard services.

Windows NT 4.0 uses asynchronous I/O whenever possible to optimize application performance. When an application initiates an I/O operation, the application can continue processing while the I/O request is fulfilled. This differs from synchronous I/O, in which an application must stop processing until an I/O operation is complete.

Asynchronous I/O is efficient. Because most I/O devices are much slower than processors, an application can do a lot of work while the I/O operation is in progress. However, the application now needs to determine when I/O operations are complete. Some applications dedicate a wait thread to watch for the I/O. Others include an application procedure call (APC) that the I/O manager calls when the asynchronous I/O operation is complete. Other applications use synchronization objects, such as an event or the file handle, that the I/O system sets to the signaled state when the I/O operation is complete.

Look-Aside Lists

Windows NT 4.0 Workstation and Server now use Look-Aside Lists to help manage the amount of the nonpaged pool memory used by I/O Request Packets (IRPs). Look-Aside Lists replace the I/O zone used as the IRP memory management strategy for in Windows NT 3.51 and earlier versions. However, zones, which preallocate a fixed amount of physical memory, are still supported and used in other Windows NT drivers.

Look-Aside Lists keep track of the current number of entries freed from the nonpaged pool and an allowed maximum number of them. Space for the entries is allocated as needed from the Look-Aside List and counted against the maximum. If processes needs more than the maximum number of entries, space for them is allocated from the nonpaged pool, but the space is returned to the pool when the memory is released, not to the Look-Aside List. The maximum number of entries is based on the amount of physical memory in the system and whether it is a workstation or a server. For a given amount of physical memory, the maximum number of entries for servers is higher.

I/O Queuing

The I/O Manager processes requests from the I/O queue in order of priority, not in the order received. When an environment subsystem issues an asynchronous I/O request, the I/O Manager returns to the environment subsystem immediately after putting the request in a queue, without waiting for the device driver to complete its operations. Meanwhile, a separate I/O Manager thread administers the queue. When each I/O request is finished, the I/O Manager notifies the process that requested the I/O.

 

Figure 5.4 I/O Queueing 

Cache Manager

The I/O architecture includes a single Cache Manager that handles caching for the entire I/O system. Caching is a method used by a file system to improve performance. Instead of reading and writing directly to the disk, frequently used files are temporarily stored in a cache in memory, and reads and writes to those files are performed in memory.Cache Manager uses a file-mapping model that is closely integrated with Windows NT Virtual Memory Manager. Cache Manager provides caching services to all file systems and network components under the control of the I/O Manager. Cache Manager can dynamically increase and decrease the size of the cache as the amount of available physical memory varies. When a process opens a file that already resides in the cache, Cache Manager simply copies data from the cache to the process's virtual address space, and vice versa, as reads and writes are performed.

Cache Manager offers services such as lazy write and lazy commit, which can improve overall file system performance. Lazy write lets you record changes in the file structure cache, which is quicker than recording them on disk. Then later, when demand on the processors is low, Cache Manager writes the changes to the disk. Lazy commit is similar to lazy write: Instead of immediately marking a transaction as successfully completed, the system caches the committed information and later writes it to the file system log as a background process.

File System Drivers

The I/O Manager routes communication to file system drivers. Windows NT 4.0 enables multiple NTFS (Windows NT File System) and FAT (File Allocation Table) systems to coexist in different logical partitions of the same physical device.

Note Windows NT 4.0 does not support High Performance File System (HPFS), the file system designed for OS/2 1.x operating systems. Support for this file system ends with this release.

The I/O Manager treats file system drivers as just another device driver, routing messages for certain volumes to the appropriate software driver for that device adapter. When the I/O Manager cannot determine the file system for a volume, it forwards messages to the RAW default file system, which attempts to interpret requests and determine the appropriate low-level device driver before logging an error.

NTFS, the file system designed for Windows NT, supports many features, including file system security, Unicode, recoverability, long filenames, and POSIX. FAT, which is a simpler file system, supports long filenames, but not file system security. FAT is supported for backward compatibility with MS-DOS and Windows 3.x.

Windows NT 4.0 also supports Compact Disc Filing System (CDFS), an ISO9660-compliant file system for CD-ROM devices.

The Windows NT I/O architecture not only supports traditional file systems but has implemented its network redirector and server as file system drivers. The I/O Manager sees no difference between accessing files stored on a remote networked computer and accessing those stored locally on a hard disk. In addition, redirectors and servers can be loaded and unloaded dynamically, just like any other driver, and multiple redirectors and servers can coexist on the same computer.

For more information about supported file systems, see Chapter 18, "Choosing a File System." For more information about supported redirectors and servers, see Chapter 1, "Windows NT Networking Architecture," in the Windows NT Server Networking Guide.

Hardware Device Drivers

Hardware device drivers are also components of the I/O architecture. Windows NT-compatible hardware device drivers—such as mouse drivers and disk drivers—are written in the C, C++, or Assembler programming language, are 32-bit addressable, and can be used with multiprocessor computers.

Device drivers access the hardware registers of the peripheral devices through entry points in Windows NT Executive dynamic link libraries. A set of these routines exists for every platform that Windows NT supports; because the routine names are the same for all platforms, the source code of Windows NT device drivers is portable across different processor types.

Designers of device drivers are encouraged to create separate drivers for different devices, rather than monolithic drivers, and the design of I/O Manager makes it easy to do so. This allows more flexibility to customize device configurations on the computer and to layer device drivers and other drivers.

For example, the Intel 8042 processor is an interface device: the keyboard and mouse communicate with the i8042 driver as well as with their own respective drivers. Three separate drivers are used — for the i8042, for the keyboard, and for the mouse — rather than one large monolithic driver. This makes it easier to change one component (exchanging the mouse for a different pointing device, for example).

Network Drivers

A third type of driver implemented as a component in the I/O architecture is the network device driver. Windows NT includes integrated networking capabilities and support for distributed applications. Networking is supported by a series of network drivers.

Redirectors and servers are implemented as file system drivers and run at or below a provider interface layer where NetBIOS and Windows Sockets reside.

Transport protocol drivers communicate with redirectors and servers through a layer called the Transport Driver Interface (TDI). Windows NT includes a number of transports that communicate with the redirector:

• Transmission Control Protocol/Internet Protocol (TCP/IP), a popular routable protocol for wide-area networks.

• NetBEUI, which is compatible with existing LAN Manager, LAN Server, and MS-Net installations.

• NWLink, an implementation of IPX/SPX, which provides connectivity with Novell NetWare.

• Data Link Control (DLC), which provides an interface for access to mainframes and network-attached printers.

  Note DLC, unlike the other protocols in Windows NT (NetBEUI, NWLink IPX/SPX, TCP/IP), is not designed to be a primary protocol for use between personal computers. DLC only provides applications with direct access to the data link layer, and thus is not used by the Windows NT redirector.

 

Figure 5.5 Networking Components in Windows NT 

At the bottom of the networking architecture is the network adapter card device driver. Windows NT currently supports device drivers written to the Network Device Interface Specification (NDIS) version 3.0. NDIS allows for a flexible environment of data exchange between transport protocols and network adapters. NDIS 3.0 allows a single computer to have several network adapter cards installed in it. In turn, each network adapter card can support multiple transport protocols for access to multiple types of network servers.

For more information about network device drivers, see Chapter 1, "Windows NT Networking Architecture," in the Windows NT Server Networking Guide.

Object Manager

Object Manager is the part of the Windows NT Executive that provides uniform rules for retaining, naming, and setting the security of objects. Objects are software components that consist of a data type, attributes, and a set of operations the object performs.

Like other Windows NT components, the Object Manager is extensible so that new object types can be defined as technology grows and changes.

Object Manager also creates object handles. An object handle consists of access control information and a pointer to the object. Processes use object handles to manipulate Windows NT objects.

In addition, the Object Manager tracks the creation and use of objects and manages the global namespace for Windows NT. The namespace includes all named objects in the local computer environment. The object namespace is organized like a hierarchical file system, with directory names in a path separated by a backslash (\). Some of the objects that can have names include

• Directory objects 

• Object type objects 

• Symbolic link objects 

• Semaphore and event objects 

• Process and thread objects 

• Section and segment objects 

• Port objects 

• File objects

Windows NT Security Model

In a multitasking operating system such as Windows NT, applications share a variety of system resources including the computer's memory, I/O devices, files, and system processor(s). Windows NT includes a set of security components that ensure that applications cannot access these resources without authorization. Together, these components—the Security Reference Monitor component, the Logon Process, and the Security protected subsystems—form the Windows NT security model.

The Security Reference Monitor is responsible for enforcing the access-validation and audit-generation policy defined by the local Security subsystem. It provides services to both kernel and user mode for validating access to objects, checking user privileges, and generating audit messages. The Reference Monitor, like other parts of the Executive, runs in kernel mode.

The user-mode Logon Process and Security protected subsystems are the other two components of the Windows NT security model. Because it affects the entire Windows NT operating system, the Security subsystem is known as an integral subsystem rather than an environment subsystem. (Environment subsystems are discussed later in this chapter.)

The Windows NT Kernel and Executive are based on an object-oriented model that allows for a consistent and uniform view of security, right down to the fundamental entities that make up the base operating system. This means that Windows NT uses the same routines for access validation and audit checks for all protected objects. That is, whether someone is trying to access a file on the disk or a process in memory, there is one component in the system that is required to perform access checks, regardless of the object type.

The Windows NT Logon Process provides for mandatory logon to identify users. Each user must have an account and must supply a password to access that account. Before users can access any resource on a Windows NT computer, they must logon through the Logon Process so that the Security subsystem can authenticate their username and password. After successful authentication, whenever a user tries to access a protected object, the Security Reference Monitor runs an access-validation routine against the user's security information to ensure the user has permission to access the object.

The security model also provides for discretionary access control so that the owner of a resource can specify which users or groups can access resources and what types of access they're allowed (such as read, write, and delete).

Resource protection is another feature provided by the security model. Tasks can access each others' resources, such as memory, only through specific sharing mechanisms. This feature helps enforce object hiding.

Windows NT also provides for* *auditing so that administrators can keep an audit trail of which users perform what actions.

By providing these features, the Windows NT security model prevents applications from gaining unauthorized access to the resources of other applications or the operating system either intentionally or unintentionally.

For more information about Windows NT Workstation security, see Part II, Chapter 6, "Windows NT Workstation Security." For more information about the C2 Evaluation of Windows NT, see the Windows NT Administrator's Security Guide. (It is available from Microsoft. Refer to Part #236-074-495.)

In addition to the protected subsystems, Logon Process and Security, Windows NT includes a number of other user-mode components called environment subsystems. The next section describes each of them.

Process Manager

The Process Manager is the operating system component that creates and deletes processes and tracks process objects and thread objects. It also provides a standard set of services for creating and using threads and processes in a particular subsystem environment.

Beyond that, the Process Manager does little to dictate rules about threads and processes. Instead, the Windows NT design allows for robust environment subsystems that can define specific rules about threads and processes. For example, the Process Manager does not impose any hierarchy or grouping rules for processes, nor does it enforce any parent/child relationships.

A process is an application program or modular part of a program. The operating system sees a process as an address space, a set of objects, and a set of threads that run in the context of the process. The process object specifies the virtual address space mapping for the thread and accumulates thread run time.

A process object:

• Includes a pointer to an address map.

• Maintains a list of ready threads when the process is not in the balance set.

• Maintains a list of threads that belong to the process.

• Keeps track of the time accumulated by all threads executing in the process.

• Records the process's base priority and default thread affinity.

A process object must be initialized before any thread objects that list that process as their parent can be initialized.

A thread is most the basic schedulable entity in the system. It has its own set of registers, its own kernel stack, a thread environment block, and user stack in the address space of its process.

The Windows NT Process Manager works with the Security Reference Monitor and the Virtual Memory Manager to provide interprocess protection. Each process is assigned a security access token, called the primary token of the process. This token is used by Windows NT access-validation routines when threads in the process reference protected objects. For more information about how Windows NT uses security access tokens, see Chapter 6, "Windows NT Security."

Local Procedure Call Facility

Applications and environment subsystems have a client-server relationship. That is, the client (an application) makes calls to the environment server (a subsystem) to satisfy a request for some type of system services. To allow for a client-server relationship between applications and environment subsystems, Windows NT provides a communication mechanism between them. The Executive implements a message-passing facility called a Local Procedure Call (LPC) facility. It works very much like the Remote Procedure Call (RPC) facility used for networked processing, but it is optimized for two processes running on the same computer.

For more information on RPCs, see Chapter 1, "Windows NT Networking Architecture," in the Windows NT Server Networking Guide.

Applications communicate with environment subsystems by using the LPC facility. The message-passing process is hidden from the client applications by function stubs, nonexecutable placeholders used by calls from the server environment. The stubs are kept in dynamic-link libraries (DLLs).

When an application makes an application program interface (API) call to an environment subsystem, the stub in the client application packages the parameters for the call and sends them to a server subsystem process which implements the call. The LPC facility allows the stub procedure to pass the data to the server process and wait for a response.

From the application's perspective, the function in the DLL satisfied the call. The application does not know that the work was actually performed by another subsystem or process or that a message was sent on its behalf.

Virtual Memory Manager

The Virtual Memory Manager maps virtual addresses in the process's address space to physical pages in the computer's memory.

It hides the physical organization of memory from the process's threads to ensure that the thread can access its own memory but not the memory of other processes. Therefore, as illustrated by Figure 5.6, a thread's view of its process's virtual memory is much simpler than the real arrangement of pages in physical memory.

 

Figure 5.6 Mapping Virtual Memory to Physical Memory 

Windows NT Workstation has a demand-paged virtual memory system based on a flat, linear address space with 32-bit addresses.

Virtual memory allows the operating system to allocate more than the actual physical memory of the computer. It does this by using disk space as an extension of memory and by swapping code between physical memory and disk as it is needed. The virtual memory is mapped to addresses in physical memory.

The Virtual Memory Manager allocates memory in two phases for efficiency: reserving it, then committing it. Committed memory is part of the paging file, the disk file used to write pages to physical memory. Reserved memory is held until needed, then committed. The act of reserving memory maintains a contiguous virtual address space for a process, which is then consumed as needed.

Linear addressing, in which memory addresses begin at 0 and continue in 1-byte increments to the extent of physical memory, replaces segmented memory schemes where each address begins with a segment number. Because virtual memory is limited only by the number of unique addresses, 32-bit addressing allows four billion bytes (4 gigabytes) of address space.

Demand paging is a method by which data is moved in pages from physical memory to a temporary paging file on disk. As the data is needed by a process, it is paged back into physical memory.

 

Figure 5.7 Conceptual View of Virtual Memory 

The Virtual Memory Manager allocates to each process a unique protected set of virtual addresses available to the process's threads. Each process has a separate address space, so a thread in one process cannot view or modify the memory of another process without authorization. This address space appears to be 4 gigabytes (GB) in size, with 2 GB reserved for program storage and 2 GB reserved for system storage.

Note Windows NT versions prior to 3.51 included some 16-bit data structures that limited processes to 256 MB (64K pages) of virtual memory. These have been converted to 32-bit data structures, so 2 GB of virtual memory is available to all processes.

Window Manager

Window Manager is the part of the Windows NT Executive that creates the familiar screen interface. It is also responsible for processes, like messaging, that use windows functions without ever affecting the user interface.

The Window Manager (USER) and Graphics Device Interface (GDI) functions are implemented by a single component in the Windows NT Executive: Win32k.sys, known as Winsrv.dll in previous releases of Windows NT.

Applications call the standard USER functions to create windows and buttons on the display. Window Manager communicates these requests to GDI, which passes them to the graphics display drivers where they are formatted for the display device.

The Window Manager notifies applications when changes occur in the user's interaction with the interface, such as movement or resizing of windows, cursor movement, and icon selection.

Prior to Windows NT 4.0, the Window Manager was the USER component of the Win32 subsystem and ran in a protected process in user mode. With this release, they were moved into the Windows NT Executive to run in kernel mode. This change was designed to speed up graphics calls and reduce the memory requirements of interprocess communication.

Graphics Device Interface

The Graphics Device Interface (GDI), also called the graphics engine, consists of functions in Win32k.sys that display graphics on the computer monitor and printers. It is implemented by the same component as Window Manager.

GDI provides a set of standard functions that let applications communicate with graphics devices, including displays and printers, without knowing anything about the devices. GDI functions mediate between applications and graphics devices such as display drivers and printer drivers.

GDI interprets application requests for graphic output and sends them to graphics display drivers en route to the hardware. It includes functions for advanced line, text and figure drawing, and graphics manipulation. GDI provides a standard interface for applications to use varying graphics output devices. This enables application code to be independent of the hardware devices and their drivers.

GDI is also the display driver's connection to the operating system and to the applications it supports. GDI passes API requests to the graphics device drivers, and graphics devices drivers can request services from GDI.

GDI tailors its messages to the capabilities of the device, often dividing the request into manageable parts. For example, some devices can understand directions to draw an ellipse; others require GDI to interpret the command as a series of pixels placed at certain coordinates.

Prior to Windows NT 4.0, GDI was part of the Win32 subsystem and ran in a protected process in user mode. With this release, it was moved into the Windows NT Executive to run in kernel mode. This change was designed to speed up graphics calls and reduce the memory requirements of interprocess communication.

Graphics Device Drivers

Graphics device drivers are dynamic link libraries of functions that let GDI communicate with graphic output hardware devices such as monitors, printers, and fax machines. Display drivers and printer drivers are the most common graphics device drivers. The following section describes display drivers in detail. For more information about printer drivers, see Chapter 7, "Printing."

Display Drivers

Display drivers draw text and graphics on the display and retrieve information about the display device (such as color resolution, screen size and screen resolution). They are specific to a hardware device or group of devices and are sometimes provided by hardware vendors. Windows NT 4.0 Workstation and Server include graphics device drivers for most common devices.

Display drivers are higher-level drivers which reside between the Graphics Device Interface (GDI) and lower-level drivers which control the hardware. They receive application requests from GDI and call GDI functions to help fulfill requests, or break them down into simpler tasks that the hardware device can handle.

 

Display drivers depend on lower-level drivers. They are paired with video miniports, which are hardware-manipulating drivers provided by the display driver vendor.. Windows NT provides a video port and a library of common functions to simplify the tasks of the display driver and video miniport. It also ships with several display drivers and their miniports.

The miniport carries out user and application requests to configure the hardware for a specific video mode.. It also enables the graphics device drivers to communicate directly with the hardware. For example, when a miniport sets up registers and memory frame buffers for a hardware device, it also sends the display driver pointers to the buffers so that the GDI and the driver can write directly to the device's memory.

Prior to Windows NT 4.0, display drivers and printer drivers were part of the Win32 subsystem and ran in user mode. They are now part of the Windows NT Executive running in kernel mode. As a result, display drivers written for previous versions of Windows NT will not run on Windows NT 4.0, and new kernel-mode display drivers written for Windows NT 4.0 are not backward compatible. However, video miniports, which have always run in kernel mode, do not need to be revised to comply with the new architecture.

Environment Subsystems

Windows NT is designed to allow different types of applications to run seamlessly on the same graphical desktop. It runs applications written for existing operating systems and APIs such as MS-DOS, OS/2 1*.x*, and Windows 3.x, POSIX and Win32.

Windows NT supports a variety of applications through the use of environment subsystems, which are Windows NT processes that emulate different operating system environments.

This chapter has described how the Windows NT Executive provides generic services that all environment subsystems can call to perform basic operating system functions. The subsystems build on the Executive's services to produce environments that meet the specific needs of their client applications.

Each subsystem runs as a separate user-mode process, with each subsystem protected from errors in the others: Failure in one won't cause another subsystem or the Executive to be disabled. Applications are also user-mode processes, so they can't hinder the subsystems or Executive.

Windows NT provides the following protected environments subsystems and Virtual DOS Machines (VDMs):

• MS-DOS NTVDM

• Win16 NTVDMs

• OS/2 subsystem

• POSIX subsystem

• Win32 subsystem

Each environment is optional and is loaded only when its services are needed by a client application.

MS-DOS Environment

MS-DOS-based applications run on Windows NT 4.0 in a process called an NT Virtual DOS Machine (NTVDM). NTVDM is a 32-bit Windows application that simulates an Intel 486 computer running MS-DOS.

Each MS-DOS application runs in a separate NTDVM process, although all are named Ntvdm.exe by default. An unlimited number of NTVDM processes can be run. Each runs in its own address space. This protects the applications from each other and protects the rest of the operating system from the NTVDMs.

Note You can change the name of the process in which MS-DOS applications run by editing the configuration registry. For details, see "Monitoring MS-DOS Applications" in Chapter 9, "The Art of Performance Monitoring."

When Windows NT is running on an Intel 486 or higher processor, a processor mode called Virtual-86 mode is available. This mode allows direct execution of most instructions in an MS-DOS-based application. A few instructions (such as I/O instructions) must be emulated in order to communicate with the hardware. On RISC processors, NTVDM emulates all Intel 486 instructions in addition to providing a virtual hardware environment.

An NTVDM running a MS-DOS application consists of three threads: an application thread on which the MS-DOS application runs, a heartbeat thread which simulates the timer interrupts to the MS-DOS application, and a console thread which handles console I/O for the application.

To run MS-DOS-based applications, the NTVDM creates a virtual computer including support for:

• Intel x86 instructions, provided by the Instruction Execution Unit

• Read-only memory basic input and output (ROM BIOS) interrupt services, provided by the MS-DOS emulation module

• MS-DOS Interrupt 21 services, provided by the MS-DOS emulation module

• Virtual hardware for devices, such as the screen and keyboard, provided by Virtual Device Drivers

 

Figure 5.8 Structure of an MS-DOS NTVDM 

On Intel 486-based computers, character-based applications can run either in a window or in a full screen. Graphic applications can run only in full screen. If an application in a window changes its video mode, it is automatically switched to full screen. On RISC-based computers, character-based and graphic applications run only in a window.

Windows 16-bit Environment

16-bit Windows applications also run in an NTVDM. An Intel 486 emulator in Windows NT enables16-bit Windows applications to run on RISC computers, too.

Windows NT 4.0 runs 16-bit Windows applications as separate threads in a single NTVDM process with a shared address space. This differs from MS-DOS applications which each run in a separate NTVDM process. The Win16 NTVDM is also known as WOW (for Win16-on-Win32). The Win16 NTVDM can also run 16-bit applications On RISC processors, NTVDM emulates all Intel x86 instructions in addition to providing a virtual hardware environment.

The Win16 NTVDM is a multithreaded process wherein each of the threads is a different 16-bit Windows application. This single process is multitasking—that is, on a multiprocessor computer, one of the 16-bit processes in the NTVDM can run at the same time as threads of other processes. However, only one 16-bit Windows application thread in an NTVDM can run at a time; all other threads of that NTVDM process are blocked. If a Win16 NTVDM thread is preempted (interrupted by a higher priority thread), the Microkernel always resumes with the thread that was preempted.

Every Win16 NTVDM includes two system threads: a Wowexec.exe thread which starts Win16 applications, and a heartbeat thread which simulates timer interrupts to the application. In addition, there is a thread for each Win16 application running in the process.

Windows NT 4.0 includes an option to run a 16-bit Windows application in its own separate NTVDM process with its own address space. This allows 16-bit Windows applications to be fully preemptible and multitasking. For more information, see "Optimizing 16-Bit Windows Applications" in Chapter 9, "The Art of Performance Monitoring."

 

The Windows NT 4.0 NTVDM provides stubs for Windows 3.1 dynamic-link libraries and drivers, and it automatically handles translation of 16-bit Windows APIs and messages.

 

Figure 5.9 Structure of the Win16 VDM

For more information about using Windows 3.x applications on Windows NT, see Chapter 27, "Windows Compatibility and Migration."

OS/2 Subsystem

The OS/2 subsystem supports OS/2 1*.x* character-based applications on x86-based computers. Although this subsystem isn't supported on RISC computers, OS/2 real-mode applications can run on a RISC computer in the MS-DOS environment. Bound applications (those designed to run under either OS/2 or MS-DOS) will always run in the OS/2 subsystem if one is available.

Note Windows NT 4.0 does not support HPFS, the file system designed for OS/2 1.x operating systems. Support for this file system ends with this release.

For more information about using OS/2 1.x applications on Windows NT, see Chapter 28, "OS/2 Compatibility."

POSIX Subsystem

The Windows NT POSIX subsystem is designed to run POSIX applications and meets the requirements of POSIX.1.

POSIX (Portable Operating System Interface for Computing Environments) is a set of standards being drafted by the Institute of Electrical and Electronic Engineers (IEEE). It defines various aspects of an operating system, including topics such as programming interface, security, networking, and graphical interface. So far, only one of these standards, POSIX.1 (also called IEEE Standard 1003.1-1990), has made the transition from draft to final form and gained a base of customer acceptance.

POSIX.1 defines C-language API calls between applications and the operating system. It is an API based on ideas drawn from the UNIX file system and process model. Because POSIX.1 addresses only API-level issues, most applications written to the POSIX.1 API must rely on non-POSIX operating system extensions to provide services such as security and networking.

POSIX applications need certain file-system functionality, such as support for case-sensitive filenames and support for files with multiple names (or hard links). The new file system, NTFS, supports these POSIX requirements. Any POSIX application requiring access to file system resources must have access to an NTFS partition. POSIX applications that do not access file system resources can run on any supported file system.

For more information about using POSIX applications on Windows NT, see Chapter 29, "POSIX Compatibility."

Win32 Subsystem

Win32 is the native environment subsystem of Windows NT. Prior to Windows NT 4.0, this subsystem included graphics, windowing, and messaging support and the graphics device drivers. These functions have been moved into the Windows NT Executive as executive services running in user mode. For more information about this change, see "What's Changed in Windows NT 4.0 Workstation," earlier in this chapter.

 

The remaining Win32 user-mode functions, known as the Console and miscellaneous environment functions support 32-bit Windows applications:

• The Console provides text window support, shutdown, and hard-error handling.

• Miscellaneous environment functions consist of specialized functions for 32-bit Windows applications, like creating and deleting processes.

Application Types on Various Hardware Platforms

Windows NT 4.0 runs on computers with Intel 486 or higher processors, MIPS, PowerPC, and Digital Alpha AXP processors. The following table shows how Windows NT supports applications of various types on these different hardware platforms.

Processor	Win32	MS-DOS and Windows 3.x	POSIX	OS/2 1.x
Intel 486 and Pentium	Source- compatible	Runs application in a VDM	Source-compatible	16-bit character-based only
PowerPC	Source-compatible	Runs application in Intel 486 emulation	Source-compatible	Not available; can run real-mode applications in MS-DOS subsystem
Digital Alpha AXP	Source-compatible	Runs application in Intel 486 emulation	Source-compatible	Not available; can run real-mode applications in MS-DOS subsystem
MIPS R4000	Source-compatible	Runs application in Intel 486 emulation	Source-compatible	Not available; can run real-mode applications in MS-DOS subsystem

DirectX

Introduced with Windows 95, DirectX is a high-performance application program interface that hides hardware and operating system characteristics from the application. DirectX is designed to provide high-speed, real-time response to the user interface.

Windows NT 4.0 now includes three DirectX components: DirectDraw, DirectSound, and DirectPlay for Windows NT 4.0 let you run games and other applications designed for DirectX on Windows 95 on Windows NT 4.0 Workstation and Server.

DirectX for Windows NT 4.0 supports the application entry points called by programs designed for DirectX in Windows 95. The functions are implemented differently in Windows NT than in Windows 95, but they allow you to run the DirectX-based programs on a Windows NT 4.0 workstation or server without changes.

The goal for incorporating DirectX in Windows NT was to provide the best possible graphics performance without compromising the robustness of the system. For example, in Windows NT, DirectX functions never communicate directly with hardware; all graphics functions are mediated by the GDI.

 

DirectDraw

DirectDraw for Windows NT 4.0 supports a 32-bit application program interface for accelerated drawing. DirectDraw also can emulate functions by breaking them down into simpler tasks for the hardware, much as GDI does for its clients.

Unlike DirectX for Windows 95, DirectDraw for Windows NT does not communicate directly with the driver or with any hardware. All DirectDraw functions are implemented in Windows NT 4.0 but are mediated by the GDI.

DirectSound

For Windows NT 4.0, DirectSound provides all application entry points for DirectX sound functions. However these functions are emulated and are not in accelerated form.

DirectPlay

DirectPlay is a DirectX DLL that simplifies communications between computers, allowing DirectX programs to be run over the network, using a modem, even modem-to-modem. The communications method is hidden from the application and optimized to have minimal effect on the real-time performance of the interface.

DirectPlay for Windows NT 4.0 supports TCP/IP and Novell IPX network protocols on a local area network as well as point-to-point modem connections using TAPI, the Windows Telephony API.