1.发了一个重复贴，不好改，索性将把之前翻译的winddk文档搬上来，即兴的翻译，很差，见谅。
2.看chm会舒服很多，但是我还没有翻译完成。完成之后会放一个chm。
3.希望能够帮助到有需要的同学。
另：恳请指出错误，我需要您的指正才能进步，因为我讲自己译得差是讲真的，不是谦虚。
谢谢


Windows组件概述

下图显示了基于NT构架的操作系统的主要内部组件：



NT组件概观

如图所示，基于NT构架的操作系统包括用户模式和内核模式组件。内核模式组件拥有相对独立的功能而与其他内核模式组件相独立。

对内核模式驱动程序员来说，最令人感兴趣的执行体(Executive)组件是I/O管理器(I/O Manager)，配置管理器(Configuration Manager)，即插即用管理器(Plug and Play)，电源管理器(Power Manager)，内存管理器(Memory Manager)，执行体支持(Executive Support)，处理器结构(Process Structure)，内核(Kernel)，和硬件抽象层(Hardware Abstract Layer)。一些驱动开发人员也会对其他组件如对象管理器(Object Manager)和安全引用监视器(Security Reference Monitor)感兴趣。

在图中文件系统(File System)，中间(Intermediate)和最底层(Lowest)驱动位于I/O管理器框中，是因为，在很大程度上由I/O管理器(I/O Manager)初始化这些驱动的I/O操作。




Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

Windows驱动程序种类

有两种类型的windows驱动：

用户模式驱动(User-Mode Driver) 运行于用户模式下，这种驱动一般提供了一套从Win32应用程序到内核模式驱动或者其他操作系统组件之间的接口。例如，打印机由用户模式驱动和内核模式驱动一起支持。更多打印机驱动组成的信息，请看打印简介。

内核模式驱动(Kernel-Mode Driver) 作为执行体的一部分，运行于运行内核模式下，而执行体则由管理I/O，即插即用，内存，进线程，安全等的内核操作系统组件组成。内核模式驱动一般情况都是分层的。一般地，高层驱动从应用程序那里接收数据，过滤数据，然后将其传送到提供设备功能的下层驱动。

一些内核模式驱动被称为WDM驱动，这些驱动遵守Windows驱动模型(WDM)。所有的WDM驱动支持即插即用，和电源管理。WDM驱动在Windows 98 /Me 和 Windows 2000以及其后的操作系统之间源代码兼容（但不是二进制文件兼容）。

和操作系统本身一样，内核模式驱动是分散的，模块化了的组件，这些组件都具有特定的一系列功能。所有内核驱动都具有了一系列的由系统定义的标准驱动过程（standard driver routine) 。

下图将内核模式驱动分为几种类型。



内核驱动的种类

如上图所述，在驱动栈中有三种基本的内核驱动类型：最高层，中层，和最底层驱动。每种驱动之间结构只是微小的差异，但功能上却有很大的区别。

最高层驱动(highest driver)。最高层驱动包括提供文件系统的文件系统驱动(FSDs) ，列如： NTFS

File allocation table (FAT) 

CD-ROM file system (CDFS) 

最高层驱动总是基于下层驱动的支持，比如中间层功能驱动或最底层硬件总线驱动。

中间层驱动(intermediate dirver)，比如虚拟磁盘，映像，或者特定设备类型的类驱动(class driver) 。中间层驱动基于下层驱动的支持。中间层驱动还可细分成如下几种类型： 功能驱动(function driver)控制I/O总线上的特定的外围设备。

过滤驱动(filter driver)将自身插入功能驱动之上或者之下。

软总线驱动(software bus driver)包含一系列的子设备，而包括高层类，功能或者过滤驱动都可以挂钩在这些子设备上。

例如，一个控制多设备多功能适配器的驱动可以称之为软总线驱动。

任何由系统提供的定义系统的类/子类(class/subclass)接口的类驱动(class driver)就功效来说都是一种与多个的子类驱动(miniclass driver) 相联的中间层驱动（有时候也称这种子类驱动为子驱动[minidriver]）。每一个类/子驱动(class/minidriver)对提供了功能驱动或者软总线驱动同等的功能。

