Given the importance of this topic, you might rightly ask: "Why haven?t I read more about this stuff over the past year?" The simple answer is that most of the details are covered by Non Disclosure Agreements (NDA) with Microsoft. Sigh! However, because WinHEC?s sessions are not under NDA, we?re happy to be able to share with you details of the latest WDF release.
Since then, there have been very significant changes. Even the name?s been changed. Now, it?s the Windows Driver Foundation, which comprises a Kernel Mode Framework and a User Mode Framework. Hey, whatever. It?s all WDF to us.
If you remember a little from what we wrote last year, you already know that the Framework is meant to be simple, conceptually scalable, highly diagnosable, flexible and extensible. And, like I said before, it?s meant to replace WDM.
I can hear some of you now: "Microsoft is going to force some crappy beginner?s model on us, and shove us in a box, and we?ll be back to the miniport game of trying to fit 10 pounds of product differentiation into a model built to hold 5." I say: "Shut up." This model doesn?t suck, and it?s not a trivial subset driver model designed to please newbies and losers. It?s a C language, object oriented, model that takes a lot of the mundane work out of driver writing by doing the right things by default. Well, at least most of the time. And if you don't like the defaults WDF provides you, you can drop right back on down to the direct use of WDM without having to totally abandon WDF.
I?ve had time to play with WDF extensively, including some real quality time over the past couple of months. Now remember, I already know WDM from having written tons of WDM drivers. And guess what? Given my choice, I would very strongly prefer to write a driver using WDF today than write a driver using WDM. Yes, on the whole, it?s that?s good.
What?s Changed From A Year Ago?
Well, lots of the bumps have been smoothed out, for one thing. But the really big news is that WDF has an entirely new, integrated, PnP and power management model. It totally abstracts you from the hideousness that is PnP and power management in WDM. That means that if you never did get around to learning how to write a proper power policy owner in WDM, once the Framework is released you?ll never have to.
The available serialization models in the Framework have significantly changed in the past year, too. After a lot of thinking, the WDF team settled on a couple of models that either provide you serialization by default, or basically let you do your own thing.
How Cool Is It?
If you?ve been paying attention, you already know that I think it?s pretty cool. I managed to write a Digital I/O driver (a power policy owner yet) that fully supports PnP, power management, power-down on idle, and the ability to wake itself and the system from sleep, in something like 1200 lines of code. And that includes copious comments.
This is about the same size as the simplest power management implementation that I could write to support those same features. Assuming, of course, I would even dare to try to implement those features in a WDM driver (which, to be perfectly honest, I usually would not). To me, that?s already cool.
What?s ice cold is that the WDF team is still working to smooth out the rough edges. They recognize that they don?t know every type of driver that we write out here in the real world. So they?re looking to the community for feedback. Does the model work for all types of devices? Does the model meet your needs? What could be done better? These folks are serious about wanting your feedback.
So, Show Me Some Code Already!
Well, check out the detailed article A New Framework - Writing a WDF Driver and download our sample driver example and check it out. Join the WDF beta program. Write a driver or two for your own favorite devices and see if the Framework works in the ways that you need it to. And provide feedback.