by It took “a while” but, without any fanfare, sometime in May of 2022, Microsoft released a version of the Windows Driver Kit (WDK) that supports Visual Studio (VS) 2022. This version is referred to as the Windows 11 Version 22H2 WDK. This new version of the WDK is only support on VS 2022. It cannot be used with VS 2019.
Support for VS 2022 is a good thing. Given that many (if not most) Windows driver developers these days often also write some sort of application code, having one tool chain that supports both jobs is both useful and most welcome. There are some nice new features in VS 2022, including native 64-bit support (for the IDE itself) and support for C++ 20.
But, alas, there are a few surprises lurking in this most recent WDK release. Specifically:
- No support for building drivers that target any Windows version before Windows 10. This means that it’s no longer possible to use the latest WDK to build drivers that support Windows 7 or Windows 8, or Windows 8.1.
- No support for building 32-bit drivers, for any platform, x86 or ARM, or for any OS version including 32-bit Windows 10.
These new restrictions will come as unwelcome news to many in the driver development community. Microsoft can wish what they want, but it is beyond question that there is still a significant installed base of Windows 7 and 32-bit Windows systems. Remember that only a couple of years ago (2020) Microsoft was still building, releasing, and supporting 32-bit version of Windows 10. That means there are lots of companies that need to be able to update the drivers for their hardware or software (I’m looking at you, file system minifilter people) on those systems.
Microsoft would have us continue to use the “old” Windows 11 WDK hosted on VS 2019 to build drivers for the platforms that are no longer supported. And, yes… as long as that works, that is a possible way forward. Microsoft assures us that “side by side” (SxS) installation of the VS 2019 and the old Windows 11 WDK and VS 2022 and the new Windows 11 22H2 works, and is supported.
You’ll have to excuse me if I’m a bit skeptical of this claim. Our experience here at OSR with using SxS VS and WDK installs hasn’t exactly been without pain. Heck, for the last few releases, nothing about using the WDK has been without pain. But, we’ll leave that alone for now.
If you’re wondering why Microsoft made these decisions, maybe I can help explain. As you probably know, the WDK is built as part of the Windows build process. In fact, the key header files (wdm.h, ntddk.h, and ntifs.h) are actually “synthetic” files that are created during the build process. These files are composed of extracts from actual, native, Windows OS header files. As you a probably also know, Microsoft is no longer building 32-bit versions of Windows. No Windows dev, when working on the kernel (let’s say) is going to worry about getting the 32-bit defines in the native headers correct, when there are no more 32-bit OS builds being produced. Telling them “the WDK needs this” only goes so far. That means, from a practical standpoint, there’s really no way for anybody to ensure that the 32-bit versions of the WDK header files still work. At least, not without doing really exhaustive and comprehensive testing of real drivers on old 32-bit builds of Windows. That’s complicated, fraught with difficulties and dangers, and not really practical. So, however painful it might be, I totally don’t blame the WDK team for dropping support of 32-bit driver builds.
While the decision not to support 32-bit drivers with the latest WDK is understandable, I think that it’s still likely to cause the driver development community a great deal of pain. Even if you ignore the ancient OS versions, there are a lot of 32-bit Windows 10 systems running out there in the world. OEMs and IHVs will certainly hear from their customers if they just stop fixing bugs on these platforms.
When it comes to no longer supporting Windows 7 as a driver target for 64-bit drivers, I’m afraid that I’ve got no really satisfying explanation. I suspect that it simply comes down to: “Well, if folks will need to have a separate WDK/VS installation to be able to build 32-bit drivers, then they can just as well use that to build their drivers that target both 32-bit and 64-bit Win7 and Win8 and whatnot.” While this decision does not exactly fill me with “undiluted pleasure”, I’ve got to say that if this was the team’s thinking, I sort of get it. It doesn’t make me happy. I’m not sayin’ they should have done it. I’m just saying… I understand.
Where does this leave us, fellow community members? It leaves us having to make some decisions:
- Do you have technical reasons why you need to use VS 2022? Other projects that require VS 2022? Do you lust for the new VS 2022 features? If so, and you still need to support those 32-bit or Win7/Win8/win8.1 targets, you’re going to need to live with a SxS install of VS 2019 and VS 2022 and the most recent versions of their associated WDKs. Hope for the best!
- Or… do you still need to support Win7/Win8/Win8.1 and 32-bit targets… but you can forgo updating to the latest and greatest version of VS. In this case, you can just continue to live with VS 2019 and the older WDK. No risk, no problem.
But wait! We might have an even better option for you: Consider upgrading your VS development environment (and WDK) to VS 2022 and the 22H2 WDK, and building your drivers for 32-bit or down-level OS versions using the Enterprise WDK (EWDK). This option leaves relieves you of any potential problems maintaining a SxS VS/WDK environment might bring. The only “cost” in terms of usability is that the Enterprise WDK only allows you to build from the command line. But, heck, that’s no big deal (you still use MSBUILD and Solution and Project files). And yes, you can still download older version of the EWDK.
If you have other experiences or observations to share about the VS 2022 and the new 22H2 WDK, we’d love to hear about them. Head on over to our Community site and post something there.
OSR Open Systems Resources, Inc.