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