=============================================================================

****
**** The EATPAGES sample can be downloaded from the
**** file 7-1.zip in library section number 7
****

Eatpages: A VxD that Consumes Physical Pages

Revised: February 1993

Eatpages is a virtual device (VxD) that demonstrates the
use of the virtual machine manager (VMM) linked list
services and page allocation services. The VxD simply
allocates half of the free physical pages at boot time and
frees the pages at system exit. This can be useful for
simulating low-memory conditions.

Eatpages uses the following VMM services:

>  _GetDemandPageInfo
>  _PageAllocate
>  _PageFree
>  List_Create
>  List_Allocate
>  List_Attach_Tail
>  List_Get_First
>  List_Get_Next
>  List_Remove
>  List_Deallocate


To build Eatpages:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of Eatpages using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute Eatpages:

1.  Run EATPAGES.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. Eatpages will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename EATPAGES.EXE
to EATPAGES.386 and move it to the Windows SYSTEM
subdirectory. Add the line DEVICE=EATPAGES.386 to the
[386Enh] section of the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

Eatpages was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The GENERIC sample can be downloaded from the
**** file 7-2.zip in library section number 7
****

Generic: Illustrates the Basic Structure of a VxD

Revised: February 1993

Generic illustrates the basic structure of a virtual
device (VxD). This VxD can be used as a base set of source
files for starting a VxD project. Generic can be loaded,
but it performs no function.


To build Generic:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of Generic using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute Generic:

1.  Run GENERIC.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. Generic will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename GENERIC.EXE to
GENERIC.386 and move it to the Windows SYSTEM
subdirectory. Add the line DEVICE=GENERIC.386 to the
[386Enh] section of the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

Generic was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The GPTRAP sample can be downloaded from the
**** file 7-3.zip in library section number 7
****

GPTrap: A VxD that Traps GP Faults

Revised: February 1993

GPTrap is a virtual device (VxD) that uses the
Hook_PM_Fault service to catch general protection (GP)
faults. When a GP fault occurs, GPTrap receives control
and executes an Interrupt 1. If execution is then
continued, control is passed to the next handler in the
fault handler chain.


To build GPTrap:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of GPTrap using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute GPTrap:

1.  Run GPTRAP.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. GPTrap will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename GPTRAP.EXE to
GPTRAP.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=GPTRAP.386 to the [386Enh] section of
the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

GPTrap was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VDIALOG sample can be downloaded from the
**** file 7-6.zip in library section number 7
****

VDialog: A VxD that Demonstrates How to Serialize I/O to a
Device

Revised: February 1993

VDialog is a virtual device (VxD) that demonstrates how to
serialize I/O to a device in Microsoft(R) Windows(TM)
enhanced mode. Install this VxD as described below and run
the accompanying sample programs, WINACC and DOSACC. These
two programs simply try to perform an IN instruction to a
predetermined but undefined port. VDialog protects
multiple virtual machines (VMs) from accessing (either
reading from or writing to) the port and displays a dialog
box to resolve the contention.

VDialog uses the following services:

>  Install_IO_Handler
>  Shell_Resolve_Contention
>  Enable_Local_Trapping
>  Disable_Local_Trapping


To build VDialog:

You will need Microsoft Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows version 3.1 Device Driver Kit
(DDK), you can build its version of VDialog using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VDialog:

1.  Run VDIALOG.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. VDialog will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VDIALOG.EXE to
VDIALOG.386 and move it to the Windows SYSTEM
subdirectory. Add the line DEVICE=VDIALOG.386 to the
[386Enh] section of the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

3.  Open an MS-DOS box (that is, execute COMMAND.COM).

4.  Execute DOSACC.EXE in the MS-DOS box.

5.  Switch back to Windows without destroying the MS-DOS
box (that is, do not "exit").

6.  Execute WINACC.EXE, and choose Read! from its menu
bar.

7.  Admire the contention dialog box that has appeared.

Another way to generate the contention dialog is to switch
steps 4 and 6.

VDialog was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VFINTD sample can be downloaded from the
**** file 7-7.zip in library section number 7
****

VFIntD: A VxD that Captures Floppy Disk Interrupts

Revised: February 1993

VFIntD, the virtual floppy interrupt device, is a VxD that
shows how to handle the virtualization of a particular
interrupt request (IRQ). This VxD provides a good base for
other VxDs that need to perform similar functions.

