Using WDK 8.1 to build drivers that can run in XP

Is anyone doing this? If so what did you have to do to make it work?

And does anyone have reasons they choose to stay with WDK < 8 for XP support?

It would be good to hear from a sampling of the developers.

>And does anyone have reasons they choose to stay with WDK < 8 for XP support?

  1. It is supported.
  2. It was already working.
  3. I did not have to go figure out how to do what you are trying to figure out.
  4. I have other fish to fry.

Good Luck,
Dave Cattley

It is fairly typical that when we make a driver that it needs to run in XP or later and be aware of protocol in the newest operating systems. For instance, new Windows 8 ioctls, structures and defines. You can’t build a driver like that in a supported way. The old kit doesn’t have the new protocol and the new kit won’t build for XP. Branching code bases and building and maintaining two sets of drivers isn’t practical. So the only realistic option is to modify either the build environment, preferably the new one since you have to use it anyway and it has other advantages like the new development environment, better optimizer, and C++11.

I don’t understand why successive DDK’s break things like this and this isn’t the first time we’ve been forced into this pickle. It seems so unnecessary and if you look back it is a real step back in technology from VxD’s. The Microsoft people really got VxD development right. You could use the very latest development kit for Win Me to develop a VxD that would load in Windows 3 and do everything you wanted in Win Me. That was perfection. The DDK for the XP lineage has been compatibility headaches every time they do this and there is no clear explanation why it was necessary to cancel development for such a critical operating system. Customers will continue to demand XP for years to come. Visual Studio 2012 still allows building apps for XP. So will Visual Studio 13. So why do we always get the short end of the stick?



Wow! This is the first time I can recall that VxD programming has been
recalled as an example of how much better driver development could be.

BIOS and DOS INTx was pretty rock’n too for forward/backward compatibility
development.

I understand your frustration to an extent. Build two drivers. That
which you can produce with the latest WDK targeting the NT6 platforms and
that which picks up the NT5 platforms. Just like VxDs, NT5 drivers *will*
die off eventually. Or are you still building in VxDCall stubs to WDM
drivers to pick up WinME compatibility too?

Dave Cattley

> Build two drivers

Doubling the number of code bases and drivers in our company is not a realistic solution.

Wow! This is the first time I can recall that VxD programming has been
recalled as an example of how much better driver development could be

It’s a perfect analogy because it sends home the message: “sad but true”!

Just like VxDs, NT5 drivers *will* die off eventually.

Of course and I can’t wait for that day. But speaking about the present, XP is still such a huge thing that Visual Studio will be supporting developing apps for it well into the future. App developers don’t need to branch their code bases, fire up an old version, and build something special for XP and something else for newer stuff like we do.

Let’s keep in mind we are not talking about withdrawing NT 3.51 support here–XP is a different kettle of fish.

If you are targeting XP, then either don’t use >XP functionality or build
two skews of your driver, one using the Win7 WDK, the other the Win 8 WDK.

You can in fact have one source code base with a lot of ugly conditional
compilation flags, and carefully chosen prefast gobbledygook, which for
some reason seems to change with every release, and just build the driver
twice.

Mark Roddy

On Wed, Sep 25, 2013 at 8:46 PM, wrote:

> > Build two drivers
>
> Doubling the number of code bases and drivers in our company is not a
> realistic solution.
>
> > Wow! This is the first time I can recall that VxD programming has been
> > recalled as an example of how much better driver development could be
>
> It’s a perfect analogy because it sends home the message: “sad but true”!
>
> > Just like VxDs, NT5 drivers will die off eventually.
>
> Of course and I can’t wait for that day. But speaking about the present,
> XP is still such a huge thing that Visual Studio will be supporting
> developing apps for it well into the future. App developers don’t need to
> branch their code bases, fire up an old version, and build something
> special for XP and something else for newer stuff like we do.
>
> Let’s keep in mind we are not talking about withdrawing NT 3.51 support
> here–XP is a different kettle of fish.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

True, in many cases the differences could be compartmentalized enough to #ifdef code blocks for the new stuff.

Regardless of what approach one takes, the next issue is going to be the testing fiasco. You must test XP with the old WLK. You must test newer operating systems with the new HCK. The WLK and HCK do not coexist. So this means we must now have 2 machines each running 64-bit windows server 2008 r2–one with the WLK controller and the other with the HCK controller. To be honest, burning even one machine was not a good situation. Now it is two.