On topic: WTF is up with difx being disappeared?

quoth msft:

“The Driver Install Frameworks (DIFx) tools were removed from the Windows
10 Version 1607 WDK. Instead, we recommend providing your driver as a
standalone package that doesn’t require an installer, ideally through
Windows Update. To add your driver to Windows Update, the first step is to
submit your driver package to the Sysdev Driver Portal
http:</http:>.”

seriously? The implication here is that in some future release drivers can
only be installed via windows update. That can’t possibly work. Can we
start with the air-gapped computer case?

Back to reality, this now requires the ~10,000 production build systems out
there that rely on Difx to have both the latest wdk and some earlier
deprecated wdk installed, the latter just to fetch the appropriate difx
components, or to rely on the truly ancient crap that comes with the wix
installer, or to go back to writing their own install tools.

whining and gnashing teeth, no hair left to pull,
Mark Roddy

In related news…

DIFx doesn’t work on Windows Server 2016 “Nano Server”.

The only way to do an online driver installation on Nano Server is using
pnputil.exe. The device installer API’s are gone. Based on the size of the
file, I suspect the SetupDi code got static linked into pnputil.exe.

The good news is that it may not matter. 99% of Nano Server users will be
creating custom images, and will likely prefer to inject drivers into the
image rather than installing them online. Make sure your driver package works
with dism!

–John

-------- Original Message --------
Subject: [ntdev] On topic: WTF is up with difx being disappeared?
From: Mark Roddy
To: Windows System Software Devs Interest List
Date: 2/20/2017 12:58 PM

> quoth msft:
>
> “The Driver Install Frameworks (DIFx) tools were removed from the Windows 10
> Version 1607 WDK. Instead, we recommend providing your driver as a standalone
> package that doesn’t require an installer, ideally through Windows Update. To
> add your driver to Windows Update, the first step is to submit your driver
> package to the Sysdev Driver Portal http:</http:>.”
>
> seriously? The implication here is that in some future release drivers can
> only be installed via windows update. That can’t possibly work. Can we start
> with the air-gapped computer case?
>
> Back to reality, this now requires the ~10,000 production build systems out
> there that rely on Difx to have both the latest wdk and some earlier
> deprecated wdk installed, the latter just to fetch the appropriate difx
> components, or to rely on the truly ancient crap that comes with the wix
> installer, or to go back to writing their own install tools.
>
> whining and gnashing teeth, no hair left to pull,
> Mark Roddy

SetupDi doesn’t exist at all on nano (or on any OneCore based products), it isn’t statically linked into pnputil

Bent from my phone


From: xxxxx@lists.osr.com on behalf of John McNamee
Sent: Tuesday, February 21, 2017 9:24:39 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] On topic: WTF is up with difx being disappeared?

In related news…

DIFx doesn’t work on Windows Server 2016 “Nano Server”.

The only way to do an online driver installation on Nano Server is using
pnputil.exe. The device installer API’s are gone. Based on the size of the
file, I suspect the SetupDi code got static linked into pnputil.exe.

The good news is that it may not matter. 99% of Nano Server users will be
creating custom images, and will likely prefer to inject drivers into the
image rather than installing them online. Make sure your driver package works
with dism!

–John

-------- Original Message --------
Subject: [ntdev] On topic: WTF is up with difx being disappeared?
From: Mark Roddy
To: Windows System Software Devs Interest List
Date: 2/20/2017 12:58 PM

> quoth msft:
>
> “The Driver Install Frameworks (DIFx) tools were removed from the Windows 10
> Version 1607 WDK. Instead, we recommend providing your driver as a standalone
> package that doesn’t require an installer, ideally through Windows Update. To
> add your driver to Windows Update, the first step is to submit your driver
> package to the Sysdev Driver Portal http:</http:>.”
>
> seriously? The implication here is that in some future release drivers can
> only be installed via windows update. That can’t possibly work. Can we start
> with the air-gapped computer case?
>
> Back to reality, this now requires the ~10,000 production build systems out
> there that rely on Difx to have both the latest wdk and some earlier
> deprecated wdk installed, the latter just to fetch the appropriate difx
> components, or to rely on the truly ancient crap that comes with the wix
> installer, or to go back to writing their own install tools.
>
> whining and gnashing teeth, no hair left to pull,
> Mark Roddy


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:>

Of course I have no way to know if SetupDi itself got static linked into
pnputil.exe. What is clear is that pnputil.exe is a small file on “regular”
Windows, and it imports from the usual suspects (e.g. SetupAPI.dll). The Nano
version is a much larger file that has no such imports (because those DLL’s
don’t exist on Nano).

My conclusion is that the code to support driver installation now lives in
pnputil.exe. Anybody who wants to install a driver on Nano has to call out to
pnputil.exe, and can’t do it themselves via API calls.

–John

-------- Original Message --------
Subject: Re: [ntdev] On topic: WTF is up with difx being disappeared?
From: Doron Holan
To: Windows System Software Devs Interest List
Date: 2/21/2017 11:48 AM

