If you're like most sane people, you've probably been pretty much ignoring the whole Vista thing until now. However, now that RC1 (and a follow-on update) has shipped, giving some brain bandwidth to your drivers on Vista is pretty much mandatory. Afraid you've missed some key Vista info? Wanna sound like you actually know what you're doing when grilled by your marketroid? No worries, your friends here at OSR have you covered.
So, without further ado and in no apparent order, here are the ten most important things that any driver dev needs to know about Windows Vista:
1. By default, users now have almost no privs.
Unlike in previous Windows releases, where users typically had administrator privileges, Vista has a feature called "Least-privileged User Account" or LUA for short. You'll also see this feature referred to as "User Account Controls" or UAC. With this lovely feature, any time you try to do something that requires privilege (like, ah, install a driver) you're prompted with a pop-up saying, in effect, "Do you really want to do this??" (See Figure 1)
I'm sure somebody wants this feature, though I can personally attest that it's annoying as hell for a dev. The good news is, you can just turn it off. Hector found out how. Check out his memo from April of this year: "Disabling User Account Control on Vista".
Figure 1 - Yes, I Really Want to do This... |
2. By default, there's no Administrator account.
And even when there is, you can't log into it because it's been disabled. Fortunately, you can enable it from the MMC-based Computer Management section of the Administrative Tools Control Panel. To make it work, be sure to disable all other user accounts that have admin privileges as well.
3. The DDK is now called the WDK.
Pretty much the same stuff for driver devs (but not testers, see the next item!) but with a different name.
4. The HCTs have been replaced.
In case you care, the HCTs have been replaced with a new set of tests and a new testing framework called the Driver Test Manager. Community-wide, the jury is still out on whether this is a good thing. But, we can tell you that the HCT's were old, crufty, badly documented, awkward, unsustainable, and intensely annoying. At least DTM provides a new platform on which Microsoft can build cool stuff in the future.
5. You don't use boot.ini on Vista anymore.
You say you want to enable debugging in Vista? Or perhaps you want to specify an alternate kernel and HAL image? Well, you don't do this by editing boot.ini anymore. Now, you have the privilege of using the BCDEDIT utility. And you're particularly lucky, because we've included a "how to" about BCDEDIT in this issue of The NT Insider ("Tooling Around with Vista").
6. DbgPrint and KdPrint aren't displayed by default in the debugger.
This is one Hector actually warned us about two years ago. It seems that, in a quest to reduce debug spew, ordinary DbgPrint and KdPrint commands are turned into DbgPrintEx commands using the "default debug print filter." Check out Hector's memo on this topic for how to enable your debug output: "Getting DbgPrint Output To Appear In Longhorn".
7. You have to digitally sign your driver package, and perhaps your .sys file, to run on any Vista x64 system.
No, this doesn't mean that you have to submit your driver to WHQL for testing. What it means is that your x64 driver package will have to be signed with your organization's Class 3 Code Signing Certificate to be able to install it. Further, if your x64 driver starts at boot time, the driver image itself (the .sys file) will have to be signed. While there are ways around this for testing, there is no way to permanently disable this "feature" on an x64 Vista system. You can read about this program, and the process of actually signing your drivers, on Microsoft's WHDC website: http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx-- and in Hectors lastest Memo on this topic. Just one more caveat: To avoid going insane, you'll want to be sure that you're using the absolute latest version of the signing tools and certificates.
8. You can now write USB drivers in user-mode.
The release of Vista marks the official release of the User Mode Driver Framework (UMDF). Based on a highly simplified COM model, this incredibly clever framework actually lets you write user-mode code for USB-type devices using function calls that are very similar to those implemented by KMDF. And, no... the performance doesn't suck. Unless you spend your entire life coding in kernel-mode, we recommend you give UMDF a try for your next USB-related project.
9. You can't just WHQL the 32-bit version of your driver.
This is one of the most amazing things that I've heard to date about Vista. If you want to submit your device/driver to WHQL for testing, you must submit an x64 driver. You can submit just an x64 driver, or you can submit an x64 driver along with a 32-bit driver. But no 32-bit only driver submissions will be accepted. Good news for x64 adoption. If you haven't done so already, start porting!
10. Technical Changes? Few.
I guess it's good that this is number ten on our list. When it comes to significant technical changes for driver devs in Windows Vista, there are few. Yes, the display architecture has changed again. But you know we barely acknowledge the existence of display drivers here in The NT Insider anyhow. And yes, there are a bunch of new NDIS models and features. But most of these are still "optional" or "recommended." Obviously, if you work in the network space, you'll want to check these out. If you write WDM drivers, the most significant technical changes that you'll have to deal with are those to Power Management. And those changes are all for the better. Check out our previous article from The NT Insider titled "Power Management Changes in Vista".
How Did We Do?
Did we list the Vista items that are most relevant to you as a driver dev? Add to the list! Tell us your top items in Windows Vista that your colleauges need to be aware of by leaving a comment below.
Post Your Comment
