Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 8  
12 Jun 18 14:36
David F.
xxxxxx@terabyteunlimited.com
Join Date: 12 Jan 2012
Posts To This List: 118
DriverSigning Selection of Windows Versions?

Hi, While the authority on the subject are here, there is another issue that has confused me lately (I may have asked in the past). When you submit for signing, you have the option to sign for various windows versions. 1607, RS2, RS3, RS4, etc.. (I don't even know what is meant by the RSx version, but know it works on all the latest windows versions and insider preview versions, looking it up looks like a new naming style for the various releases), but the question is, do you have to check the box for all the OS versions for the driver to work on on those versions or can you say select the lowest supported version and that works on all the newer versions? TIA!!
  Message 2 of 8  
12 Jun 18 15:01
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 127
DriverSigning Selection of Windows Versions?

On Tue, Jun 12, 2018 at 1:36 PM, xxxxx@terabyteunlimited.com <xxxxx@lists.osr.com> wrote: > Hi, > > While the authority on the subject are here, there is another issue that has confused me lately (I may have asked in the past). When you submit for signing, you have the option to sign for various windows versions. 1607, RS2, RS3, RS4, etc.. (I don't even know what is meant by the RSx version, but know it works on all the latest windows versions and insider preview versions, looking it up looks like a new naming style for the various releases), but the question is, do you have to check the box for all the OS versions for the driver to work on on those versions or can you say select the lowest supported version and that works on all the newer versions? > A past response indicated the driver would be brought forward properly if you only checked the oldest version, at least for Windows 10. Someone might be able to provide a citation or the behavior of other releases.
  Message 3 of 8  
12 Jun 18 17:16
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12023
DriverSigning Selection of Windows Versions?

xxxxx@terabyteunlimited.com wrote: > When you submit for signing, you have the option to sign for various windows versions. 1607, RS2, RS3, RS4, etc.. (I don't even know what is meant by the RSx version, The first release of Windows 10 was codenamed Threshold.  You saw that referred to in internal documents as TH.  The first update was TH2. The first big refresh of Windows 10 was codenamed RedStone.  Its releases were RS1, RS2, etc. There does seem to be a bit of schizophrenia in terms of version naming.  We used to have service packs and build numbers; now we have codenames, marketing names ("Creator's Update"), builds, and date codes. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 4 of 8  
13 Jun 18 02:10
David F.
xxxxxx@terabyteunlimited.com
Join Date: 12 Jan 2012
Posts To This List: 118
DriverSigning Selection of Windows Versions?

Okay that's good info, but if I choose to sign for TH2, then does that mean the signature will be good to to that version and the newer ones? The first response seems to recall that, was just looking for clarification.
  Message 5 of 8  
13 Jun 18 10:23
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6254
List Moderator
DriverSigning Selection of Windows Versions?

<quote> choose to sign for TH2, then does that mean the signature will be good to to that version and the newer ones </quote> I believe so. But, why not do what WE do... select them all. Collect the whole set! Peter OSR @OSRDrivers
  Message 6 of 8  
13 Jun 18 10:54
Alan Adams
xxxxxx@novell.com
Join Date: 20 Dec 2010
Posts To This List: 34
DriverSigning Selection of Windows Versions?

> ...if I choose to sign for TH2, then does that mean the signature > will be good to to that version and the newer ones? The only known effect that I'm aware of is the OS attribute that gets created in the .CAT file, which Windows will use to declare whether the .CAT file is suitable for installation on the running version of Windows. For example on a .CAT signed during RS3 release time frame with all available platforms selected, the .CAT ended up with an OS attribute of "_v100, _v100_X64, _v100_RS1, _v100_X64_RS1, _v100_RS2, _v100_X64_RS2, _v100_RS3, _v100_X64_RS3". My empirical test was to sign one of our product builds by selecting only the TH1 1507 platform (OS = "_v100, _v100_X64"), and then attempting to install the signed product on the then-current RS3 platform. This worked, as expected. By "as expected" I mean that I expect any version of Windows 10 to accept a Microsoft-signed driver even if it was only signed and OS-attributed for a Windows 8.1 or earlier platform; let alone simply an earlier version of Windows 10 itself. Backwards compatibility demands that this be true where ever possible. Neither the HLK process nor the attested signing process require that we "re-sign and re-publish our drivers every time a new Windows 10 platform is released." Hence the expectation that signing with only the oldest TH1 1507 platform would be accepted for all subsequent platforms, too. Because at some point in the past, TH1 was the only platform we even COULD select during attested signing, and those drivers are still able to be installed and used on today's platforms. I'm not aware of any compelling reason NOT to select all platforms you're compatible with, similar to what Peter recommended. But at least in my software-only non-PnP driver case, there is no known benefit to selecting anything other than the oldest platform, either. Alan Adams Client for Open Enterprise Server Micro Focus xxxxx@microfocus.com
  Message 7 of 8  
13 Jun 18 11:10
Bob Ammerman
xxxxxx@ramsystems.biz
Join Date: 05 Jun 2016
Posts To This List: 56
DriverSigning Selection of Windows Versions?

Correct me if I am wrong... The idea of selecting supported versions is that Windows will automatically 'adapt' to a down-level driver. Thus, if you say you are compatible with RS2, for instance, a newer version of Windows will ensure that your driver doesn't see anything that is new in RS3, for example, that might break it. This is certainly the way it happens with manifests on user mode programs. * Bob ? Bob Ammerman ? xxxxx@ramsystems.biz ? 716.864.8337 138 Liston St Buffalo, NY 14223 www.ramsystems.biz -----Original Message----- From: xxxxx@lists.osr.com <xxxxx@lists.osr.com> On Behalf Of Alan Adams <xxxxx@novell.com> Sent: Wednesday, June 13, 2018 10:53 AM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: Re:[ntdev] DriverSigning Selection of Windows Versions? > ...if I choose to sign for TH2, then does that mean the signature will > be good to to that version and the newer ones? The only known effect that I'm aware of is the OS attribute that gets created in the .CAT file, which Windows will use to declare whether the .CAT file is suitable for installation on the running version of Windows. For example on a .CAT signed during RS3 release time frame with all available platforms selected, the .CAT ended up with an OS attribute of "_v100, _v100_X64, _v100_RS1, _v100_X64_RS1, _v100_RS2, _v100_X64_RS2, _v100_RS3, _v100_X64_RS3". My empirical test was to sign one of our product builds by selecting only the TH1 1507 platform (OS = "_v100, _v100_X64"), and then attempting to install the signed product on the then-current RS3 platform. This worked, as expected. By "as expected" I mean that I expect any version of Windows 10 to accept a Microsoft-signed driver even if it was only signed and OS-attributed for a Windows 8.1 or earlier platform; let alone simply an earlier version of Windows 10 itself. Backwards compatibility demands that this be true where ever possible. Neither the HLK process nor the attested signing process require that we "re-sign and re-publish our drivers every time a new Windows 10 platform is released." Hence the expectation that signing with only the oldest TH1 1507 platform would be accepted for all subsequent platforms, too. Because at some point in the past, TH1 was the only platform we even COULD select during attested signing, and those drivers are still able to be installed and used on today's platforms. I'm not aware of any compelling reason NOT to select all platforms you're compatible with, similar to what Peter recommended. But at least in my software-only non-PnP driver case, there is no known benefit to selecting anything other than the oldest platform, either. Alan Adams Client for Open Enterprise Server Micro Focus xxxxx@microfocus.com --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 8 of 8  
13 Jun 18 13:07
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12023
DriverSigning Selection of Windows Versions?

xxxxx@ramsystems.biz wrote: > The idea of selecting supported versions is that Windows will automatically 'adapt' to a down-level driver. Thus, if you say you are compatible with RS2, for instance, a newer version of Windows will ensure that your driver doesn't see anything that is new in RS3, for example, that might break it. Nope, it doesn't work that way in the kernel.  The CAT file is used when the driver is installed -- you'll get a warning that "this driver is not compatible with this version of Windows -- but after the driver is installed, the CAT file is never used again.  It stays in the driver store, and is not part of driver loading. What that means is that the kernel has an enormously painful burden to maintain backward compatibility.  The RS3 kernel simply cannot introduce any service changes that break XP drivers.  It can introduce NEW services, and the CAT file will insure that a driver that needs those new services won't install on a system that doesn't have them, but it can't break existing services. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 19:44.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license