Universal INFs: No ClassInstall32 Section?

I wrote an article in the last issue of The NT Insider that described the whole “thing” about the Universal Driver model, and how it was more than just writing a driver that uses a (very common) subset of Driver Development Interfaces (DDIs).  The bottom line is that writing a truly Universal Driver now necessarily includes support for the DCHU design principles.

For a quick refresh, the DCHU design principles are:

• Declarative – You use a Declarative INF file
• Componentized – You separate your INF into a Base INF and zero or more Extension INFs
• Hardware Support Apps – Written at a UWP app, of course
• Universal – Your driver (and INF) is restricted to the Universal feature set

While there is unquestionably a lot to argue about, I don’t want to argue the good and bad aspects of every single of these points.  I want to focus on one, specific, issue that is causing me, my clients, and apparently other people who write drivers a lot of unnecessary grief.  That issue is the fact that Universal INFs are not allowed to have ClassInstall32 sections.  Says who?  Says MSDN:

Let me get to my opinion right away:  This sucks.  I said it right away, the minute I read this restriction.  And I’ve been saying it as loud and clear as my little voice can manage since.

Not being able to put my special devices in their own Device Class totally and completely sucks.  I do not want to lump my drivers in with their generic Windows counterparts, even those that are “available to vendors” (hmmm… what WOULD be the generic Windows counterpart of a luminometer?).  I do not want to use the class “System.”

Why don’t I want to use one of the pre-existing device setup classes?

First, I want my devices to be organized and visible in Device Manager (or via programmatic query) in sensible, intuitive, ways.  This is true regardless of whether the system onto which my device is installed is a Windows Server system, or some IoT Enterprise system. When a server manager looks at Device Manager, I want her to be able to see that the system’s high-precision time provider device is installed and “working.”  When there’s a dedicated (perhaps embedded) system with a ton of special purpose hardware, I want to be able to organize that special hardware in Device Manager in a way that makes sense to my users (whether those “users” are support people, application devs, or even end users).

Second, I frequently want to be able to apply specific protections to the PDOs and FDOs for my devices.  Among the easiest and best ways to do this is to set a default protection for an entire device class in the INF file.  Secure by design.  This is a big deal.

Finally, there’s the issue of manageability.  Suppose I want to allow users to control my device via property page entries.  Those entries are managed on a per device class basis.

Now… before somebody (like, oh, I don’t know… somebody from Microsoft) writes to me and says “yes, but suppose you’re not on a system that has a GUI!  It won’t matter what device class your device is in.  And we don’t REALLY want you to be writing property pages anymore.  That’s out of style, bro!”  Yes, I know both of these things.  They both may matter someday.  But today, in the real world today where my device is going to run on Server 2016 or on some embedded PC running Windows Embedded Standard 7, they really aren’t relevant.

To further reinforce my argument, I will retreat to the refuge of every secondary school student and state “I’m not the only one who thinks so either!!”

According to long-time driver consultant Don Burn, in a recent thread on our NTDEV list:

I have clients that reject [using] the universal driver model, because they need a separate device class.

Yup.  Give that man a prize.

Soooo… I’m glad to have gotten that off my chest.  Please, Microsoft.  Can you reconsider??