驱动与系统简史.doc

1.11.1 设备驱动程序简史设备驱动程序简史 1.1 设备驱动程序简史 最早的运行在 Intel 处理器芯片上的 PC 机，CPU 提供给其 640KB 的所谓的“实” 内存这是因为内存是真正在那里以内存芯片的形式存在，并且可以依靠处理 器的 20 位物理地址直接访问的而处理器也只提供了一种模式，称之为实模式， 其内部由处理器将两个 16 位的寄存器结合，组成 20 位的内存地址形式，给相 应的涉及内存操作的指令使用计算机体系结构高扩了扩充插槽的概念使得一 些用户可以将买来的独立的板卡组装到机器上这类板卡常常伴随有一些用于 设置 DIP 开关的指令（随后，跳线出现），这些指令可以轻微地改变 I/O 配置 但你不得不了解你 PC 的所有 I/O 和中断分配来正确的做这件事情MS-DOS 基 于 CONFIG.SYS 文件整合起了一种架构，使得操作系统能够装载原始设备和附加 板卡的实模式设备驱动程序所以，不可避免的就是这些驱动程序要使用汇编 语言来编写并且或多或少地依赖于一定的 BIOS 中断指令和 MS-DOS 自身的系统 服务这样，最终用户不得不通过命令调用应用程序而应用程序开发者也不 得不为程序开发出视频显示，键盘，和鼠标程序，因为 MS-DOS 和系统 BIOS 都 没有把其做的充分。

之后，IBM 引入了基于 80286 处理器的 AT 系列的个人计算机286 处理器添加 了保护模式作业，这样，这样程序可以访问的主内存和扩展内存达到 16MB，其 使用 24 位段地址（通过一个在 16 位段寄存器中的段选择器被间接指定）和一 个 16 位的偏移地址MS-DOS 自己保持为一个实模式操作系统，所以当时许多 软件厂商做过一些 DOS 的扩展产品来允许程序员将其实模式下的应用程序移到 保护模式下并能访问到全部内存自 MS-DOS 开始统治电脑以来，驱动程序技术 基本上就没有前进改变 PC 机技术的分水岭在我看来，应当是——Intel 发布其 80386 处理器芯片 之日386 允许程序通过页表间接地访问访问高达 4GB 的虚拟内存地址，它还 允许程序不费吹灰之力就能将 32 位数据用于算法和寻址上那一阵子曾经让软 件工具市场很狼狈，如编译器厂商和 DOS 扩展产品的公司…………设备驱动程 序依旧是用汇编语言写的 16 位的实模式程序并且通过 CONFIG.SYS 安装，而终 端用户依旧需要手动配置板卡之后的处理器主要是在性能和速度上的提升，本质上并没有改变如我写这章 的时候，1GHz 的 CPU，50G 的硬盘和 512MB（乃至更高）的内存的计算机已经司 空见惯了。

与之同时，操作系统平台上的反展也进行着大多数人，甚至包括系统程序员， 也更加喜欢图形交互式的计算机而不是字符式的了实际上 Microsoft 在图形 化操作系统上并没有抢先一步，Apple 在其第一款 Macintosh 上倒是先发制人 但之后微软却用其 Windows 系列操作系统在这个领域上取得了霸主地位一开 始，Windows 不过是一个实模式的 MS-DOS 下的一个图形模式的外壳，随着时间 的过去，一批包括显示，键盘和鼠标的通用 Windows 驱动出现了这些驱动是 可执行文件，其扩展名为.DRV，主要使用汇编语言编写随着 AT 系列电脑的问世，Microsoft 生产了一个有保护模式版本的 Windows 但 Microsoft 还是在保护模式下使用实模式下的.DRV 驱动硬件除了标准的 Windows 设备（如显示，键盘和鼠标）外，继续沿用实模式下的 MS-DOS 驱动最终，在 386 处理器时代后不久，Micorsoft 发布了 Windows3.0，一个完全利 用虚拟内存方式的使用“增强”模式作业的操作系统虽然如此，但其新的硬 件依旧需要实模式驱动但现在已经有了大问题。

