Programming 版 (精华区)

发信人: Sun (大灯泡), 信区: Programming
标  题: [转载] [技术]VXD BackGround    
发信站: 紫 丁 香 (Thu Sep  9 10:41:38 1999), 转信

【 以下文字转载自 VisualProgram 讨论区 】
【 原文由 xiaojun 所发表 】

主题: [技术]VXD BackGround                   kingchurch (转寄)
日期: 1998年9月19日 07:30:25
发件人: lyj.bbs@bbs.net.tsinghua.edu.cn
收件人: lyj@hs1.hit.edu.cn

发信人: winson (阿苦), 信区: Programming
标  题: VXD BackGround
发信站: BBS 水木清华站 (Mon Apr 13 20:56:21 1998)

VxD technical background paper



A VxD is a device driver. Device drivers enable the operating system to
present applications with an abstract interface to the hardware. By
providing a standardized way of interacting with a device, the operating
system shields the application programmer from the low-level hardware
details. This makes application development easier, which leads to more
successful applications and a more successful operating system platform. 

Under the Windows operating system, VxDs are responsible for implementing
an environment in which application code can successfully interact with
the PC hardware. The task of presenting a standardized view of hardware to
all applications is complicated by the fact that some of the interfaces
VxDs must support are inherited from the older DOS programming model.
Furthermore, multiple applications may simultaneously require access to
the same hardware. 

To allow users of the Windows operating system to run multiple
applications simultaneously, the system's designers implemented virtual
machines. A virtual machine is a separate environment in which an
application runs. It has its own address space, register state, stacks,
local descriptor table, interrupt table state, and execution priority.
Each DOS box is a separate virtual machine. 

The first virtual machine created when Windows starts is called the system
virtual machine. All Windows applications and DLLs run in this virtual
machine, and consequently, they all share the same address space. (The
exception to this rule is that Win32 applications running under Windows 95
have private address spaces.) Most of what application programmers think
of as Windows, that is DLLs like KERNEL, USER, and GDI, are actually
components of a complex graphical application, not parts of the true
operating system. 

A reasonable way to distinguish between application code and operating
system code is to consider the privilege level at which the code runs.
Modern microprocessors have distinct modes of operation for execution of
trusted system code and execution of application code. Operating systems
take advantage of this feature for better system reliability. 

Like most operating systems, Windows is structured in layers. Only VxDs
run at ring 0, the most privileged mode of operation. Applications run at
ring 3, and rings 1 and 2 are not used. Windows components referred to as
Device Drivers (those having the extension .DRV) are different from VxDs;
they are 16-bit components that run at ring 3. 

The original designers of Windows created a programming environment for
the privileged level of the system with performance and flexibility in
mind. VxDs live in a flat address space. The code, data, and stack
segments all have a linear base of zero, and a limit of 4GB. This
effectively means segmentation is not an issue; the 32-bit offset
component of an address is sufficient to address any location in the
processor's address space. There is rarely, if ever, the need to reload
the segments registers, which is an expensive operation. 

A special VxD called the virtual machine manager, or VMM, plays an
executive role in coordinating use of system resources. The primary job of
the VMM is to create, schedule, and destroy virtual machines. In addition,
it provides the services that enable other VxDs to intervene between
applications and hardware. This ability to control, in software, all
interaction between applications and hardware is essential to the multiple
VM architecture of Windows. DOS applications, written for a single program
environment, often attempt to directly access sensitive hardware
resources, such as the interrupt controllers and DMA controllers. In order
to run multiple such applications, along with Windows applications, the
operating system must implement instances of virtual devices for each
virtual machine. 

The task of a VxD is to manage a virtual device state for each client
virtual machine that needs access to the corresponding physical device.
VxDs collectively provide virtual machine environments for client
applications by transparently arbitrating access to the underlying
physical layer. This is referred to as virtualization. 

Although VxDs were originally designed with the purpose of virtualization
in mind, their usage has evolved to encompass much more than that.
Increasingly, system designers choose VxDs for maximum performance and
fine control. Many VxD implementors are concerned only with providing the
best support for their hardware, and not with compatibility with legacy
DOS applications. For example, to support a device that requires low
interrupt latency, a VxD is essential. In many cases, designers handle all
the actual hardware interaction in a VxD, and the VxD presents a
simplified API to applications. Another use of VxDs is to replace legacy
TSRs, which eases memory requirements in the low 640 KB, and may improve
performance, as well. In general, VxDs are the best means to alter the
environment that an application sees, whether it be the hardware or
software environment in question. 

In the evolution from Windows 3.1 to Windows 95, the importance of VxDs
has grown considerably. Operations that were formerly done via calls to
the real mode BIOS or to 16-bit DLLs are now handled in the 32-bit
protected mode environment of VxDs. To a large degree, Windows 95
displaces DOS from its former role as the underlying operating system
substrate. Consequently, Windows 95 defines new interfaces at the VxD
level to encompass the additional functionality. There is new architecture
for handling block devices, comm devices, networks, displays, and more. 

Architects at Microsoft have made it easier to support new devices under
Windows 95 by factoring out device specific functionality into
"minidrivers". For a given class of device, VxDs provided with Windows
implement functionality common to all devices in the class, and implement
an interface to the application level. These system VxDs interface to
smaller device specific VxDs, called minidrivers, which are responsible
only for the lowest level of hardware interaction. The burden on a
developer tasked with supporting a new device is thereby reduced to the
minimum amount of code needed to handle the unique characteristics of the
hardware in question. 

What kinds of things should a prospective VxD developer be familiar with?
First of all, operating system concepts such as address space, execution
contexts, resource locking, interprocess communication, and asynchronous
event handling are essential. Second, a solid understanding of the Intel
microprocessor, including the register and instruction sets, protection
mechanisms, paging mechanisms, and virtual 8086 mode is most beneficial.
Finally, familiarization with the services and interfaces provided by the
VMM and other Windows VxDs will be crucial. 


It is DL from vireo!

--
m6m※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 166.111.52.63]m

--
※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: hs5.hit.edu.cn]
--
※ 转载:．紫 丁 香 bbs.hit.edu.cn．[FROM: 202.118.239.237]