| |
Just as Windows 2000
builds upon the NT kernel, or core, Microsoft's "Windows Driver Model,"
or WDM, draws from the NT driver model with several fundamental
differences. WDM is an attempt to bridge the gap between Windows 98 and
Windows 2000 driver development, with performance benefits even for users
of Win98.
With the creation of this new driver standard, manufacturers are faced
with support of the previous, virtual device driver model, or "VXD,"
for Win95/98, plus NT support, plus the development of the WDM driver
which, by definition, must work in both Windows 98 and 2000. Initially,
at least, that's a double-edged sword for manufacturers. One edge is the
awesome task of creating a new set of drivers for a complete line of devices,
and the other edge is the legacy support with inevitable obsolescence.
The latter edge is perhaps not quite so sharp, and therefore ultimately
more painful.
For the user and eventually for the hardware manufacturer, these are positive
strides. Let's take a closer look at what this all means to the end-user.
Why WDM?
Microsoft recognized the difficulty for independent hardware
vendors to develop and maintain two completely different driver standards,
i.e., one for Windows 95/98 and one for Windows NT 3.51 and 4.0. With
NT 5 (better known as Windows 2000) on the horizon, the WDM driver standard
was introduced for Windows 98 to bridge the gap between the need to develop
two separate sets of drivers and to encourage driver development for Windows
2000 (WDM will not work in Win 95, though it does contain some of the
necessary elements). At the time, yet possibly less so today, legacy support
for Windows 95 was a necessary evil.
The other side of the coin was Microsoft's reluctant yet eventual acknowledgment
of the increasing use of the personal computer for applications where
large amounts of continuous data needed to be streamed to hardware, and
where the time-sensitive nature of that data required precise synchronization.
Previously, Microsoft seemed to address only the more traditional business
applications in a serious and efficacious way. Perhaps the cry, "Hey,
what about us audio and video guys?" was finally heard. While streaming
and synchronization were negatively impacted by the inefficient use of
system resources and system latency coupled with an inconsistent driver
model, WDM represents major advances in this area.
How WDM?
With WDM, some of the work of a device driver is offloaded onto portions
of the code that are integrated into the operating system. These portions
of the driver code are known as driver "classes," or the class
driver. The class driver handles all of the low-level buffer management,
including DMA and even Plug and Play device enumeration. The result is
that the actual WDM device driver is far more streamlined with far less
code, and with much greater efficiency.
Class drivers themselves are divided into two categories, and with this
simplification of the driver model, the class drivers are referred to
as "miniport" and "minidriver" (not to be confused
with the actress, Minnie Driver) approaches to driver operation. The port
class/miniport model serves devices designed for the PCI and ISA bus,
while the stream class/minidriver model addresses the needs of
USB and FireWire ports. The class driver communicates with the OS through
WDM, and with the rest of the world through WDM CSA.
WDM is based on the layered approach of the Windows NT driver. Built on
top of WDM, is the Connection Streaming Architecture (WDM CSA), and is
designed to address the higher level functions including data streaming
and synchronization and delivery delays, a/k/a system latency. CSA is
modular in nature, something that previous driver models lacked. This,
together with the manner in which WDM CSA presents drivers as "filters"
which pass streaming media (isolating the hardware issues from the streaming
issues), allowed driver writers to manipulate driver behavior without
having to rewrite the driver or the application.
NEXT
|