最底层驱动(lowest driver) 控制了与外设相连I/O总线 。最底层 驱动不基于任何其他下层驱动。 硬件 总线驱动(bus driver) 是由系统提供的，通常用来进行I/O总线的动态配置 。 硬件总线驱动与即插即用管理器一同为所有连接到I/O总线的子设备配置和重新配置系统硬件资源，（硬件总线驱动包括windows2000之前发行的NT构架操作系统的HAL组件的一部分功能。）

传统驱动(legacy driver)直接控制物理设备，是最底层驱动。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

内核驱动程序的设计目标

内核驱动程序设计目标与操作系统的很多设计目标相同，特别是与系统的I/O管理器设计目标基本相同。内核驱动程序要求：

可移植：从一个平台到另一个平台

可配置：多种软硬件平台

优先级多工和可中断

在多处理器平台上多处理器安全 

基于对象 

基于可重复IRPs的包驱动I/O

支持异步I/O


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

移植性

所有的驱动必须确保能够在所有的Windows硬件平台上运行。为了达到多平台可移值的目的，驱动开发师应该： 

使用C语言（而不是汇编语言）

只使用由DDK提供的程序接口和头文件

用C语言写驱动

所有的内核模式驱动应该使用C语言来编写，这样我们只需使用特定系统的C语言编译器重新编译，链接，而不必重写或者 替换任何代码，即可运行于其他Microsoft Windows平台上。大部分操作系统组件是完全由C语言编写的，只有硬件抽象层(HAL)及内核(kernel)的小部分是由汇编书写的，因此操作系统在不同的硬件平台上取得移植性。

驱动不应该依赖于任何特定系统的C语言编译器或者语言库，如若这些特定的功能并不为其他的系统的编译器所支持。一般情况下，驱动代码应该遵循ANSI C标准并且不依赖任何该标准描述为“没有定义”的功能。 

为了书写可移植的驱动，首先得避免：

依赖于那些不同平台具有不同大小的数据类型。

调用尚待讨论的标准的C运行库函数。

调用C语言运行库函数，而不使用由操作系统提供的等价支持例程。


使用DDK提供的接口

每一个NT执行体组件提供了一系列的内核模式 驱动支持例程(driver support routines) 。驱动程序和其他内核模式组件都会调用这些驱动支持例程。 因为组件接口不会改变，即使底层的支持例程随着时间发生变化，她的调用者仍旧可以维护可移植性。 

DDK提供了一系列的头文件。这些头文件定义了系统特别的数据类型以及驱动（其他内核模式组伯）用来维持可移植性的一些常量。所有内核驱动都包含了一个DDK内核模式主头文件，wdm.h或者ntddk.h。主头文件不仅仅提供了定义基本内核模式类型的头文件还包括了对任意处理器构架的特别头文件，当然这个时候要求驱动程序使用特定的指令来进行编译。

也有一些驱动，如SCSI微型端口驱动(SCSI miniport drivers), NDIS驱动(NDIS drivers)和 显卡微型端口驱动(video miniport drivers),包括其他的由系统提供的头文件。 

如果一个函数要求使用平台相关的定义，您最好是使用#ifdef语句将这些定义独立起来，这样驱动即可以编译，链接到适合的硬件平台。然而，你一般情况下都可以使用支持例程，宏，常量以及其他由DDK主要头文件提供的数据类型，来避免在您的驱动中使用平台相关，条件编译的代码。

内核模式驱动可以使用内核模式DDK中当中文档化了的RtlXxx例程。内核驱动不能够使用用户模式下的RtlXxx例程。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

可配置性

今天的外设必须能够做到硬件－配置(hardware-configurable)，因此她们的驱动必须做到软件－配置(software-configurable)。

如果一个设备能够接受系统硬件资源不同的配置（比如I/O端口数量），而不必要进行特理上的更改，那么我们称该设备为硬件-可配置(hardware-configurable)设备。例如，如果有一些可热插拔的即插即用的磁盘连组成廉价冗余磁盘阵列(RAID)，用户可以在系统运行进时，更换。如果一个设备是硬件-可配置(hardware configurable)的，她的驱动就不能够有硬编码(hard-coded)，或者依赖于系统的设备硬件资源的值。

一个驱动器可称为软件-可配置(software-configurable)，如果：

她能动态地接收或者改变她的设备硬件资源。 

