If you thought that big changes in the Windows driver arena were complete with the release of the Windows 8 WDK (which for the first time includes integration with Visual Studio)… you'd be WRONG.
The WDK Team continues to surprise and amaze us by making our most profound wishes true. The latest news, announced at the //Build conference, is UMDF V2. This is a new version of UMDF that uses exactly the same syntax and supports most of the same features as KMDF. Now you can choose to develop your USB driver (if you even NEED to write a USB driver, more about that in another post) using UMDF and if you decide you don’t like the performance or whatever… just move the driver to KMDF without few changes to the syntax of the driver.
Yup… About 90% of the code is the same between UMDF and KMDF: The syntax is the same. The structure definitions are the same. The Queues work the same way. YAY! I’ve been asking for this level of compatibility since, well… to be honest… since UMDF was first on the drawing board.
Not only that, but debugging for UMDF drivers is now much enhanced and on a par with that for KMDF. There’s a fully featured set of UMDF debugger extensions, and the “in flight recorder” that makes KMDF driver debugging so much easier is now available for UMDF drivers (and, due to some very clever sleight of hand, the trace log survives the death of the UMDF driver process).
Of course that doesn’t mean that there are exactly NO differences between KMDF and UMDF. UMDF and KMDF don’t support exactly the same devices. Certain limitations of running in user mode make supporting certain devices, such as PCI devices with line-based interrupts for example, impractical. DMA operations are also not currently supported from UMDF drivers. And it’s probably important to note that you don’t have the same WDM “escapes” available to you in user-mode that you do in kernel-mode. So, if that KMDF driver that you’ve written for a USB device calls ExAllocatePool, you’re going to have to replace that with a macro of your own invention that calls ExAllocatePool when the driver’s built for execution in kernel-mode and malloc (or VirtualAlloc or HeapAlloc or whatever you little hear desires) when you’re driver’s built for user-mode.
My personal hot button is that the WDF team didn’t see fit to give us a DbgPrint macro for use in user-mode. Can ANYBODY tell me why, in general, there isn’t an equivalent of DbgPrint in user-mode? Why does OutputDebugString not take the same arguments as printf? Arrrgh.
While UMDF V1’s ugly, annoying, frustrating, COM-based syntax is still supported, we understand that most of the emphasis (and new features) for UMDF from now forward will be focused on UMDF V2.
Here at OSR, we’ve been playing with UMDF V2 for several weeks and can tell you that it IS pretty cool. We’ll be doing more analysis – including a head-to-head performance comparison of UMDF and KMDF drivers for the same USB device – in the coming weeks.
In the meantime, why not download the Developer Preview of the Windows 8.1 WDK and give it a try? While it can supposedly be installed side-by-side with the Win 8 WDK, I learned my lesson with the pre-release Windows 8 WDK: Install the Developer Preview in a VM.
The WDK Team continues to surprise and amaze us by making our most profound wishes true. The latest news, announced at the //Build conference, is UMDF V2. This is a new version of UMDF that uses exactly the same syntax and supports most of the same features as KMDF. Now you can choose to develop your USB driver (if you even NEED to write a USB driver, more about that in another post) using UMDF and if you decide you don’t like the performance or whatever… just move the driver to KMDF without few changes to the syntax of the driver.
Yup… About 90% of the code is the same between a driver written using UMDF V2 and one for the same device using KMDF: The syntax is the same. The structure definitions are the same. The Queues work the same way. YAY! I’ve been asking for this level of compatibility since, well… to be honest… since UMDF was first on the drawing board.
Not only that, but debugging for UMDF drivers is now much enhanced and on a par with that for KMDF. There’s a fully featured set of UMDF debugger extensions, and the “in flight recorder” that makes KMDF driver debugging so much easier is now available for UMDF drivers (and, due to some very clever sleight of hand, the trace log survives the death of the UMDF driver process).
Of course that doesn’t mean that there are exactly NO differences between KMDF and UMDF V2. UMDF and KMDF don’t support exactly the same devices. Certain limitations of running in user mode make supporting certain devices, such as PCI devices with line-based interrupts for example, impractical. DMA operations are also not currently supported from UMDF drivers. And it’s probably important to note that you don’t have the same WDM “escapes” available to you in user-mode that you do in kernel-mode. So, if that KMDF driver that you’ve written for a USB device calls ExAllocatePool, you’re going to have to replace that with a macro of your own invention that calls ExAllocatePool when the driver’s built for execution in kernel-mode and malloc (or VirtualAlloc or HeapAlloc or whatever you little hear desires) when you’re driver’s built for user-mode.
My personal hot button is that the WDF team didn’t see fit to give us a DbgPrint macro for use in user-mode. Can ANYBODY tell me why, in general, there isn’t an equivalent of DbgPrint in user-mode? Why does OutputDebugString not take the same arguments as printf? Arrrgh.
While UMDF V1’s ugly, annoying, frustrating, COM-based syntax is still supported, we understand that most of the emphasis (and new features) for UMDF from now forward will be focused on UMDF V2.
Here at OSR, we’ve been playing with UMDF V2 for several weeks and can tell you that it IS pretty cool. We’ll be doing more analysis – including a head-to-head performance comparison of UMDF and KMDF drivers for the same USB device – in the coming weeks.
In the meantime, why not download the Developer Preview of the Windows 8.1 WDK and give it a try? While it can supposedly be installed side-by-side with the Win 8 WDK, I learned my lesson with the pre-release Windows 8 WDK: Install the Developer Preview in a VM.
