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).
Tip
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[11] 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.
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.[12]
- 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.
The first version of Windows NT (Windows NT 3.1[13]) 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[14] 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)[15] 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:
- 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.[16]
- 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.
[11] 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.
[12] 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).
[13] It was dubbed Version 3.1 mainly because it reported version number 3.1 for backward compatibility with Windows 3.1 applications.
[14] All hosts have to be on the same network segment to be able to communicate using NetBEUI.
[15] Microsoft has renamed its SMB protocol implementation " CIFS” (Common Internet File System) in a marketing effort to make it an “open” protocol.
[16] You can configure DCOM to use a specific port range on a per-application basis using the DCOM Configuration Properties application (dcomcnfg.exe).
Get Securing Windows NT/2000 Servers for the Internet now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
