The Microsoft Windows system includes virtual device drivers. M icrosoft also has a device driver development k i t specifically for ueveloping v i rtual device drivers. 1 This section uescribes the envi
ronment for developing and debugging this driver software.
Development Tools
Current ly, virtual device d rivers are wri tten in assembly language because higher-level language compilers general ly lack the abil ity to generate code with _32-bit offsets and registers. A special 32-bit assembler and l i nker are provided with the M icrosoft Windows device d river development kit.
Debugging Tools
Vi rtual device drivers are debugged using the WDEB386 software modu le. This debug tool requ ires that a terminal or equ ivalent be connected to one of the com munication ports on the PC; the debugger performs i ts I/O to that com munications port. Symbols are avai lable in the debugger, but source-level debugging is not provided.
To take fu l l advantage of the WDEB386 capabi l i
ties, the debug version of the M icrosoft Windows WlN386.EXE mod u le should be used . Th is version contains many featu res essential for i nvestigating the behavior of the Windows system and, in par
ticu lar, for debugging virtual device drivers. The features incl ude commands to displ ay the registers, the stack, and the control blocks for each v irtual machine. Many of the v irtual device drivers i ncluded with the Windows system, and the two i ncluded in the PATHWORKS for OOS product, have a debug entry point that may be invoked by entering the period keyboard character, followed by the name of the virtual device d river. Two particu larly usefu l debug entry points are .YMM and .V86MMGR, which provide detailed information about memory usage for each virtual machine, including the use of expanded memory and the high memory area.
WDEfl)86 can be used successfu l ly in the Windows environment to debug virtual device drivers and to diagnose bugs in the read-only memory basic l/0 system (ROM BIOS) and other resident rea l-mode software.
Vol. 4 No. I Winter /')'Jl D igital Technical Journal
\lfcmsujl \\ iudoii'S . \ eltmrk 1 /'r/t((f/ Oe/ ' ice /)rit ·ers in F I TIH\ ONK.\jin· nos
PATHWORKS: PC I ntegration Software
SYSTEM V I RTUAL MAC H I N E
I I I I I
I
W I N DOWS A P P LICATION I I I I
V I RTUAL MAC H I N E R U N N I N G A DOS APPLICATION
I I I I I I I I I
EXTEN D E D M EMORY
V D N ET.386 V I RTUAL DEVICE D R I V E R
1 088KB 1 024KB
640KB
H I G H M E MORY AREA V I DEO M EMORY
E X PA N D E D M E M O R Y PAGE FRAME
ADAPT E R M E M O R Y AVAILABLE
DOS A P P LICATION
H I G H MEMORY AREA V I D EO M E MO R Y
EXPANDED MEMORY PAGE FRAME
ADAPTER M E M O R Y AVAILABLE
DOS APPLICATION
TOP OF CONVENTIONAL
GLOBAL
�
AVAILABLE HOOK M EMORYI
M E MO R Y
CONTROL BLOCKS M A P P I N G AREA
OTHER R E S I D E NT SOFTWARE DECNET NETWORK PROCESS DOS O P ERATING SYSTEM
Figure 2 Microsoft Windows Initialization
al loca tes a hook control block to the operation.
This control block resides i n global memory and i ncludes an IOCB or NCB, which the virtual device driver passes to the resident network ing software.
The driver globa l ly maps the cal ler's buffers in the mapping-space pool al located at initial ization.
The IOCR or NCB embedded i n the hook control block contains addresses changed to point to the remapped address in the mapping-space pool. The cal l back (post) address is set to the cal l back rou tine i n the virtual device driver, so the driver is cal led when the operation is complete.
Optional ly, if the operation is a blocking cal l that takes a long time to complete, the v irtual device d river may convert the operation to an asynchro
nous ca l l. I n this case, the d river sets a n i n ternal flag, HF_Suspend_Unti l_POST. and does not return control to the cal l i ng app l ication until the
opera-'52
tion is complete . Al l other virtual machines con
tinue to run while the network I/0 is in progress.
This design prevents the operation from monopo
l izing the entire system.
Asynchronous Calls If the cal l is asynchronous or has been converted to an asynchronous cal l, the vir
tual device driver must establ ish a cal l back i n order to be notified when the cal l completes. Because the v irtual device driver runs in protected mode and the resident network runs i n v irtual mode, a spe
cial type of cal l back is requ ired. The v i rtual device driver uses the Wi ndows Al locate_ V86_Cal l back service to obtain a real-mode poi nter to an instruc
tion in global memory that causes a trap when exe
cuted i n virtual mode. The Windows system hand les this trap and transfers control to the virtual device driver in protected mode.
Vol. 4 No. I Winter I'J'Jl Digital Teclmicaljournal
Jficrosojt W indou ·s Netll 'ork Virtuo/ /)el'ice /)ril•ers in fJA J' I I W()!<KSJor f)()S
b l l ·o!.'inl!, t/Je .Vet/l 'ork Process The ' i rt u a l de,·ice d r i ,-cr i :; no'' prep;trnl to pass the c;i l l ro t he real
mode networking soft ware. The d rin:r e l l l <:rs a c ri t ical �<:nion to a n l i d rt-c n t rance prohlcms and ca l ls t he S i m u l a t<:_Hct l -.\-lmlc_ l n te r r u p t sen ice to i n voke t h e net work process as i f il were b<:ing innlknl in ret I mode The ' i r t u a l d e,· i ce d rin- r lea,·c.� t he c ri t i c a l sel"l ion when t h e s i m u la t nl i nter
rupt ret u rns I f the o p er a t i o n is n o t as\· n c h ronous.
t h e c a l ler's IOC!l or .'\Cll i:; u pda ted . bu ftns arc u n m a pped . and the hook cont ro l block is freed . Figure _J., s hows a :vl i crosofr W i n dows ca l l t o t h e net \\ ork. i n t cr cc p l l'll hy the Y i r t u a l de,· icc d r i n.: r ami p;tssed to t h e network proc<:ss.
(;o/1/)(fck l<ou l ine The dL·,· icc d r i n-r chL-cks t h e I I F_Suspend_lltJtii_I'OST lbg to d u c r m i nc i f the ca l l " as a bl ocking call that t h e ' i rt u a l tl<:\ ie<:
ARGUM ENT BLOCK PASSED
-SYS EM VIRT UAL M A C H I N E
W INDOWS APPLICATION
-110
CONTROLBLOCK