VFIntD uses the VPICD_Virtualize_IRQ service to allow an
application to "capture" the interrupts on IRQ6 (used by
the floppy device); this interrupt is normally global. For
example, a backup program that must access the floppy
controller hardware directly to improve performance would
"lose" interrupts to other virtual machines unless action
is taken to change the global nature of IRQ6. VFintD can
be used in this case to capture the "focus" of the floppy
device and the interrupts it generates.

VFIntD has two components: the VxD and a sample MS-DOS(R)
application. All the files that have the VFINTD filename
are part of the VxD. The MS-DOS application is called
TSTFINT; its only purpose is to capture the floppy
interrupts. The focus is not released in the sample
application, but this functionality is provided in the
VxD.

VFIntD uses the following services:

>  VPICD_Virtualize_IRQ
>  VPICD_Phys_EOI
>  VPICD_Clear_Int_Request
>  VPICD_Set_Int_Request


To build VFIntD:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VFIntD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VFIntD:

1.  Run VFINTD.EXE from the MS-DOS prompt before starting
Windows. When enhanced-mode Windows starts up, the VxD
will load automatically. Thus, you do not need to modify
the SYSTEM.INI file to load this VxD. VFIntD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VFINTD.EXE to
VFINTD.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VFINTD.386 to the [386Enh] section of
the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

3.  Run TSTFINT.EXE from an MS-DOS virtual machine (VM)
such as COMMAND.COM to capture the floppy interrupts.
TSTFINT will print the VxD's version number to indicate
that it has successfully communicated with the VxD.

VFIntD was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VHOOK86D sample can be downloaded from the
**** file 7-8.zip in library section number 7
****

VHook86D: A VxD that Hooks Interrupt 2Fh in V86 Mode

Revised: February 1993

VHook86D is a virtual device (VxD) that demonstrates the
use of Hook_V86_Int_Chain, which is one of the virtual
machine (VM) interrupt and callback services. VHook86D
exists for demonstration purposes only; this VxD adversely
affects system performance because it hooks Interrupt 2Fh
and prints Trace_Out messages to the debugging monitor.


To build VHook86D:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VHook86D using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VHook86D:

1.  Run VHOOK86D.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. VHook86D will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VHOOK86D.EXE
to VHOOK86D.386 and move it to the Windows SYSTEM
subdirectory. Add the line DEVICE=VHOOK86D.386 to the
[386Enh] section of the SYSTEM.INI file.

2.  Run Windows in enhanced mode and watch the debugging
display (which must be connected to COM1). The Trace_Out
messages will slow the system down to a c-r-a-w-l.

The code responsible for self-loading the VxD is in the
VXDSTUB.ASM file and is linked into the final VxD file by
the STUB 'VXDSTUB.EXE' module definition (.DEF) file
statement. When executed from the MS-DOS prompt, the
VxDStub hooks Interrupt 2Fh, terminates, and stays
resident. When Microsoft Windows initializes itself, the
TSR responds to the Interrupt 2Fh, AX=1605h broadcast and
returns a structure that causes the VxD to be loaded. This
technique is discussed in the "TSR Support in Microsoft
Windows Version 3.1" technical article on the Microsoft
Developer Network CD.

VHook86D was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VIDLED sample can be downloaded from the
**** file 7-9.zip in library section number 7
****

VIdleD: A VxD that Demonstrates the Call_When_Idle Service

Revised: February 1993

VIdleD is a virtual device (VxD) that demonstrates the use
of the virtual machine manager (VMM) Call_When_Idle
primary scheduler service. VIdleD exists for demonstration
purposes only; the VxD may impair system performance
because it issues a Trace_Out call on every idle callback.


To build VIdleD:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VIdleD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VIdleD:

1.  Run VIDLED.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. VIdleD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VIDLED.EXE to
VIDLED.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VIDLED.386 to the [386Enh] section of
the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

VIdleD was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VITD sample can be downloaded from the
**** file 7-10.zip in library section number 7
****

VITD: A VxD that Simulates an Interval Timer Device

Revised: February 1993

VITD, the virtual interval timer device, is a VxD that
creates an "interval timer"--a non-existent piece of
hardware that enables programs to measure elapsed CPU time
in a virtual machine (VM). Applications communicate with
VITD the same way they communicate with real hardware
timers: through I/O ports.