支持即插即用的驱动不包括设备硬件资源的值勤的硬编码，而且驱动也不会一直询问该设备来确定她的资源安排。相反地，系统动态地为这个设备安排资源，同时为其驱动安排资源值。

驱动并不对在驱动栈当中任何位于其上或者其下的驱动作任何假定。

比如， 一个为磁盘设计的底层设备驱动程序必须具有良好的扩展性，以便支持多种由多种高级文件系统驱动形成的文件系统，运行于同 一台电脑上。 除此之外，如果一台电脑有中够的大规模储存能力，在一个文件系统当中，底层磁盘驱动不应该与中间层驱动交流来支持整个系统的容错能力（被设计为镜像分区，stripe sets,或者卷设备） 。 


即插即用管理器和每个即插即用硬件总路线驱动一同为特定类型的I/O总线和系统级软件提供不同平台之间访问的接口。即插即用管理器创建了一个设备树，设备树当中的每个节点都代表的系统当中的一个设备（包括总线）。即插即用管理器为每一个设备保持有两个列表：

一个使用中硬件的硬件资源列表

一个实际分配到设备的硬件资源列表


设备驱动程序协同即插即用管理器创建这两个列表，这两个列表储存于注册表当中。一个设备加入系统或者一个设备从系统当中移除，即插即用管理器都会重新配置那些必须配置的资源然后更新这两个列表。

系统的硬件抽象层(HAL)组件，被设计成动态链接库，为其他系统组件或者内核模式驱动提供一些硬件级别的，平台相关的支持。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

总是可优先和总是可中断

操作系统优先权级别和可中断的设计目标为了最大化系统的性能。任何都可以被其他优先级高的线程超过，同样任何驱动的中断服务例程(interrupt service routine[ISR])都可被其他拥有更高中断请求级别(interrupt request level[IRQL])的例程所中断。

内核组件(Kernel)根括代码的优先级情况，来决定一段代码序列何时执行：

内核为线程定义的实时优先规则。

每一个系统中的线程都有一个相应的优先级属性。一般情况下，大部分线程拥有一个可变的优先级属性：她们总是可以被优先或者根据圆棒算法调度其与等同优先级线程的运行。有一部分线程拥有实时(real-time)优先级：这些对时间要求特别高的线程将会运行到结束除非她们被另一个拥有更高优先级的实时线程所超越。Windows构架从本质上来讲就从来不是一个实时(real-time)系统 。 

无论线程的优先级，当硬件中断或者特定种类的软件中断发生时，系统中的任何线程都可被超越。

由内核(Kernel)定义的中断请求级别(IRQL)与特定的中断向量(interrupt vector)相绑定。

内核优先执行硬件中断和软断，因此一些内核模式的代码，包括大部分的驱动运行于高IRQLs,来确保其具有比系统当中其他线程更高的优先级。由底层设备的硬件优先级来确实相同级别IRQL时运行何段内核模式驱动的代码。

内核模式代码永远都可以被中断：一个拥有更高级别IRQL值的中断可以在任何时候产生，从而这一拥有更高的IRQL的代码能够立即在处理器上得到执行。然而，当一段代码运行机制于一个给定IRQL上，内核将屏bi所有IRQL小于或者等于该IRQL的中断向量号(interrupt vectors)。


最低的IRQL级别被称为PASSIVE_LEVEL。在这个级别上，没有屏蔽任何中断微量. 

一般情况下,线程都运行于IRQL=PASSIVE_LEVEL。下一个更高阶的IRQL级别是软中断。这些级别包括APC_LEVEL，DISPATCH_LEVEL，或者为了内核调试，WAKE_LEVEL。设备中断拥有更高阶的IRQL值。内核为系统严重中断（如系统时钟和总线错误）保留了最高级别的IRQL。

一些系统支持例程只能运行于IRQL=PASSIVE_LEVEL的环境下，这可能是因为她们被设计成为可分页代码或者她们会访问可分页数据，当然也可能因为一些内核组件创建属于她们自己的线程。

同样地，一些标准驱动例程(standard driver routines)常运行于IRQL=PASSIVE_LEVEL。然而，一些标准驱动例程运行于IRQL=DISPATCH_LVEL或者对于最底层驱动来看，运行于设备IRQL级别（device IRQL,亦被称为DIRQL）。更多关于IRQLs的信息，请见 