> SetupDi doesn’t exist at all on nano (or on any OneCore based products), it
> isn’t statically linked into pnputil
>
> Bent from my phone
>
> ------------------------------------------------------------------------------
> From: xxxxx@lists.osr.com
> on behalf of John McNamee
> Sent: Tuesday, February 21, 2017 9:24:39 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] On topic: WTF is up with difx being disappeared?
>
> In related news…
>
> DIFx doesn’t work on Windows Server 2016 “Nano Server”.
>
> The only way to do an online driver installation on Nano Server is using
> pnputil.exe. The device installer API’s are gone. Based on the size of the
> file, I suspect the SetupDi code got static linked into pnputil.exe.
>
> The good news is that it may not matter. 99% of Nano Server users will be
> creating custom images, and will likely prefer to inject drivers into the
> image rather than installing them online. Make sure your driver package works
> with dism!
>
> --John
>
>
> -------- Original Message --------
> Subject: [ntdev] On topic: WTF is up with difx being disappeared?
> From: Mark Roddy
> To: Windows System Software Devs Interest List
> Date: 2/20/2017 12:58 PM
>
>> quoth msft:
>>
>> “The Driver Install Frameworks (DIFx) tools were removed from the Windows 10
>> Version 1607 WDK. Instead, we recommend providing your driver as a standalone
>> package that doesn’t require an installer, ideally through Windows Update. To
>> add your driver to Windows Update, the first step is to submit your driver
>> package to the Sysdev Driver Portal http:</http:>.”
>>
>> seriously? The implication here is that in some future release drivers can
>> only be installed via windows update. That can’t possibly work. Can we start
>> with the air-gapped computer case?
>>
>> Back to reality, this now requires the ~10,000 production build systems out
>> there that rely on Difx to have both the latest wdk and some earlier
>> deprecated wdk installed, the latter just to fetch the appropriate difx
>> components, or to rely on the truly ancient crap that comes with the wix
>> installer, or to go back to writing their own install tools.
>>
>> whining and gnashing teeth, no hair left to pull,
>> Mark Roddy

To address a few points here:

We’re moving away from any EXE-style install (DIFx included), to an INF-driven install. Pnputil, right-click->install, DISM, and DiInstall* APIs are all recommended. SetupDi* APIs were essentially deprecated in Win8 (although they won’t be removed from desktop), and the DiInstall* APIs are now the way to go for programmatic driver installation.

Nano doesn’t include any programmatic way to install drivers, pnputil should be used.

Fascinating. You might want to fix the link here
https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/difx-guidelines
that neglects to mention that there is a replacement api. I had no clue.

Mark Roddy

On Tue, Feb 21, 2017 at 1:50 PM, wrote:

> To address a few points here:
>
> We’re moving away from any EXE-style install (DIFx included), to an
> INF-driven install. Pnputil, right-click->install, DISM, and DiInstall*
> APIs are all recommended. SetupDi* APIs were essentially deprecated in
> Win8 (although they won’t be removed from desktop), and the DiInstall* APIs
> are now the way to go for programmatic driver installation.
>
> Nano doesn’t include any programmatic way to install drivers, pnputil
> should be used.
>
> —
> 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:>

Given a Windows app coupled with a custom class filter driver which are installed together, the driver using DIFx. What is the future/correct way to accomplish this installation?

This might be completely off base, but how poor form is it to include
devcon.exe from the ddk with your bundled software and use that for the
installation? Seems to be an easy path, and then call that from your app or
app installer?

On Tue, Feb 21, 2017 at 7:31 PM wrote:

> Given a Windows app coupled with a custom class filter driver which are
> installed together, the driver using DIFx. What is the future/correct way
> to accomplish this installation?
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> 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:>

@Sven - Assuming you mean a traditional win32 program, unfortunately the easiest way to install a class filter is still probably SetupApi: InstallHInfSection().

@Jesse - I’d personally prefer basically any other way. SetupDi*, DiInstall*, pnputil, etc.

If exists I want to know the future/correct way to install a class filter; not guesses, easy ways, or personal preferences. It’s important to me when developing that the most future proof and correct design is chosen.

You don’t have redistribution rights for devcon. You can build the sample.with a custom name if you want.

Bent from my phone


From: xxxxx@lists.osr.com on behalf of Jesse Conn
Sent: Tuesday, February 21, 2017 4:57:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] On topic: WTF is up with difx being disappeared?

This might be completely off base, but how poor form is it to include devcon.exe from the ddk with your bundled software and use that for the installation? Seems to be an easy path, and then call that from your app or app installer?

On Tue, Feb 21, 2017 at 7:31 PM > wrote:
Given a Windows app coupled with a custom class filter driver which are installed together, the driver using DIFx. What is the future/correct way to accomplish this installation?


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:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>

On Feb 21, 2017, at 10:50 AM, xxxxx@microsoft.com wrote:

We’re moving away from any EXE-style install (DIFx included), to an INF-driven install. Pnputil, right-click->install, DISM, and DiInstall* APIs are all recommended. SetupDi* APIs were essentially deprecated in Win8 (although they won’t be removed from desktop), and the DiInstall* APIs are now the way to go for programmatic driver installation.

“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.

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

On Feb 21, 2017, at 10:14 AM, John McNamee wrote:
>
> Of course I have no way to know if SetupDi itself got static linked into
> pnputil.exe.

Yes, you do. Doron just told you. The SetupDi APIs are not available in Windows 10 Mobile, either. Fortunately, virtually everything you can do with SetupDi can also be done with the CM_ APIs.

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

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?