Subject: Windows NT Architecture Guide Type: BULLETIN Status: MODERATION_CHANGES Content Type: TEXT/PLAIN Creation Date: 15-MAY-1995 Last Revision Date: 29-SEP-1999 Language: USAENG Microsoft Windows NT Architecture --------------------------------- PURPOSE ======= The intention of this document is to give a global overview of Microsoft's NT architecture. SCOPE & APPLICATION =================== The informaton contained in this document is for research purposes of Support Analysts only. RELATED DOCUMENTS ================= Microsoft Windows NT Workstation Resource Kit (Microsoft Press) Note:46053.1 Windows NT Memory Architecture Overview Note:73294.1 WINDOWS NT 4.0 FILESYSTEMS 1) Windows NT Design Goals Portability Security Compatibility Extensibility Reliability and Robustness Multiprocessing and Scalability Network Connectivity Internationalization 2) Windows NT System Structure a) Hardware Abstraction Layer (HAL) b) Windows NT Kernel Architecture -Priority c) NT Executive Services * I/O MANAGER - I/O Queuing: - Cache Manager: - File System Drivers: - Hardware Device Drivers - Network Drivers * Object Management * Security Reference Monitor * Process Manager * Local Procedure Call Facility * Virtual Memory Manager d) ENVIRONMENT SUBSYSTEMS * Security Subsystem * OS/2 Subsystem * POSIX Subsystem * VDM Architecture * WOW Architecture * Win32 subsystem: Windows NT Shell 3) Robustness 4) Windows NT Registry 5) Summary This is an overview of the architecture of Windows NT. It covers Windows NT design philosophy, gives a technical description of major architectural components of Windows NT, defines what is meant by client-server architecture within Windows NT, and describes the layered I/O model. 1) Windows NT Design Goals ========================== Portability: ----------- The system should be portable across multiple processor architectures. The original target architectures were the Intel 386/486 and the MIPS R4000 processors. In making the system portable, Microsoft wanted to ensure that one can take advantage of future hardware enhancements. Currently only the Intel (x86) and Dec Alpha platforms are supported. Security: -------- Microsoft wanted to have a uniform security architecture that would meet the requirements for a U.S. government C2 rating. Many of the features required by the government are also applicable in the commercial sector. Compatibility: ------------- Compatibility takes many forms. Microsoft wanted to be compatible in the areas of existing operating systems such as MS-DOS?, Windows? 3.x, POSIX, and OS/2? 1.x; existing file systems such as FAT and HPFS; and networking compatibility and interoperability with existing systems such as Microsoft LAN Manager, Novell NetWare, and Banyan VINES. Extensibility: ------------- Microsoft wanted to provide extensions without privileged code. The Windows NT design allows for protected subsystems to be modified and extended without affecting the executive. Microsoft also wanted to provide privilege extensions through installable device drivers, multiple active installable file systems, and multiple active installable network redirectors. Reliability and Robustness: -------------------------- The operating system is designed to respond predictably to error conditions. It should also protect itself from accidental or deliberate damage from user programs. Each application and subsystem runs in its own address space. Microsoft employs structured exception handling and validate parameters each time a user-mode program calls the kernel. Multiprocessing and Scalability: ------------------------------- Windows NT fully supports symmetric multiprocessing hardware and provides performance that scales with the addition of more processors (to as many as 4). Today, Windows NT runs several multiprocessor architectures from different vendors. Network Connectivity: -------------------- Windows NT was designed with built-in networking. It is compatible with LAN Manager, and it supports multiple active network redirectors. So, from a single Windows machine, a user can access Windows NT and LAN Manager servers as well as NetWare servers. Internationalization: -------------------- Windows NT could not be successful if Microsoft ignored international markets. Windows NT has been designed to be easy to localize, since all strings in the executive are Unicode and all Win32 APIs (Application Programming Interfaces) support Unicode. 2) Windows NT System Structure ============================== a. HARDWARE ABSTRACTION LAYER (HAL) b. MICROKERNEL * Symmetric Multiprocessing c. NT EXECUTIVE SERVICES * I/O MANAGER - I/O queueing - CACHE MANAGER - FILE SYSTEM DRIVERS - HARDWARE DEVICE DRIVERS - NETWORK DRIVERS * OBJECT MANAGER * WINDOWS NT SECURITY MODEL * PROCESS MANAGER * LOCAL PROCEDURE CALL FACILITY * VIRTUAL MEMORY MANAGER * WINDOWS MANAGER & GRAPHICS DEVICE INTERFACE * GRAPHICS DEVICE DRIVERS d. ENVIRONMENT SUBSYSTEMS * MS DOS NT Virtual Dos Machine * Window 16-bit Environment * OS/2 Subsystem * POSIX Subsystem * Win32 subsystem The Windows NT system structure supports several key operating system concepts. First, Windows NT supports programs running in USER mode and programs running in KERNEL mode. All of the Windows NT subsystems and applications run in user mode, and each subsystem and application runs in its own protected address space. This design has several advantages. It simplifies the base operating system and makes it possible to extend the features of the environment subsystems without affecting the Windows NT executive. It also improves reliability because applications, subsystems, and the executive are protected from each other. Client applications communicate with environment subsystems using a client-server model by utilizing a message-passing facility in the executive. Windows NT lends itself well to a distributed computing model. Since networked computers are based on a client-server model and use messages to communicate, local servers can easily send messages to a remote machine as well. Clients don't need to know whether certain requests are satisfied locally or remotely. Second, Windows NT employs a layered model in the kernel-mode portion of the operating system. At the lowest layer is the Hardware Abstraction Layer (HAL). On top of the HAL is the kernel or Microkernel, which is the lowest layer in the executive. On top of the kernel is the rest of the Windows NT executive components. The kernel performs low-level operating system functions such as thread scheduling and exception and interrupt handling. The HAL is a layer of platform-specific code that protects the kernel and the rest of the executive from platform differences. The HAL manipulates hardware directly. The remaining components of the executive provide system services to the environment subsystems. They interact with each other through a set of well-defined formal interfaces. a) Hardware Abstraction Layer (HAL) =================================== The HAL consists of a series of functions that hide or abstract differences among hardware platforms. Although originally conceived to support variations in MIPS R3000/R4000 hardware platforms, the usefulness of abstracting hardware variations along with the advantage of providing a consistent programming model has led to the extension of the HAL to cover industry-standard i386 platforms as well. The HAL allows a large number of variations in hardware platforms for a single processor architecture without requiring a separate version of the operating system for each one. Thus vendor X can supply an x86 machine with one type of bus, and vendor Y can supply an x86 machine with another type of bus, but both machines will run the same x86 kernel. HAL routines are called from the base operating system and from device drivers. In both cases, the goal is to enable a single version of software to work across all compliant platforms. For drivers, this results in the ability to support a wide variety of I/O (Input/Output) architectures, instead of either being restricted to a single hardware model or performing extensive adaptation. The HAL is provided by the system hardware vendor as a separate file in standard Windows NT image format. Windows NT includes HALs for PC compatibles and some multiprocessor computers. The HAL is installed at setup time. b) Windows NT Kernel Architecture ================================= The Microkernel is a small, well-contained body of code approximately 60K in size. It is responsible for * thread scheduling and dispatching * multiprocessor synchronization * exception and interrupt handling * the implementation of low-level machine -dependent functions. The kernel executes entirely in kernel mode; it is nonpageable and nonpreemptible, but it is interruptible. Symmetric multiprocessing systems such as Windows NT allow the operating system to run on any free processor or on all processors simultaneously, sharing memory between them. At various stages during its execution, the kernel must guarantee that one, and only one, processor at a time is active within a given critical region. This is necessary to prevent code executing on one processor from simultaneously accessing and modifying data that is being accessed and modified from another processor. The mechanism by which this is achieved is called a spin lock. Eighty percent of the software in the kernel is machine independent. Of the 20 percent of the kernel that is machine dependent, 90 percent of the code is written in assembly language. Priority -------- Scheduling and Priorities: The Microkernel schedules threads for processor time based upon their dynamic priority, which varies in their predefined BASE PRIORITY CLASS. The dynamic priority is a number from 1 to 31 which represent the importance of the task. The highest priority thread always runs on the processor, even if this requires that a lower-priority thread should 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 ts threads. In NT 4.0, the base priority classes are IDLE (1-6) NORMAL (6 - 10) HIGH (11- 15) REAL-TIME (16 - 31) 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. Windows NT 4.0 has a virtual-memory system that combines physical memory, The priority of threads within the real-time (kernel) priority class is not altered by the kernel. However, as quantum end events occur, the threads within a level are round-robin scheduled. (A quantum is the processor time interval given to each thread after it has been in the waiting state.) The priority of threads within the variable priority classes are altered by the kernel. Threads have a base priority, and their priorities can be boosted or decremented dependent on the execution profile of the respective threads. At each quantum end event, the priority of the executing thread is decremented and a decision is made as to whether it should be preempted by another thread. If it should be preempted to execute a higher priority thread, a context switch occurs. When a thread in the variable priority class transitions from a Waiting state to a Ready state, it is given a priority boost that is dependent on the type of event that caused the Wait to be satisfied. If the event was keyboard input, for instance, the thread would get a large boost. However, if the event was disk I/O, it would be given a smaller boost. When a thread is readied for execution, an attempt is made to dispatch the thread on an idle processor. If an idle processor can be selected, preference is given to the last processor on which the thread executed (soft affinity). If an idle processor is not available, an attempt is made to find a processor that should be preempted. If an appropriate processor is located, preference is given to the last processor on which the thread executed. If no processor can be preempted to execute the ready thread, the thread is inserted at the end of the ready queue selected by its priority. The kernel exports a set of abstractions, called kernel objects, to the executive layer. Kernel objects are represented by a control block that describes the contents of each object. The executive layer uses kernel objects to construct more complex objects that are exported in user-level APIs. There are two kinds of kernel objects, dispatcher and control. Dispatcher objects have a signal state (Signaled or Not-Signaled) 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 kernel, but they do not affect dispatching or synchronization. Control objects include asynchronous procedure calls, interrupts, processes and profiles. c) NT Executive Services ======================== * I/O MANAGER =========== The I/O system is responsible for the management of all input and output operations in the system, and for presenting the remainder of the system with a uniform and device-independent view of the various devices connected to the system. The goals of the I/O system were to * support multiple installable file systems * provide services to make device driver development easier * provide facilities to load and unload device drivers automatically * allow device drivers to be written in a high-level language * ensure that I/O processing is fast. In addition to these specific goals, the I/O system had to provide the right capabilities to support the various environment subsystems. The Windows NT I/O is primarily based around an asynchronous I/O model with 64-bit file addressing, which leaves plenty of room for future expansion in hardware technology. Within the executive, everything the I/O manager does is asynchronous. However, a user-mode program can make synchronous or asynchronous calls and, as far as they are concerned, that's how the call behaves. To perform I/O operations in Windows NT, you must first acquire a file handle. File handles can be obtained by calling services to either create or open a file and return a handle to it. Alternatively, the services may open a device directly and return a handle to the device. In each case the handle is still referred to as a "file handle." The I/O architecture in Windows NT is based on a layered driver model with a well-defined formal interface. That is, one driver may be layered on top of another device driver. This allows functionality to be added to the I/O system in such a way that device drivers themselves can be smaller, and common code can be used for various types of devices. Device drivers are manipulated through file handles, and file handles are simply executive file objects. Therefore, Windows NT device drivers are subject to all of the Windows NT security mechanisms. The architecture supports multiple installable file systems that can be active simultaneously. Today NT supports FAT, HPFS (only NT3.5x), CDFS (the CD-ROM file system), and NTFS. The I/O system integrates into the global cache through services provided by the virtual memory manager. - I/O Queuing: the I/O manager processes requests from the I/O queue in order of priority, not in the order it received them - Cache Manager: the Windows NT cache manager supports a global cache, for the I/O system that varies in size from 64 MB,512 MB (Megabyte) controlled by a cache manager. The cache is divided into 256K chunks shared across all open files. The Cache Manager provides caching services to all file system and network components under the control of the I/O Manager. 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. - File System Drivers: see Note:73294.1 WINDOWS NT 4.0 FILESYSTEMS With Windows NT a new file system has been introduced called NTFS. Which gives support to very large volumes and very large file systems. Obviously FAT (File Allocation Table) was not designed to facilitate this, and HPFS (High-Performance File System) is limited to 32 bits, which means that Microsoft would have had to try to extend FAT or HPFS, and neither was easy to do in a compatible way. What Microsoft decided to do was to solve some of the other problems. One was crash recovery. If anyone has ever had a 600 MB disk and the system crashed, you noticed that it takes several minutes for chkdsk to complete. As your disk gets bigger, the time needed to run chkdsk increases linearly. So on a multigigabyte disk volume you could be waiting for over an hour, which is totally unacceptable. Therefore, one of the goals was to have a file system where the crash recovery time took seconds rather than minutes. NT achieves this by logging file system changes to a log file. Essentially this is simply a circular buffer that time-stamps the hanges to the disk structure and logs them to the log file. On reboot from a crash, it replays the log file and makes the appropriate updates to the disk structure. This keeps the structure consistent. It says nothing about the integrity of the data within the files, but what it does say is that the file system's integrity is 100 percent assured, which is exactly what chkdsk does. Chkdsk runs down through all the nodes in the file system and makes sure that they are all consistent. NT doesn't have to do this with NTFS because NT implements a careful write policy and a file structure log that it can replay when NT reboots. NTFS is also the file system that supports Unicode names. When you open a file on FAT or HPFS, NTFS takes the Unicode name in the executive and translates it to the current codepage in its ASCII name, and then looks it up on the disk. On NTFS, names are stored in the same Unicode that NT has in the executive, so you actually have localizable files. NTFS also supports long filenames (up to 254 Unicode characters), but it auto-generates 8.3 names so that MS-DOS applications can continue to work. There are mechanisms to get the directories of both the long names and the 8.3 names, and there are mechanisms to open them by either name. NTFS is the only file system that supports ACLs (Access Control Lists) on files, so if you want to have a secure file system you must use NTFS. There are File Manager/Explorer extensions for displaying ACLs, setting ACLs, and changing ACLs. Microsoft designed NTFS so that it can be extended without having to obsolete volumes or reformat the disk. NT does this with versioning numbers, and it has a set of mechanisms to allow upward-compatible changes. NTFS also supports multiple data streams and the mechanism to get to them. NT also provides utilities to convert FAT and HPFS volumes to NTFS volumes. There are no utilities to convert them in the other direction. As from NT4 there is no more support for the HPFS-filesystem. NTFS: Windows NT File System FAT: File Allocation Tables CDFS: Compact Disc Filing System HPFS: High Performance File System (OS/2) - Hardware Device Drivers Windows NT-compatible hardware device drivers (mouse drivers, disk drivers) Access the hardware registers of the peripheral devices through entry points in the Windows NT Executive dynamic link libraries. A set of these routines exists for every platform that NT supports. - Network Drivers Windows NT networking is part of the I/O systems, thus networking components are implemented using and utilizing the layered driver model. Although the redirector and server are built into Windows NT,they have no dependencies on the hardware on which the operating system is running. They are written in C and are implemented as file system drivers. They can be loaded and unloaded from the system at any time. Implementing the server and redirector as file system drivers gives them all the benefits of being part of the I/O system. For example, they have full access to the cache manager just like any other file system. Furthermore, because the I/O system's layered driver model is similar to the natural layer of the network protocols, the redirector and server can be layered on top of as many transport protocols as necessary. TDI (Transport Driver Interface) is an asynchronous, transport-independent interface that implements a generic addressing mechanism and a set of services and libraries. TDI does not operate on IRPs (I/O Request Packets) or SMBs (Server Message Blocks); rather, it provides a set of functions that any redirector can use to send whatever type of data it needs to send across the transport. TDI supports both connection- and connectionless-based transports. Windows NT is shipped with 32-bit versions of NetBEUI, TCP/IP, and DLC (Data Link Control) that are portable, are written in C, and are multiprocessor aware. NDIS (Network Device Interface Specification) is still supported and has been updated to version 3.0. Previous versions of NDIS drivers will have to be rewritten to operate on the Windows NT platform. To provide support for networking clients from multiple vendors, Windows NT has two components that decide which redirector to invoke when a remote I/O request is issued. The components responsible for this are the MPR (Multiple Protocol Router), a DLL (Dynamic-Link Library) that determines which network to access when an application uses the Win32 WinNet API for browsing a remote file system, and MUP (Multiple UNC Provider), a driver that determines which network to access when an application uses the Win32 I/O API to open a remote file. Windows NT's RPC can be implemented over named pipes, NetBIOS, and sockets. NT is compatible and can interoperate with other environments that support the DCE (Distributed Computing Environment) RPC, but it doesn't support connectionless RPCs. Supported protocols are: - TCP/IP (Transmission Control Protocol/Internet Protocol) - NetBEUI (Net Bios Extended User Interface) - NWLink (an implementation of IPX/SXP for connectivity with Novell Netware) - Data Link Control (interface for access to mainframes and network attached printers) * Object Management ================= The Windows NT object manager is the focal point for several types of resource management tasks, such as resource naming, placing quotas on the amount of resource each process can use, sharing resources between two or more processes, and securing resources against unauthorized access. Windows NT is based on an object model that has a uniform name space. All Windows NT objects are located in one name space; event objects, file objects, and process objects are all in one name space. All objects are accessed via object handles, and handles are assigned on a per-process basis. This has several advantages: 1. The operating system accesses and manipulates its resources uniformly. It creates, deletes, and references a thread object in the same way that it does an event object; by using object handles. The object manager can track resources by monitoring the creation and use of object handles. 2. Security is simplified because all objects are protected in the same way. Every time someone tries to access a protected object, the security system intervenes and does an access validation check. 3. Through the use of object handles and object security, two processes can share an object by simply opening a handle to it. Object security ensures that only authorized processes can open a handle to a shared object. The object manager puts wrappers around the basic kernel objects and exports them to user mode for use by the subsystems. The subsystems in turn provide objects for their own client applications that run against the subsystem. * Security Reference Monitor ========================== see Security Subsystem * Process Manager =============== The body of code that manages the creation and deletion of processes is known as the process structure. The Windows NT system is designed to support multiple operating system environments. Rather than packaging all the capabilities of these operating system environments into the Windows NT kernel and executive, the system has been designed so that robust, protected subsystems can be built to provide the necessary API emulation. The Windows NT approach is similar to the approach taken in Carnegie Mellon's Mach operating system. The Mach system design is based on a simple process structure, IPC (Interprocess Communication) mechanism, and virtual memory system. Using these primitives, Mach can implement both POSIX and UNIX 4.3BSD operating system environments as protected subsystems. Like Mach, the Windows NT process structure provides a very basic set of services. The Windows NT system provides no hierarchy, grouping, or process relationship. It does provide a complete set of services that subsystems can use to provide the set of semantics that are required by a particular operating system environment. The process structure is based on two types of objects. A process represents the virtual address space and control information necessary for the execution of a set of thread objects. A process contains: - A pointer to an address map - A list of threads - The total accumulated time for all threads executing within the process - a base priority A thread object represents the basic schedulable entity in the system. It contains its own set of machine registers, its own kernel stack, and a user stack in the address space of its process. Internally NT provides quotas to prevent errant or malicious applications from acquiring all the resources in the systems. The quotas NT provides are for paged and nonpaged resources, and for memory quotas. The statistics NT captures are per-process CPU (Central Processing Unit) time (kernel and user time) and per-process page faults. You can examine all of this through the Windows NT Performance Monitor * Local Procedure Call Facility ============================= Applications and environment subsystems have a client-server relationship, where the applications (clients) make calls to the environment subsystems (servers) to satisfy a request for some type of system services. Therefore, Windows NT must provide some form of fast communication mechanism between the client and the server. The executive solves the communication problem by implementing a message-passing facility called a Local Procedure Call (LPC). The LPC facility works very much like the RPC (Remote Procedure Calls) facility but is optimized for two processes running on the same computer. When an application makes an API call to the server, the call is intercepted by a stub in the client process that packages the parameters to the call and sends them to a server process that will actually implement the API. The LPC facility is the system that allows the stub procedure to pass the data to the server process and wait for a response from the server. The primary data structure used to implement the Windows NT LPC mechanism is the port object. A port object can have an optional memory section. The purpose of the optional memory section associated with a port is to optimize message passing. Since the maximum size of a message is fixed at port creation time, the data for messages that are too big to fit in the message queue is placed in the section object, and the address of the data is passed via the message queue. The LPC mechanism has no knowledge of the format of the section object; it is only concerned with making the section visible to both the client and server processes whenever a connection is established. The memory is managed by the process that created the section. The other important feature of this mechanism is the ability of the server to take on the security context of the client and impersonate the client. This means that access to protected objects is carried out in the correct security context. The other mechanism used for client-server communication is the Event Pair Synchronization mechanism. * Virtual Memory Manager ====================== The memory architecture of Windows NT is a virtual memory system based on a flat, linear address space accessed via 32-bit addresses. A process's virtual address space is a set of addresses available for the process's threads to use. Each virtual address space is 4 GB (Gigabyte), with 2 GB reserved for program storage that is private to the process and 2 GB reserved for system storage that is shared among all processes. NT4 SP3 Enterprise Edition has the 4GT Tuning Model, which allows to reserve 3 GB memory for a program and only 1 GB for the system. The VMM (Virtual Memory Manager) exports file mapping (section) objects to implement shared memory. The Windows NT file mapping functions provide a simple method for applications to share data. File mapping enables a process to view a file or piece of memory as part of the process's virtual address space. Cross-process operations are supported by permitting other processes to view the same file or memory as part of their address spaces, if they have an appropriate name or handle. The VMM manages copy-on-write protection to share read/write memory between two or more processes as long as none of the processes writes to memory. When a thread in one of the processes writes to the page, the VMM duplicates the page in the process's address space and sets the new page's protection to read/write. That process now has a private copy of the shared page that only it has access to. The VMM provides guard page protection to facilitate automatic bounds checking on stacks. When a thread accesses a guard page, the system generates an exception. VMM handles the exception by noticing that it exists within the stack range for that thread and automatically creates another guard page. It grows the stack by one page until the stack limit is reached, in which case the system generates a stack overflow exception. Guard pages can also be used with other data structures. Windows NT supports multiple paging files. Windows NT can do asynchronous I/O to the paging files and can access several paging files simultaneously. You can greatly improve performance if you create multiple paging files on different disks. d) ENVIRONMENT SUBSYSTEMS ========================= The Windows NT protected subsystems are user-mode server processes created by Windows NT when the system boots. The protected subsystems run continually, responding to messages sent to them from applications or other subsystems. Windows NT supports two types of protected subsystems, environment and integral. Environment subsystems implement operating system APIs, for example, Windows, POSIX, and OS/2. Integral subsystems act as part of the operating system, for example, security. Each protected subsystem provides services to its clients by calling native Windows NT executive services. Subsystems communicate by passing messages to each other. Normally, when an application calls an API, the environment subsystem responsible for handling that API will call a native Windows NT service or pass the call to another subsystem. After handling the call, the environment subsystem sends a message back to the application. All the message passing between applications and protected subsystems is transparent to the user and is facilitated by the LPC facility. The benefits in choosing this client-server model are: 1. It's possible to provide multiple APIs while keeping the Windows NT kernel and executive simple and maintainable. 2. It is possible to extend the environment subsystems without affecting the base operating system. 3. Environment subsystems are protected from client applications and from each other. However, one of the hurdles to overcome with the client-server approach is that of performance. In order for the protected subsystem to handle a client's call, the Windows NT executive must perform a context switch. That is, it must save the client thread's context, load the server thread's context, do some work, save the server thread's context, load the client thread's context, and pass back the results. Context switching has been highly optimized under Windows NT. The message-passing facility has also been optimized to handle both short and long messages. In addition, the Windows NT developers have established a number of techniques to reduce the number of interactions a client must make with a server: 1. The use of client-side DLLs to implement the API routines that don't use or modify global data. 2. Storing certain subsystem data in the executive, or caching subsystem data in the client-side DLL. 3. Batching client API calls and sending them to the server in a single message. The first technique provides the greatest benefits. If you take a close look at the various APIs, it becomes evident they can be divided into two categories: those that use or change global data and those that don't. The APIs in the latter group need not call the subsystem at all. That is, they can be implemented in a private client-side DLL. The DLL calls native Windows NT services to do its work, thereby avoiding context switching and message passing altogether. Although Windows NT supports multiple environment subsystems, Windows NT is first and foremost a Windows operating system. I am going to very briefly describe the Win32, POSIX, and OS/2 subsystems. Then I will go into more detail on how the security subsystem works and how Windows NT supports MS-DOS and 16-bit Windows-based applications. The Win32 subsystem provides a 32-bit flat memory model for developing 32-bit Windows-based applications. It supports preemptive multitasking, memory protection, security, and advanced operating system capabilities such as multithreading, process synchronization, memory management, and internationalization. In very general terms, the Win32 API is the Windows 3.x API stretched to 32 bits, with additional APIs to take advantage of the extra facilities offered by the Windows NT executive. The POSIX subsystem is implemented to POSIX.1 applications. The OS/2 subsystem supports OS/2 1.x character-based applications. For example, one of the applications that Microsoft tested the OS/2 subsystem with is SQL Server 4.2, which is a substantial character-based OS/2 application. * Security Subsystem ================== The security subsystem is known as an integral Windows NT subsystem. Along with the logon processes and the security reference monitor, these three components represent the Windows NT security architecture. Before a user can gain access to anything on a Windows NT machine, the user must be authenticated. Authentication of users is handled by the logon process and the security subsystem. After successful authentication, the user's shell process is tagged with a security access token. From this point forward, whenever the user attempts to access a protected object, the security reference monitor will run an access validation routine against the user's security access token. Also, any other process that the user creates will be tagged with the user's access token; thus any process acting on the user's behalf will have access validation routines run against the user's security access token. It is possible to track any security-related events that the user may initiate, which is one of the requirements for a C2 rating. One of the reasons Microsoft adopted an object model for Windows NT was to provide a consistent security model. With NT's consistent base security model, MS can now design security subsystems to meet almost any arbitrary security requirement. Although Windows NT is designed to provide more stringent security requirements, for the first release Microsoft is having NT evaluated for the U.S. DOD (Department Of Defense) C2 rating. C2 provides for: 1. Discretionary access control to protected objects based on the identity of a user, a group of users, or both. That is, access to a protected object is at the discretion of an authorized user. In the case of Windows NT, we are talking about the owner. 2. Protection from the reuse of objects. For example, if someone has deleted a file, no other user should be able to access that file. 3. Identification and authentication of all users before they can access any protected object. 4. Auditability of any security-related events (for example, access to a protected file) once a user is authenticated. (For NT4: only the NT4 workstation has received the C2 certificate) * OS/2 Subsystem ============== NT supports OS/2 1.X character based applications on x86 based computers. * POSIX Subsystem =============== The NT posix subsystem is designed to run POSIX applications (standard POSIX.1) POSIX = Portable Operating System Interface for Computing Environments) * VDM Architecture ================ Let's take a look at how NT runs MS-DOS and 16-bit Windows-based applications under Windows NT. Many people talk about an MS-DOS and a Win16 subsystem when in fact these are simply Win32 processes. A virtual MS-DOS machine (VDM) is simply a Win32 process with some MS-DOS emulation code. You can think of a VDM as being divided into two sections: a 16-bit section, where NT runs its 16-bit MS-DOS emulation and applications; and a 32-bit section, where NT provides a 32-bit portion of MS-DOS emulation, Virtual Device Driver (VDD) support, and an Instruction Execution Unit (IEU). The IEU is the only component that differs across platforms. On a RISC (Reduced Instruction Set Computing) platform, NT has licensed SoftPC technology from Insignia Solutions that emulates instructions. It does this by doing dynamic incremental compilation of x86 instructions. It is dynamic in that it will do a first pass of the compilation and, if it finds that the instructions are in a loop, it will optimize the compilation. It provides the same VDD interface regardless of platform, so the same VDDs will run on either platform with recompilation. To run MD-DOS applications, a VDM must provide a virtual PC. This involves providing virtual hardware for devices such as the screen and keyboard, support for ROM BIOS interrupt services, support for DOS Int 21 services, and support for executing x86 instructions. Hardware virtualization is provided by the VDD, ROM and MS-DOS support is provided by the MS-DOS emulation module, and instruction execution support is provided by the IEU. There is no limit on the number of VDMs that can be run, and each VDM runs in its own address space, which protects the MS-DOS applications from each other and the rest of the operating system from the VDMs. The Windows NT VDM features: MS-DOS 5.0 application support Virtual device drivers that run in user mode Over 625K free memory MS-DOS 5 compatible XMS (Extended Memory Specification) (MS-DOS 5 HiMem) support EMM (Expanded Memory Manager) LIM (Lotus/Intel/Microsoft) 4.0 support Full screen and windowed text Graphics full screen only on x86 computers Completely pageable Transparent access to Windows NT file systems and network redirected drives DPMI (DOS Protected Mode Interface) 0.9 (same as Windows 3.1) Multiple MS-DOS sessions Copy and paste to the Clipboard The VDM process always contains 3 threads - application thread: executes the code - heartbeat thread: simulates the timer interrupts - console thread: handles console I/O * WOW Architecture ================ The WOW (Windows 16 On Windows 32) is based on a single multithreaded VDM. All Win16 applications run in one VDM. However, only the WOW VDM is preemptively multitasked with respect to other processes running on the system. Each Win16 application is nonpreemptively multitasked with respect to each other; only one Win16 application runs, while the others are blocked. If the WOW VDM is preempted when the system returns, it always unblocks the Win16 application that was running before the WOW VDM was preempted. Additionally, the WOW VDM has a Windows 3.1 kernel, and stubs for the user, GDI (Graphics Device Interface), DLLs, and code to handle thunking (translation to and from 16 bit) of Windows APIs and messages. When a 16-bit Windows-based application issues an API call, the appropriate stub starts the thunking process. Parameters are pushed onto the stack, the call is converted to the equivalent 32-bit call and issued to the Win32 subsystem, and any handles, parameters, or messages that are returned are converted back into 16 bits and then passed back to the application. * Win32 subsystem: Windows NT Shell ================================= Three notable new utilities are Performance Monitor, Backup, and User Manager. Performance Monitor, as its name suggests, monitors the performance of your system in excruciating detail; CPU time per process, per thread, page faults per processor, disk reads per second, writes per second, and a host of other counters that will keep the bean counters happy into the next century. User Manager manages your user account database; creation, deletion, renaming, group assignment, and user rights assignment. Windows NT truly has a seamless interface to all the operating environments it supports. It has a single command-line interface that can execute MS-DOS, Win32, Win16, POSIX, and OS/2 applications. What's more, it is possible to pipe character-based I/O between subsystems or to mix subsystem commands on the same line. 3) Robustness ============= When designing an operating system with the caliber of Windows NT, it is important and necessary to provide a decent backup system. The Windows NT tape backup system was designed in conjunction with Maynard Systems, who have a very good pedigree in tape backup systems. Not only did Microsotf supply a tape backup system, but Microsoft also designed a set of tape I/O APIs so that third parties can develop their own tape backup/management systems. The APIs shield the application writer from file system details and tape hardware details. Tape backup is a GUI-based tool that supports backup of any Windows NT file systems and most standard backup procedures;normal, full, differential, incremental, and so on. There are no strange limitations. With Backup, NT supports multiple sets per tape, and files and sets can span tapes. It supports on-tape catalogs, which make restore a lot easier. Currently MS tape backup support is based around a wide selection of SCSI (Small Computer System Interface) devices. Disk Manager is a GUI-based disk management system; it has all the components of FDISK plus integrated fault tolerance. It is partition-based, so it can do mirroring, say between a SCSI drive and an ESDI (Enhanced Small Device Interface) drive. Span sets let you take up to eight odd pieces of partition and combine them into one logical drive. This has no significance on read/write performance, and it is not bootable. MIRRORING OR MIRROR SETS under Windows NT have no concept of a primary and secondary partition; both are considered equal. If any one fails, it is taken offline and the other one continues. All work at run time; no reboot is necessary. Under high I/O loads, you can get up to two times read improvement. Mirroring across controllers provides duplexing capabilities. Mirror sets are bootable. STRIPE SETS WITHOUT PARITY is where NT takes reads in 64K chunks, which is called a data stripe. NT reads a 64K chunk across all of the disks in the set. Writes are performed simultaneously to all disks. Under high loads, you can get N times read improvement, where N is the number of disks in the stripe set. Stripe sets work across disk controllers, but they are not bootable. They require 2 to 8 partitions. STRIPE SETS WITH PARITY, or RAID5, has the same functionality as stripe sets, but with parity. The parity information is stored on one of the striped disks (non-dedicated). If one of the disks in the stripe arrangement should fail, NT can recover the disk. If only one disk fails, the stripe arrangement will still function with some degradation. However, if two partitions fail, the stripe arrangement fails. It is not bootable, but it works across controllers. It requires 3 to 8 partitions. Users have long had the problem wherein they have 2 to 3 disks. They buy a new disk and connect it to the system, and what was the D: drive is now the E: drive, what was the E: drive is now the F: drive, and so on. This is a real problem for everything that depends on paths. Windows NT solves this by using a unique disk signature that is stored in the registry with the drive letter, partition, and fault-tolerance information. Every time we move the disk, the registry reads the signature information and lo and behold, we have the same drive letter. Drive letters "stick" with a drive, allowing new drives to be added without drive letters shifting and confusing applications. We can now physically move external drives between machines without complications. MS-DOS ignores the signature. Windows NT supports a UPS (Uninterruptible Power Supply) service that signals your Windows NT machine through the serial port when the power fails, and it provides an orderly shutdown of the system. 4) Windows NT Registry ====================== A longstanding problem with personal computers has been the management of their operating system and application configuration information. Even the simplest installations have a proliferation of configuration information for operating system, applications, and installed hardware strewn all across the hard disk. Every time you add a new application or hardware device to your system, more than likely you will add yet another configuration file to your system. With no protection and no standard location for configuration information, it is very easy to find yourself in a position where something does not run and your only recourse is to reinstall the application or, worse yet, the operating system. Windows for MS-DOS goes some way toward addressing some of these issues through the use of .INI files. Even though this is a step in the right direction, there are issues that still need to be addressed, such as security, remote management, and centralization. Windows NT introduces a whole new concept for managing configuration information for the operating system and the applications deployed on the operating system. This new management concept is based around the Windows NT configuration registry. The Windows NT configuration registry provides a secure, remotely accessible, unified database for storing operating system and configuration information. When you boot a Windows NT machine, the registry is populated with volatile hardware configuration data, information about hardware detected in your system. On x86 machines, this information is detected by a program called NTDETECT.COM. On ACE machines, this information is extracted from the ACE firmware. During boot, Windows NT extracts information from the registry, such as which device drivers to load and in what order. The kernel also passes back information on itself, such as its version number. Device drivers also send and receive data from the registry. The drivers receive load parameters and configuration data, similar to what you might find on the DEVICE line in a CONFIG.SYS file. A well-behaved device driver reports system resources it is using, for example, hardware interrupts, DMA (Direct Memory Access) channels, and so on. Device drivers can also report back discovered configuration data. The registry does have a dedicated tool to administer the registry, but it is not the tool you would use on an everyday basis to modify your configuration data. Windows provides several other tools that permit you to modify your configuration data in a way that is totally transparent to you. And finally, whenever you run a setup program, operating system installation, or application installation, it will add data to the registry. 5) Summary ========== Windows NT is a modern 32-bit operating system that delicately balances technical innovation with compatibility. It is portable across multiple CPU architectures, it has advanced security features designed in, its client-server architecture offers room for easy extendability without affecting the base operating system, it's scalable, and it will run the same applications on your desktop or your 4-processor server.