“Jan Bottorff” wrote in message news:xxxxx@ntdev…
>
> Even stranger, on the front page of the Jan-Feb 2002 NT Insider, it talks
> about clever new in-stack queued spin locks, and also says they are NOT
> available in WDM drivers, only “standard kernel mode drivers” or “file
> system drivers”. I guess somebody forgot to inform the OS core developers
> than “standard kernel mode drivers” were no longer acceptable. The DDK
help
> file seems to agree, you need ntddk.h and not wdm.h. It has been suggested
> here: wdm.h is the future, and ntddk.h is the past. Looking at ntddk.h for
> the WinXP DDK, KeAcquireInStackQueuedSpinLock seems to be inside the
> comments that say “begin_wdm”.
>
> Perhaps the truth is we have “standard
> kernel mode drivers” which are the same as “wdm” drivers but are different
> than “WDM” drivers.
>
The naming situation for Windows driver models is nothing short of
ridiculous. Ask 3 developers, ANY 3 developers, what a “WDM Driver” is and
you’ll probably get 4 different answers. Hell, I use the term
inconsistently all the time.
Screw the naming, at least for the moment. I’ll try to describe the various
types of drivers that exist to the best of my ability. It’s ugly, but I’ll
do my best. If you don’t care, hit delete now.
Instead of the names, let’s focus on the attributes of Kernel Mode drivers
themselves:
1) Drivers that do not support PnP or power. These drivers create device
objects in their DriverEntry routines. They may include ntddk.h or wdm.h –
it doesn’t really matter. We’re talking NT V4 types of drivers here.
2) Drivers that support PnP (and hopefully power) that include wdm.h, and
build with targettype=driver.
3) Drivers that support PnP (and hopefully power) that include ntddk.h, and
build with targettype=driver.
4) Drivers that support PnP (and hopefully power) that include wdm.h, and
build with targettype=wdm. These are downlevel compatible to the world of
WinSE/ME.
5) All the other drivers in the world that support PnP (and hopefully power)
to the extent that they are required, and include whatever .h file their
individual architecture requires. For example, file systems would fit into
this category. As would SCSI Miniport, StorPort, Kernel Streaming, and
every other driver type we’re not addressing in 1-4 above.
Type 1’s are mostly called LEGACY drivers. You really don’t want to write
one of these today if you can avoid it. Such drivers, developed and tested
on Win2K are not guaranteed to be compatible with Windows XP or .NET server.
We have seen in this news group several such instances.
Enough about the past. Let’s look at PnP drivers. WDM.H is the preferred
api set for driver development. It is versioned. It is carefully revision
controlled, so that developers don’t get whiplash during beta cycles using
functions that are IN, then are OUT, then come back, then are gone again as
has sometimes happened in the past in NTDDK.H.
Because WDM.H is carefully revision controlled, there’s only a new WDM.H
when there’s a new version of WDM declared.
On the other hand, NTDDK.H has all the crufty legacy stuff in it. It might
change during beta cycles as frequently as with each build of the operating
system. Why are there things in NTDDK.H that are NOT in WDM.H? There are a
lot of actual reasons. But mostly, a function has been left out of WDM.H
because it’s just plain not recommended. Consider the function
MmIsAddressValid(…). This function is IN NTDDK.H, but NOT IN WDM.H. Why?
Cuz it’s almost never used right, and it doesn’t do what most folks think it
does (even though the documentation is very clear on the problem with using
it). Othertimes, functions are left out by oversight. This is why God
invented the bug report.
Sodrivers from item 2 above are those using WDM.H, which is the “preferred”
and “revision controlled” header file, for PnP-supporting driver
development. And drivers from item 3, above, support PnP but are using
other than the recommended core set of functions.
The only reason a driver would build with WDM.LIB, and thus use
targettype=wdm, are those that REQUIRE compatibility back to Windows SE/ME.
These are item 4.
Item 5 is “other”.
Now, which of the above is a WDM driver? Those described by item 1, or
those described by item 4? Who knows. In fact, I’d suggest that “WDM
Driver” is so confusing, it’s ceased to be a useful term. I think we’ll try
to ban its usage from The NT Insider…
I realize this is clear as mud, but it’s as close to reality as I can
explain it at present. And, of course, (a) it’s only MY view, and (b) it’s
subject to change.
I TOLD you it would be ugly,
Peter
OSR