Windows NT Kernel Architecture (Windows Nt内核体系结构)

（图片没有处理好，显示比较慢。）

Now that we've looked at the high-level architecture of Windows 2000, let's delve deeper into the internal structure and the role each of the key operating system components plays. Figure 2-3 is a more detailed and complete diagram of the Windows 2000 system architecture and components than was shown earlier in the chapter (in Figure 2-2)

Figure 2-3 Windows 2000 architecture

If above Figure 2-3 you feel too complexity, you can see under Figure2-2.

Figure 2-2 Simplified Windows 2000 architecture

The following sections elaborate on each major element of this diagram. Chapter 3 explains the primary control mechanisms the system uses (such as the object manager, interrupts, and so forth). Chapter 4 describes the process of starting and shutting down Windows 2000, and Chapter 5 details management mechanisms such as the registry, service processes, and Windows Management Instrumentation (WMI). Then the remaining chapters explore in even more detail the internal structure and operation of key areas such as processes and threads, memory management, security, the I/O manager, storage management, the cache manager, the Windows 2000 file system (NTFS), and networking.

As shown in Figure 2-3, Windows 2000 has three environment subsystems: OS/2, POSIX, and Win32. As we'll explain shortly, of the three, the Win32 subsystem is special in that Windows 2000 can't run without it. (It owns the keyboard, mouse, and display, and it is required to be present even on server systems with no interactive users logged in.) In fact, the other two subsystems are configured to start on demand, whereas the Win32 subsystem must always be running.

The subsystem startup information is stored under the registry key HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/SubSystems.Figure 2-4 shows the values under this key.

Figure 2-4 Registry Editor showing Windows 2000 startup information

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. That means that some things can be done from an application built on one subsystem that can't be done by an application built on another subsystem. For example, a Win32 application can't use the POSIX fork function.

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. This type code is specified with the /SUBSYSTEM qualifier of the link command in Microsoft Visual C++ and can be viewed with the     Exetype tool in the Windows 2000 resource kits.

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.

The Win32 subsystem consists of the following major components:

• The environment subsystem process (Csrss.exe) contains support for:
  • Console (text) windows
  • Creating and deleting processes and threads
  • Portions of the support for 16-bit virtual DOS machine (VDM) processes
  • Other miscellaneous functions, such as GetTempFile, DefineDosDevice, ExitWindowsEx, and several natural language support functions

The kernel-mode device driver (Win32k.sys) contains:

• • The window manager, which controls window displays; manages screen output; collects input from keyboard, mouse, and other devices; and passes user messages to applications.
  • The Graphics Device Interface (GDI), which is a library of functions for graphics output devices. It includes functions for line, text, and figure drawing and for graphics manipulation.
• Subsystem DLLs (such as Kernel32.dll, Advapi32.dll, User32.dll, and Gdi32.dll) translate documented Win32 API functions into the appropriate undocumented kernel-mode system service calls to Ntoskrnl.exe and Win32k.sys.
• Graphics device drivers are hardware-dependent graphics display drivers, printer drivers, and video miniport drivers.

Ntdll.dll

Ntdll.dll is a special system support library primarily for the use of subsystem DLLs. It contains two types of functions:

• System service dispatch stubs to Windows 2000 executive system services
• Internal support functions used by subsystems, subsystem DLLs, and other native images

The Windows 2000 executive is the upper layer of Ntoskrnl.exe. (The kernel is the lower layer.)

The executive includes the following types of functions:

The Windows 2000 executive is the upper layer of Ntoskrnl.exe. (The kernel is the lower layer.) The executive includes the following types of functions:

• Functions that are exported and callable from user mode. These functions are called system services and are exported via Ntdll. Most of the services are accessible through the Win32 API or the APIs of another environment subsystem. A few services, however, aren't available through any documented subsystem function. (Examples include LPCs and various query functions such as NtQueryInformationxxx, specialized functions such as NtCreatePagingFile, and so on.)
• Functions that can be called only from kernel mode that are exported and documented in the Windows 2000 DDK or Windows 2000 Installable File System (IFS) Kit. (For information on the Windows 2000 IFS Kit, go to www.microsoft.com/ddk/ifskit.)
• Functions that are exported and callable from kernel mode but are not documented in the Windows 2000 DDK or IFS Kit (such as the functions called by the boot video driver, which start with Inbv).
• Functions that are defined as global symbols but are not exported. These would include internal support functions called within Ntoskrnl, such as those that start with Iop (internal I/O manager support functions) or Mi (internal memory management support functions).
• Functions that are internal to a module that are not defined as global symbols.

