The Windows driver world changed on 5 December 2005 when Microsoft released the first version of the Windows Driver Foundation (WDF) Kernel Mode Driver Framework (KMDF).  Since that time, the User Mode Driver Framework (UMDF) has joined the pack and KMDF has received a couple of small revisions.

As a result of these changes, a new Windows driver writer is faced with an interesting problem: Can you be a competent driver developer if you just learn WDF, or do you still have to expend the effort required to learn all the details of WDM?  Mike Kemp of Sintefex Audio, an experienced WDM driver developer working in the audio space who wanted to know how to advise a colleague, raised precisely this question on our NTDEV list recently.  And that's the question we'll answer in this article.

Non-Trivial
When WDF was first being conceptualized, everyone involved dreamed of creating an entirely new abstraction for driver development.  The goal was nothing less than creation of a model that would decouple driver development from the pains of WDM forever!   However, reality -- and the constraints imposed by time, resources, managers, and the need to work within the framework of an existing operating system -- intervened.  In addition, the Windows driver development community injected a few key requirements.  For one, the community was adamant that the new architecture must not limit the types of drivers or solutions that could be created.  This posed a significant challenge to the WDF designers.

When the WDF architecture was ultimately revealed, it comprised a useful abstraction that mostly sat on top of WDM. In the end, WDF did not supplant WDM so much as add to it.  Thus, the answer to the WDM versus WDF question isn't immediately obvious or trivial to discern.   If WDF itself uses WDM, does everyone still need to learn WDM or can a new dev really "get by" with learning just WDF?

It Depends
One reason that the M versus F question is so difficult to answer is that driver developers comprise an exceptionally varied community.  Just a few years ago, it was not uncommon for a driver developer to specialize, exclusively, in the design and development of Windows drivers.  More recently, in the rare case that a software engineer is just a driver dev, it's more common than not for that person to be responsible for writing drivers for their company's products on multiple operating systems. Mostly, however, driver devs these days work on drivers for only part of their time, and spend the rest writing code in user mode.

Not only are driver developers varied, but so are the companies for which they work.  Some companies view driver development as a necessary evil on the road to release of their product. Developing a driver for them is just one more annoying but necessary step in the process, much like FCC or CE certification.  On the other hand, for some companies the driver provides a critical part of their product's value.  For these companies, functionality or performance are critical, differentiating factors.

All these factors bear on the decision as to whether learning WDF is "enough" or detailed knowledge of WDM is "required."

Bear in mind that in this article we're absolutely not addressing the question of whether an experienced Windows driver writer should use WDF or WDM to write a driver for their device.  The answer to this question is simple: If you can use WDF, you should use WDF.  Here at OSR, we don't write device drivers using WDM anymore.  I've called PoRequestPowerIrp for the last time (Insh'Allah).  So, it's not about what you should use if you know both, it's about what a newbie needs to learn.

Some Guidelines
As you can see, we've thought long and hard about this problem over the past couple of years.  As we designed our WDF seminar, we needed to consider what concepts from WDM we needed to include.  Because we're not about giving people surface-level knowledge, or providing cookbooks, we wanted to be sure we "did the right thing" by students who learned KMDF and UMDF.

So here are some guidelines we developed:

1. If you need to write file systems or file system filters, forget you've even heard of WDF.  Sorry, you've got to learn all of WDM and then all about the world of Windows file systems.  Good luck, you've got a long row to hoe.  Stop reading here.  Have a nice day.
2. If you need to write video, audio, most types of network or storage adapter drivers, there are specialized driver models that apply to you.  WDF may be useful for filters in your stack, or for special purposes, but you're going to have to learn the specific driver model and interface that Windows uses to support your device.  Because WDM is the underlying technology for all Windows drivers, learning the basics of WDM will enhance your understanding.  But learning and using WDF by itself is pretty much not an option.
3. If you need to write drivers for printers there's a special model for you, too, and I have no idea what it is.  But it's not WDF.  I think it's some user-mode thing.  Anyhow, if you're a printer driver developer you're not reading this article anyhow.  Or, if you are, please give this issue back to the person from whom you stole it.
4. If you need to maintain or enhance an existing WDM driver, you're going to have to learn WDM in the short term.  In the long term, consider learning WDF and re-writing the driver if at all possible.  Your boss will hate the idea, but when you finally do it you'll be the hero of your company due to the decrease in bug reports.
5. If the performance (or resource utilization) of your device is ultra-critical, you'll probably have to learn WDM.  I'm not saying the WDF isn't performant.  Rather, I'm saying that in order for you to be able to make the best possible trade-offs when it comes to optimizing the performance of your device and driver, you're going to need all the architecture and I/O subsystem knowledge you can get.  And that means you're going to have to learn WDM.
6. If you don't fall into any of the previous categories or...
7. You need to write a filter driver to modify or add-value to the behavior of (most any) device stack in Windows.

You're in luck, because it's very possible that learning WDF (accompanied by a few, basic, Windows O/S and WDM concepts) will be sufficient for you!  It's likely that the majority of drivers written for Windows fall into these last two categories. Think about it: HID filters, storage filters, drivers for most USB devices, SDCard devices, industrial control devices, and lab peripherals.  And you can write drivers for these devices extremely well by concentrating only one WDF.

However, there are a few other limitations that need to apply to ensure that learning WDF alone will be sufficient for your needs:  Your device needs to be relatively simple, your driver needs to follow a well-established programming pattern, there needs to be a good WDF sample for you to start with, and you better not need to do too much in-depth debugging.

Why the limitations?  To do a good job when your driver or device doesn't meet the limitations, you'll probably have to augment your WDF knowledge with some significant understanding of WDM.  So, if you have a complicated DMA device or a device that can process multiple simultaneous requests in strange combinations, you'll probably still want to use WDF for the driver... but you'll also probably need to learn the details of WDM.

Another fact that often surprises new Windows driver devs is that any serious debugging of a WDF driver often requires a good working knowledge of WDM.  This is because delving down to the WDF layer alone won't always get you the answers you need.  Remember, we said that WDF was based on WDM.  So, learning WDM will always be a "nice to have" even for a WDF developer.

So, What's a Newbie To Do?
In almost all cases, a newbie should start by learning WDF along with a few key WDM concepts.  Read Russinovich and Solomon for a decent background in Windows OS concepts, and then go write a few WDF drivers.  They don't have to be complex.  Just be sure you make them work.  By doing this, you'll get a good grasp on the fundamental issues of managing user buffers, dealing with a device, debugging in kernel mode (unless you use UMDF exclusively) and working with the Windows I/O Manager.

When you've mastered the WDF basics and you want to, and have the time to progress further, that's the time to tackle WDM.  You'll find WDM a heck of a lot easier to understand -- and less burdensome -- once you have a practical understanding of the flow of control in your driver, serialization issues, and the flow of I/O requests in the system.  By learning WDM after WDF you'll also know which parts of WDM you can safely ignore in favor of WDF's abstractions (like, most of power management).

Then again, if you're a newb that's stuck working on an existing WDM driver (or, heaven forbid, a file system), there's no reason to despair.  Sure, WDM is harder, but it's also more powerful.  By learning WDM first, you'll have a solid grasp of Windows fundamentals.  And when you do get the chance to learn WDF, you'll find the concepts quickly "drop into place" and make driver writing a shorter, simpler, pleasure.