精华区文章阅读

发信人: pony (找不着道的小马), 信区: Windows
标题: 如何转换Windows NT 4的驱动程序为Windows 2000驱动�
发信站: 哈工大紫丁香 (2001年10月29日09:23:58 星期一), 站内信件

原文：http://china-pub.com/computers/emook/0649/info.htm

如何转换Windows NT 4的驱动程序为Windows 2000驱动程序（WDM）

前言
　　首先要说明的是：已经存在的Windows NT V4的设备驱动程序（通常称为"标准
核心模式驱动程序"）不用改变就可以在Windows 2000中运行。只不过这些驱动程
序不支持电源管理和新的即插即用功能。
　　因为上述原因，一些比较极端的观点认为：对于大多数驱动程序开发者，如果
硬件对于电源管理和即插即用不是很需要的话，最好的策略就是不要转换NT V4的
设备驱动程序（至少在短期内）。因为Windows2000的驱动程序和NT V4不是直接兼
容的，如果你将Windows NT V4驱动程序转换到Windows 2000下的话，就要需要维
护两套驱动程序分别用于Windows NT V4平台和Windows 2000。这样就要加大系统
维护的负担。
　　但是如果你想要测试你的硬件是否能够在Windows 2000下正常工作，且支持电
源管理和即插即用。那么就需要研究一下如何进行转换了！

Windows2000==WDM?
　　在转换前有一些知识需要了解，其中有好的也坏的。好的是：1。所有的
Windows NT系统内部和设备驱动程序概念仍然有效，Windows 2000和WDM仍然实现
了一个层次化的驱动程序结构（只不过多了几层）。2。完全WDM兼容的驱动程序能
够不加修改的工作在Windows2000和Windows 9X下。
　　但是不要认为WDM驱动程序和Windows 2000的驱动程序是相同的。WDM标准是
Windows 2000核心模式驱动程序标准的子集。一个驱动程序能够完全兼容
Windows 2000标准，支持即插即用和电源管理，但是仍然可能不支持WDM，因此可
能不能直接用在Windows 9X。WDM驱动程序是引用了文件WDM.H，而Windows 2000标
准核心模式驱动程序是引用NTDDK.H。
　　这有什么不同呢？WDM驱动程序使用了一个端口和微驱动程序概念，类似于
SCSI微端口驱动程序所使用的方法。WDM驱动程序通常都更小，几乎仅仅包含了针
对具体设备的支持。这些驱动程序只调用标准NT APIs的一个子集。大部分工作（
如处理中断）是通过他们的类驱动程序处理。而大部分我们熟悉的接口在WDM驱动
程序中还可使用，部分老的接口（如：HalGetAdapter(...),
IoConnectInterrupt(...), and IoAssignResources(...) ）被一些新的方法取代
。一些不常使用的特征如：内存域和ERESOURCES不被WDM支持了。
　　另一方面，Windows 2000驱动程序包含了一套新的IRP_MJ功能，新的驱动程序
入口点和新的处理方法。但是大部分我们熟悉的旧函数仍然被Windows 2000核心模
式驱动程序标准支持。
　　正是由于上面的原因，Windows 2000标准是WDM标准的一个超集，所以没有一
个Windows 2000驱动程序是容易变成WDM驱动程序的。

具体步骤
现在我们来讲述如何将Windows NT V4核心驱动程序升级为Windows 2000驱动程序
。（注：但是不一定是WDM驱动程序）
　　在Windows NT V4，所有的驱动程序和设备初始化工作都是在DriverEntry(…
)中实现的。在DriverEntry(…)，我们通过Driver对象输出入口点、识别设备，且
对每个找到的设备产生一个设备对象。这通常意味着扫描总线发现设备，然后调用
IoCreateDevice(…)。接下来给设备保留硬件资源，如对于PCI设备调用
HalAssignSlotResources(…) 和IoAssignResources(…)来获得设备需要的硬件资
源CM_RESOURCE_LIST，这些资源包括：端口、共享内存区域、IRQs、DMA通道以及
其他我们的设备需要的硬件资源。我们也在DriverEntry(..)中连接中断等等。
　　在Windows2000中，前面在DriverEntry(…)中的处理被分成了三个部分：
　　1．初始化驱动程序本身。如：输出程序入口点。
　　2．发现驱动程序需要支持的设备。如：产生一个设备对象（现在这部分被移
到AddDevice(…)入口点）。
　　3．设备资源分配和设备初始化。这部分是在处理一个IRP_MJ_PNP IRP（其中
次功能号为IRP_MN_START_DEVICE）进行的。