若要多任务地执行 MS-DOS 程 序（这是用户所需要的），Micorsoft 不得不建立虚拟操作系统每个 MS-DOS 应用程序在 Windows 的图形环境上运行在其自己的虚拟机上但是所有这类的 MS-DOS 应用程序都可能会通过 IN 和 OUT 指令来直接访问硬件，读写设备存储 器，处理来自硬件的中断此外，两个或更多的应用程序共享处理器时间片将 会导致硬件上的指令冲突这类冲突当然也会在显示，键盘和鼠标上表现出来为了允许多种程序共享物理硬件，Microsoft 引入了虚拟驱动设备的概念，其 主要的目的是“虚拟”一个硬件设备这样驱动被统一称之为 VxD，因为其大 部分的文件名适合 VxD.386 的特征其中，x 代表其管理的设备利用这一概 念，Windows 3.0 创建了可以单独使用许多硬件设备的虚拟机外观但由于设 备自身的发展，大多数的时候它还得被实模式的 MS-DOS 驱动程序所驱动VxD 就扮演了 通过首先截取应用程序试图接触硬件的尝试，把应用程序的访问传递 给了硬件，并暂时地将处理器切换到一种被称为虚拟 8086 的实模式下来运行 MS-DOS 驱动程序的这种操作这样其实也不是很好，使用模式切换来运行实模式的驱动……Microsoft 版本的 OS/2 最后成为了 Windows NT，其第一次公开发行是在刚刚发 布完 Windows 3.1 的上个世纪 90 年代。

Microsoft 构建 Windows NT 系统是想 让其成为一种稳定和安全的平台Windows NT 的驱动使用一种崭新的内核模式 技术实际上其几乎没有参与当时流行的其它的两种驱动技术Windows NT 驱 动程序完全使用了 C 语言编写，这样就可以在不改变任何代码的情况下在新的 CPU 架构上被重新编译另一件有关 Windows 3.0 发展的事情，这已经成为我们今天的一个重要的分支 Windows 正式将软件世界分成了用户模式程序和内核模式程序用户模式程序 包括了用户买来使用的所有的应用程序和游戏但其并不被信任能够健壮地 （甚至是诚实地）来处理硬件或者其他程序而内核模式程序则包括操作系统 自身和大家写的全部的驱动程序内核模式程序是被系统完全信赖的，并且可 以接触到它们想要的系统的任何资源虽然 Windows 3.0 使用了其作业模式的 隔离程序，但没有一个版本的 Windows（甚至包括 Windows Me）真正地引入内 存保护使其成为一个安全的系统安全是 Windows NT 和其后继者的主要职责， 如禁止用户模式程序查看或者更改由内核管理的资源实际上 PC 机的平均计算能力直到最近才满足了 Windows NT 良好运行地需要。

因此 Microsoft 不得不延长其它 Windows 的产品的使用周期Windows 3.0 成 长为 3.1，3.11，和 95以 Windows 95 开始，如果你打算编写一个设备驱动，你就会去写一种被称为 VxD 的真正的 32 位保护模式的驱动程序同样，从 Windows 95 开始，终端用户可以丢掉他们的 I/O 图，因为操作系统新的即插即 用的特点可以开始自动地识别并配置硬件了但是作为一个硬件制造者，你还 不得不为了那些不打算从 Windows 3.X 升级的用户编写一个实模式驱动同时， Windows NT 发展到了 3.5，4.0你可能需要第三方的驱动来支持这些系统，而 且你需要在这些项目中使用你的编程知识之后，Micorsoft 又开发了一个新的设备驱动技术——Windows 驱动模块 （WDM），并且将其应用到了 Windows 95 后的 Windows 98 和 Windows Me它 们也将此技术应用到了 Windows NT 后的 Windows 2000 和 Windows XP在 Windows Me 时，MS-DOS 只是象征性的存在，并且不需要硬件制造者担心实模式 的设备驱动。

