１ Windows 9X系統結構
確切的說Windows 9X不是一個操作系統，而是一個操作系統的集合。當計算機運行在保護模式下時，有“兩個”操作系統同時存在，即Windows 本身和一個更低的操作系統，我們把它稱為VMM/DPMI(virtual machine manager/Dos protect mode interface)。VMM的主要目的是管理同時運行的32位保護模式Windows應用程序（Win32 applications以及運行在虛擬86模式下的MS-DOS程序，前者稱為“線程”（threads），后者稱為VM（virtual machine)。VMM使每一條線程擁有自己的獨立地址空間，使每一個VM都“單獨”占有CPU，并為它們提供各種服務。從圖１中我們可以看出，threads和VMs所能訪問到的資源已不是直接的物理資源，而是被VMM虛擬化virtualized后的虛擬資源了。
另外，VMM是一個可擴充的“操作系統”，它的核心部件以及標準部件（比如，DMA控制器管理VDMAD，中斷管理VPICD等）是由Microsoft提供的。但我們可以編寫一些擴充模塊，也就是用VxD來增強VMM對硬件的虛擬能力，使整個操作系統獲得對新硬件的訪問能力。不僅如此，這種擴充操作系統的辦法，還能為Win32程序與MS-DOS程序之間的通訊提供一種新的途徑以代替傳統的MS-DOS設備驅動程序以及內存駐留程序TSRs。從某種意義上說，沒有VxD不能完成的事情，而且由于VxD是運行的保護模式下，所以它并不占有寶貴的常規內存。此外，運行實模式MS-DOS驅動程序所導致的模式切換也不復存在。因此一般來講，VxD的運行速度要高出MS-DOS驅動程序一倍以上。更重要的是VxD在Windows 9X下可以動態裝入與卸載而不需要重新啟動計算機，這就大大提高了系統的靈活性，同時也為即插即用（Plug and Play)提供了可能。與實模式的驅動程序相比，可動態裝、卸載可謂是一場革命。
２ VxD的結構及通訊策略
普通的Win32應用程序都是PE格式（Portable Exectable Format)的，而ＶｘＤ則不同，它沒有一般程序的進出口而是輸出一種稱作設備描述塊DDB（Device Descriptor Block)的數據結構。它包括VxD設備ID、初始化順序、Win32DeviceIOControl回調函數句柄、V86API句柄、PM API句柄等VMM在調用VxD時所需要的重要信息。此外，同其他應用程序一樣，VxD由五個段構成，它們分別是：
（１）VxD＿CODE段：保護模式代碼段。該段包含VxD系統控制過程、回調過程、服務和API過程。
（２）VxD＿DATA段：保護模式數據段。該段包括設備描述表、服務表和部分VxD全局數據。
（３)VxD＿ICODE段：保護模式初始化代碼段（可選）。該段一般包括只在VxD初始化過程中使用的過程和服務，VMM在Init＿Complete消息發生后丟棄此段。
（４）VxD＿IDATA段：保護模式初始化數據段（可選）。該段一般包括初始化過程和服務使用的數據，VMM在Init＿Complete消息發生后丟棄此段。
（５）VxD＿REAL＿INIT段：實模式初始化段（可選）。該段包含實模式初始化過程和數據，VMM在裝載VxD其它部分之前調用此過程，過程返回后丟棄此段。
當VxD裝入內存時，VxD通常要靠DDB中所添入的一個16位的VxD設備ID，以區別于其它VxD。為了防止與其他新VxD沖突，Microsoft通過請求和注冊標識來保證自己的VxD設備ID沒有被其它廠商使用，為此Microsoft保留0～01FFH之間的所有VxD設備ID供自己使用。
在編寫VxD時首先要編寫VMM的消息處理函數，以便作相應的處理。例如，在VxD裝入內存時VMM對能動態裝載的VxD發出SYS＿DYNMAIC＿DEVICE＿INIT消息，在要求卸載VxD時VMM又向其發出SYS＿DYNAMIC＿DEVICE＿EXIT消息。在VxD中只需編寫相應的處理函數，便可達到設備初始化與卸載釋放資源的目的。拿Win32程序來說，它使用CreateFile API函數打開可動態裝、卸載的VxD時VMM便會發出SYS＿DYNAMIC＿DEVICE＿INIT消息。相應的，當它使用CloseHandle API函數卸載VxD時VMM便會發生SYS＿DYNAMIC＿DEVICE＿EXIT消息。
另外，在具體調用VxD中的函數時，也不像調用ring-3 DLL中的函數那樣容易。我們以調用對象不同分以下幾種情況討論：
（１）從其他VxD中調用（ring-0調用ring-0） 當生成VxD時，所有可以被其他VxD調用的函數都列在一個數組里，我們稱這種函數為一個服務（Service）、這個數組為服務項目表（Service＿Table。在調用時，并不是用服務的名稱而是直接使用該函數在數組中的索引號。例如對VMM中的１號服務Get＿Cur＿VM＿Handle 可采用如下格式： int 20h DD00010001h 32位的DD由兩部分組成，它的高字包含了VxD設備的ID，低字包含了服務號（這里VMM的設備ID為0001h。 （２）從V86代碼或Win16（保護模式）代碼中調用ring-3調用ring-0 這里應用程序要申請被調用的VxD函數地址，這個地址可以通過int 2FH/AX=1648h調用獲得。為了識別是調用哪一個VxD的函數，調用時可令BX=VxD設備ID。當int 2Fh指令返回時，寄存器ES:DI（對保護模式有ES:EDI）包含一個seg:offset（對保護模式有selector:offset指針，調用該指針就可以把控制權交給運行在ring-0下的VxD （３）從Win32代碼中調用（ring-3調用ring-0) 事實上Microsoft隱藏了Win32的VxD服務接口，作為替代提供了Windows NT下的設備輸入、輸出控制（DeviceIOControl)Win32 API。Win32程序通過使用此函數向特定的VxD發送控制碼與數據。與此相應在編寫VxD時要提提供一個相應的回調函數以響應它所發出的W32＿DeviceIOControl消息，并再去回調函數中響應相應的控制碼，還要把該回調函數的句柄添加到DDB中。它的定義如下： BOOL DeviceloControl( HANDLE hDevice,//用CreateFile API函數打開VxD設備獲得的句柄 DWORD dwloControlCode,//ring3程序向VxD傳遞的命令碼（可由編程寫者自定） LPVOID lpOutBuffer,//程序傳給VxD的數據緩存的地址 DWORD nlnBufferSize,//ring3程序傳給VxD的數據緩存的字節數 LPVOID lpOutBuffer,//VxD的返回數據所存放的緩存地址（該緩存由ring-3預留） DWORDnOutBufferSize,//VxD的返回數據所存放的緩存的字節數 LPDWORD lpBytesReturned,//VxD實際返回數據的字節數 LPOVERLAPPED lpOverlapped //一個OVERLAPPED的結構地址，通常為NULL）； 由此不難看出這種DeviceIOControl的結構也為VxD向ring-3回傳數據提供了一種途徑。這種通訊方式在ＮＴ的設備驅動程序中也得到了廣泛應用，它是Microsoft大力提倡的Win32程序應采用的一種通訊方式。 ３ ＶｘＤ的實現 從編程工具方面來看，我們需要Windows 95 DDK和一個32bit的匯編編譯器，如MASM6.11c，如果打算用C/C++開發驅動程序的話，還應選用一個32bit的c/c++4.0編譯器，筆者推薦采用Micrfoft Visual C++4.0以上的版本，因為它支持一種新的關鍵字——declspec(naked) 。采用該關鍵字的函數，編譯器將不為其生成相應的函數進出口代碼，這樣對于采用特殊函數結構的VxD函數來說是非常方便的。除此之外，也有一些公司提供了一些VxD向導器以幫助用戶生成C/C++的程序框架，使用它們可以大大提高開發效率，應予以考慮，其中的有Vtoolsd95,VxDwriter等。在編程中應注意，不要使用C/c++所提供的庫函數，特別是Microsoft的MFC，因為它們都是運行在ring-3上的，如果非用不可的話，只有一些個別函數能通過使編譯器生成嵌入式指令來達到目的，但這樣做是要相當小心的。另外，調試運行在ring-0的驅動程序是相當困難的，VC++以及MASM中的調試均不能滿足需要，而需采用內核級的調試工具比如Microsoft的WDEB386以及Numega的SoftIce等。 ４ VxD的局限性 VxD技術只適用于Windows 9X操作系統，Windows NT不支持此項技術，而是采用更為先進的面向對象的驅動程序模型，例如Windows 98和Windows 2000就采用了一種基于ＮＴ的驅動程序模型WDM。此外，由于VxD運行在ring-0上根本不受ring-3的制約，也給病毒的制造者即黑客以可乘之機，比如的CIH病毒是一個VxD。