On topic: WTF is up with difx being disappeared?

Tim Roberts wrote:

“Essentially deprecated”?? Can you really say that with a straight face?
Is that like “double secret probation” from Animal House? Because I
have certainly never seen anything like that mentioned in any official
document.

Kind of funny that the company that valued app compat over all else is now “essentially deprecating” major OS functionality by way of an offhand post to an email list by some guy we’ve all never heard of before two weeks ago. Move fast and break things?

The development of drivers is difficult enough. Having so much uncertainty about how to get the damned things installed has always been a beef of mine. Sure Windows Update is great for connected devices, but that’s not a luxury my customers often have.

I’ve long used WiX based installers so I can maintain a consistent install experience. Am i going to have to do something stupid like create a custom action that runs pnputil, or worse yet create a custom action that uses the DiInstall* APIs directly?

> Am i going to have to do something stupid like create a custom
action that runs pnputil, or worse yet create a custom action that uses the
DiInstall* APIs directly?

Nothing existing will break or stop working. Deprecation does not mean removal, and anything setupapi-based will continue to work on desktop.

I gotta tell you: The whole march to OneCore doesn’t really make a lot of sense to many of us out here in the trenches. A lot of us have drivers that primarily target desktop and server. It’s hard for those of us to GAF about, never mind have our world rocked by, the install experience on IoT or Mobile. Or, yes, even NanoServer.

Instead of making Windows as good an OS platform as it can be on desktop and server, we see a lot of effort being redirected to making Windows be a reasonably acceptable OS for IoT, tablet, and Mobile. And we see a lot of other stuff getting caught in the crossfire. It’s the kind of thing that make you go “Hmmmmmm…” – and, yes… I realize its not your call. But Terry doesn’t post here, or ask my opinion, and I need to whinge at somebody.

Having said that, I *do* appreciate the definitive answers about the future direction for installers. I just don’t happen to particularly like that direction.

Peter
OSR
@OSRDrivers

Specifically around OneCore and the install experience, I can provide some context. Not that there aren’t some strong points in how setupapi works, but it is a slow and heavyweight way to install drivers, with a lot of edge cases handled very poorly. I could go on about some very core modern driver install scenarios don’t work well with setupapi (anything offline or with manufacturing, especially), but I’ll spare you guys.

For Win8, we introduced a new model: device configuration. It has since gotten varying names, depending on the context (Universal installer, OneCore driver install, etc.), but it’s all the same mechanism. I won’t go too into the details, but the two models are essentially a hybrid on desktop - it dynamically decides if it can use configuration, and if not, falls back to setupapi. Configuration has some advantages: the actual device installation is FAST (well over an order of magnitude faster than setupapi), drivers can be added to the system 100% offline, it’s easier to validate and triage, more reliable, really lightweight (it’s all done in the kernel), and I could go on. The downside, of course, is that it can’t use certain things which are only in setupapi, like coinstallers. Just to highlight some of the coolness of configuration, when Windows Update sends up driver information to check for new drivers, it took ~60 seconds to generate that info using setupapi calls (on my dev box), and when we switched it over to calls into configuration, it now takes < 1 second.

Hopefully it’s not hard to understand why we are bought into configuration as the improved way to install drivers and set up devices going forward. Coincidentally (or maybe not), it’s the exclusive install mechanism for OneCore-based SKUs. So the OneCore SKUs might be why you’re hearing about it, but it was in desktop before then, and was designed as such. But we are 100% aware that a lot of developers are invested in setupapi and only care about server/desktop - so we have no intention of forcing you away from setupapi if you need it. You just get all those other things as freebies if you’re able to ditch setupapi.

Well. That’s a good and well-reasoned a response. One that lets me do things the old way… but encourages me to change. OK.

But… how do I install my new device class now and set all its cool stuff… if the universal INF doesn’t allow ClassInstall32? If I can’t define my own device class, how do I install my missile launcher driver and have it show up in Decice Manager under “OSR Missile Launchers”??

Peter
OSR
@OSRDrivers

So, I’m hearing two install models:

  1. Configuration
  2. setupapi

Where can I learn more about the configuration model?

I’m mostly concerned with distribution of my driver(s) in offline environments. If I’ve got a piece of hardware that has custom driver(s) and user space software application(s) I want to send customers a single installer that has everything they need.

What’s the recommended install model to use in this scenario and how does driver installation integrate with the installation experience?

So apparently the thread will end with a lot of unanswered questions. Short recap of one I brought up: corect me if I am wrong, but the suggestion by Microsoft to install drivers using windows update is impossible for a class filter driver. Though several different installation methods may still work, no one seems to know which way is actually most correct or future proof leaving a vacuum for the poor developers to select the wrong way.

It is appalling to read the shift in direction that user friendly single click installers that install an app and a filter driver are now frowned upon. Instead, a more complicated, decoupled, and less robust install process is seen as the future. Maybe it’s great for some types of drivers, but it’s a giant step backwards for others and will lessen the appeal of such products and the windows platform in general.

Bingo. The question of the week, if you add “and the custom driver is for hardware that I want to appear in Device Manager in a custom device class.”

I *THINK* I heard the answer was: Just use setupapi, per:

of course, this is sorta contradicted by the fast that

So… I *still* would like to know how I install a device into a custom device class on NanoServer. I feel like I’m missing something. What’s best practice considered to be?

Peter
OSR
@OSRDrivers

What value //functionality are you getting from a custom device class? If it is UI grouping and pretty icons, nano has none of these things.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, February 24, 2017 8:04 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] On topic: WTF is up with difx being disappeared?



Bingo. The question of the week, if you add “and the custom driver is for hardware that I want to appear in Device Manager in a custom device class.”

I THINK I heard the answer was: Just use setupapi, per:



