KMDF 1.7 and the Server 2008 Vista SP1 RC1 WDK
Well, the best news of all for most WDF users is that the coinstallers in this WDK work on all supported platforms (with caveats I'm about to mention because we missed the deadlines for making them "offishul" [in the release notes])... I've been promising Ilias for weeks now as we've beaten ourselves silly trying to test this and make sure it works that I was going to say this, so here it is appropriately bolded:
Ilias made the coinstallers rock!
Well, OK, I just showed that to him, and I'm not even bruised, so I guess that passed muster... Seriously, we all put a lot of work into this in light of some of the past issues we've seen. There are a few (like the problem that prompted me to blog in the first place) that we still can't completely overcome, but even there, we give you better guidance in our output (rather than suggesting you've mismatched something when you didn't)- you should end up spending less time spinning on false alarms.
About them caveats...
OK, the first couple are unavoidable, and fall into the category of "we just plain can't fix this":
- Vista uses KMDF 1.5 inbox, and there are multiple devices (some of which cannot be disabled) using it. When you use the 1.7 coinstaller the first time on Vista, you will have to reboot afterwards, because the 1.5 runtime is in use, we need to replace it with 1.7, and by design we do not run minor versions side-by-side.
- More annoying (because you wind up thinking, "why didn't we see this one coming?") is this fact of life- if you install KMDF 1.7 drivers on a pre-Vista OS and then upgrade that machine to Vista RTM, it will initially replace the 1.7 runtime you've installed with the 1.5 runtime that is inbox with Vista. Now, all is NOT lost- the coinstaller remains, and it will eventually attempt to upgrade if your device still appears to be attached. But remember that first bullet- that requires a reboot to complete, meaning the device is still not working as setup tries to sort out what works and what doesn't.
Our testing indicates some devices will indeed survive the upgrade process, but not all. Those that don't tend to get pruned, so they will need to be reinstalled after an upgrade. I never got a good handle on which will or won't work, and it is a niche case. At least there's a workaround...
Yeah, I figured that scenario out, tested it to confirm my suspicions and while I understand it, I still don't like it. Even for 1.9 [the next great Windows OS will have it inbox] we may not be able to craft an ironclad solution- but Ilias is thinking about it, so all is not lost!
The Big Itanium "Oops"
By now many WDF users are aware of the mantra "use the free coinstaller on the retail OS, and the checked coinstaller on checked OS". Well, this is still true, but on Itanium machines running Windows 2003, due to some kinks in the build process not being totally ironed out, your handy-dandy RC1 KMDF IA64 coinstallers will gleefully install the checked version of KMDF on retail builds and vice versa. To prove we also love our UMDF users, and don't want to leave them out of the ouch, the IA64 UMDF coinstaller doesn't work at all on Windows Server 2008 [the one place it is supposed to do nothing, because you really shouldn't even need it].
But Papa has answers, and some of them you will find useful even after this temporary insanity (this is technically still beta software and not for redistribution, remember) has run its inevitable course. So, here it is:
The 1 True Papa's Guide to disassembling the KMDF coinstaller so you can get at the gooey goodness inside
Why you want to do this? So you can use free or checked KMDF runtime on systems where you can't normally install them is the best reason.
What I am telling you about is one of those "broke the seals and thus voided the warranty" sort of things. It can help you out of a jam, but if you make this a canned solution to your install processes, we will not be happy, and Papa may get his gnarled old hands slapped, ending this wealth of trivia I'm now sending your way...
- I assume you're technically adept enough to have Visual Studio or something capable of extracting resources from a binary available. If you didn't understand that, perhaps you should read something else. I'll discuss VS, assuming the folks who do it another way is plenty smart enough to figger out the gaps themselves.
- So load the coinstaller into VS using "file/open" or the nice icon with the open folder. VS will open it in resource view, which is just the way we want it.
- Examine the RCDATA resources.
- Export WDFCAB_RESOURCE, and give it a cool name ending in .cab, oh, say like wdfcab.cab ("MyKneeHasAS.cab" also works).
- Open the cab in explorer (or WinZip) and extract the EXE with the big long name- for 1.7 it's Microsoft Kernel-Mode Driver Framework Install-v1.7-Win2k-WinXP-Win2k3.Exe, but you can probably figure out which one it is if you're doing this for an earlier version (yup, this pretty much works for any of 'em so far).
- Now run that EXE with the /X command switch (this prompts you and thus lets you say where to unzip it all, you can use an additional /u if you want it dumped where it sits). If you forego a command line it will do things you really don't want done- don't go there, please!
- The wdf01000.sys and wdfldr.sys are now wherever you had it all extracted. You can copy them to drivers directory to replace the other versions, or whatever else it is that strikes your fancy.
This entry's getting a bit long, so I'll post the UMDF Server 2008 workaround separately (Want to go over the steps and make sure I got it right).
Why two posts in one day (three in one week)? Well, I'm supposed to be writing test specs for even more cool 1.9 features in WDF. So I'll practice writing on the unsuspecting public [actually, since this is to the public from within Microsoft, perhaps that's the "suspects everything, given the source" public) while my subconscious creates brilliant test designs. Yeah, that's the ticket...
"This is the time of year things slows down a bit, anyway", he mumbles, waddling off to the Starbucks machine... L8r, d00dz!
