VXDs: comparison to old device drivers.
Andrew Tumpach
Could someone explain virtual device drivers? How are they different from
previous device drivers? As much detail as possible would be helpful.
Thanks,
Andrew
David Lively
A Virtual Device Driver represents a generic <device>, such as a modem, and
supports common functions for that type of device. The VXD then talks to the
manufacturer's device driver, which interfaces with the hardware.
How this is different then the way things were done before, I'm not sure. (I
wasn't around then. =))
Andrew Tumpach wrote in message <75dspc$21...@forums.borland.com>...
John Topley
(Much of the following is taken from the brilliant "Unauthorised Windows 95"
by Andrew Schulman.)
In order to understand what a virtual device driver is, you have to
understand what a virtual machine is. A virtual machine (VM) is a complete
software emulation of the underlying computer hardware. Apart from timing,
there should be no way for software to determine if it's running in a VM or
on the bare hardware. The virtual machine concept was invented by IBM at
their Scientific Research Centre in Cambridge, MA in the late 60's and early
70's and first realised with the release of their VM/370 mainframe operating
system in 1972. Mainstream Windows (Windows 3.0 to Windows 98) is heavily
based on this work. In order to create the illusion that each VM is a
complete, separate machine, IBM recognised the need for device
virtualisation - each virtual machine must think that it has its own disk,
display, printer etc. Virtual device drivers are written to manage each
device. Each virtual device driver can arbitrate requests from multiple VMs,
refuse requests, pass them directly through to the device, or simulate them
completely.
In the context of Windows, a virtual machine is a complete software
emulation of an IBM compatible PC running MS-DOS. Whenever you start an
MS-DOS prompt, a separate virtual machine is created. Virtual machines are
pre-emptively multitasked by the heart of Windows, the Virtual Machine
Monitor (VMM). In Windows 3.x the VMM resides in WIN386.EXE, in Windows 9x
it's VMM32.VXD. The VMM is basically an operating system for running other
operating systems. Theoretically, each virtual machine can run a different a
different operating system (in Windows 3.0 you could type "win" at a DOS
prompt to start a separate role-mode copy of Windows). It's not widely
known, but this VMM/VxD heart of Windows has been 32-bit ever since
Windows/386 came out in 1988. This was made possible by Intel releasing the
386 chip which as well as real mode and protected mode, introduced a Virtual
8086 mode (V86 mode) which is like a one megabyte form of protected mode.
Microsoft actually helped Intel with the design of this feature. What V86
mode allows in practical terms is for multiple MS-DOS sessions to run
concurrently without the drawbacks of real-mode DOS i.e. no memory
protection, direct access to hardware etc. The parts of Windows that
programmers traditionally regard as being the at the centre of things,
Kernel, User and GDI execute within the context of the System VM, which is
pre-emptively multitasked with any MS-DOS sessions that are running. It's a
common misconception that Windows is a GUI layer perched shakily on top of
MS-DOS. What in fact happens, is that once loaded, Windows runs MS-DOS
itself in a VM - a case of the tail wagging the dog!!
VxDs (the 'x' represents anything) are 32-bit protected mode drivers with
their own file format (LE - Linear Executable) that provide device
virtualisation for virtual machines. They contain privileged code and as
such operate at an altogether lower level than device drivers. A number of
important VxDs are bound into the VMM itself during setup. If you look at
your SYSTEM.INI file under the [386Enh] section, you can see a list of VxDs;
the ones rolled into VMM have an asterisk preceding the name. Virtual device
driver files have a VXD or 386 extension. When Windows for Workgroups 3.11
was released in 1993, there was a furore because some existing disk
compression products stopped working. This was because Microsoft introduced
a new installable file system (IFS) which allowed 32-bit file access. This
scheme of things was implemented using VxDs; the disk software stopped
working because the VxDs were handling the disk interrupts which weren't
then being passed to the disk software. This was a rare case of what was
seen as a bug actually being a feature; 32-bit file access gives better
performance. Even more interesting was the fact that everyone who bought
Windows for Workgroups was in fact beta testing the Windows 95 file system -
one of the IFS files actually contains the string "prototype" within it!!
Windows for Workgroups didn't have long file names, but there was no
technical reason why Microsoft couldn't have introduced them. It was just
that doing so would have broken the 16-bit shell. Sometimes software running
in a VM executes quicker than if it were running of the bare hardware. This
"virtual machine performance anomaly" is because device virtualisation
allows caching, reordering of requests, and so on that might be more
efficient than the actual device.
Windows NT has virtual machines too (the command prompt executes using
NTVDM.EXE - NT Virtual DOS Machine) but the architecture is different. It
must use virtual device drivers but I don't know the details. Whatever, the
VxDs of Windows 3.0 through to Windows 98 are soon to be an endangered
species. And no, you can't write a VxD using Delphi, you need the Microsoft
Device Driver Kit and it's not a task for the faint hearted!
Hope this helps...
--
John
(JTSoftware - http://ds.dial.pipex.com/john.topley)
Glynn Owen
Glynn
John Topley
>Glynn
Thanks for the compliment :)
The biggest thanks of all though should go to Andrew Schulman who wrote the
"Unauthorised Windows 95" book. Nearly three quarters of the copy was way
over my head (particularly the dense C listings), but the parts that I did
understand changed how I think about Windows and my understanding of it,
forever.
Regards,
Glynn Owen
think I'll correct that oversight immediately. Thanks again.
Glynn
John Topley wrote:
>
> >Wow! That's a keeper. Thanks for the great article.
> >Glynn
>
> Thanks for the compliment :)
>
> The biggest thanks of all though should go to Andrew Schulman who wrote the
> "Unauthorised Windows 95" book. Nearly three quarters of the copy was way
> over my head (particularly the dense C listings), but the parts that I did
> understand changed how I think about Windows and my understanding of it,
> forever.
>
> Regards,
>
John Topley
What's "Undocumented Windows" like - I tried to buy it from amazon.com but
it's been out of print for quite a while, is it any good? That's the one
that documents the undocumented Windows 3.1 APIs, right? Unfortunately,
"Unathorised Windows 95" appears to be out of print too, so good luck
finding a copy. If you didn't know, Schulman has an "Undocumented" bookstore
site at http://www.sonic.net/~undoc/bookstore.html although it doesn't
appear to have been updated recently.
The other good author of this type of book that I'm aware of is Matt
Pietrek. I've got his "Windows Internals" book and I'm eagerly awaiting
"Windows 95 System Programming Secrets"!
Regards,
--
John
(JTSoftware - http://ds.dial.pipex.com/john.topley)
>I have his Undocumented Windows, but I didn't buy the one you mention. I
Glynn Owen
internals of Win 3.1. In addition to the many undocumented calls that it
spelled out, it also spelled out many of the data structures used by
Windows. I haven't even looked at it in 2 years, though. I waited a long
time for 32-bit programming, and that's all I've done since D2.
Thanks for the references. If I run across a copy of UW I'll let you
know.
Regards, Glynn
John Topley wrote:
>
> Glynn,
>
> What's "Undocumented Windows" like - I tried to buy it from amazon.com but
> it's been out of print for quite a while, is it any good? That's the one
> that documents the undocumented Windows 3.1 APIs, right? Unfortunately,
> "Unathorised Windows 95" appears to be out of print too, so good luck
> finding a copy. If you didn't know, Schulman has an "Undocumented" bookstore
> site at http://www.sonic.net/~undoc/bookstore.html although it doesn't
> appear to have been updated recently.
>
> The other good author of this type of book that I'm aware of is Matt
> Pietrek. I've got his "Windows Internals" book and I'm eagerly awaiting
> "Windows 95 System Programming Secrets"!
>
> Regards,
>
> --
> John
>
> (JTSoftware - http://ds.dial.pipex.com/john.topley)
>