Can you hear it? It’s the drumbeat that says “forward, onward, upgrade to newer/faster/better/newer/newer/newer.” There’s no place this drum beat is louder than in Redmond, Washington.
I’m sure you’ve read that Windows XP (SP 3, to be specific) will be reaching the end of its super-duper double secret Extended Support as of April of this year. But did you know that XP has been out of what’s called “Mainstream Support” since 2009? And, for both people who installed it, Mainstream Support for Windows Vista ended sometime in 2012. Heck even support for Windows 7 RTM (with no service packs) ended last year in 2013.
I get that support has to end sometime. All good things must come to an end. And I get that Windows XP RTM’ed in 2001, and XP SP3 was released in 2008, two years after Windows Vista.
Here’s the problem, though: Lots of people are still running Windows XP. Lots and lots of people. How many? ZDNet (an authority second only to Wikipedia) says that between 25 and 33 percent of all the world’s desktops are still running Windows XP (http://www.zdnet.com/windows-xp-what-to-expect-once-microsoft-shuts-down-support-7000025348/). Why? Probably because XP works perfectly well for the purpose it’s used and the environment that it’s being used in. Heck, I’ve got a computer at home that I use as part of an amateur radio system that still runs XP. It runs very well, too, thank you very much.
You’re probably wondering why I’m pontificating on this topic. I write system software. Who cares about XP, right? Let me answer that for you: Our clients care about Windows XP. And not because they have amateur radio setups that use it, either. Our clients care because their customers care. That means our clients make supporting Windows XP our problem.
So if OSR writes a driver in many cases (not all, mind you, but many) the client will want that driver to support Windows XP or Windows Server 2003. Heck, we just finished designing and implementing a complex piece of storage monitoring software that had to work on Server 03 and later.
But we’ve got KMDF and we can always just ship that latest co-installer and we’re good to go, right? The most recent rev of KMDF is V1.13, so we can just use that. Well, wrong. This is where it gets sticky.
The Windows 8 WDK only supports building drivers targeted at Windows Vista and later. The Windows 8.1 WDK only supports building drivers for systems running Windows 7 or later. OK, so using the 8.1 WDK and losing Vista support is no big loss…who cares about Vista. The problem I’ve discovered is people DO still care about Server 2008.
So if I want support for Windows XP, I have to use the Windows 7 WDK. And the WDK for Windows 7 only supports KMDF V1.9. What’s worse is that the Windows 7 WDK uses the old sources/dirs method of building driver projects. Starting in Windows 8, the WDK uses the new driver development environment that’s integrated with Visual Studio and does not support the old sources/dir projects. So, if I need to support Windows XP I need to go old school and create sources and dirs Files and use the Windows 7 WDK. Later, if my client or I want to upgrade that driver, we’re going to be stuck using the same ancient build environment or upgrading the driver project to a new, Visual Studio integrated, WDK … but then you lose XP support. You can’t win, basically.
Note that the problem is similar (though not as bad) if you need to support Windows Server 2008 and later. You’re stuck using the Windows 8 WDK. However, in this case – assuming I understand this right, I haven’t successfully gotten it to work – you’re supposed to be able to upgrade your driver project so that it works with both the Windows 8 WDK using VS 2012 and the Windows 8.1 WDK using VS 2013. That’s not convenient, but it’s not great either.
And don’t even ASK me about trying to support a single binary that uses up-level features on OS versions where those features are available. This used to work. I know, I was part of the (then DDK, not WDK) team that helped spec and test it. But today? I sure haven’t gotten it to work, I’ll tell you that.
Last, I want to whine about my new friend, UMDF 2.0. It’s a new Framework that’s provided for the first time in the Windows 8.1 WDK. It’s cool because it uses almost exactly the same syntax as KMDF 1.x – and that’s just about the best idea since chicken and waffles. As a result, you can try running your driver in user-mode, and if you don’t like its performance… you can move it to KMDF and run it in kernel-mode with a trivial amount of effort. Awesome! What’s not to like, right? Well, there’s this one thing: UMDF 2.0 is only supported on Windows 8.1 and later versions of Windows. So its use is going to be limited to very particular and special cases.
I know time marches forward, but as of today there are few companies who will target their drivers to only Windows 8.1 and later. I dunno… maybe for my birthday Microsoft will start supporting UMDF 2 on older operating systems. Now, that would be cool. Especially if they’ll support it back to XP. Hey, if I’m going to dream, I might just as well dream big.
Peter Pontificates is a regular column by OSR Consulting Partner, Peter Viscarola. Peter doesn’t care if you agree or disagree with him, but there’s always the chance that your comments or rebuttal could find its way into a future issue. Send your own comments, rants or distortions of fact to: PeterPont@osr.com.
OSR Open Systems Resources, Inc.