The executive contains the following major components：

The configuration manager (explained in Chapter 5) is responsible for implementing and managing the system registry.

The process and thread manager (explained in Chapter 6) creates and terminates processes and threads. The underlying support for processes and threads is implemented in the Windows 2000 kernel; the executive adds additional semantics and functions to these lower-level objects.

The security reference monitor (described in Chapter 8) enforces security policies on the local computer. It guards operating system resources, performing run-time object protection and auditing.

The I/O manager (explained in Chapter 9) implements device-independent I/O and is responsible for dispatching to the appropriate device drivers for further processing.

The Plug and Play (PnP) manager (explained in Chapter 9) determines which drivers are required to support a particular device and loads those drivers. It retrieves the hardware resource requirements for each device during enumeration. Based on the resource requirements of each device, the PnP manager assigns the appropriate hardware resources such as I/O ports, IRQs, DMA channels, and memory locations. It is also responsible for sending proper event notification for device changes (addition or removal of a device) on the system.

The power manager (explained in Chapter 9) coordinates power events and generates power management I/O notifications to device drivers. When the system is idle, the power manager can be configured to reduce power consumption by putting the CPU to sleep. Changes in power consumption by individual devices are handled by device drivers but are coordinated by the power manager.

The WDM Windows Management Instrumentation routines (explained in Chapter 5) enable device drivers to publish performance and configuration information and receive commands from the user-mode WMI service. Consumers of WMI information can be on the local machine or remote across the network.

The cache manager (explained in Chapter 11) improves the performance of file-based I/O by causing recently referenced disk data to reside in main memory for quick access (and by deferring disk writes by holding the updates in memory for a short time before sending them to the disk). As you'll see, it does this by using the memory manager's support for mapped files.

The virtual memory manager (explained in Chapter 7) implements virtual memory, a memory management scheme that provides a large, private address space for each process that can exceed available physical memory. The memory manager also provides the underlying support for the cache manager.

Kernel

The kernel consists of a set of functions in Ntoskrnl.exe that provide fundamental mechanisms (such as thread scheduling and synchronization services) used by the executive components, as well as low-level hardware architecture-dependent support (such as interrupt and exception dispatching), that are different on each processor architecture. The kernel code is written primarily in C, with assembly code reserved for those tasks that require access to specialized processor instructions and registers not easily accessible from C.

Kernel Objects

The kernel provides a low-level base of well-defined, predictable operating system primitives and mechanisms that allow higher-level components of the executive to do what they need to do.

Outside the kernel, the executive represents threads and other shareable resources as objects. These objects require some policy overhead, such as object handles to manipulate them, security checks to protect them, and resource quotas to be deducted when they are created. This overhead is eliminated in the kernel, which implements a set of simpler objects, called kernel objects, that help the kernel control central processing and support the creation of executive objects. Most executive-level objects encapsulate one or more kernel objects, incorporating their kernel-defined attributes.

One set of kernel objects, called control objects, establishes semantics for controlling various operating system functions. This set includes the APC object, the deferred procedure call (DPC)object, and several objects the I/O manager uses, such as the interrupt object.

Another set of kernel objects, known as dispatcher objects, incorporates synchronization capabilities that alter or affect thread scheduling. The dispatcher objects include the kernel thread, mutex (called mutant internally), event, kernel event pair, semaphore, timer, and waitable timer. The executive uses kernel functions to create instances of kernel objects, to manipulate them, and to construct the more complex objects it provides to user mode.

Hardware Support

The other major job of the kernel is to abstract or isolate the executive and device drivers from variations between the hardware architectures supported by Windows 2000. This job includes handling variations in functions such as interrupt handling, exception dispatching, and multiprocessor synchronization.

Hardware Abstraction Layer (HAL)

One of the crucial elements of the Windows 2000 design is its portability across a variety of hardware platforms. The HAL is a key part of making this portability possible. The HAL is a loadable kernel-mode module (Hal.dll) that provides the low-level interface to the hardware platform on which Windows 2000 is running. It hides hardware-dependent details such as I/O interfaces, interrupt controllers, and multiprocessor communication mechanisms—any functions that are both architecture-specific and machine-dependent. Windows 2000 internal components as well as user-written device drivers maintain portability by calling the HAL routines when they need platform-dependent information.

Device Drivers

Device drivers are loadable kernel-mode modules (typically ending in .sys) that interface between the I/O manager and the relevant hardware. They run in kernel mode in one of three contexts:

• In the context of the user thread that initiated an I/O function
• In the context of a kernel-mode system thread
• As a result of an interrupt (and therefore not in the context of any particular process or thread—whichever process or thread was current when the interrupt occurred)

