本章对于 Windows 2000 Native API 的讨论，主要集中在这些 API 和系统模块之间的关系，将重点介绍 Windows 2000 采用的中断机制。 Windows 2000 利用此机制将对内核服务的请求从用户模式向内核模式传递。另外， Win32K 接口和一些与 Native API 相关的主要运行时库也会被提及，同时还将介绍一些经常使用的数据类型。

有关 Windows 2000 架构的详细讨论已经很多。许多有关 Windows NT 的讨论同样适用于 Windows 2000 。《 Inside Windows NT 》（ Custer 1993, Solomon 1998 ）的第一、二版都是有关此方面的好书，同样的还有《 Inside Windows 2000 》（ Solomon and Russinovich 2000 ）。

NT*() 和 Zw*() 函数集

有关 Windows 2000 架构的一个有趣的事实是：它模拟了多个操作系统。 Windows 2000 内置三个子系统来支持 Win32 、 POSIX 和 OS/2 应用程序。 Win32 子系统是最流行的一个，因此它更多的被开发人员和操作系统所关照。在 Windows 9x 中， Win32 接口实际上是作为整个系统的基础结构来实现的。但是， Windows 2000 的设计却有很大不同。尽管 Win32 子系统包含一个名为 kernel32.dll 的系统模块，但这并不是实际的操作系统内核。它仅仅是 Win32 子系统的一个基本组件。在很多编程书籍中， Windows NT/2000 的软件开发被简化为与 Win32 API 打交道的工作， NT 平台暴露出的一个隐藏的事实是存在另一个更为基础的调用接口： Native API 。相信编写 kernel-mode driver 或 file system driver 的开发人员已经对 Native API 非常熟悉了，因为 kernel-mode 模块位于更低的系统层，在那里子系统是不可见的。然而，你并不需要到驱动程序一层才能访问此接口 ---- 即使一个普通的 Win32 应用程序也可在任何时候调用 Native API 。这没什么技术上的限制 ---- 仅仅是微软不支持此种应用程序开发模式而已。因此，有关此话题的信息并不是很多， neither SDK nor the DDK make the Native API available to Win32 Application.

未文档化的级别

本书中的多数东西都来自被称为未文档化的信息。这通常意味着微软没有公开发布这些信息。然而，未文档化也存在几个级别，这是因为可能被公布的有关庞大的操作系统（如 Windows 2000 ）的信息非常的多。我个人的系统分类如下：

l 正式文档 ：这些信息来自微软出版的书、文件或者开发工具。大多数重要信息来自 SDK 、 DDK 和 MSDN 。

l 半文档化的（ Semidocumented ） ：尽管不是正式文档，但这些信息还是可以从微软正式发布的文件中挖掘出来的。例如， Windows 2000 的很多函数和结构体并没有在 SDK 或 DDK 文档中提到，但出现在一些头文件或示列程序中。以 Windows 2000 为例，很多重要的半文档化信息都源自头文件 ntddk.h 和 ntdef.h ，这两个文件都是 DDK 的一部分。

l 未文档化，但并没有隐藏 ：这些信息不能在任何官方文档和开发文档中找到，但其中的一部分对调试工具是可用的。可执行文件或符号文件中的所有符号化信息都属于这一部分。最好的例子是内核调试器的 !processfields 和 !threadfields 命令，这两个命令会给出两个未文档化的结构： EPROCESS 和 ETHREAD 的成员名称及其偏移量。

l 完全未文档化的 ：微软很好的隐藏了某些信息，要获得它们只能通过逆向工程和推理。此类信息包含很多实现细节的信息，没有人认为 Windows 2000 开发人员需要关注它们，但是这些信息对于系统开发人员和开发调试软件的人来说却非常宝贵。挖掘系统内部的信息是非常困难的，但同样是非常有趣的。

本书讨论的 Windows 2000 的内部细节覆盖了上述系统分类的后三个。

系统服务分配器（ System Service Dispatcher ）

Win32 子系统和 Native API 之间的关系可以由 Win32 核心模块与 Windows 2000 内核模块之间的依赖关系很好的解释。 图 2-1 展示了模块间的依赖关系，方框表示系统模块，箭头表示模块间的依赖关系。如果一个箭头从模块 A 指向模块 B ，这表示 A 依赖于 B ，即，模块 A 调用 B 中的函数。模块由双向箭头连接，表示二者之间相互依赖。在 图 2-1 中，模块： user32.dll 、 advapi32.dll 、 gdi32.dll 、 rpcrt4.dll 以及 kernel32.dll 实现了基本的 Win32 API 。当然，还有其他的 DLL （如 version.dll 、 shell32.dll 和 comctl32.dll ）也为 Win32 API 提供支持，为了更清晰些，我省略了它们。 图 2-1 表现出的一个特性非常有趣，所有的 Win32 API 调用最后都转移到了 ntdll.dll ，而 ntdll.dll 又将其转移到了 ntoskrnl.exe 。

Ntdll.dll 是一个操作系统组件，它为 Native API 准确地提供服务， ntdll.dll 是 Native API 在用户模式下的前端。 Native API 真正的接口在 ntoskrnl.exe 中实现。从其文件名可以猜出它就是 NT 操作系统内核。事实上，内核模式驱动程序对系统服务的请求多数时候都会进入该模块。 Ntdll.dll 的主要任务就是为运行于用户模式的程序提供一个确定的内核函数的子集，这其中就包括 Win32 子系统 DLLs 。在 图 2-1 中，从 ntdll.dll 指向 ntoskrnl.exe 的箭头旁标注的 INT 2eh 表示 Windows 2000 使用此中断将 CPU 特权级从用户模式切换到内核模式。开发内核（ kernel-mode ）模式程序的人员认为用户模式的代码是具有攻击性的、充满错误的和危险的。因此，必须让这些代码远离内核函数。而通过在调用 API 的过程中将特权级别从用户模式切换到内核模式是一种可控制这些问题的方式。调用程序从来不可能触及内核，它只能察看它们。

例如，由 kernel32.dll 导出的 Win32 API 函数 DeviceIoControl() 最终会调用由 ntdll.dll 导出的 NtDeviceIoControlFile() 。通过反编译该函数会发现此函数令人惊讶的实现方式 — 它是如此的简单！ 示列 2-1 展示了这些。首先， CPU 寄存器 EAX 被装入了一个“魔术”数字 0x38 ，这是一个分派 ID 。接下来，寄存器 EDX 被设置指向堆栈中的某处，其地址为堆栈指针 ESP 加上 4 ，因此， EDX 将指向堆栈中返回地址的后面，该返回地址在进入 NtDeviceIoControlFile() 时将被立即保存下来。显而易见， EDX 指向的位置是用来临时存放传递进来的参数的。接下来的指令是一个简单的 INT 2eh ，该指令将跳转到中断描述符表（ Interrupt Descriptor Table,IDT ）的 0x2e 位置上存放的中断处理例程（ interrupt handler ）中。这看上去是不是很熟悉？事实上，这有些像 DOS 下的 INT 21h 调用。然而， Windows 2000 的 INT 2eh 接口要远比一个简单的 API 调用有用，分配器（ dispatcher ）利用它从用户模式进入内核模式。请注意，这种模式切换方式是 x86 处理器特有的。在 Alpha 平台上，有不同的方式来实现此种功能。

[1] [2] [3] [4] 下一页