Windows 95下的虚拟设备驱动程序.docx

Windows 95下的虚拟设备驱动程序 虚拟设备驱动程序(VxDs)在很大程度上支持了Windows 3.x和Windows 95。通常,我们从 两个级别的意义上来认识VxDs:从低级意义上来说,它们直接存取系统的硬件;而从高级意义 上来看,它们在最高优先级别上运行。 在Windows 95中,VxDs显得更加重要,Microsoft正是靠VxDs扩展了操作系统内核的处理 能力。Win 95中的VxDs可以处理涉及从文件系统到声卡以至网络系统的各种事务。 可能您还未认识到:尽管VxDs本身是32位的,但它却诞生于16位的非线程、非抢占性的操 作系统。而现在人们期待甚至要求VxDs能运作于具有线程化、可抢占性的操作系统,简单的 变形是不能解决此问题的。 虚拟机假想 一台虚拟机(VM)只不过是人们的一个假想。而特别的,这个假想认为一个给定的进程可 对一台计算机的所有硬件设备进行独占性的存取,这些设备包括了内存、I/O口、中断和其它 进程想要占用的部件。VxDs就是为了此假想产生的。 Windows 3.1中有两种虚拟机(VMs):DOS壳和Windows VM本身(后者称为系统虚拟机 所有的Windows应用程序运行于其中)。而虚拟机管理器(VMM),尽管它本身不是一VM,但 却充当着激活VMs和VxDs的主要管理员。例如,VMM要处理在运行VMs时的抢占时间片工作。 另外,任何用来虚拟管理I/O设备的VxD都必须在VMM中登记。因此,如果一VxD要占用一些 特殊的I/O端口,就必须请求VMM挂起这个端口。这样,无论何时当一Windows应用程序试图对 此口进行存取操作时,VMM将把这个存取请求传给特定的VxD。 在Win 95中这样的情况基本相同,但做得更好。仍然是DOS壳作为一VM,所有的Windows进 程作为一VM。但这些进程包含了一些比Windows 3.x中的Win32s程序具有更强能力的Win32应 用程序。 这就产生了一些VxD设计者必须清楚的新问题。例如,Win 95中的Win 32应用程序可以是 多线程化的,一个VxD不再只知道是哪一个VM请求服务,有时一个VxD还必须知道是哪一特定V M中的哪一个线程需要服务。 顺便提一下,也许一些读者和我最初一样认为每一个Win 32应用程序在Win 95中就是它 自己的VM,而事实上是,尽管它们有自己的地址空间,每一个Win32应用程序却只是系统VM的一 个成员。 更重要的是,Win95中的一个成功的VxD应该是既可与新的32位Windows应用程序协作,也 可与过去的16位Win-dows应用程序协作运行。这就使得VxDs有些不同起来。 过去的方法 尽管VxDs可以通过挂起I/O口和执行中断等其它高优先级事件来虚拟硬件设备,但这只是 它为应用程序做的一部分事务。VxDs还可以提供可调用的APIs,使得一个应用程序可以直接 申请VxD服务。 在Windows 3.x里,我们可以通过中断2FH来得到一个VxD的API(限于篇幅,这里不再多言 )。这种机制在Win 95中可以通过16位应用程序来有效地使用。实际上,Win 95有一点变化: 将BX寄存器设为零,并在ES:DI寄存器对中存放一指针而不是从BX寄存器中调用设备号。这个 指针指向VxD的名字,它是一个八位长的大写字符串。和以前相同的是,在程序执行INT 2FH指 令后,VxD的API地址返回在ES:DI中。 糟糕的是,INT 2FH技术并不适用于Win32应用程序。实际上,Win32应用程序不能执行软 件中断。 对我们来说,这是否意味着Win32应用程序和VxDs处于不可跨越的裂缝中?答案是否定的 ,我们仍可用VxD代表32位应用程序来虚拟I/O端口,只是在VxD将API地址提交给Win 32程序时 有些麻烦。但这也不要紧,VxD既提供了16位API又提供了32位API,这使得在Win 95环境下16 位Windows应用程序与Win 32应用程序一样重要。 新的VxD 无论何时,当一个VxD必须处理的事件发生时,就有一条控制消息传送给VxD。这些消息来 自VMM或其它的VxDs,VxD处理它们就像Windows程序处理Windows事件一样。通常,这些消息告 诉VxD:一应用程序正试图存取你管理的I/O口,有消息来注意。 Win 95添加了一条新消息W32-DEVICEIOCON-TROL,这条消息是在一个Win 32应用程序调 用DeviceIo-Control()函数时发给VxD的。这就是一Win32应用程序可直接调用VxD的机制。 对Win32应用程序来说,它必须首先调用CreateFile()函数得到一特定VxD的句柄。通常 这函数是用于创建打开磁盘文件的,但如果程序在调用它时,给文件名前加上前缀.,系统 就会识别出此文件名是对应于一VxD名。(当然在C/C+中,字符串中的反斜杠字符必须加更多 的反斜杠前缀,因此.就成了.) 函数CreateFile()返回一句柄,这里是一个VxD的句柄。应用程序可用这个句柄调用函数 DeviceIoControl()来发消息给VxD。(调用函数DeviceIoControl()实际上调用了一个中间V xD:VWIN32,它再调用代表应用程序的VxD) 函数DeviceIoControl()提供了通知VxD执行何功能的参数,同时提供用于在应用程序和 VxD间传送数据的输入输出缓冲区指针。 动态VxDs 使用函数DeviceIoControl()与VxD通讯还有另外一个好处。在Win 3.1中VxDs是静态装 载的,也就是说,当Win-dows启动时要装载所有要用的VxDs,它们将在Windows执行生命期间一 直处于活动状态。 Win 95(以及Windows for workgroups 3.11)却允许动态装载卸下VxDs。当一应用程序 用CreateFile()函数存取一VxD时,系统会跟踪每个VxD打开了多少句柄。当应用程序终止时 ,它要调用函数CloseHandle()释放这个VxD打开了多少句柄。当应用程序终止时,它要调用函 数CloseHandle()释放这个VxD的句柄,这就减少了系统打开的句柄数。(有一点很重要,当一 进程消亡时,与其相联的句柄会被自动调用) 只要一VxD的句柄数减到零,系统会给这个VxD发送一条控制消息SYS-DYNAMIC-DEVICE-E XIT,告诉它:你即将被卸下,请消除一切。VxD在处理完这条消息后,系统就卸下它。 一点补充说明 当然,VxD设计者还没有做到尽善尽美,他们还必须设置另外的事件处理程序来处理W32- DEVICEIOCONTROL消息。尽管为了利用VxD的API而单独创建一条途径似乎有些令人难受,但随 着Win 32程序数量的增多,我们会发现这条路并不难走。实际上,我们并不需要做太多的事。 VxD在俘获由VMM