“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> The OP’s problem has occurred on this list at least a dozen times, and
> the recommended remedy, (that is the correct recommended remedy,) is to
> use ntddk.h.
>
Yes, I agree completely… and I said this in my reply to you and in my
reply to the OP! This is ESPECIALLY true if we’re talking about NEW
functionality.
On the other hand, how many times on ths list have we had to answer “Why
doesn’t my call to HalGetBusData(ByOffset) work on XP the way it worked on
NT V4?” That’s another example of a function that’s in NTDDK.H but not
WDM.H – And it’s not in WDM.H for a reason, right? Caveat driver writer.
I agree that it IS very confusing. As Windows evolves, things change.
Let’s all hope that along with the promise of a bright shiny new future O/S
version, Microsoft will grant our wish for a clean, yet comprehensive,
version of WDM.H.
Peter
OSR
Daniel Simard wrote:
It looks very not clear to me as a simple kernel developper engineer. I
think Microsoft should clarify those things meanwhile you have convince me
to recommand our group here to move to ntddk.h since we need a lot of
missing functions into wdm.h. We have tried to stick to the rules stated
by the DDK help, but clearly this was not right.
Personally, I build my drivers using ntddk.h and go to some trouble to
maintain backward portability by judicious selection of which DDIs I
call. For whatever reason, most of my consulting clients want support
back to 98 Gold, which is a big part of why I keep adding new things to
WDMSTUB.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
So what is wrong in using both? If I am not mistaken, it is quite possible
to use WDM in one or more source modules and NTDDK in one that then provides
the functionality relegated to NTDDK. I do know that I have done this with
SCSIPORT.
–
Gary G. Little
Seagate Technologies, LLC
“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
> >
> > The OP’s problem has occurred on this list at least a dozen times, and
> > the recommended remedy, (that is the correct recommended remedy,) is to
> > use ntddk.h.
> >
>
> Yes, I agree completely… and I said this in my reply to you and in my
> reply to the OP! This is ESPECIALLY true if we’re talking about NEW
> functionality.
>
> On the other hand, how many times on ths list have we had to answer “Why
> doesn’t my call to HalGetBusData(ByOffset) work on XP the way it worked on
> NT V4?” That’s another example of a function that’s in NTDDK.H but not
> WDM.H – And it’s not in WDM.H for a reason, right? Caveat driver writer.
>
> I agree that it IS very confusing. As Windows evolves, things change.
> Let’s all hope that along with the promise of a bright shiny new future
O/S
> version, Microsoft will grant our wish for a clean, yet comprehensive,
> version of WDM.H.
>
> Peter
> OSR
>
>
>
>
Just copy/paste the prototypes of queued spinlock routines from NTDDK.H to some
header of your own.
Then continue working with WDM.H.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Daniel Simard”
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 11, 2003 9:51 PM
Subject: [ntdev] Re: Missing functions into wdm.h ?
> I want to use the queued spin lock, but they are not available in wdm.h. I
> can’t include both ntddk.h and wdm.h, and since I code new WDM drivers I
> should only have to include wdm.h. Is it a bug int wdm.h or what ? Is
> there another solution to get access to those functions wihtout including
> ntddk.h ? What about KeGetCurrentProcessor ?
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> Hmmmm… Well, look: *I* don’t personally recommend you build with
DRIVERTYPE=WDM. Just leave it out. Since you’re targeting XP and later,
Really? This governs -driver:wdm linker switch, which in turns governs the .SYS
image header bit.
This bit can be important for the OS.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Max,
That can lead to a hell of a headache later one when the project changes
hands. If the original structures change in later SPs or releases, a new
engineer supporting the code can have problems figuring out why things go
bump in the night. Even documenting the fact they need to be refreshed with
new releases will not
totally eradicate such problems. Besides that was already proposed and shot
down by the Big Dogs. 
–
Gary G. Little
Seagate Technologies, LLC
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> Just copy/paste the prototypes of queued spinlock routines from NTDDK.H to
some
> header of your own.
> Then continue working with WDM.H.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Daniel Simard”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, September 11, 2003 9:51 PM
> Subject: [ntdev] Re: Missing functions into wdm.h ?
>
>
> > I want to use the queued spin lock, but they are not available in wdm.h.
I
> > can’t include both ntddk.h and wdm.h, and since I code new WDM drivers I
> > should only have to include wdm.h. Is it a bug int wdm.h or what ? Is
> > there another solution to get access to those functions wihtout
including
> > ntddk.h ? What about KeGetCurrentProcessor ?
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> > Hmmmm… Well, look: I don’t personally recommend you build with
> > DRIVERTYPE=WDM. Just leave it out. Since you’re targeting XP and
later,
>
> Really? This governs -driver:wdm linker switch, which in turns governs the
.SYS
> image header bit.
> This bit can be important for the OS.
>
What do you mean “can” be important?
If you mean that it COULD be important for NT-based systems, but it isn’t,
then I agree with you.
To this day, I have never shipped a driver that was not destined for
Win98/me/se with DRIVERTYPE=WDM. Trust me on this one…
Peter
OSR
Peter Viscarola wrote:
If you mean that it COULD be important for NT-based systems, but it isn’t,
then I agree with you.To this day, I have *never* shipped a driver that was not destined for
Win98/me/se with DRIVERTYPE=WDM. Trust me on this one…
The switch is one of two clues that are used in different parts of the
kernel to decide whether a driver is a legacy driver or not. The other
clue is whether DriverEntry sets an AddDevice pointer. Since different
places in the kernel use different tests, it can be important in some
cases that both indicators be consistent. This bit me very hard one time
when I needed to dynamically load a driver – trust me that I had a good
reason for doing it.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> The switch is one of two clues that are used in different parts of the
> kernel to decide whether a driver is a legacy driver or not. The other
> clue is whether DriverEntry sets an AddDevice pointer.
>
On this we at least partially of agree. But, in this case, we must define
“legacy” to mean "a driver that has DRVO_LEGACY_DRIVER set in its
DriverObject->Flags word (this define appears in NTDDK.H).
Having this flag most CERTAINLY does NOT mean that this driver does not
participate in PnP or power management, like an NT V4 driver, which is what
I think most people mean when they say “legacy driver.”
>Since different
> places in the kernel use different tests, it can be important in some
> cases that both indicators be consistent. This bit me very hard one time
> when I needed to dynamically load a driver – trust me that I had a good
> reason for doing it.
>
I have never had that experience, and I’d like to know the situation in
which a driver that was not built with DRIVERTPE=WDM was prevented from
loading dynamically. I’d suggest that is a bug in Windows.
[Let’s take this off line… I’ll get back to the list with the ultimate
answer.]
Peter
OSR
“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
> [Let’s take this off line… I’ll get back to the list with the ultimate
> answer.]
>
Walter and I discussed this a bit off-list.
We agree that neither of us has ever seen a CONVENTIONAL windows driver that
was built without DRIVERTYPE=WDM that can’t be loaded dynamically by the
system.
Walter strongly urges people to be consistent in their settings and use
DRIVERTYPE=WDM where appropriate.
On the other hand, neither has my advice changed: Leaving out DRIVERTYPE=WDM
is perfectly appropriate for drivers that are not destined for use on
Win98/me/se. To this day, nobody at OSR has EVER written a driver with
DRIVERTYPE=WDM for use on an NT-based system. There is nothing in my
discussion with Walter that leads me to believe that there’s any reason to
change this practice.
Peter
OSR
>
Just copy/paste the prototypes of queued spinlock routines
from NTDDK.H to some header of your own. Then continue
working with WDM.H.
Yeah that gets you the worst of all possible worlds! Whatever benefit you
were getting from using wdm.h to start with is now lost, plus you have just
committed the cut’n’paste error, thus being nearly certain to achieve
incompatability with future releases of the ever changing ntddk.h.
When you get to the absurd point of having to cut’n’paste from ntddk.h in
order to avoid ‘using’ ntddk.h, isn’t it a bit of a simpler approach to stop
avoiding ntddk.h?
> Walter strongly urges people to be consistent in their settings and use
DRIVERTYPE=WDM where appropriate.
Maybe we would ask MS what DRVO_LEGACY_DRIVER flag does?
DRIVERTYPE=WDM updates the build environment paths, and also adds a -driver:wdm
linker command line parameter, this sets the bit in the PE binary header, which
causes DRVO_LEGACY_DRIVER to be reset in the driver object later.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com