VITD uses the following virtual machine manager (VMM) and
virtual timer device (VTD) services:

>  _Allocate_Device_CB_Area
>  Fatal_Memory_Error
>  Install_Mult_IO_Handlers
>  Get_VM_Exec_Time
>  Set_VM_Time_Out
>  Cancel_Time_Out
>  Get_VM_Exec_Time
>  Call_Priority_VM_Event
>  Begin_Nest_Exec
>  End_Nest_Exec
>  Exec_Int
>  VTD_Get_Interrupt_Period
>  VTD_Begin_Min_Int_Period
>  VTD_End_Min_Int_Period
>  VTD_Get_Version
>  VTD_Get_Interrupt_Period


To build VITD:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VITD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VITD:

1.  Run VITD.EXE from the MS-DOS(R) prompt before starting
Windows. When enhanced-mode Windows starts up, the VxD
will load automatically. Thus, you do not need to modify
the SYSTEM.INI file to load this VxD. VITD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VITD.EXE to
VITD.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VITD.386 to the [386Enh] section of
the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

3.  Create an MS-DOS virtual machine (for example, run
COMMAND.COM).

Inside the virtual machine:

4.  Run SAMPLE.EXE to set up an interval timer.

5.  Run GETCOUNT.EXE to report the current interval timer
count.

6.  Run DOSIT.EXE to register an interval timer interrupt
handler that will start an interval timer. Wait until an
interval timer interrupt occurs.

The interrupt usage, I/O addresses, status bits, and
overall functioning of VITD are documented in the
ITIMER.INC header file and the VITD.ASM source file.

VITD was built and tested under Microsoft Windows version
3.1 using Microsoft MASM versions 6.0 and 6.1 and the
tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VKXD sample can be downloaded from the
**** file 7-11.zip in library section number 7
****

VKXD: A VxD that Simulates the ALT+ENTER Key Combination

Revised: February 1993

VKXD, the virtual keyboard extension device, is a VxD that
demonstrates how to write extensions to the virtual
keyboard device (VKD).

VKXD extends VKD by letting you use F9 as the ALT+ENTER
key combination to switch your MS-DOS(R) applications
between full-screen mode and window mode.

Warning:  The ALT+ENTER key combination causes different
actions in Microsoft(R) Windows(TM) versions 3.0 and 3.1
(for example, in the Windows 3.1 Program Manager, pressing
ALT+ENTER when a program icon is selected will bring up
the Program Item Properties dialog box). VKXD is given as
an example of using VKD services; it is not intended to be
a "perfect" implementation of a window-to-full-screen
toggle key.

VKXD uses the following VKD services:

>  VKD_Define_Hot_Key
>  VKD_Cancel_Hot_Key_State
>  VKD_Force_Keys


To build VKXD:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VKXD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VKXD:

1.  Run VKXD.EXE from the MS-DOS(R) prompt before starting
Windows. When enhanced-mode Windows starts up, the VxD
will load automatically. Thus, you do not need to modify
the SYSTEM.INI file to load this VxD. VKXD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VKXD.EXE to
VKXD.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VKXD.386 to the [386Enh] section of
the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

VKXD was built and tested under Microsoft Windows version
3.1 using Microsoft MASM versions 6.0 and 6.1 and the
tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VMIOD sample can be downloaded from the
**** file 7-12.zip in library section number 7
****

VMIOD: A VxD that Monitors I/O Traffic on a Port

Revised: February 1993

VMIOD, the virtual monitor I/O device, is a VxD that
demonstrates how to call the Install_IO_Handler service to
monitor I/O traffic on a port. Although most VxDs that use
this service are designed to virtualize the I/O port,
VMIOD only monitors the port and writes to a secondary
monitor to display the port activity.

Warning:  The Microsoft(R) Windows(TM) operating system
allows only one I/O handler per port. This means that you
can't install an I/O handler on a port that is already
trapped in the system. Most of the hardware devices that
Windows knows about (keyboard, timer, video) are trapped
ports, and thus cannot be monitored by VMIOD. For a simple
demonstration of VMIOD, try 3F5, a floppy controller port.
This port was untrapped in the retail release of Windows
versions 3.0 and 3.1.

VMIOD only demonstrates I/O port trapping, not interrupt
request (IRQ) handling. See the VMIRQD sample for more
information on working with IRQs.

