UMDF 1.0 to 2.0 mapping?

I’m porting my old UMDF 1.0 USB driver to UMDF 2.0. I wonder if there is a mapping of UMDF 1.0 COM interfaces/methods to UMDF 2.0 functions. It’d be really helpful, without it this task is a bit tedious.

I expected it exists and tried to find it but no success. I hope it is just my inability to use Google :wink:

Extraordinarily painful … you’re likely better off rewriting it in UMDF 2.0 in all seriousness. Beyond the “fun” of COM, there are enough functions that don’t quite completely map to UMDF 2.0 land that you’ll spend more time working around those rough edges than if you simply sketch out what the driver is supposed to do and write that in UMDF 2.0

1 Like

I have it already done. Yes, it wasn’t straightforward and I’m still debugging some issues caused by differences but still better than rewriting from scratch. The driver logic remained the same.

When I compare the result with the original code I find UMDF 2.0 code shorter, easier to read and more logical. Just all functions have one more parameter, the device context. Seems to me UMDF 1.0 was step out which shouldn’t be done.

In hindsight, I completely agree. At the time, there was reason to believe that COM was the durable abstraction we should use if we wanted to enable app developers to be comfortable writing drivers (since they already lived and breathed COM). Now we know that UMDF1.0 developers were almost exclusively KM developers who moved up into UM and COM was far from ideal for that audience. That’s is one of the strong reasons why UMDF2 is code compatible with KMDF, the dev pool for both is the same.

Another reason COM was in UMDF1.0 was that to a small degree, we shipped our org. There were separate UMDF and KMDF dev teams reporting to the same manager and each team was hyper focused on their own environment. We shared code and patterns, but operated somewhat independently. The passion for COM came from the UMDF team, the KMDF team stated its objections, but in the end, the UMDF team owned the decision.

the KMDF team stated its objections, but in the end, the UMDF team owned the decision.

That’s a very candid explanation that matches exactly with my personal recollection. IIRC, the architect who owned the I/O Subsystem at the time weighed in heavily on the side of COM, as well. /rolls eyes

The UMDF team’s primary misunderstanding was the thought “user mode devs” would write UMDF drivers, and “all user mode devs” know COM.

In fact, it’s not “user mode devs” who write drivers. It’s mostly device people who write drivers. And there’s little chance that those folks will know COM.

The genesis of UMDF was a big departure from that of KMDF. Almost all the critical decisions about KMDF development were discuss by the MSFT team with a third party driver devs before a final decision was made. I’m not saying the MSFT blindly did whatever the third parties wanted. I’m just saying they were frequently consulted. In MY mind, this collaboration stands as one of the great historical milestones of KMDF. There’s rarely been collaboration like, before or since.

Peter

Also, UMDF was incubated in the Windows Media Player team to support USB media devices. That incubation was entirely COM based and influenced the project’s API direction

It’s all about what you’re used to. I started my first UMDF driver this month (a virtual HID device with a rather complicated report descriptor). I couldn’t get it to stay loaded, and it wasn’t clear why. In about 15 minutes, I rebuilt it as a KMDF driver, where I’m very comfortable with the tools. That finally got me an error that pointed out a typo in my report descriptor. I’ll now go back to UMDF because I need to talk to a user-mode DLL from the client, but it was a really good example of how tight the UMDF2/KMDF matching is. And it’s nice to know that switching is so easy.

Doron, thanks for the background. It happens, I guess all of us made decisions which are suboptimal at least from hindsight.

Still it would be nice to at least add links to original UMDF 1.0 docs to appropriate UMDF 2.0 pages. I made several funny mistakes because haven’t found the right alternative on the first try. OTOH I’m not sure if is has use now, maybe most of UMDF 1.0 drivers were already rewritten to 2.0.

BTW, I wrote this driver at 2009 and it was used all the time by different companies because of acquissions and mergers. The only reason to rewrite it now was AoAc/DFx requirements which need UMDF 2.0. I joined current owner recently without knowing it and it ended this way. I was going to port my 12 years old code :slight_smile:

Tim, yes, I like KMDF/UMDF matching a lot. As for the tools it is even easier to debug UMDF driver, you only need to know how. My driver also couldn’t stay loaded on the first try, traces didn’t work for unknown reason so I had to think what to do. Finally it was easy, a loop in DriverEntry, attach process from VS, break the loop manually and find the problem as in application (the driver process didn’t have rights to access registry where we have traces configuration).

The best is you can do it locally as I always did (where is my SoftICE… :)) but with UMDF it is safer.

it’s nice to know that switching is so easy.

Absolutely. I really wish it was easier. I have long fantasized about a setting in the driver properties dialog for user mode vs kernel mode.

And, yes… I realize that some of the APIs differ slightly. But wouldn’t it be cool… and EVEN EASIER… if the vast majority of the code would “just work”… Like why shouldn’t you be able to call WdfDeviceMapIoSpace in kernel mode? Ah, to dream…

It’s all about what you’re used to.

This, right here, exactly. Every time I personally undertake to write something “real” in UMDF, I always wind-up switching to KMDF. … because I’ve been writing kernel-mode driver code “lo these many years” and it’s reasonably efficient for me to attack it that way – But I totally acknowledge that’s a limitation of my skill set and not an advantage.

I’d love to have a serious reason to do something UMDF.

What can be done in user mode should be done in user mode. Isn’t it a serious reason for you? I thought you were proposing it in the past but maybe my memory isn’t correct.

For me it is although I like kernel and low level programming. Most of my work in past years was some firmware, bare metal or some RTOS.

This driver is biometric and it is no brainer. The driver itself is just a wrapper over big biometric library. Porting it to kernel mode is probably possible but not easy, memory allocations and stack usage. But mainly, code robustness. It was written by good developers but not driver ones. Code is robust but not paranoid. For example, they wrote:

ASSERT(Parameter != NULL);
*Parameter = ...

whereas I write

if (VERIFY(Parameter != NULL)) {
   *Parameter = ...
}

The former causes BSOD in kernel with NULL parameter whereas the latter just leads to a red line in DebugView and forces me to fix it. In user mode the former crashes the driver proces which also isn’t good but occasional loss of functionality is much better than BSOD. It really happened in my new driver as I made a mistake and called the library with NULL parameter in some scenario. Who knows how many such things are there? Thanks for UMDF :slight_smile:

What can be done in user mode should be done in user mode.

Oh, I absolutely agree.

Isn’t it a serious reason for you?

Yes, but by itself not sufficient. The other part of “serious reason” that I’ve be lacking is a paying project that lends itself to being done in user mode and has a reason to live there, other than “it’s possible, but not optimal.” Given the types of work we tend to do here, that’s not super likely to come along. It’s rare that we get so write a driver for an ordinary USB device (for example). Though I’m open to the idea…

I thought you were proposing it in the past but maybe my memory isn’t correct.

Oh, I’m all in favor of UMDF 2. No question.

Peter