管理硬件优先级。

驱动当中任何例程都是可以被中断的。这包括那些运行于高于PASSIVE_LEVEL的IRQL级别的例程。任何运行于特定IRQL级别的例程只有在没有更高级别IRQL发生时才可以得到CPU的控制权。

与一些较古老的计算机操作系统不同，一个Microsoft Windows驱动的ISR从来都不是一个完成大部分I/O处理的由大而复杂的例程 。这是因为所有驱动的中断服务例程(interrupt service routine[ISR])都能够被其他任何更高级IRQL上他例程所中断（例如，被其他驱动的ISR）。因此，一个驱动的ISR不一定能够从一而终不间断的得到CPU的控制权， 

在Windows的驱动中，一个ISR一般都保存了硬件状态信息，排队了一个延时过程调用(deferred procedure call[DPC])， 然后快速退出。过后，系统从队列中取得该驱动的DPC,这样驱动就能够在低IRQL(DISPATCH_LEVEL)完成I/O操作了。为一个优秀的全局效率，所有运行于高IRQLs必须主动快速放弃其对CPU的控制权。

在Windows当中，所有的线程都有一个线程上下文环境。这个上下文包括了标志拥有该线程的进程，还有一些线程访问权限的属性。

一般说来，只有最高级别的驱动运行于请求驱动I/O操作的线程当中。中间层驱动或者最底层驱动永远都不应该假定自己执行于请求当前I/O操作的线程环境当中。

结果是，驱动的例程常常执行于一个异线程环境(aribitrary thread context)－ 标准驱动例程被调用时正在运行的任意线程。考虑到性能的问题(为了避免上下文交换），只有很少的驱动创建其自身的线程。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

多处理器安全

基于NT的操作系统被设计成可以运行于单处理器或者对称多处理器(symmetric multiprocessor[SMP])平台上，同样内核驱动程序也应该如此。

在所有Microsoft Windows多处理器平台上， 都存在以下的条件： 

所有的CPU都是一样的，没有任何CPU能够拥有一样的协处理器。

所有的CPU分享一块内存并且拥有一致的访问内存的权力。

在对称(symmetric)多平台上，每一个CPU都能够访问内存，处理中断，以及访问I/O控制寄存器。（相反地，在一个非对称（asymmetric)多处理器机器在上，一个CPU处理所有其他CPU的中断）。


为了多处理器平台下的运行安全，一个操作系统必须得保证运行于单处理器的代码一不会同时访问和修改另一个处理正在访问和修改的数据。例如，如果一个最低层的驱动的ISR只在一个处理器上处理一个设备的中断，她就必须独享这个设备寄存器或者驱动定义的数据，以防止同时发生在另一处理器上的设备中断。

更重要的是，一个在单处理器机器上能够处理的驱动的连续I/O操作可能在对称多处理器电脑上发生重叠。也就是说，一个驱动的处理输入I/O请求例程 可能正在一个处理器上执行，但是另一个与设备通信的例程更在另一个处理器上执行。无论内核模式驱动是在单处理器上或者是对称多处理器上执行，她们都必须得对所有驱动定义的数据和系统提供的在不同驱动例程当中共享的资源进行同步，当然也得同步对特理设备的访问，如果存在物理设备的话。

NT内核组件提供一种称为自旋锁的同步机制。驱动程序能够使用这种机制保护在对称多处理器平台上同时运行的一个或者多个例程共享的数据（或者设备寄存器）免受多个例程的同时访问。内核强制两种使用自旋锁的规则：

一个例程可以在任何时候拥有一个特定的自旋锁。在访问共享数据，每一个例程必须访问该共享数据的例程必须得首先申请该数据的自旋锁。为了访问同一段数据，另一个例程只有申请得到自旋锁才可以访问，但是自旋锁在之前那个例程没有释放之前是不可能申请得到的。

内核为系统当中的每一个自旋锁都绑定了一个IRQL值。只有当一个内核模式的例程运行于自旋锁的IRQL时，才能够申请得到该自旋锁。

这两个规则防止一个运行于低层IRQL驱动的例程，但持有一个自旋锁的被线程被基其他拥有高优先级的驱动例程得到。以防止死锁的发生。

