by With its unique C++ syntax and its “charming” COM programming pattern, UMDF has largely been ignored by the Windows driver development community. But the arrival of UMDF V2 could change all that. With a C Language interface that shares the same syntax as KMDF, UMDF V2 promises to be a useful option for developers. But is it any good? And if so, what’s it good for? What are the main attractions of UMDF V2? What are its restrictions and limitations? In this video Scott and I answer these questions. We give you the run down on — and of course our opinions of — UMDF V2, the new user-mode driver development option.
Stay tuned: More videos are on their way over the next few weeks!
Prefer Reading to Watching?
Interested in what Peter and Scott think, but hate watching videos? Video blocked in your current location? Here’s a transcript of their conversation:
Peter: We should talk a little bit about UMDF V2, because it’s another thing that people have been asking us a lot about. Given that people already know what we think about UMDF version one…
Scott: Which is not very much!
Peter: We don’t think about it very much because we don’t like it. So, we should probably tell them a little bit about what we think about UMDF V2.
Scott: UMDF V2 is certainly UMDF V1 should have been.
Peter: That’s right.
Scott: What we thought it would be, even, originally: “Write one driver using one set of APIs, compile it in user mode or compile it in kernel mode.”
Peter: That’s right. So we should say for the record that UMDF V2 syntax is essentially the same as KMDF but it gets you new features, right?
Scott: Yep.
Peter: It runs in user mode, which means that when you deref a null pointer it’ll cause your driver to die, but the whole system doesn’t crash.
Scott: Restart the service, instead of restarting the system.
Peter: That’s right, and in fact the service automatically restarts.
Scott: The system does that too…. Peter: (laughs) Sure, the system automatically restarts.
Scott: Yeah.
Peter: Exactly, exactly. UMDF V2, they’ve actually now made the debugging support on a par with what we’ve had for ages with KMDF.
Scott: We’ve got the in flight recorder. Yay!
Peter: Yay! We’ve got the WDF log!
Scott: Yes. Peter: The syntax is pretty much the same [as the syntax in KMDF], but there are some limitations and a couple of little differences.
Scott: It’s in C!
Peter: Yay!
Scott: Not God forsaken C++ COM… (it’s not the bad COM though)
Peter: …derived from IUnknown. Yuck.
Scott: Yeah.
Peter: [With UMDF V2] it’s easy to go from KMDF to UMDF even back to KMDF.
Scott: Dump your KMDF driver! Death to KMDF! [sarcasm]
Peter: No no no no no no! It’s got some very specific uses. For example, it’s very good for writing drivers for USB type devices. Anything really where performance isn’t super critical.
Scott: And when you have to build a structure that describes your operation and then send it. Why build it in kernel mode and send it when you could just as easily build it in user mode and send it?
Peter: Yeah. One thing that most people aren’t aware of, and actually takes people by surprise, is that you can actually talk to hardware devices with UMDF V2. Programmed I/O device only, you don’t DMA support, right? You can actually read and write registers, and you can even take interrupts.
Scott: Shocking!
Peter: So, any time that you don’t have something that’s performance critical, or the latency isn’t really critical, because as you can imagine if your device interrupts, the way UMDF passes that interrupt to user mode it simply cues a DPC from the DPC it schedules a work item, and when that work item runs, it calls your ISR. So I mean, it’s basically running like any other user thread. Although it is real time priority. Let’s look at some of the limitations, right? So, we already said no DMA.
Scott: Yep.
Peter: No bus drivers is another one, right? No Method Neither I/O, which means no in-caller context Event Processing Callback. No escapes to WDM in general.
Scott: Go figure.
Peter: Direct I/O in UMDF V2 is weird too, right?
Scott: Yeah. Please give me direct I/O…
Peter: If my buffer is greater than this size…
Scott: …but if you don’t that’s okay.
Peter: So it’s really only a suggestion.
Scott: Yes.
Peter: There is one ultimate limitation.
Scott: 8.1 and later only!
Peter: Right. UMDF V2 runs on Windows 8.1 only.
Scott: That’s a limitation? [sarcasm]
Peter: Not a limitation if you’re writing drivers like, for Windows phone. But aside from that, most people in the real world have to write drivers that work on all the way back to Windows 8, and oh my God, even Windows 7!
Scott: Wow! My goodness.
Peter: Ancient! [laughing; sarcasm]
Scott: Ancient, yeah! That certainly narrows the field quite a bit. Like oh, you get people on board [with using UMDF V2]: Yeah, sure! You can do your programmed I/O, USB, you’ll crash your service and you won’t crash the system. Oh this sounds great!
Peter: Awesome!
Scott: Except.. You only care about 8.1 and later, right?
Peter: Uh, no.
Scott: The nice thing though is that, with the shared syntax, depending on what you’re doing, for many drivers you can pretty easily transition it from a KMDF driver to a UMDF V2 driver.
Peter: Yeah, but why would you want to do that?
Scott: Well, think about doing something like a test harness.
Peter: Uh huh.
Scott: So you could have a test harness that exercises your driver in user mode.
Peter: Yeah.
Scott: Or rapid prototyping.
Peter: Yeah.
Scott: Sure, your customers care about Windows 7 and later. But during your initial development process you don’t want to have to reboot your target machine all the time.
Peter: And now that the debugging tools don’t suck…
Scott: …and you can do everything through Visual Studio. And it’s all, it’s all in user mode.
Peter: Yeah… You do it through Visual Studio anyways, don’t you
Scott: Didn’t we already talk about that?
Peter: We did.
Scott: So you have hat nice user mode development environment with all of your user mode tools. You can have a familiar development environment while you’re getting up to speed in drivers, and while you’re getting your initial code written.
Peter: Yeah.
Scott: And all that code isn’t just throw away.
Peter: All in all, UMDF V2 is not bad, and could be pretty helpful. Now all we need is support [for UMDF V2] on earlier versions of Windows. So this is Peter!
Scott: And this is Scott!
Peter: See you later.
OSR Open Systems Resources, Inc.