@David_Scheele
It shows the list of target OS versions that you’ve been running tests for (there can be more than one version, if you merge hlkx packages from different test runs for different targets). The real question is, how the selected version affects ability to install the driver on other Windows targets. Unfortunately, I don’t know the answer, but it would be logical to expect that backward compatibility is the primary scenario. Therefore I would suggest testing and signing for older Windows version (like 1607), and use these drivers for all Win10 versions (plus win7/8/8.1, if you need them). Unless your drivers require some newer Windows kernel features, of course.
There is that question again, will I have to test for all Win10 Versions currently out there?
No. We just check all the (applicable) boxes. The resulting driver package just all’s in whatever Windows 10 erosion.
Peter
@“Peter_Viscarola_(OSR)” said:
No. We just check all the (applicable) boxes. The resulting driver package just all’s in whatever Windows 10 erosion.
Sorry, I don’t understand.
You check the applicable boxes… in the submit form?
There are only the “Request Signatures” to check, for older versions.
What do you mean by “just all’s in whatever Windows 10 erosion”?
@CaptainFlint
Thanks again. I’ll be setting up a 1607 setup for now. Guess we will find out if that procedure is the correct “Microsoft-Approved” way.
This has always confused me a little. If you check only the oldest Windows 10 boxes, the resulting package loads everywhere. I’ve never been sure whether the checkboxes are trying to say “I work from here on”, or “I work up through here”, because they certainly aren’t saying “I only work here.”
Yeah, sorry… spell check on my iPad “helped” me with the last post. And I didn’t proof read as I should have.
What we do when we do a submission is we check everything that’s even remotely applicable. So, if we have a 64-but driver, we just check every 64-bit platform. And the driver package works on every version of Windows 10 we try it on.
Peter
I do believe we can say that for Attestation Signing, the selected platform(s) are the “minimum required versions”. Meaning as Tim Roberts said, just choosing the old TH1/TH2 platforms and nothing newer gets you all the Windows 10 platforms.
Selecting more Windows 10 platforms would add more entries to the operating system list in the .CAT file, but because there isn’t currently “a later version of Windows 10 which will consider a .CAT file attributed as TH1/TH2 to be invalid for the current platform”, there isn’t any practical effect from “selecting all Windows 10 platforms.” At least not among the x64 and x86 platforms we target; I won’t speak for ARM.
That said, we definitely did the same as Peter did, and just “selected all of them anyway” when making manual Attestation Signing submissions; even though I did test selecting just TH1/TH2 several times. But now that we have automated the Windows 10 Attestation Signing submissions, our automation is set to request only TH1/TH2 for all builds. And the .CAT is accepted as valid even on 21H1, Server 2016 and Server 2019; as well as current Server 2022 and Windows 11. For what it’s worth.
I do not yet HCK or HLK sign anything, although we’re working towards that. But the same question arises for me there. If I’m distributing a single binary (i.e. no Windows 10-specific build or binary; I do happen to be talking out our software-only drivers and network redirector; no hardware, PnP or Windows Update involved), and I have successfully HCK tested and signed even just for Windows 7 platforms, what benefit to Windows platform acceptance would come from testing for the Windows 10 platforms as well?
Because to my thinking this would be a similar scenario: There is no Windows 10 platform that currently would reject installation of a signed driver with a .CAT that specifies Windows 7 platforms. i.e. The default position of backwards compatibility forever in all versions of Windows means this “driver package created when Windows 7 was the only platform” still intentionally installs under current Windows 10 versions.
So in that case – similar to choosing TH1/TH2 in Attestation Signing as “the oldest platform so that your .CAT will be compatible with everything that came afterwards” – would a successfully HCK tested and signed package for Windows 7 be considered “the bare minimum needed to successfully load even on current Windows 10 platforms?”
Obviously this all changes if and when there is “a line drawn in the sand” where driver packages must have a .CAT targeted to something later than TH1/TH2 to be considered valid on a future Windows 10 / Windows 11 / Server 2022 platform. So I’m looking at it from the perspective of the way things are today.
So… up the thread a bit there was a question about whether the Microsoft policy has changed, and it was no longer possible to sign an HLK submission with a non-EV cert even if you had an EV Cert on-file with the Dashboard.
It’s finally been confirmed that the policy has, in fact, NOT CHANGED. As long as you have an EV Cert on file with the Dashboard, you CAN sign your submissions with a non-EV Cert (that you also have on file with the Dashboard).
The doc page has been updated, and I can go back to relaxing again.
Peter