Windows 2000的驱动程序入口：DriverEntry(…)
　　和Windows NT V4一样，在Windows 2000中DriverEntry(…)也是当驱动程序第
一次被载入时，在IRQL_PASSIVE_LEVEL级调用的。
　　DriverEntry(…)只做驱动程序的初始化工作。包括通过Drivers对象输出程序
入口点。其中两个重要的入口点是(1)AddDevice(…)，放在
DriverObject->DriverExtension->AddDevice.
　(2) IRP_MJ_PNP IRPs的分派入口点，放在
DriverObject->MajorFunction[IRP_MJ_PNP]).
　　你也可以在DriverEntry(…)完成前，可以保存注册路径信息供以后使用。但
是这一项不是必须的，只有在你以后如果调用下列函数时，可能需要这些信息作为
参数。如：IoRegisterDriverReinitialization(…)，HalAssignSlotResources(
…)，IoAssignResources(…).。或者在AddDevice(…)处理过程中进行注册表查找
。当然，一个好的Windows 2000驱动程序不使用这些方法。如果你确实需要存储注
册表路径，一定要存储注册表路径数据，而不是注册表路径的指针。因为I/O管理
器在调用完DriverEntry(…)后，会释放注册表路径数据占用的空间。
虽然Widnows 2000的文档中没有明显指明，但是在DriverEntry(…)中还是可以生
成Device对象的。只不过这不是一种标准的方法了。事实上，在DriverEntry(…)
中唯一需要生成的设备对象是那些整个驱动程序都需要的设备对象。如：一些操作
管理设备。如果你确实需要在DriverEntry(…)中生成任何设备对象，注意一定要
将设备对象的DO_DEVICE_INITIALIZING位清除。
　　上面就是Windows 2000的DriverEntry(…)所做的工作，与以前的Windows NT
版本相比较，内容大大减少了。接下来就是在AddDevice(…)中进行处理了。

AddDevice(…)过程
　　在DriverEntry(…)处理完后，如果你的驱动程序需要处理的任何设备被加到
系统的话，I/O管理器就会调用驱动程序中的AddDevice(…)入口点过程。它的原型
如下：
　　NTSTATUS XxxxAddDevice (IN struct _DRIVER_OBJECT *DriverObject,
　　IN struct _DEVICE_OBJECT *PhysicalDeviceObject);
　　其中DriverObject参数的内容和传给DriverEntry(…)入口点的参数内容一样
。PhysicalDeviceObject参数是一个描述设备的物理设备对象(PDO)指针。这个对
象是总线驱动程序在扫描总线时对发现的每个物理连接到总线的设备产生的。PDO
被用做总线驱动程序和即插即用管理器通信，通知你的驱动程序一个PnP事件（如
：突然设备断开）。图一展示了实际物理设备对象和功能设备对象的关系。

　　
　　　　　　　　　　　　　　　　图1
在AddDevice(…)入口点过程中，主要做两个工作：
　　1．生成一个或多个Device对象来代表你的实际设备，这是用
IoCreateDevice来实现的。但是要注意，DeviceObject->Flags中的
DO_DEVICE_INITIALIZING位要被清除。这是重要的，如果这个位没有被清除，其他
设备就不能附加在这个设备上。如果你没有清除这个位，在Debug版的驱动程序运
行时，I/O管理器会提醒你的。还有一个就是如果外部通过CreateFile来操作这个
设备的话，则需要为这个设备对象用IoCreateSymbolicLink(…)生成一个符号连接
.
　　2．将这个新生成的设备对象附加在设备驱动程序生成的物理设备上。这步可
用IoAttachDeviceToDeviceStack(…)来实现，传递的参数为你新生成的设备对象
和AddDevice(…)所传递进来的物理对象。返回值为事件被附加到的实际设备对象
。

　　在AddDevice(…)完成前，你可以对每个设备对象进行初始化。包括：检查注
册表中与设备相关的信息。因为你没有接触到实际的硬件，所以此时你还不能处理
你所收到的请求。正确的理解是：此时你的设备虽然被生成了，但是还没有被启动
（你只是收到一个针对这个设备的AddDevice(…)调用，还没有收到
IRP_MN_START_DEVICE请求），只是排队任何IRPs请求供以后在你的设备上处理。

