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.
Windows NT/2000 Subsystems and Services
Operating 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 through ntdll.dll (running in user mode). The kernel mode subsystems make up the Windows NT Executive, and consist of the following:
- Object Manager
- 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.
- Process Manager
- Responsible for creating and terminating processes and threads using underlying kernel functions.
- Virtual Memory Manager
- Implements the virtual memory used to allocate a private address space to each process.
- I/O Manager
- Provides a device-independent I/O system to processes. It dispatches I/O requests to the appropriate device driver.
- Local Procedure Call (LPC) Facility
- Implements a fast, lightweight version of Remote Procedure Call (RPC) for communication between components within a computer.
- Security Reference Monitor (SRM)
- 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.
- Window Manager and Graphical Device Interface (GDI)
- 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 subsystems running in user mode are called the environment subsystems. There are three environment subsystems:
- Win32 subsystem
- 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 (csrss.exe ).
- POSIX subsystem
- Provides support for POSIX.1 applications. It’s an optional component that is loaded on demand.
- OS/2 1.x subsystem
- Provides support for OS/2 1.x console applications. It’s an optional component that is loaded on demand.
Windows NT also provides support for MS-DOS and 16-bit Windows 3.x applications through its Virtual DOS Machine. This is not a native NT subsystem. It’s a Win32 application that emulates a DOS environment.
Windows NT Networking
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:
- Name service
- Locates NetBIOS names on the network.
- Session service
- Provides a connection between two computers.
- Datagram service
- Provides a connectionless communication channel between computers.
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.
Server Message Block (SMB)
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.
NT networking architecture
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:
- Windows Sockets (Winsock)
- The Windows NT implementation of the widely used Sockets API. Applications that use Winsock include Internet Explorer, IIS, Telnet, and FTP.
- SMB Named Pipes
- One-way or duplex communications channels between the pipe server and one or more pipe clients.
- SMB Mailslots
- A simple IPC mechanism that can be used to send or receive small (less than 425 bytes) datagram broadcast messages.
- Remote Procedure Call (RPC)
- 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:
- MS-RPC over SMB
- 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.
- MS-RPC using Windows Sockets
- 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.
- MS-RPC over SMB
- SMB filesystem drivers
- There are two components that enable SMB file sharing:
- SMB Redirector
- The redirector is a filesystem driver that communicates with the SMB server driver component on a remote system. The Workstation service uses the SMB redirector.
- SMB Server
- The Server filesystem driver and the Server service work for the connections requested by client-side redirectors, forwarding them to the appropriate local filesystem driver, such as NTFS.
- NetBIOS Interface API
- The NetBIOS interface API is provided primarily for existing applications that use IBM NetBIOS 3.0 and need to be ported to the Win32 API.
There are two boundary layers in the network architecture:
- Transport Driver Interface (TDI)
- 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.
- Network Driver Interface Specification (NDIS)
- 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.