VMIOD uses the following virtual machine manager (VMM)
services:

>  Get_Profile_Hex_Int
>  Install_IO_Handler
>  Clear_Mono_Screen
>  Set_Mono_Cur_Pos
>  Out_Mono_String


To build VMIOD:

You will need Microsoft Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows version 3.1 Device Driver Kit
(DDK), you can build its version of VMIOD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VMIOD:

To use VMIOD, you must have a secondary (monochrome)
monitor on your system.

1.  Place the following lines in the [386Enh] section of
your SYSTEM.INI file:

DEBUGMONO=TRUE
VMIOD_Port=nnnn

where nnnn is the hex I/O port number to monitor (try
floppy controller port 3F5).

2.  Run VMIOD.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. VMIOD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VMIOD.EXE to
VMIOD.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VMIOD.386 to the [386Enh] section of
the SYSTEM.INI file.

3.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

VMIOD was built and tested under Microsoft Windows version
3.1 using Microsoft MASM versions 6.0 and 6.1 and the
tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VMIRQD sample can be downloaded from the
**** file 7-13.zip in library section number 7
****

VMIRQD: A VxD that Virtualizes a Hardware Interrupt

Revised: February 1993

VMIRQD, the virtual monitor interrupt request (IRQ)
device, is a VxD that demonstrates the virtualization of a
hardware interrupt. This VxD declares a virtual device ID
number; see the VMIRQD.INC file for the declaration.
VMIRQD works only for unvirtualized IRQs. Most of the
hardware interrupts that Windows knows about (keyboard,
timer, mouse) use IRQs that are already virtualized, and
thus cannot be monitored by this VxD. For a simple
demonstration of VMIRQD, try IRQ6, the floppy controller
IRQ. This IRQ was not virtualized in the retail release of
Windows versions 3.0 and 3.1.

VMIRQD uses the following virtual machine manager (VMM)
and virtual programmable interrupt controller device
(VPICD) services:

>  _Get_Profile_Decimal_Int
>  Clear_Mono_Screen
>  Set_Mono_Cur_Pos
>  Out_Mono_String
>  _VPICD_Virtualize_IRQ
>  _VPICD_Phys_EOI


To build VMIRQD:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VMIRQD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VMIRQD:

To use VMIRQD, you must have a secondary (monochrome)
monitor on your system.

1.  Place the following lines in the [386Enh] section of
your SYSTEM.INI file:

DEBUGMONO=TRUE
VMIRQD_IRQ=x

where x is the IRQ number you wish to monitor (try
floppy controller IRQ 6).

2.  Run VMIRQD.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. VMIRQD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VMIRQD.EXE to
VMIRQD.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VMIRQD.386 to the [386Enh] section of
the SYSTEM.INI file.

3.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

VMIRQD was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VMPAGES sample can be downloaded from the
**** file 7-14.zip in library section number 7
****

VMPages: A VxD that Exports a VMM Service to an
Application

Revised: February 1993

VMPages is a virtual device (VxD) that demonstrates how to
export a VxD service (in this case _GetVMPgCount) to an
application. VMPGS.EXE is an MS-DOS(R) application that
calls the application programming interface (API) that
VMPAGES exports. Although VMPages and VMPGS are very
simple and very incomplete samples, they illustrate the
essential requirements for exporting an API from a VxD to
an application.


To build VMPages:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VMPages using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VMPages:

1.  Run VMPAGES.EXE from the MS-DOS prompt before starting
Windows. When enhanced-mode Windows starts up, the VxD
will load automatically. Thus, you do not need to modify
the SYSTEM.INI file to load this VxD. VMPages will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VMPAGES.EXE to
VMPAGES.386 and move it to the Windows SYSTEM
subdirectory. Add the line DEVICE=VMPAGES.386 to the
[386Enh] section of the SYSTEM.INI file.

2.  Run Windows in enhanced mode under WDEB386 (or any
other debugger that traps Interrupt 01), and then run the
MS-DOS application VMPGS.EXE in a virtual machine (VM)
inside Windows.

