Windows 10 versions: use Windows Registry to obtain release Id/display name

[josephsl]

Hi,

I'd be happy to provide a pull request regarding this - after all, what I'm proposing was already implemented as part of an add-on.

Introduction

As part of Windows as a Service (WaaS) model, Microsoft releases new releases of Windows every six months or so. As of June 2021, the latest release is 21H1 (May 2021 Update).

Until Windows 10 RTM (Version 1507/build 10240), one way to determine Windows releases was build number (Windows 10 uses Windows NT version 10.0 internally). With Version 1511 (November Update released in 2015), Microsoft added "ReleaseId" (aka YYMM) to identify releases, with this info displayed as part of About Windows (WinVer) dialog. The release Id can be found under the Windows Registry path HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion.

Then in 2020, Microsoft made two related changes: the codename for a feature update became a public name for a semi-annual update, the best known being Version 20H2 (October 2020 Update). To reflect this change, a new key named "DisplayName" was added to the mentioned Registry path, which is used by WinVer instead of ReleaseId when displaying version information. If you recall, a few months ago we had a discussion about Windows 10 versions to be used (2009 versus 20H2) as part of #11795 (see that issue for details), and the new Registry key is the reason why.

The picture became complicated in 2021. As of June 2021, Microsoft is working on at least four code bases: Vibranium (2004/20H2/21H1), Iron Server 2022 and initial (and now canceled) version of Windows 10 X), Cobalt (a likely 21H2 build), and Nickel (next year and first bits may show up to dev channel Windows Insiders in a few weeks). Consequently, four build ranges were spotted by Windows Insiders: 1904x for Vibranium, 203xx for Iron, 21xxx for Cobalt, 22xxx for Nickel. As a result, it becomes harder to keep track of which release is which in the current Windows 10 version implementation, which is described below.

Is your feature request related to a problem? Please describe.

Currently winversion module includes a record of which Windows 10 release is tied to a specific build. This is used by winVersion.WinVersion class to display Windows 10 release information.

As described above, with multiple code bases being developed, it becomes harder to associate a feature update with a specific build number. This will become an issue when recognizing 21H2 later this year, as one needs to use a tuple or a similar structure to record multiple builds for a given release and look up the correct index based on product type.

Describe the solution you'd like

Retrieve Windows 10 version information (Release Id/display name) directly from Windows Registry, and to use an updated releases to builds map as a fallback if Registry access is denied. In short, the following solution (source: Resource Monitor add-on which I am currently maintaining) is proposed:

1. For Windows 10 build 10240, return "1507".
2. Look for "DisplayName" key from the Registry path noted above.
3. If it fails, look up "ReleaseId" key.
4. If Registry access is completely denied, use the refined Windows 10 releases to builds map as a fallback. I expect it won't be necessary unless Registry access is denied to user programs such as NVDA.

This solution is applicable to Windows Server releases as well i.e. Server 2019 will say "Windows 10 1809" when winVersion.GetWinVer() is called.

The biggest advantage is that there is no need to add entries to releases to builds map when making NVDA recognize new Windows 10/Server releases - all the developer needs to do is add a WIN10_* constant (for Server 2022, if it turns out the build number is different then client releases, I think it would be better to call it WIN10_VER_SERVER, or perhaps WINSERVER_2022) since the needed info comes from Windows Registry. Plus, for Insiders on dev channel, display name is "Dev", making it easier for developers to determine which Windows 10 release is in use by simply looking for "Windows 10 whatever".

The biggest issue is prerelease builds that are being tested by beta and release preview Insiders. Prior to general availability, Microsoft assigns a specific build as the feature update build, and this will be noticed by beta and release preview Insiders ahead of time by months to weeks, respectively. Therefore, to make sure people can add the correct Windows version information/constants, I propose that people should wait until a feature update is released to release preview Insiders before sending a pull request to update winVersion module (this was the route I took to add 21H1 information a few weeks ago).

Perhaps an unlikely issue is Registry access denial. I doubt this will be the case, but just in case this happens, I think existing releases to builds map should be used as a fallback to some degree.

Describe alternatives you've considered

Leave it as is and refine releases to builds map to account for a given feature release using different build numbers based on product type. One approach (although folks will need to wait until 2022.1 cycle) is change releases to builds map so that it records builds:releases instead of releases:builds.

Additional context

For a practical implementation, see:
https://github.com/josephsl/resourceMonitor

Don't worry about Windows Server LTS bits as it is not applicable to this issue. Also, if anyone would like to base a PR on bits of resource Monitor, feel free to do so.

Thanks.

[josephsl]

Hi,

For now releases to builds map will be left as is. The upcoming PR will add Registry checks as part of Windows version announcement method unless there is a need to create a separate function just for Windows 10 releases.

Thanks.