绑定到自旋锁上的IRQL一般情况是申请自旋锁的拥有最高IRQL的例程的IRQL。

例如，一个最底层驱动的ISR常常与这个驱动的DPC例程共享一些状态数据。这个DPC例程调用一个驱动提供的临界区(critical section)例程去访问共享数据。 保护共享数据的自旋锁拥有和设备中断DIRQL 一样的IRQL。只要临界区例程保持一个自旋锁然而以DIRQL级别来访问共享数据，这个ISR就不能够运行任何的单处理器或者对称多处理器电脑上了。 

这个ISR不能够运行于单处理器机器是因为这个设备中断已经被屏蔽了，见总是可优先和总是可中断

在一个对称多处理器的机器上，一个ISR在临界区例程保持一个自旋锁并且在DIRQL访问共享数据时，不能够得到保护共享数据自旋锁。

一系列的内核模式线程能够同步共享数据或者一些被其他内核的分派对象：事件(event)，互斥体(mutex),信号(semaphore),时钟(timer)或者基他线程访问。然而，大部分的驱动不会创建其自身的线程，因为如果避免线程上下文切换的话，能够得到更好的效率。当一个时间－严重的内核模式支持例程和驱动运行于IRQL=DISPATCH_LEVEL或者在DIRQL时，她们必须使用内核的自旋锁来同步共享数据或者资源的访问。

更多信息，见自旋锁，管理硬件优先级 和 内核分派对象。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

基于对象

基于NT的操作系统是基于对象的。执行体(executive)的大部分组件定义一个或者多个对象类型。每一个组件引出了一些内核模式支持例程来操纵她们的对象类型的实例。没有任何组件能够直接访问其他组件的对象。为了使用其他组件的对象，一个组件必须调用其他组件输出的支持例程。

这种设计使得操作系统能够在具有移植性的同时，具有扩展性。例如，在将来的发布新的操作系统时，完全可更新定义同样类型数据的内核，但是拥有不同的内部结构。如果这个不同的内核输出与现存内核同样名称和参数支持例程，那么内部结构的改为并不会对现存系统中任何其他执行体组件的移植性产生影响。

同样的，为了支持可移植性和可配置性，驱动必须得与操作系统通信， 或者与其他驱动通信，只使用由DDK当中描述的支持接口。

和操作系统相似，驱劝一样是基于对像的。例如：

文件对像 代表了一个模式应用程序到一个设备的连接。

设备对像 则代表每个设备的逻辑，虚拟和物理设备。

驱动对象 代表了每个驱动的映像。 


I/O管理器为文件对像，设备对象和驱动对像定义了结构和接口。

和其他执行体组伯一样，驱动通过调用I/O管理器或者基他内核组件所提供的内核模式支持例程来使用对像。内核支持例程的名字一般都表明了该例程要处理的对像类型及要对其进行的操作。下述支持例程名字具有以下的形式： 

操作对像的前缀



地点



前缀

指明导出该支持例程的内核模式组件，往往这个组件也定义了对像的类型。大部分前缀由两个字符组成。



操作

描述对该对像做什么。



对像

标明对像的类型。



例如，I/O管理器的IoCreateDevice例程创建了一个设备对像来表明一个作为I/O请求目的地的物理，逻辑或者虚拟的设备

一个系统组件能够引出例程来调用其他组件的支持例程。这就能够降低驱动的调用。I/O管理器，例如，引出一些易用的开发驱动的例程。例如， 最底层驱动用来注册中断服务例程的 IoConnectInterrupt，就调用了对中断对内核支持例程。 

不透明的对像

一些系统定义的对象是不透明的(opaque)： 只有系统组件知悉这些对象的内部结构并能够只接访问对象的所有数据。定义不透明对象的系统组件会引出一些供驱动程序或者其他内核组件使用的支持例程来操纵这些对像。驱动程序决不能够直接访问非透明对象。

注意 为了保证驱动的要移植性，驱动程序必须只使用由系统提供的支持例程来操作系统定义的结构。定义该结构的系统组随时都可能会更改该对象的内部结构。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

Kernel-Mode Driver Architecture: Windows DDK

基于可重复IRPs的包驱动I/O
I/O管理器，即插即用管理器，和电源管理器使用I/O请求包(IRPs)来与内核模式驱动通信，内核模式驱动之间使用这种机制来通信。

