WMI

NTDEV
1

Maybe I’m late to this party, but I’m just starting to explore what WMI
could do for me and my drivers.

I have delivered a couple of filter driver solutions that used the
“control device object” concept to allow control panel-like access to
the filters. This works, and it’s easy to use from the user-mode side,
but it’s not very clean, and the bookkeeping is somewhat awkward, since
there is a 1-to-many relationship.

It appears that virtually all of what I need could be exposed through
WMI instead. As I see it, this looks to be a much cleaner solution, and
actually takes a bit less code in the driver, although it seems to take
a LOT more code in the user-mode app (in C, anyway; it’s easy from a
managed app). It also allows me to use standard WMI browsers to play
with things.

What’s your experience? Is WMI support worth the trouble?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

2

As to your user-mode aspect of the question, I found writing accessor code about as verbose as registry access code. It’s not bad, really.

The utility I wrote was to retrieve version information from the BIOS. I did this in C at first, but later refactored to C++ for fewer lines. (I wish I could remember the details of what example code I derived it from, but that was a while ago and I don’t work for that company now.)