The code responsible for self-loading the VxD is in the
VXDSTUB.ASM file and is linked into the final VxD file by
the STUB 'VXDSTUB.EXE' module definition (.DEF) file
statement. When executed from the MS-DOS prompt, the
VxDStub hooks Interrupt 2Fh, terminates, and stays
resident. When Microsoft Windows initializes itself, the
TSR responds to the Interrupt 2Fh, AX=1605h broadcast and
returns a structure that causes the VxD to be loaded. This
technique is discussed in the "TSR Support in Microsoft
Windows Version 3.1" technical article on the Microsoft
Developer Network CD.

3.  Using the debugger, examine the buffer returned after
Interrupt 01.

VMPages was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VNMID sample can be downloaded from the
**** file 7-15.zip in library section number 7
****

VNMID: A VxD that Hooks the Non-Maskable Interrupt

Revised: February 1993

VNMID, the virtual non-maskable interrupt device, is a VxD
that demonstrates hooking the non-maskable interrupt
(NMI). It does not perform any actions during the NMI
except to chain to the previous handler.

VNMID uses the following virtual machine manager (VMM)
services:

>  Get_NMI_Handler_Addr
>  Set_NMI_Handler_Addr
>  Hook_NMI_Event


To build VNMID:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VNMID using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VNMID:

1.  Run VNMID.EXE from the MS-DOS(R) prompt before
starting Windows. When enhanced-mode Windows starts up,
the VxD will load automatically. Thus, you do not need to
modify the SYSTEM.INI file to load this VxD. VNMID will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VNMID.EXE to
VNMID.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VNMID.386 to the [386Enh] section of
the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

VNMID was built and tested under Microsoft Windows version
3.1 using Microsoft MASM versions 6.0 and 6.1 and the
tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VWATCHD sample can be downloaded from the
**** file 7-16.zip in library section number 7
****

VWatchD: Illustrates the Basic Structure of a VxD

Revised: February 1993

VWatchD, the virtual watch device, demonstrates the basic
structure of a VxD. TEST.EXE is an MS-DOS(R) application
that calls the VWatchD V86 API entry.

VWatchD uses the following virtual machine manager (VMM)
services:

>  _Allocate_Device_CB_Area
>  Get_System_Time
>  Fatal_Memory_Error


To build VWatchD:

You will need Microsoft(R) Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you can build its version of VWatchD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VWatchD:

1.  Run VWATCHD.EXE from the MS-DOS prompt before starting
Windows. When enhanced-mode Windows starts up, the VxD
will load automatically. Thus, you do not need to modify
the SYSTEM.INI file to load this VxD. VWatchD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VWATCHD.EXE to
VWATCHD.386 and move it to the Windows SYSTEM
subdirectory. Add the line DEVICE=VWATCHD.386 to the
[386Enh] section of the SYSTEM.INI file.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

3.  Start an MS-DOS virtual machine (VM) and run TEST.EXE
in that VM. TEST.EXE will ask the VWatchD device when the
VM was created and report that number in milliseconds.

4.  Start another MS-DOS VM and run TEST in that VM. Note
the older "birthday" of the second VM.

You should set up a debug terminal to see the debugging
output produced by VWatchD. Run the debugging version of
WIN386.EXE.

VWatchD was built and tested under Microsoft Windows
version 3.1 using Microsoft MASM versions 6.0 and 6.1 and
the tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VWFD sample can be downloaded from the
**** file 7-17.zip in library section number 7
****

VWFD: A VxD that Reports a VM's Windowed vs. Full-Screen
State

Revised: February 1993

VWFD is the virtual windowed/full-screen device. When
installed on a system running Microsoft(R) Windows(TM) in
enhanced mode, VWFD allows MS-DOS(R) applications to
determine whether they are running full screen or in a
window. VWFD supplies the following callback to accomplish
this:

call:  VWFD_API_Callback
entry:  BX=VMID of the virtual machine (VM) to test
exit:  AX=0 if VM is full screen

VWFD uses the following virtual machine manager (VMM)
services:

>  Allocate_Device_CB_Area
>  Hook_Device_Service
>  Get_Next_VM_Handle
>  Test_Cur_VM_Handle

TSTWF.ASM is a sample MS-DOS program that uses the VWFD
callback to find out if it is being run in a windowed or
full-screen VM. TSTWF uses the following functions:

>  Interrupt 2Fh, AX=1600h -- Determine if enhanced-mode
Windows is running.
>  Interrupt 2Fh, AX=1684h -- Get VxD function callback
address.


To build VWFD:

