WinVer Windows 10 release identification

[Anders]

I'm considering adding more detailed Windows 10 detection support to WinVer and I'd like to get some feedback on the API design. How should each release be identified?

Technical note: Anything other than the build number will most likely require a lookup at compile-time and therefore a new NSIS release will be required to support new Windows 10 releases. If we choose something other than the build number, a macro for the build number will still be available.

[T.Slappy]

I voted for Build number, I think it is the most common way.

[Anders]

I voted for Build number, I think it is the most common way.

MSDN actually seems to use the date:

Minimum supported client:
Windows 10, version 1511 [desktop apps only]

but there is no API to retrieve this date AFAIK. I'm not even sure if this number is documented as a date (or even documented anywhere on the developer pages on MSDN for that matter).

https://developer.microsoft.com/en-u...windows-10-sdk manages to use "Fall Creators Update", "10.0.16299.91" and "1507" on the same page. https://docs.microsoft.com/en-us/win...10-build-10586 and https://docs.microsoft.com/en-us/win...10-build-16299 starts off with "Windows 10 build 10586 (also known as the November Update or version 1511)" and "Windows 10 build 16299 (also known as the Fall Creators Update or version 1709)" which is not really helpful.

https://docs.microsoft.com/en-us/win.../waas-overview calls the date version "feature updates":

Because feature updates are delivered more frequently than with previous Windows releases — twice per year, around March and September, rather than every 3–5 years

[prisma86]

I voted for Release Date, because in case of support customers mostly know, oh, yes, I just got the 1803 Update ( f*** ) They never know about a build number.

[sai20180]

Windows 10 release identification

many users of Windows 10 have a solid idea of which build they are on. In fact, most consumers likely do not know, and that is an OK thing. Windows 10 should be transparent, and users should not have to know the exact build of the OS they are running.

Windows Insiders, however, are a different breed. You, folks, like to keep tabs on every release and sometimes, just sometimes, you may have forgotten which build you are on. Alternatively, sometimes things update but you do not know what changed.

[Anders]

We have decided to try to support all variations. Give https://sourceforge.net/p/nsis/code/...ude/WinVer.nsh a try.

${If} ${AtLeastWaaS} 'Fall Creators Update'
...

[StevenRosenberg]

Winver_2019

When will the proper values be added to the WinVer.nsh for Windows 2019 x64?

I understand the version is 10.0.17763, but it is not clear what the hex number value will be for the WINVER_2019_NT and WINVER_2019 defines?

[Anders]

When will the proper values be added to the WinVer.nsh for Windows 2019 x64?

I don't know if we will continue adding these defines since they are all "Windows 10" but you can check for a specific build on your own:

${If} ${AtLeastBuild} 17763 ; Or use ${AtLeastWaaS} 1809
${AndIf} ${IsServerOS}
  ...
${EndIf} 

I frankly don't understand how server versions work anymore.

Take https://docs.microsoft.com/en-us/win...s-server-1809# for example, it says:

In addition to features that are new in Windows Server version 1809, the following new features and capabilities for Windows Server 2019 also apply to Windows Server version 1809

but 1809 is version 10.0.17763 so what is the difference between "Windows Server 2019" and "Windows Server version 1809"? Since there are two "releases" per year, does that mean that there will be two versions of "Windows Server 2019"?

Microsoft does not really want people to do version checks anymore. If you require a specific feature you should try to detect that feature if possible instead of checking the version.