As stated in the preceding section, device drivers in Windows 2000 don't manipulate hardware directly, but rather they call functions in the HAL to interface with the hardware. Drivers are typically written in C (sometimes C++) and therefore, with proper use of HAL routines, can be source code portable across the CPU architectures supported by Windows 2000 and binary portable within an architecture family.

There are several types of device drivers:

• Hardware device drivers manipulate hardware (using the HAL) to write output to or retrieve input from a physical device or network. There are many types of hardware device drivers, such as bus drivers, human interface drivers, mass storage drivers, and so on.
• File system drivers are Windows 2000 drivers that accept file-oriented I/O requests and translate them into I/O requests bound for a particular device.
• File system filter drivers, such as those that perform disk mirroring and encryption, intercept I/Os and perform some added-value processing before passing the I/O to the next layer.
• Network redirectors and servers are file system drivers that transmit file system I/O requests to a machine on the network and receive such requests, respectively.
• Protocol drivers implement a networking protocol such as TCP/IP, NetBEUI, and IPX/SPX.
• Kernel streaming filter drivers are chained together to perform signal processing on data streams, such as recording or displaying audio and video.

Because installing a device driver is the only way to add user-written kernel-mode code to the system, some programmers have written device drivers simply as a way to access internal operating system functions or data structures that are not accessible from user mode (but that are documented and supported in the DDK). For example, many of the utilities from www.sysinternals.com combine a Win32 GUI application and a device driver that is used to gather internal system state not accessible from the Win32 API.

 

 

中文翻译：

我们现在在一个比较高的高度看看Windows 2000的结构。让我们深入的专研这些内部结构每个关键的系统元件。下面的图2-3描绘了Windows 2000体系结构，比早些出现的图2-2的的描述要详细了很多。

   

图 2-3 Windows 2000 体系结构图

如果上图   2-3 让你感觉到过于复杂，请看下面的 图 2-2.


图 2-2 简易的 Windows 2000 体系结构图

下面的章节我们详细的描述图2-3的每一个主要的元素。第三章解释系统使用的主要控制机制（例如对象管理、中断，等等），第4张描述了Windows 2000系统的进程开始与结束。第5张详细的描述了系统的管理机制例如注册表、服务进程、Windows管理规范（WMI）。剩下的章节更详细的讨论了系统的内部结构和关键区域例如进程和线程、内存管理、安全，I/O管理，存贮管理和缓存（译者注：CPU）管理，Windows 2000的文件系统和网络。

 

子系统和子系统动态链接库

正如2-3描绘的那样，Windows 2000后3个子系统，分别是OS/2,POSIX,和win32子系统，As we'll explain shortly, of the three,Win32子系统特别重要对于Windows 2000来说，没有他，我们的Windows 2000将不能运行。（Win32 子系统管理鼠标，键盘，和输出显示，在还没有用户登陆到系统上的时候Win32子系统需要把系统的运行通过显示器呈现出来（译者注：这里不太准!））实际上，其他两个子系统在被要求启动的时候才会启动，而win32子系统是肯定需要启动。

    子系统的启动信息存储在注册表HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/SubSystems这个为之中。

 

图 2-4 注册表编辑器信息

系统启动时装载他需要的值。这个值有两个字符串：Windows和Debug.Windows这个值Win32子系统的详细规格说明。Csrss.exe(译者注：相信大家对这个程序都不会觉得陌生吧，要是想看看可以打开“任务管理器”您肯定可以找到这个进程)，全称叫做客户端/服务端即时运行子系统Client/Server Run-Time Subsystem。Debug是空的(它是用来做内部测试的)，所以它什么都没有。可选址证明了OS/2和POSIX子系统只有在要求启动时才会启动。Win32子系统的核心模式的文件名被包含在注册表的之中，win32.sys(往后的章节解释)。

 

子系统这个角色揭露应用软件执行Windows2000系统服务的一些子集(这里有点问题不太会翻译)，Windows2000本地服务的每个子系统提供不同的子集。这就是说某个子系统下编译执行的程序不能执行在其他子系统之下。例如，一个Win32应用程序不能使用POSIX子系统下的fork()函数。

 

每个可执行映像（例如后缀为.exe的）只能绑定一个子系统，当映像运行时，进程创建代码会在映像头检查对应子系统类型，所以，他通报对应的子系统的新子进程，微软可视化开发工具(VC++)连接代码的类型指定合适类型的子系统，也可以使用Exe文件类型的观察工具在Windows2000的源码工具箱里面。