You will need Microsoft Macro Assembler version 6.0 or
higher, as well as some special tools and include files;
see the "VxD Tools" and "VxD Include Files" abstracts to
copy these files to your development system. Configure
your development environment as described in the "VxD-Lite
Mini-DDK" technical article on the Microsoft Developer
Network CD.

If you have the Windows version 3.1 Device Driver Kit
(DDK), you can build its version of VWFD using the DDK-
supplied MASM5.EXE (a special version of Macro Assembler
version 5.10). Note that the DDK samples require a
specific structure for the source and include
subdirectories, whereas the corresponding samples in the
"VxD-Lite Mini-DDK" utilize the INCLUDE environment
variable to give you more flexibility in structuring your
development files.


To execute VWFD:

1.  Run VWFD.EXE from the MS-DOS prompt before starting
Windows. When enhanced-mode Windows starts up, the VxD
will load automatically. Thus, you do not need to modify
the SYSTEM.INI file to load this VxD. VWFD will
automatically load each time you start Windows until you
reboot your computer; once rebooted, the stub loader is
cleared from memory and the VxD will not load.

If you prefer to have Windows load the VxD without first
executing it from the MS-DOS prompt, rename VWFD.EXE to
VWFD.386 and move it to the Windows SYSTEM subdirectory.
Add the line DEVICE=VWFD.386 to the [386Enh] section of
the SYSTEM.INI file and restart Windows.

2.  Run Windows in enhanced mode. The code responsible for
self-loading the VxD is in the VXDSTUB.ASM file and is
linked into the final VxD file by the STUB 'VXDSTUB.EXE'
module definition (.DEF) file statement. When executed
from the MS-DOS prompt, the VxDStub hooks Interrupt 2Fh,
terminates, and stays resident. When Microsoft Windows
initializes itself, the TSR responds to the Interrupt 2Fh,
AX=1605h broadcast and returns a structure that causes the
VxD to be loaded. This technique is discussed in the "TSR
Support in Microsoft Windows Version 3.1" technical
article on the Microsoft Developer Network CD.

3.  Run an MS-DOS VM (for example, COMMAND.COM), and run
TSTWF.EXE in it. TSTWF will report whether the VM is
windowed or full-screen.

4.  Press ALT+ENTER to toggle the VM between windowed and
full-screen mode, then run TSTWF.EXE again; it should
report the opposite state.

VWFD was built and tested under Microsoft Windows version
3.1 using Microsoft MASM versions 6.0 and 6.1 and the
tools and include files provided in the "VxD-Lite Mini-
DDK."

KEYWORDS: PR-CD1; CD3 (revised)

THIS TOOL IS NOT SUPPORTED BY MICROSOFT CORPORATION. IT IS
PROVIDED "AS IS" BECAUSE WE BELIEVE IT MAY BE USEFUL TO
YOU. PLEASE DO NOT CONTACT MICROSOFT PRODUCT SUPPORT
SERVICES FOR SUPPORT OR ASSISTANCE SHOULD YOU HAVE
PROBLEMS USING THIS TOOL.

READ THE ASSOCIATED DOCUMENTATION, IF ANY, REGARDING THIS
TOOL PRIOR TO USING. ANY USE BY YOU OF THE TOOL IS AT YOUR
OWN RISK. THE TOOL IS PROVIDED FOR USE "AS IS" WITHOUT
WARRANTY OF ANY KIND. MICROSOFT AND ITS SUPPLIERS DISCLAIM
ALL WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

=============================================================================

=============================================================================

****
**** The VXDINC sample can be downloaded from the
**** file 7-18.zip in library section number 7
****

VxD Include Files: Used for Building Virtual Devices

Revised: February 1993

These include files are needed for building virtual
devices (VxDs). Use them in conjunction with the VxD tools
(see the VxD Tools abstract). These include files are
not the same as the files supplied in the Microsoft(R)
Windows(TM) version 3.1 Device Driver Kit (DDK); they have
been modified to be compatible with Microsoft Macro
Assembler version 6.0 and higher. If you have the Windows
3.1 DDK, you can use the MASM5.EXE assembler that is
included in the DDK and do not need the "VxD-Lite Mini-
DDK" include files or sample VxDs.

Copy these include files to your hard drive in a
subdirectory of your choice. Before assembling one of the
sample VxDs, set your INCLUDE environment variable to this
directory; for example, with the following batch file
command:

