WDF is a framework that makes it easier to write Windows drivers. NDIS is a framework for writing low-level Windows network drivers. The purposes of these frameworks overlap a bit, and some people (okay, probably many people) are confused about the relationship between NDIS and WDF. Today we’ll set down a few guidelines. But first – let’s dispel one tenacious myth.
Myth: Some people think that NDIS drivers cannot use WDF.
In reality, you can use WDF in your NDIS driver. I know this works rather well, because I have personally written several WDF-based NDIS drivers.
So where do people get the idea that WDF is incompatible with NDIS? There are a few sources of this idea:
Now that we know you can combine WDF with NDIS, let’s talk about whether you should combine WDF with NDIS. In nearly all cases, an NDIS driver will work with or without WDF. So you rarely have the decision forced upon you by the technology. Ultimately, it will come down to what you decide, based (hopefully) on a good engineering judgment call. Let’s collect some evidence to help you make that decision.
Generally speaking, it’s a good idea to consider WDF. But there are a few reasons why WDF might not be very useful to your NDIS driver:
Mind you, it’s still quite possible to link against WDF in these situations. But you’ll probably find that there aren’t a lot of opportunities to actually use WDF APIs. Integrating with WDF doesn’t give a lot of value if you don’t call its APIs. In those cases, the pragmatic engineering decision may be to just not use WDF.
Okay, so let’s suppose you’ve decided to give WDF a spin. You’ll eventually notice that WDF overlaps somewhat with NDIS. For example, both frameworks have APIs for workitems (NdisQueueIoWorkItem versus WdfWorkItemEnqueue). Which API should you use? Again, in many cases, either framework’s APIs will work. Again, it’s an engineering decision that ought to consider several factors, including maintaining consistency with your other code, etc. But if you are new to NDIS and WDF, you can use this quick-reference table as a starting place for your decision-making process.
Remember, the above table only contains guidelines. It is still acceptable to ship a driver that uses an API marked "Avoid". You should use the table to help nudge your decision-making when you have no other compelling reasons to use a particular API family.