因为有 WDM 在，至少由原始的意图，实际同样在所有的平台上， 写一个这样的驱动成为了可能总之，我们是站在最初的 PC 架构和早期的 MS-DOS 的基础上的最终用户仍还 会打开机箱，安装一些扩展的板卡，但和以前相比，现在我们可以使用一些不 同的、更强有力的总线即插即用和周边元件扩展接口（PCI）总线已让最终用 户远离了 I/O，内存和中断请求的使用虽然现在还有 BIOS，但其现在的主要 作用只是引导系统并告诉操作系统（Windows XP 或 Windows Me）那些被发现的 配置细节WDM 驱动程序的扩展名是.SYS，就和当初实模式下的驱动程序一样1.21.2 操作系统概述操作系统概述 操作系统概述操作系统概述Windows driver model 为驱动程序运行在两种操作系统中提供了一个结构框架： Windows98，windowsMe 和 windowsXP,windows2000在之前的历史摘要中所讨 论的那样，这两种操作系统是两种平行的发展方向的产物实际上，我将之前 的这个系统称为 98/Me 是为了强调他们共同的传统，而后来的这个系统则简单 称之为 XP 了虽然对最终用户来说这两种系统很类似，但他们的内部工作十分 不同，在一节中，我将对这两套系统进行简单概述。

XPXP 概述概述图 1-1 是一张 Windows XP 操作系统的简略的逻辑图， 图里我对写设备 驱动的人强调了一些重要的特点 Windows XP 对每个平台都支持两种执行模 式 软件既在用户模式又在内核模式下运行 一个用户模式下的程序想要从 一个设备中读取一些数据，他就会向 application programming interface(API)发 送一个请求，比如说发送“readfile”而子系统模块(像 KENRNEL32.DLL)通 过调用一个本地的本地的 API 功能(像 NtReadFile)来实现有关本地 API 的信息的请 参考下面The native API） 我们经常所说 NtReadFile 是被一个称为 I/O Manager 的系统部件的一部分I/O Manager 这个术语可能稍使人误解，因为并不存在这个的单独可执行模件当我们讨论围绕着驱动程序的操作系统服务的不明白的地方的时候，我们就需 要要使用的一个名字而“I/O 管理器”就是我们通常使用的名字 很多程序服务类似于 NtReadFile他们在内核态里运行，它响应了一个应 用的请求后，用某种方式来与一个设备交互。

他们验证所有的参数， 因此不 用担心因为执行了某个操作安全性得不到保障， 或者防止用户模式程序非法存 取数据 然后他们创建了一个名为 I/O 请求包（IRP）的数据结构，并把这个 数据结构送到某个驱动程序的入口点 比如以一个最初的 ReadFile 请求来说， NtReadFile 将创建一个 IRP，它带有主要功能代码 IRP_MJ_READ（在 DDK 驱动开发工具包的头文件中是一个常量） 实际的处理细节可能不同，但大体 上都会像 NtReadFile 这样：它会返回一个状态告诉用户模式发送请求者操作还 没有完成设备驱动也许会运行其他应用程序来等待操作完成，或者立即进入 等待状态不论哪种方式，设备驱动程序对该 IRP 的处理都与应用程序无关执行 IRP 的设备驱动程序最后可能会访问硬件对于一个 programmed I/O (PIO)方式的设备，IRP_MJ_READ 操作将导致直接读取设备的端口或者是 设备实现的内存寄存器尽管运行在内核模式中的驱动程序可以直接与硬件对 话，但它们通常都使用硬件抽象层(HAL)访问硬件读操作包括使用 READ_PORT_UCHAR 从某个 I/O 口读取单字节数据。

HAL 例程使用平台相关 的方法执行操作在 Intel x86 计算机上，HAL 使用 IN 指令（访问设备端口）， 在以后的 xp 平台，很可能使用内存 fetch驱动程序。