The Full Wiki

VxD: Wikis

  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

From Wikipedia, the free encyclopedia

VxD is the device driver model used in Microsoft Windows/386, the 386 enhanced mode of Windows 3.x, and Windows 9x. VxDs have access to the memory of the kernel and all running processes, as well as raw access to the hardware.

Contents

Design

The name "VxD" is an abbreviation for "virtual xxx driver", where "xxx" is some class of hardware device. It derives from the fact that most drivers had filenames of the form vxxxd.386 in Windows 3.x. Some examples are: vjoyd.386 (joystick), vmm.386 (memory manager). VxDs usually have the filename extension .386 under Windows 3.x and .vxd under Windows 95. VxDs written for Windows 3.x can be used under Windows 95 but not vice versa.

History

Prior to the advent of Windows, DOS applications frequently communicated directly with various pieces of hardware, by responding to interrupts, reading and writing device memory etc. Each application expected to have exclusive and complete control over the hardware. Though Windows applications don't often communicate directly with hardware, it was the only way to write Windows drivers, and still is in the real and standard modes of Windows 3.x. Despite the fact that Windows switched from running in real mode to protected mode, direct hardware access and interrupt hooking could still be done because when Windows switched to running in protected mode it kept the single privilege level model used in real mode. This lasted all the way through Windows 9x. Windows/386 and onwards allowed multiple MS-DOS applications to execute simultaneously. This was done by executing each legacy application within its own virtual machine. To share arbitrary physical resources amongst these virtual machines, Microsoft introduced dynamically-loadable virtual device drivers. These drivers solved issues relating to conflicting usage of physical resources by intercepting calls to the hardware. Instead of a machine port representing an actual device, it would represent a "virtual" device, which could be managed by the operating system.

Obsolescence

VxDs are not usable in Windows NT or its descendants. Starting with Windows 2000, these operating systems use the Windows Driver Model (WDM), while Windows NT 4 and earlier versions must use drivers written specifically for them. Windows Vista supports both WDM and the newer Windows Driver Foundation which includes Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). KMDF is also available for download for Windows XP and Windows 2000, while UMDF is available only for Windows XP.



VxD is the device driver model used in Microsoft Windows/386, the 386 enhanced mode of Windows 3.x, and Windows 9x. VxDs have access to the memory of the kernel and all running processes, as well as raw access to the hardware.

Contents

Design

The name "VxD" is an abbreviation for "virtual xxx driver", where "xxx" is some class of hardware device. It derives from the fact that most drivers had filenames of the form vxxxd.386 in Windows 3.x. Some examples are: vjoyd.386 (joystick), vmm.386 (memory manager). VxDs usually have the filename extension .386 under Windows 3.x and .vxd under Windows 95. VxDs written for Windows 3.x can be used under Windows 95 but not vice versa.

History

Prior to the advent of Windows, DOS applications would either communicate directly with the various pieces of hardware (responding to interrupts, reading and writing device memory etc.) or go through a DOS device driver. As DOS was not multitasking each application would have exclusive and complete control over the hardware while running. Though Windows applications don't often communicate directly with hardware, it was the only way to write Windows drivers, and still is in the real and standard modes of Windows 3.x. Despite the fact that Windows switched from running in real mode to protected mode, direct hardware access and interrupt hooking could still be done because when Windows switched to running in protected mode it kept the single privilege level model used in real mode. This lasted all the way through Windows 9x. Windows/386 and onwards allowed multiple DOS applications to execute simultaneously. This was done by executing each legacy application within its own virtual machine. To share arbitrary physical resources amongst these virtual machines, Microsoft introduced dynamically-loadable virtual device drivers. These drivers solved issues relating to conflicting usage of physical resources by intercepting calls to the hardware. Instead of a machine port representing an actual device, it would represent a "virtual" device, which could be managed by the operating system.

Obsolescence

Although Windows 98 introduced the Windows Driver Model, VxD device drivers can be used under Windows 98 and Windows Me. VxDs are not usable in Windows NT or its descendants. Starting with Windows 2000, Windows NT-based operating systems also use the Windows Driver Model (WDM), while Windows NT 4 and earlier versions must use drivers written specifically for them. Using VxD drivers instead of WDM drivers in Windows 9x resulted in advanced ACPI states like hibernation being unavailable.

VxDs should not be confused with the similarly-named NTVDM-specific 'VDDs' (Virtual Device Drivers), which provide a method of emulating direct I/O under a Windows NT "DOS Box". NTVDM VDDs run as regular, 32-bit, user-mode DLL's, and must rely on the Win32 API (or another WDM driver) to emulate the desired I/O on behalf of the 16-bit program.








Got something to say? Make a comment.
Your name
Your email address
Message