　　AddDevice(…)成功完成后，一个STATUS_SUCCESS被返回。如果返回一个错误
，则驱动程序的载入过程被中止。

分派IRP_MJ_PNP：
　　当一个前面添加的设备被启动后，即插即用管理器要调用你的驱动程序，并传
递一个IRP包含IRP_MJ_PNP主功能码和IRP_MN_START_DEVICE次功能码。
IRP_MJ_PNP被用于表示这个IRP是一个即插即用事件。其中有七个不同功能码来分
别唯一的表示各种即插即用请求。在WDM/Windows 2000中，设备驱动程序所处的驱
动程序堆栈低端如果是一个总线驱动程序。这时处理PNP请求由两点需要注意：
　　1．所有的IRP_MJ_PNP IRPs必须被你的驱动程序传到下面的总线驱动程序。
这是系统正常运行的关键。
　　2．一些PNP IRPs在被你的设备驱动程序处理前，必须被下面的总线驱动程序
正确处理。另一方面，一些PNP IRPs在被传到下面的总线驱动程序前，需要被你的
驱动程序正确处理。
　　决定哪些PNP IRPs首先被谁处理，这是你的驱动程序的任务。并且在处理完后
（或没有处理），调用IoCallDriverCall(…)来传递IRP。其中
IoCallDriverCall(…)中的Device对象参数就是驱动程序在AddDevice(…)调用
IoAttachDeviceToDeviceStack(…)返回的PDEVICE_OBJECT对象。下表总结了PNP
IRP的处理顺序。

　　
　　如果一个请求首先由设备驱动程序处理，那么当设备驱动程序接收到这个请求
后，首先检查这个请求，如果能够处理，然后处理这个请求。当设备驱动程序成功
完成了这个请求的处理后，它发送这个请求到下面的总线驱动程序。如果不能处理
这个请求，设备驱动完成这个请求并返回一个错误，此时就不将IRP传递到下面的
总线驱动程序。
　　传递一个IRP请求到目标驱动程序设备所采用的方法和以前的一样。只不过
Windows 2000现在有了一些处理宏来帮助完成这个工作。要传递一个请求到下面的
驱动程序，你只要拷贝当前的I/O堆栈位置到下一个I/O堆栈位置，并注册一个完成
例程（如果愿意的话），然后调用IoCallDriver(…)就可。例如下面这个情况：驱
动程序首先处理IRP_MJ_PNP IRP，且不需要完成例程。这部分的代码一种形式如下
：
　　// 调用堆栈拷贝宏，针对Windows2000
　　IoCopyCurrentIrpStackLocationToNext(Irp);
　　// 发送请求到总线驱动程序并返回。
　　Return (IoCallDriver(DeviceExtension->PdoPointer,Irp);

　　但这种处理方法对于所有的IRP都可以吗？答案是不行。因为如果当总线驱动
程序首先处理请求的话，上面的做法就会出问题。例如：当你的设备被启动时，收
到了一个IRP_MN_START_DEVICE IRP请求，它首先需要被总线驱动程序处理。设备
驱动程序一接到这个请求，就将它传递给总线驱动程序，本身不做任何处理。和
Windows NT V4相同，设备驱动程序此时如果想在下面的驱动程序处理完一个IRP后
被通知，可以在IRP被传递到下面的驱动程序前，设置一个完成例程。当完成例程
被调用时，这个IRP就能被这个设备驱动程序处理。但不幸的是，完成例程可能是
在IRQL>=DISPATCH_LEVEL层被调用的，如果这样的话，那么处理过程将变得复杂。

　　解决这个问题也有很多的方法，我认为最好的方法是在设备驱动程序的分派例
程中等待一个事件，当完成例程被调用时，它生成这个事件从而唤醒分派例程，然
后在分派例程中，IRP被处理和完成。而完成例程此时通过返回一个
STATUS_MORE_PROCESSING_REQUIRED给I/O管理器来宣称对于这个IRP的拥有权即可
。下面就是这样一段例子
// 这是一个Windows 2000新提供的宏。
//
IoCopyCurrentIrpStackLocationToNext (Irp);
//
//为IRP设置一个完成例程。其中的传递了一个后面
// 要进行通知的事件指针 pnpEvent
// 做为上下文敏感参数。
//
IoSetCompletionRoutine (Irp,
OsrPnpCompRoutine,
&pnpEvent,
TRUE,
TRUE,
TRUE);
//
// 初始化后面要传递的通知事件pnpEvent.
//
KeInitializeEvent(&pnpEvent,
NotificationEvent,
FALSE);

// 传递IRP到下面的驱动程序

status = IoCallDriver(devExt->NextDriverObject, Irp);
//
// 等待这个事件
//
KeWaitForSingleObject(&pnpEvent,
Executive,
KernelMode,
FALSE,
NULL);
//
// 收到完成例程中的事件后，处理IRP
//
//
status = Irp->IoStatus.Status;
if (NT_SUCCESS (status)) {
//
//
status = OsrProcessPnPIrp(Irp);
}
//
//在这里最终完成这个例程。
//
Irp->IoStatus.Status = status;
Irp->IoStatus.Information = 0;
IoCompleteRequest (Irp, IO_NO_INCREMENT);

　　不难吧，对不对？正如前面讲述的，这段代码不仅仅传递IRP到下面的驱动程
序，它也产生一个事件，并等待这个事件被通知。事件是在完成例程中被通知的。
如下：
NTSTATUS
OsrPnpCompRoutine(IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context)
{
PKEVENT event = (PKEVENT)Context;
//
// 判断是否这个IRP需要被挂起？
//
if (Irp->PendingReturned) {
IoMarkIrpPending( Irp );
}
//
// 向分派例程通知这个事件
//
KeSetEvent(event, 0, FALSE);
//
// 重新声明IRP，以便分派例程继续完成。
//
// 注意：分派例程必须调用IoCompleteRequest 来完成这个例程。
//
return STATUS_MORE_PROCESSING_REQUIRED;
}

　　无可否认，这是一个简单完善的完成例程，基本上的工作都实现了。对于这个
例程，一个没有经验的驱动程序作者可能认为，当Irp->PendingReturned被设置的
话不需要IoMarkIrpPending(…)。但实际上这是绝对需要的。具体可以参见其他资
料，这里就不详述了。

处理IRP_MN_START_DEVICE
　　现在详细讨论一下具体如何处理IRP_MN_START_DEVICE请求。
　　正如前面讲述的，当即插即用管理器想启动你的设备时，它向你的驱动程序发
送一个IRP_MJ_PNP IRP，其中次功能号为IRP_MN_START_DEVICE。这个被启动的设
备就是由我们在PNP分派例程中接收到的设备对象指针来表示。这个请求要首先被
总线驱动程序处理，然后再由设备驱动程序处理，处理过程可以采用前面讲述的方
法。
　　但是这个请求在设备驱动程序中被处理来干什么呢？回过头来我们可以看出，
到现在为止我们还没有为设备分配和保留任何资源，这个IRP_MN_START_DEVICE
IRP的主要目的就是为我们提供一个这些资源的列表。
　　包含在IRP_MN_START_DEVICE IRP的当前I/O堆栈位置中有两个参数是我们感兴
趣的：　　　　　　　　　Parameters.StartDevice.AllocatedResources （这是
一个描述设备资源的CM_RESOURCE_LSIT类型的指针）和Parameters.StartDevice.
AllocatedResourceTranslated（这是一个包含设备资源的转换值的
CM_RESOURCE_LIST类型的指针）。这些参数中的资源都是PnP管理器、I/O管理器和
HAL同意分配给你的设备使用的资源。对应于Windows NT V4的PCI设备，未转换的
资源是那些由HalAssignSlotResource(…)所返回的资源，这些资源的转换版本就
是从HalTranslateBusAddress(…)和HalGetInterruptVector(…)所输出的资源。

　　得到CM_RESOURCE_LIST，驱动程序就可以采用Windows NT V4 中的方法来处理
、初始化设备。如：当一个资源在内存空间，设备驱动程序需要调用
MmMapIoSpace(…)来赋予给它对应的核心虚拟地址。当要连接一个中断，就可以调
用IoConnectInterrupt(…)。

总结
　　当然，还有需要许多要讨论的，如怎样停止设备、移走设备等等。由于限于文
章篇幅，这里就不一一介绍了。但是目前的内容对于如何开始移植Windows NT V4
到Windows 2000是足够了。

--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 172.16.1.103]

Windows 版 (精华区)