I/O管理器运行如下几个步骤：

接收I/O请求，这通常来自于用户模式的应用模式

创建IRPs来代表I/O请求

派头IRPs到相应的驱动

追踪IRPs只到其完成

返回原始I/O操作请求者状态。


每一个IRP都可以被派发到多个驱动。例如，一个打开磁盘文件的请求可能首先被派发到文件系统驱动，通过一个中间层映像驱动，最终派发到磁盘驱动或者到即插即用硬件总线驱动。这一系列的驱动被认为是驱动栈(driver stack)。 

因此，每一个IRP都有一个固定部份(fixed part) ，加上每个控制设备的驱动相关的I/O堆栈位置(I/O stack loation) 。 

在回定部分（或者头部），I/O管理器维持着原始请求的信息，比如调用者的线程ID及其参数，打开的文件的设备对象地址，等等。固定部分也包括I/O状态块(I/O status block)，在这个块当中，驱动填写请求I/O操作的状态的信息。 

在最高层驱动的I/O堆栈位置，I/O管理器，即插即用管理器，或者电源管理器驱动特别参数，比如请求操作的函数码以及决定驱动如何运行的上下文信息。然后，每个驱动为驱动栈中下一个驱动创建一个I/O堆栈位置。

当每一个驱动处理IRP时，她能够访问IRP当中她的I/O堆栈位置 ，然而在每个驱动操作的阶段重新使用该IRP 。另外，高级驱动能够创建（或者重新使用）IRPs传送请求到下一层驱动。 

更多IRPs的讨论，参见处理 IRPs。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

异步I/O支持

I/O管理器提供了异步I/O支持，因此I/O请求的初始（往往是一个用户模式的应用程序，但是有时候也可能是另一个驱动）能够继续执行，而不是等到I/O请求完成。异步I/O支持提升了整个系统的所有处理I/O请求代码的效率。

有了异步I/O，内核模式驱动依据I/O管理器传送过来的顺序处理I/O请求。I/O管理器或者更高级驱动，能够重新安排I/O请求。一个驱动能够将大型数据传输讲求分解成很多小型数据传输讲求。而且，一个驱动能够重叠I/O请求，特别是在对称多处理器平台上，更如多处理器安全当中提到的。

更重要的是，一个内核模式驱动处理I/O请求时不必要顺序完成。也就说，一个驱动不必要处理完每个IRP才能去处理下一I/O请求。

当一个驱动接受到一个IRP，她以处理尽可能多的IRP指明的处理以响应之。如果驱动支持异步IRP处理，她就能够发送一个IRP到下一个驱动，如果有必要，不必要在IRP处理完成再开始处理下一个IRP。这个驱动可以注册一个“完全例程”(completion routine)， 当另一个程序完成了IRP之后，I/O管理器将调用该例程。驱动在IRP的I/O状态块当中填充状态值，通过访问该块的值，其他驱动可以知道这个I/O请求的状态。

驱动能够保持她现在I/O操作到她的设备对象的一个特别的部分中。这个部分被称为设备扩展。 

更多信息，请见处理IRPs和输入/输出技术.


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005

1.一口气发完这么多,不好意思,好像有点过了...有点刷屏的效果-_-
2.请求大家指正翻译上的错误.敬请交流之.
3.还是那句话:希望对有需要的朋友有用,然后请求指正.谢谢



内核驱动例子

DDK提供很多内核驱动的例子。装完DDK后，在子目录src\general当中含有很多样本驱动代码，可以应用于所有内核模式驱动。这些样本包括如下：

toaster

提供一系列遵守Windows 驱动模型的驱动的代码。这些样本也包含了一些安装程序的样本。

ioctl

演示了驱动如何支持 I/O 控制码 。 

event

演义了内核驱动能够提示程序硬件事件，如果程序要求提示。一个技术使用事件对象，另一个基于提取 提示请求只到一个事件发生。

cancel

演示安全取消IRP队列的应用 

tracedrv

演示如何使用WPP 软件追踪。


其他\src子目录如包括不同硬件类型的内核模式驱动的代码。


Microsoft Corporation
Send feedback on this topic
Built on Friday, February 18, 2005