of course, this is sorta contradicted by the fast that



So… I still would like to know how I install a device into a custom device class on NanoServer. I feel like I’m missing something. What’s best practice considered to be?

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Well, sure. That’s true. But that’s not really an answer to the question. It’s a way to avoid the situation.

I want to put my OSR Missile Launcher in its own Setup Class because, as a best practice, that’s where it belongs. I want to be able to establish a predictable default device projection for all devices in the class, and default device characteristics. On SKUs where there IS a UI, I want the Missile Launcher to be easily discovered.

And I want to have ONE INF file that works on Workstation and Server and even NanoServer, if anybody elects to use one to control their missile system.

Peter
OSR
@OSRDrivers

I’m not as hung up about “how it looks in device manager”. I’m sure Peter has use cases that make this a bigger deal for him and his clients.

My customers don’t need to go to the device manager to verify the device (or it’s drivers) are working; even though that’s what they have become accustomed to for many years. If they need a way to confirm these things, I can provide appropriate software. I’m completely fine lumping “non conforming” things into the “System Devices” or equivalent “other” class. If it doesn’t fit into a “normal” device class category the purpose of the machine is probably closely related to the special driver I’m authoring anyhow.

I am, however, still highly interested in hearing a response to:

> user friendly single click installers that install an app and a filter driver are now frowned upon

They’re not frowned upon, there just isn’t support for class filters in device configuration. By all means, do whatever you were doing before.

Where can I learn more about the configuration model?

We don’t have detailed documentation on the underlying implementation, but we’ve got an overview here: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/using-a-configurable-inf-file

What’s the recommended install model to use in this scenario and how does driver
installation integrate with the installation experience?

The thing to keep in mind is that one of the design goals of configuration is to decouple things like software installation from the actual driver installation. You can have an exe that wraps the two of them (this is great), but you should still have the standalone driver package that does nothing except bring the device up to a functional state. The idea being that if you were bring up your device on a OneCore SKU, the actual driver would still work, you’d just need to figure out the software part if you wanted it for that SKU. I hope I’m explaining it well - exe that installs a driver and then installs some piece of software (or vice versa): recommended and configurable; an INF that uses a coinstaller to install software inline with the driver install: not recommended and setupapi-dependent.

From your exe, install the driver with DiInstallDevice or DiInstallDriver. It will automatically pick the correct installation mechanism. You can determine if your INF itself is compatible with configuration by using InfVerif to check if it’s universal (https://msdn.microsoft.com/windows/hardware/drivers/devtest/infverif). Keep in mind that some *classes* will always fall back to setupapi (display and media come to mind), even if your INF works with configuration.

Microsoft to install drivers using windows update is impossible for a class
filter driver

This is true because Windows Updates target specific hardware devices, and presumably your filter driver does not. Otherwise, it would work, even if using setupapi

So… I *still* would like to know how I install a device into a custom device
class on NanoServer.

[ClassInstall32] actually works just fine with configuration. You just can’t use a class installer for your class, since installer DLLs are specifically non-configurable. We discourage the use of custom classes in most situations though, but I’ll leave that up to your discretion.

I am looking into this documentation issue

Really? It is listed as one of the sections that is “invalid” in a universal INF file, on the page you referenced.

Seriously. That’s why I asked.

The overall problem with ClassInstall32 is that it only really works for the first INF encountered for the class. After that, its ignored. I’ll grant you, that’s not a great model, but we work with what we’ve been given.

Bad plan. Even if you ONLY consider the major mess that is Device Object protection.

But we can debate that later, after I learn how to install my device in its own Setup Class via configuration.

Peter
OSR
@OSRDrivers

@ Mark “Fascinating. You might want to fix the link here”

You mean MSFT actually document something clearly? Don’t hold your breath… :wink:

1 Like

Actually the docs do get updated. Sometimes they get updated too much. Plus
compared to, for example the vast pile of incompatible misinformation that
is the internets of *nix man pages, the msft docs are pretty good.

but really stackoverflow is better.

Mark Roddy

On Mon, Feb 27, 2017 at 8:04 AM, wrote:

> @ Mark “Fascinating. You might want to fix the link here”
>
> You mean MSFT actually document something clearly? Don’t hold your
> breath… :wink:
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

I am still waiting for any of my valid criticisms of MSFTs documentation to get implemented…

But Linux, its open source, so you cant expect a single point of documentation like Windows has to have, which is propitiatory. Instead LInux is documented by its uses cases. Hence stackoverflow.

(I also do linux kernel code by the way, its is interesting working on both camps)

xxxxx@hotmail.com wrote:

I am still waiting for any of my valid criticisms of MSFTs documentation to get implemented…

I don’t think you fully appreciate the processes involved in a large
corporation. Nothing gets done without being scanned, vetted,
discussed, approved, scheduled, assigned, written, checked,
double-checked, and deployed. Their writers were already busy doing
other work, so your task will move into some future sprint. I’m sure
your comments have gone into somebody’s proposed task list, and they
will talk about how to improve things.


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

… blocked, ignored, NFI’d…

No one cares you know. Really.

Or perhaps I am just very cynical and have a jaded view of the world.

well if I can’t compare the MSFT docs to the docs for the only alternative
os to windows, then the msft docs are beyond comparison. They are neither
good nor bad, they are just “the docs”.

And stackoverflow is essential for both windows and linux.

Mark Roddy

On Mon, Feb 27, 2017 at 12:54 PM, wrote:

> I am still waiting for any of my valid criticisms of MSFTs documentation
> to get implemented…
>
> But Linux, its open source, so you cant expect a single point of
> documentation like Windows has to have, which is propitiatory. Instead
> LInux is documented by its uses cases. Hence stackoverflow.
>
> (I also do linux kernel code by the way, its is interesting working on
> both camps)
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>