set INCLUDE=c:\vxd\include;%INCLUDE%

When deciding on a directory location, keep in mind that
some VxD code (including all of the regular Windows 3.1
DDK code) assumes that the INCLUDE directory is adjacent
to the sample code subdirectories, as shown below:

Parent Directory
|
+------------------+------------------+
|                  |                  |
Sample1            Sample2            Include
1.asm              2.asm              vmm.inc
1.inc              2.inc              v86mmgr.inc
...                ...                ...

Note: The make files for the VxD samples in the "VxD-Lite
Mini-DDK" do not assume this directory structure. Instead,
they use the INCLUDE environment variable to locate the
files.

When building a VxD that uses this convention, you must do
one of the following:

>  Structure your directories according to the assumption
described above.

>  Modify the make file by changing the MASM -I option to
point to the directory location you selected for the
include file.

>  Declare a new MS-DOS(R) environment variable such as
VXDINCLUDE to point to the VxD include files, then modify
the make file so the MASM -I option uses the environment
variable as a macro. For example:

masm -I$(VXDINCLUDE) vxdstub;

>  Set the MS-DOS INCLUDE environment variable to point to
the VxD include files, then remove the MASM -I option and
let MASM find the INCLUDE directory based on the MS-DOS
INCLUDE environment variable.

For more information on using the Windows 3.1 DDK files
included on the Microsoft Developer Network CD, read the
"VxD-Lite Mini-DDK" technical article. For more
information on virtual device programming, see the
"Virtual Device Adaptation Guide" in the Windows 3.1 DDK
and read the relevant articles in the Microsoft Knowledge
Base, Microsoft Systems Journal, and the Technical
Articles sections of the Microsoft Developer Network CD.

KEYWORDS: PR-CD1; CD3 (revised)

=============================================================================

=============================================================================

****
**** The VXDTOOLS sample can be downloaded from the
**** file 7-19.zip in library section number 7
****

VxD Tools: Used for Building Virtual Devices

Revised: February 1993

You will need these tools and Microsoft(R) Macro Assembler
version 6.0 or higher (not included) to build virtual
devices (VxDs). Use them in conjunction with the VxD
include files (see the VxD Include Files abstract). If
you have the Windows(TM) version 3.1 Device Driver Kit
(DDK), you already have these tools as well as MASM5.EXE,
which is a special version of MASM 5.10b that can assemble
32-bit flat-model code.

Copy these executable files to your hard drive in a
subdirectory specified in your MS-DOS(R) environment
variable PATH. If you have already installed the Microsoft
Windows Software Development Kit (SDK), you may copy these
files into the executable files subdirectory (by default,
WINDEV\BIN). The VxD tools include linkers and assemblers
with unique names such as LINK386.EXE, MAPSYM32.EXE, and
ADDHDR.EXE, so they will not overwrite the standard MS-DOS
and Windows SDK versions of the same utilities.

In addition to the standard development tools, the VxD
tools include a debugging version of WIN386.EXE and
symbolic information files for the debug and retail
versions:

>  WIN386D.EXE - debugging version of WIN386.EXE

>  WIN386D.SYM - symbolic information file for debugging
version

>  WIN386R.SYM - symbolic information file for retail
version

These files can be used to switch between the retail and
debugging versions of WIN386.EXE. You should use the
debugging WIN386.EXE when developing virtual devices. The
easiest way to switch between debug and retail versions is
to write batch files that copy the appropriate versions of
WIN386.EXE and WIN386.SYM from the TOOLS directory into
your Windows SYSTEM directory. Before using your batch
files for the first time, you will need to copy the retail
WIN386.EXE from your Windows SYSTEM directory to the TOOLS
directory and rename it as WIN386R.EXE. The "VxD-Lite Mini-
DDK" technical article on the Microsoft Developer Network
CD contains sample batch files to perform this switching.

For more information on using the Windows 3.1 DDK files
included on the Microsoft Developer Network CD, read the
"VxD-Lite Mini-DDK" technical article. For more
information on virtual device programming, see the
"Virtual Device Adaptation Guide" in the Windows 3.1 DDK
and read the relevant articles in the Microsoft Knowledge
Base, Microsoft Systems Journal, and the Technical
Articles sections of the Microsoft Developer Network CD.

KEYWORDS: PR-CD1; CD3 (revised)

=============================================================================

