Chapter 2
System Architecture
Over view:
Windows 2000 was designed to run on a variety of hardware architectures, including Intel-based CISC systems as well as RISC systems.
Windows 2000 achieves portability across hardware architectures and platforms in two primary ways:
Windows 2000 has a layered design, with low-level portions of the system that are processor-architecture-specific or platform-specific isolated into separate modules so that upper layers of the system can be shielded from the differences between architectures and among hardware platforms. The two key components that provide operating system portability are the kernel (contained in Ntoskrnl.exe) and the hardware abstraction layer (contained in Hal.dll).
The vast majority of Windows 2000 is written in C, with some portions in C++. Assembly language is used only for those parts of the operating system that need to communicate directly with system hardware (such as the interrupt trap handler) or that are extremely performance-sensitive (such as context switching).
The four basic types of user-mode processes are described as follows:
Fixed (or hardwired) system support processes, such as the logon process and the session manager, that are not Windows 2000 services (that is, not started by the service control manager).
Service processes that host Win32 services, such as the Task Scheduler and Spooler services. Many Windows 2000 server applications, such as Microsoft SQL Server and Microsoft Exchange Server, also include components that run as services.
User applications, which can be one of five types: Win32, Windows 3.1, MS-DOS, POSIX, or OS/2 1.2.
Environment subsystems, which expose the native operating system services to user applications through a set of callable functions, thus providing an operating system environment, or personality. Windows 2000 ships with three environment subsystems: Win32, POSIX, and OS/2.
//Under Windows 2000, user applications don't call the native Windows 2000 operating system services directly; rather, they go through one or more subsystem dynamic-link libraries (DLLs). The role of the subsystem DLLs is to translate a documented function into the appropriate internal (and undocumented) Windows 2000 system service calls. This translation might or might not involve sending a message to the environment subsystem process that is serving the user application.
The kernel-mode components of Windows 2000 include the following:
The Windows 2000 executive contains the base operating system services, such as memory management, process and thread management, security, I/O, and interprocess communication.
The Windows 2000 kernel consists of low-level operating system functions, such as thread scheduling, interrupt and exception dispatching, and multiprocessor synchronization. It also provides a set of routines and basic objects that the rest of the executive uses to implement higher-level constructs.
Device drivers include both hardware device drivers that translate user I/O function calls into specific hardware device I/O requests as well as file system and network drivers.
The hardware abstraction layer (HAL) is a layer of code that isolates the kernel, device drivers, and the rest of the Windows 2000 executive from platform-specific hardware differences (such as differences between motherboards).
The windowing and graphics system implements the graphical user interface (GUI) functions (better known as the Win32 USER and GDI functions), such as dealing with windows, user interface controls, and drawing.
********************************************************************************************
[url=http://dev.csdn.net/javascript:fullSize(]
Figure-Windows 2000 architecture
Environment Subsystems and Subsystem DLLs:
Windows 2000 has three environment subsystems: OS/2, POSIX, and Win32.
The role of an environment subsystem is to expose some subset of the base Windows 2000 executive system services to application programs. Each subsystem can provide access to different subsets of the native services in Windows 2000.
Each executable image (.exe) is bound to one and only one subsystem. When an image is run, the process creation code examines the subsystem type code in the image header so that it can notify the proper subsystem of the new process.
When an application calls a function in a subsystem DLL, one of three things can occur:
The function is entirely implemented in user mode inside the subsystem DLL. In other words, no message is sent to the environment subsystem process, and no Windows 2000 executive system services are called. The function is performed in user mode, and the results are returned to the caller. Examples of such functions include GetCurrentProcess (which always returns -1, a value that is defined to refer to the current process in all process-related functions) and GetCurrentProcessId (the process ID doesn't change for a running process, so this ID is retrieved from a cached location, thus avoiding the need to call into the kernel).
The function requires one or more calls to the Windows 2000 executive. For example, the Win32 ReadFile and WriteFile functions involve calling the underlying internal (and undocumented) Windows 2000 I/O system services NtReadFile and NtWriteFile, respectively.
The function requires some work to be done in the environment subsystem process. (The environment subsystem processes, running in user mode, are responsible for maintaining the state of the client applications running under their control.) In this case, a client/server request is made to the environment subsystem via a message sent to the subsystem to perform some operation. The subsystem DLL then waits for a reply before returning to the caller.
Some functions can be a combination of the second and third items above, such as the Win32 CreateProcess and CreateThread functions.
