云南龙网

  1. 首页 > 云知道 > >

1 《Undocumented Windows 2000 Secrets》翻译 --- 第二章

云知道

本章对于 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。

推荐阅读


上一篇：车库顶板排水板怎么铺

下一篇：夏天芒果的最佳保存方法