汇编教程:VxD程序设计入门
2008-12-27 09:35:54 来源:WEB开发网我们在上一节学会了如何编写一个什么事也不做的VxD程序。在这一节里,我们要给它增加处理控制消息的功能。
VxD的初始化和结束
VxD程序分为两种:静态的和动态的。每种的加载方法都不同,接受到的初始化和结束的控制消息也不同。
静态VxD:
下列情况下,VMM加载一个静态VxD:
一个实模式常驻程序通过调用中断2FH,1605H,来调用此VxD。
此VxD在注册表中的如下位置有定义:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\key\StaticVxD=VxD带路径文件名
此VxD在system.ini中的[386enh]行下有定义:[386enh] section:
device=VxD带路径文件名
在开发的时候,我建议你从system.ini载入VxD程序,因为这样如果你的VxD程序有错而导致Windows不能启动的话,你可以在Dos下修改system.ini,而如果你使用的注册表载入的办法,就无法修改了。
当VMM加载你的静态VxD程序时,你的VxD程序会按以下顺序接收到三个系统控制消息:
Sys_Critical_Init VMM在转入到保护模式后,开放中断前发出这个控制消息。大多数VxD程序到不要用到这个消息,除非:
你的VxD程序要接管一些其他VxD程序或者保护模式程序要用到的中断。既然你处理这个消息的时候这个中断还没有打开,你就可以确定在你接管这个中断的时候此中断不会被调用。
你的VxD程序为其他的VxD程序提供了一些VxD服务。例如,一些在你的VxD程序后加载的VxD程序在处理Device_Init控制消息时需要调用一些你的VxD服务,既然Sys_Critical_Init 控制消息在Device_Init消息之前被发送,所以你应该在Sys_Critical_Init 消息发送时初始化你的程序。
如果你要对这消息进行处理,你应该尽可能快的做完初始化工作,以免太长的执行时间导致的硬中断丢失。(记住:中断还没打开)
Device_Init VMM在开放中断后发送此信息。大多数VxD程序都在得到这个消息时初始化。因为中断都开放了,所以耗时的操作也可以在这里执行而不必怕会导致硬中断的丢失。你可以在这时进行初始化(如果你需要的话)。
Init_Complete 在所有的VxD程序处理完Device_Init 消息之后,VMM释放初始化段(ICODE和RCODE段类)之前,VMM发出这个控制消息。只有少数几个VxD要处理这个消息。
你的VxD程序在成功地初始化后,必须将返回标志清零,反之,必须在返回之前把返回标志设为出错信息。如果你的VxD不需要初始化,你就不必对这些消息进行处理。
当要结束静态VxD的时候,VMM发送如下的控制消息:
System_Exit2 当你的VxD程序收到这个消息,Windows95正在关闭系统,除了系统虚拟机所有其他虚拟机都已经退出了。尽管如此,CPU仍然处于保护模式下,在系统虚拟机上执行实模式编码也是安全的。在这时Kernel32.dll也已经被卸载了。
Sys_Critical_Exit2 当所有的VxD完成对System_Exit2的响应处理并且中断都被关闭后,你的VxD收到到这个消息。
许多VxD程序并不要响应这两个消息,除非你要为系统做转换到实模式的准备。要知道,当Window95关闭时,它进入到实模式。所以如果你的VxD程序对实模式影像做了一些会导致它不稳定的操作,它就需要在这时进行恢复。
你也许会感到奇怪:为什么这两个消息后面都跟着个“2" ”。这是因为:在VMM加载VxD程序的时候,它是按照初始化顺序值小的VxD先加载的顺序加载的,这样VxD程序就可以使用那些在它们之前加载的VxD程序提供的服务。例如,VxD2要用到VxD1中的服务,它就必须把它的初始化顺序值定义的比VxD小。加载的顺序是:
..... VxD1 ===> VxD2 ===> VxD3 .....
那么卸载的时候,理所当然的是初始化顺序值大的VxD程序先被卸载,这样他们仍然可以使用比它们后加载的那些VxD程序提供的服务。如上面的例子,次序是:
.... VxD3 ===> VxD2 ===> VxD1.....
在上边的例子中,如果VxD2在初始化时调用了VxD1中的某些服务,那么卸载时它可能也要再次用到一些VxD1中的服务。System_Exit2和Sys_Critical_Exit2是反初始化顺序发送的。这表示,当VxD2接受到这些消息时,VxD1还没有被卸载,它仍可以调用VxD1的服务,而System_Exit和Sys_Critical_Exit消息不是按照反初始化顺序发送的。这意味着,你不能肯定你是否仍能调用在你之前加载的VxD提供的VxD服务。新一代的VxD程序不应该使用这些消息。
还有两种退出消息:
Device_Reboot_Notify2 告诉VxD程序VMM正在准备重新启动系统。这时候中断还是开放的。
Crit_Reboot_Notify2 告诉VxD程序VMM正在准备重新启动系统。这时候中断已经被关闭了。
到这里,你可以猜到还有Device_Reboot_Notify和Crit_Reboot_Notify 消息,但它们并不是像“2”版本的消息一样按反初始化顺序发送的。
动态VxD:
动态VxD在Windows9x里可以动态的被加载和卸载。这个特点在Window3.x下是没有的。动态VxD程序的主要作用是用来支持某些动态的硬件设备的重装,比如:即插即用设备。尽管如此,你可以从你的Win32程序中加载/卸载它,也可以把它看作是你的程序的一个到ring-0的扩展。
上一节我们提到的例子是一个静态的VxD,你可以把它转换成一个动态的VxD,只要在.def文件中VxD标记的后面加上关键字DYNAMIC。
VxD FIRSTVxD DYNAMIC
这就是你把一个静态VxD转换成一个动态的VxD所要做的一切。
一个动态的VxD可以按以下的方法被加载:
把它放到你的Windows目录下的\SYSTEM\IOSUBSYS目录中。在这个目录里的VxD会被输入输出监视器(ios)加载。这些VxD必须支持层设备驱动。所以用这种方法加载你的动态VxD并不是一个好办法。
用VxD加载服务。 VxDLDR是一个可以加载动态VxD的静态VxD。你可以在其他VxD里面或者在16位代码里面调用它的服务。
用Win32应用程序里的 CreateFile API。你在调用CreateFile时,你的动态VxD要以下面的格式填写:
\\.\VxD完整路径名
例如,如果你要加载一个在当前目录下名为FirstVxD的动态VxD,你需要做如下的工作:
.data
VxDName db "\\.\FirstVxD.VxD",0
......
.data?
hDevice dd ?
.....
.code
.....
invoke CreateFile, addr VxDName,0,0,0,0, FILE_FLAG_DELETE_ON_CLOSE,0
mov hDevice,eax
......
invoke CloseHandle,hDevice
......
FILE_FLAG_DELETE_ON_CLOSE 这个标志用来说明该VxD在CreateFile返回的句柄关闭时被卸载。
更多精彩
赞助商链接