This section provides a very basic summary of the architecture of Windows NT and Windows 2000 systems. You’ll need at least this background information for understanding the instructions in subsequent chapters. For more detailed information, see a good Windows operating system book. I particularly recommend Inside Windows NT, Third Edition by James D. Murray (O’Reilly & Associates, 1999).
In the discussion that follows, most of the details are the same for Windows NT and Windows 2000. If there is an architectural difference, I will note it.
Windows NT is a multithreaded, micro-kernel-based operating system. The term micro-kernel implies that the kernel component is very small, and provides only basic functions such as thread dispatching and hardware exception handling. Hardware-specific code is kept in a separate layer called the Hardware Abstraction Layer (HAL). The HAL simplifies porting of the operating system to new processor architectures like the IA-64.
The core operating system code runs in privileged processor mode. This mode is also known as protected mode (when referring to the CPU), or kernel mode (when referring to a process or thread). Protected mode provides direct access to system memory and other hardware. Applications run in a nonprivileged processor mode known as user mode and have no direct hardware access. Applications have to use the system calls — the API (Application Programming Interface) — in the underlying operating system to perform tasks such as reading or writing to memory or to the screen.
The basic Windows NT architecture is shown in Figure 1.9.
system services are
kept in discrete subsystems, some running in user mode and others in
kernel mode. There are several kernel mode subsystems in Windows NT.
They provide NT’s native functionality for user mode subsystems
(running in user mode). The kernel mode subsystems make up
the Windows NT Executive, and consist of the
The Windows NT architecture is not strictly object-oriented, but internal structures such as shared memory segments, processes, and threads are represented as objects to provide a uniform method for handling things like access control. The Object Manager creates, manages, and deletes Windows NT Executive objects. Objects are represented in a hierarchical namespace much like a filesystem.
Enforces the access and audit policies in the system. The Security Reference Monitor provides access validation, privilege checking, and audit message generation at runtime for both user and kernel mode processes.
These components make up the kernel mode part of the Win32 subsystem. They handle user input and screen output. All of the Win32 subsystem originally ran in user mode; however, for performance reasons, a part of it was moved to kernel mode as of NT 4.0.
The part of
the Win32 subsystem running in user mode. The Win32 subsystem is a
required part of the operating system and is loaded as a part of the
boot sequence. The subsystem consists of the Win32 API DLLs
kernel32.dll, user32.dll, gdi32.dll ) and the
Win32 subsystem process (
The first version of Windows NT (Windows NT 3.1) was released in 1993. It was positioned as a successor to the LAN Manager products from Microsoft and IBM. To interoperate and provide backward compatibility with these products, it had to support some established networking standards, such as NetBIOS and SMB. It’s important you understand what these protocols are and how they are used in Windows NT. They still provide the foundation for most Windows NT network communication in both Windows NT 4.0 and Windows 2000.
NetBIOS (Network Basic Input/Output System) is a standard for transmitting data between computers over the network. The NetBIOS specification was developed for IBM back in 1983 to allow network communication between applications. NetBIOS provides three key services:
The first implementations of NetBIOS didn’t separate the software interface from the network protocol. Later on, the network-level part of the standard was named NetBEUI (NetBIOS Extended User Interface). The Windows NT version of NetBEUI is also referred to as NBF (NetBIOS Frame). Nowadays, NetBIOS can use transports other than the nonroutable NetBEUI protocol, such as TCP/IP ( NetBIOS over TCP/IP—NetBT) or IPX/SPX.
Remember that NetBIOS is merely a standard for finding resources and transmitting bits. A higher-level protocol is required on top of NetBIOS for it to be of any real use. Here’s where SMB comes in. Server Message Block (SMB) is a standard for sending commands and data. SMB is mostly used for file and print sharing, but it can also be used for Inter-Process Communication (IPC) to communicate with processes on other systems.
SMB over NetBIOS uses ports udp/137 (NetBIOS name service) and udp/138 (NetBIOS datagram service) or tcp/139 (NetBIOS session service). Windows 2000 includes support for running SMB without NetBIOS over tcp/445. This support is referred to as Direct Host .
The I/O Manager in the NT Executive is responsible for most I/O processing, including disk and network I/O. Figure 1.10 illustrates some of the networking components in the I/O Manager and shows how user mode services interact with these components.
Like all subsystems in the Executive, the I/O Manager exposes a number of APIs to user mode processes. These APIs include the following:
Microsoft’s Remote Procedure Call (MS-RPC) provides a mechanism for using ordinary function calls to communicate with processes on another computer. Distributed Components Object Model (DCOM) components use MS-RPC.
There are two ways of performing RPC communication between two hosts:
Uses SMB-named pipes as transport for the RPC calls. Administrative tools such as Server Manager, User Manager, Performance Monitor, and Event Viewer all use MS-RPC over SMB to connect to remote hosts. Windows NT domains also rely on MS-RPC over SMB.
Communication is established by using dynamically assigned high ports (>1023) and the RPC portmapper services tcp/135 and udp/135. This RPC method is often used by DCOM applications.
There are two boundary layers in the network architecture:
The TDI provides developers with a protocol-independent network API for network services. Developers need only to program against the TDI to support all available network protocols.
The NDIS wrapper driver communicates with the network protocols. The wrapper driver provides a uniform interface between protocol drivers and NDIS device drivers.
Bindings enable communication between two components on adjacent layers in the protocol stack. For example, bindings can be configured to limit a service to one network protocol or to allow only a network protocol on one of the network adapters in the system.
In the example shown in Figure 1.11, the binding between the Server service and the NetBEUI protocol has been removed. This means the Server is not able to service requests from NetBEUI clients. TCP/IP is bound only to the NIC1 network interface card. IPX/SPX and NetBEUI are bound only to NIC2. As a result, the system will only use TCP/IP on NIC1, and both IPX/SPX and NetBEUI on NIC2.
 The NT architecture is not a true micro-kernel architecture. Most true micro-kernel implementations have exhibited poor performance. Many compromises in the micro-kernel design have been made in the NT architecture to achieve better performance.
 SRM doesn’t check for object permissions if the calling thread or process is running in kernel mode. For performance reasons, SRM assumes that the caller has permission on all objects, since it is running in kernel mode and is therefore a part of the Trusted Computing Base (TCB).
 It was dubbed Version 3.1 mainly because it reported version number 3.1 for backward compatibility with Windows 3.1 applications.
 All hosts have to be on the same network segment to be able to communicate using NetBEUI.
 Microsoft has renamed its SMB protocol implementation " CIFS” (Common Internet File System) in a marketing effort to make it an “open” protocol.
 You can configure DCOM to use a specific port range on a per-application basis using the DCOM Configuration Properties application (dcomcnfg.exe).