当一个应用程序调用某个子系统的动态链接库里的函数时，下列三种情况之一将会发生：

这个函数完全在 用户空间执行。换句话说，没有消息传送给子系统进程，也没有Windows2000的系统服务被调用。函数在用户态完成任务，把结果返回给调用者。例如某些函数里包含有GetCurrentProcess函数(他总是返回-1,被定义为参考所有进程相关函数中的当前进程的）一个值和GetCurrentProcessId (当一个进程运行时，他的ID不会改变，所以这个ID能找到进程的位置，因此避免访问内核).

函数需要一次或多次调用Windows 2000执行，例如：Win32的ReadFille和WriteFile函数会调用各自的windows 2000I/O系统服务NtReadFile 和 NtWriteFile。

函数需要在子系统进程下工作。(子系统进程负责维护客户端应用程序运行在他的控制下这样的状态。)在这样的例子中，一个客户端/服务端 需要向子系统发送消息来完成操作。子系统的动态链接库等待一个返回值返回给调用者。

    有些函数会是上面的两种或者三种情况，例如Win32子系统的CreateProcess 和CreateThread 函数。

Win32子系统

Win32子系统主要由下列部分构成：

子系统进程(Csrss.exe)支持：

控制台窗口。

创建和销毁进程与线程。

支持部分16位虚拟DOS进程。

其他辅助功能，例如 GetTempFile, DefineDosDevice, ExitWindowsEx, 和一些民族语言的支持。

内核态设备驱动(Win32k.sys)包含：

窗口管理，控制串口显示，管理屏幕输出，处理来自键盘、鼠标、等等其他的驱动，还有过时的用户的程序。

图形驱动接口(GDI)，这是一个图形输出驱动函数库，它包含了画线，文本、轮廓、等图形操作函数。

子系统的动态链接库 (例如： Kernel32.dll, Advapi32.dll, User32.dll, and Gdi32.dll)传递 Win32 API函数到内核态系统服务调用Ntoskrnl.exe 和 Win32k.sys.

图形设备驱动是依赖硬件图形显示驱动，打印驱动和视频迷你驱动。

Ntdll.dll

对于子系统来说Ntdll.dll是一个主要的、特别的系动态链接库，他包含以下两类函数：

Windows 2000系统服务的残余服务的分配。

支持子系统执行体内部使用的函数，子系统的其他DLL还有其他映像。

执行体：

    Windows2000执行体在NT的内核Ntodkrnl.exe(译者注：记得看毛老鼠的资料的时候说到Ntodkrnl实质上就是Windows NT OS kernel的缩写，然后仔细一看，还蛮像^^)的上一层(内核在他的下层).

    这一层包含以下几种重要函数：

(1)可以从用户态直接调用的函数，调用这些系统服务经过Ntdll，这些中大多数都可以调用某个WIN32 API来启动所对应的服务。然而，有一些系统服务有些服务没有用到任何子系统函数。(例如：NtQueryInformationxxx，NtCreatePagingFile等)

(2)只能从核心态调用的函数，其中有一些在 Windows 2000 DDK (DDK:device driver kit)或Windows2000 IFS(Installable File System)包中已文档化(想了解更多的Windows 2000 IFS 工具包信息，请登陆www.microsoft.com/ddk/ifskit).

(3)其他的一些只能从核心态调用的函数，没有在 Windows 2000 DDK (DDK:device driver kit)或Windows2000 IFS(Installable File System)工具包中文档化(例如视频引导驱动调用的函数等)。

(4)函数虽然定义为全局符号，但不能导出。包括Ntoskrnl内部调用的函数，例如启动的Iop(内部I/O管理支持函数)或Mi(内部内存管理支持函数)。

(5)模块内部的函数，不是定义为全局的标记的。

 

执行体从总体上可以分为以下几个模块：

(1)配置管理器：负责管理注册表(第五章解释)。

(2)进程、线程管理器：负责创建和终止进程、线程(第六章解释)。下层进程和线程的工具在内核里面；执行体对这些更底层的对象增加额外的函数。

(3)安全引用监视器：在本地计算机上执行安全策略，保护计算机的资源，执行即时的对象保护和审计(第八章解释).

(4)I/O管理器：实现I/O的设备无关性，并负责把I/O请求分配给相应的设备驱动程序以进一步处理(第九章解释).

(5)即插即用管理器（PNP）：确定设备应该由哪个驱动程序来支持并负责加载相应驱动。在启动时的枚举过程中，它收集每个设备所需要的硬件资源，并根据设备的需要来分配合适的硬件资源如I/O端口，IRQ，DMA通道之类，当系统中的设备发生变化时它负责向系统和应用程序发送通知消息(第九章解释)。

(6)电源管理：协调电源时间，当CPU空闲，通过合理的配置，使得CPU降低电源消耗，针对个别的设备根据设备驱动改变电源的功耗来协调电源管理(第九章解释).

(7)WDM管理方法例程：可以让设备驱动程序发布性能和配置信息以及从用户态的WMI服务接受命令.可是是本地命令也可以是来自网络的命令。

(8)缓冲管理器：为了更好的文件基本操作性能，将最近使读写过的数据留在CACHE中，正如您看到的，做这个需要内存映射.

(9)虚拟内存管理：执行虚拟内存，对于每一个线程能提供比实际可用内存更大的私有地址空间，内存管理也提供概念更底层的缓存管理.

内核：

内核由在Ntoskrl.exe里的一套函数组成，它提供一些基本的机制(例如线程调度和同步服务)，又对底层硬件结构提供支持(例如中断和异常)，他们每一个处理器体系结构都不同，内核的源代码主要是用C和汇编语言写的，汇编语言为每一种处理器编写专门的处理指令，因为用C操作寄存器实现起来很难。

内核对象：

在内核表层，执行体负责把线程和其他可共享的资源当成对象，这些对象需要一些管理，例如对象的句柄操作他们，对他们进行安全检查，和创建他们时对资源进行分配。这种管理不是在内核里，简单的对象，他们帮助内核控制处理器和支持创建执行对象，大多数可执行的对象装入一个或多个内核对象里，合并他们的内核属性。

一类对象叫做控制对象，控制不同的系统函数，包括APC，DPC对象以及其他几个I/O要用到的对象，如中断对象。

一类对象叫做调度对象，用于线程调度。这些对象包括线程，互斥体，事件，内核事件对，信号量，定时器，可等待定时器。执行体利用内核对象来操作他们，构造更复杂的对象给提供给用户模式。

硬件支持：

内核的另一主要功能是使得执行体和设备驱动独立于硬件，这个工作包含处理多个方面的差异：中断处理，异常处理，多处理器同步方式的差异。

硬件抽象层（HAL）：

这是windows2000实现其可移植性最重要的组成部分，HAL是一个可加载的核心态模块（HAL.DLL），它提供了windows2000所运行的硬件平台的底层接口，HAL隐藏了各种与硬件有关的细节，比如I/O接口、中断控制器、多处理通信机制等----这些都是平台相关的。当需要平台相关的信息时，windows2000的内部模块或者用户程序通过HAL来实现。

设备驱动程序：  

设备驱动程序是核心态可加载模块(以.SYS为扩展名)，它们是I/O管理器和相关硬件设备的接口。

它们运行于以下三种环境之一：

(1) 在一个初始化了I/O函数的用户线程上下文中(在一个用户线程的上下文中，这个用户线程初始化了io函数)

(2) 在内核模式的系统线程的上下文中

(3) 中断发生后(不在任何进程和线程中运行，中断发生时哪一个进程或者线程正在运行)

如前所述，windows2000的设备驱动程序并不直接操作硬件，而是调用HAL中的函数作为与硬件的接口。驱动程序通常用C语言写(有时用C++)。因此，设备驱动程序通过使用HAL可以实现平台无关性。

有以下几中设备驱动程序：

(1)硬件驱动程序：实现对物理硬件的读写 (通过使用HAL)。硬件驱动有许多种类型，例如总线驱动，接口驱动，大容量存储器驱动，等等。

(2)文件系统驱动程序：是面向文件I/O的驱动程序，它把这些请求转化成绑定到特定设备的I/O请求

(3)文件过滤器驱动程序。例如执行磁盘映射和加密，过滤I/O出入。

(4)网络重定向驱动程序。网络上的文件系统输入输出还有接收各自的请求。

(5)协议驱动程序，实现网络协议例如TCP/IP, NetBEUI, 和 IPX/SPX.

(6)内核流过滤器驱动程序，封锁起来处理数据流，信号，例如记录和显示音频和视频。

因为安装驱动程序是把用户编写的用户态代码添加到系统的唯一办法，因此，一些程序员通过编写设备驱动程序可以访问OS的内部函数或者内部数据结构来实现用户模式无法做到的东西(但这些文档在DDK中)。例如，www.sysinternals.com上许多有用的信息结合一个Win32应用程序和一个设备驱动，习惯用Win32 API来访问系统内部状态.

参考资料：《Microsoft - Inside Windows 2000 Third Edition.chm》