A question for those who have been dealing with all the variations on driver
signing in the world of Windows 10.
Typically, a lot of my clients are looking for drivers that will be
installed with a custom application to control the device. For such cases
in the past I provided an installation program plus a DLL to invoke it (the
DLL is smart enough to handle the 32-bit app on the 64 bit system case).
The installation stuff basically broke things down to 32 and 64 bit
versions. The current model is:
Given the variety of signing needed for Windows 7, Windows 8.1, and Windows
10, should the installer be smart enough to know the OS and factor that into
the install. For example should the package become
Install directory
Win7AMD64 - Windows 7 64-bit install pieces
Win7I386 - Windows 7 32-bit install pieces
Win8AMD64 - Windows 8 64-bit install pieces
Win8I386 - Windows 8 32-bit install pieces
Win10AMD64 - Windows 10 64-bit install pieces
Win10I386 - Windows 10 32-bit install pieces
I don’t do the signing myself, I just provide the pieces and the structure
(i.e. the build of the product creates an install image ready for signing)
for the client to do it, plus support. Till now my clients have
concentrated on Windows 7 with Windows 8 being an afterthought. But my
clients are now being to express a desire for Windows 10 support, and I am
trying to figure the best approach with SHA1, SHA2 and EV-Cert signing.
Why not just create an MSI which will handle your driver installations/upgrades (using difxapp) as well as all dependencies for helper dlls, services, etc?
Based on particular version of OS you can install given component (e.g., for Windows 10 you install one version of the driver, for Windows 7 another ; same goes for dependencies).
This is the current design I am using with my product (around 3-4 million of installations across 700 customers). In order to make this even more flexible I have a 32 bit installer which packages MSI files and covers all OS starting from XP -> 10 with all flavors.
Because it is easier to use the DifxAPI than use DifxApp for anything but
the simplest of installs. In this case there will be one 32-bit application
that is running on either 32 or 64 bit. I have wasted many hours fixing
broken or fragile DifxAPP based systems that use try to do everything via
scripts etc.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
Sent: Saturday, November 21, 2015 4:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver installation for multiple Windows versions
Don,
Why not just create an MSI which will handle your driver
installations/upgrades (using difxapp) as well as all dependencies for
helper dlls, services, etc?
Based on particular version of OS you can install given component (e.g., for
Windows 10 you install one version of the driver, for Windows 7 another ;
same goes for dependencies).
This is the current design I am using with my product (around 3-4 million of
installations across 700 customers). In order to make this even more
flexible I have a 32 bit installer which packages MSI files and covers all
OS starting from XP -> 10 with all flavors.
Yes, it takes a while to make an MSI with difxapp which works reliably, I agree.
But after you invest into fixing the issues you encounter in the field it later goes well and does not require your attention. At least this is my experience.
> Don, Why not just create an MSI which will handle your driver installations/upgrades
(using difxapp) as well as all dependencies for helper dlls, services, etc?
…
This is the current design I am using with my product (around 3-4 million of installations
across 700 customers). In order to make this even more flexible I have a 32 bit installer
which packages MSI files and covers all OS starting from XP -> 10 with all flavors.
Well, you have to be careful when giving ANY advice to this particullar OP - after all, there is a good chance that your advice provokes more or less the same reaction from him as the one quoted below:
First, my customers want to integrate things into their application
installer, which can be any number of things. Second, every time I’ve dealt
with a DifxAPP script, I seem to spend an inordinate amount of time
supporting it as warranty work. Third, in many cases I customize the code
for a specific situation, for example do not install driver X unless the
system has a parallel port. Finally, a number of my customers want to sign
all the executables including the installation application, which you
certainly can’t do with DifxAPP.
I discovered early on that writing the code using the DifxAPI is easier and
more customizable than using DifxAPP. Of course your results may vary, but
since DifxAPP is just a small wrapper around DifxAPI it is easier to code
things directly.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
Sent: Saturday, November 21, 2015 6:20 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver installation for multiple Windows versions
Yes, it takes a while to make an MSI with difxapp which works reliably, I
agree.
But after you invest into fixing the issues you encounter in the field it
later goes well and does not require your attention. At least this is my
experience.
Aside from being critical, did we answer your question? You create one install package that’s signed conventionally for pre-Win10, and you create an attestation signed package for Win10.
The contents can be the same, or whatever you want.
I think you answered the basics, since I am doing this all in VS2015
I’m still learning about getting the signing right within the wonders of the
driver package, etc. With the requirement of SHA1 for Win7, SHA2 for Win8,
and EV-cert for Win10, I wondered if fitting it into the VS model it was
easier just to go with three pieces.
As I said till now my clients were more concerned with XP/Win7 than
what could be called a current version of Windows.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, November 23, 2015 12:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver installation for multiple Windows versions
Aside from being critical, did we answer your question? You create one
install package that’s signed conventionally for pre-Win10, and you create
an attestation signed package for Win10.
The contents can be the same, or whatever you want.
In terms of signing, unless you have a very straight-forward requirement (and, let’s face it… who does these days when it comes to signing), you’re going to be better of building in VS and then doing the signing step yourself.