what is the preferred way to have the catalog file. should each flavor of OS have separate catalog file. How do people generally do it. when they submit package for signing with Microsoft do people prefer to make copies of the same binary and get multiple catalogs for each OS flavours.
or
get the catalog file merged and end up with one catalog file which can be used in multiple OS flavours.
which is the preferred way?
we were doing the second option these many days. But there is a time crunch we have with win2016 release. Microsoft takes more time in second option(a week or so).
so we are thinking of option 1. but what is the recommended way.
If I’m not mistaken, you’re question isn’t so much about the CATALOG file as it’s about how to best compose the driver package… is that correct?
Assuming that IS correct, it depends on (a) whether you need different binaries per OS, and (b) whether your driver package is signed by WHQL (as a result of passing the HLK tests) or whether you’re going to attestation/cross sign your drivers.
If your one binary will work on all the OS versions you need to support, AND you’re going to have your driver signed by WHQL, then one package should do it. This is easiest for everyone… you, your customers, and even WHQL.
If you need a different binary per OS, then you have to decide how sophisticated you want to make your installation procedure. In general, except for some very specific situations, if you can figure out how to do it it’s best to have a single installation procedure that installs the proper driver based on the version of the OS on which the driver is running. This eliminates mistakes that users will (always) make “I thought I was running Windows 8 so I installed that version, but I was actually running Windows 10. Oooops.”
The exception here is if you need to support “INF only, no program, no co-installer” type installs… in which case a separate package for each OS version is almost certainly the best way to go.
Hope that helps,
Peter
OSR
@OSRDrivers
xxxxx@osr.com wrote:
If I’m not mistaken, you’re question isn’t so much about the CATALOG file as it’s about how to best compose the driver package… is that correct?
…
If your one binary will work on all the OS versions you need to support, AND you’re going to have your driver signed by WHQL, then one package should do it. This is easiest for everyone… you, your customers, and even WHQL.
If you need a different binary per OS, then you have to decide how sophisticated you want to make your installation procedure.
Well, the situation is made slightly more complicated than that because
of architectures. Even if your driver works on multiple OS versions,
you sill need (at least) one binary for 32-bit and (at least) one binary
for 64-bit (and now, possibly, one binary for ARM).
I, for reasons that are difficult to enumerate, have always preferred
the one CAT / one INF solution, with different driver binaries in
subdirectories. Unfortunately, the new WDK packaging process doesn’t
support that. It wants to produce one build output from one set of
inputs. That just means I throw away the “package” project, and I still
using my old package building scripts after I run “msbuild”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim for the clarification. To be more specific about the issue, our product supports various OS flavours like win 7, win8, win8.1, win10, win server 2008, 2008 R2, win server 2012, 2012 R2.
For win7, win8, win 8.1, server 2008 R2, win 2012, 2012R2 I undergo HCK. For win 10 I undergo HLK and 2008 I undergo WLK.
Now for win 2016 release I will undergo HLK.
Driver binaries for win 8, win 8.1, win 10, server 2008R2, 2012, 2012R2 and win2016 flavours of OS will be using the driver built from win8 environment in WDK. Basically single binary installed in all the OS flavours.
Since it is a single binary while submitting to MS we give the reference that the driver is previously signed for x OS flavor and they do the merging.
But this merging is not an automated procedure at Mircosoft side. It nearly takes a week to get the final single catalog file which can be used used across all OS flavours.
so we thought of submitting the drivers separately and get different catalog files for each and every flavor of OS, which means same driver binary but different catalog files. MS takes only less time for this.
Just wanted to know how people generally do in other products when they support multiple flavours.
From your comments I understand that if the binary is same for different OS flavours then it is a single catalog file that people generally have. correct me if I am wrong.
Yes, but thus doesn’t impact the situation at all. The INF file accommodates this.
In general, you’re better off with the one driver package with one INF that’s signed for multiple OS versions.
Peter
OSR
@OSRDrivers
xxxxx@yahoo.co.in wrote:
Just wanted to know how people generally do in other products when they support multiple flavours.
From your comments I understand that if the binary is same for different OS flavours then it is a single catalog file that people generally have. correct me if I am wrong.
I cannot pretend to speak for what people “generally” do. When I
download drivers from web sites, I see both approaches. Personally, I
like a single catalog file, but as I said, the vcxproj-based build
procedure now builds one flavor per package, so I’m guessing things are
trending in that direction.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim and Peter. It gave me idea on how to proceed further. It was really helpful.
Thanks