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

josephsl · 2021-06-03T04:03:45Z

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:

For Windows 10 build 10240, return "1507".
Look for "DisplayName" key from the Registry path noted above.
If it fails, look up "ReleaseId" key.
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 · 2021-06-12T21:36:16Z

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.

…ccess#12509. From Widows 10 Version 1511 (November Update/build 10586), WinVer (About Windows) dialog uses Windows Registry to obtain version information (build 10240 wsa retroactively named '1507' then). Initially 'ReleaseId' key was used, but since 20H2, 'DisplayVersion' is used (ReleaseId for 20H2 is 2009). The Registry method is needed to support multiple Windows 10 builds with same display version. Currently release Id's to builds map contains one to one mapping between versions and builds, whereas in 21H2 development cycle, up to three builds may represent this release. Therefore use Registry method to detect all public Windows 10 releases.

…ager. re nvaccess#12509. Advised by Leonard de Ruijter: use context manager (with) associated with Windows Registry HKEY handles (of the form 'with winreg.openKey(HKEY, path) as something').

… Re nvaccess#12509. Windows 10 releases to builds map records feature update release names to builds (e.g. '1903': 18362). With the Windows Registry method in place, coupled with several build branches for Version 21H2, it makes sense to remove an unused dictionary.

…ess#12509. Advice from Reef Turner (NV Access): define a 'release name' atribute to set the public facing name for a Windows release such as 'Windows 7' for 6.1.7600. This is useful for Widows 10 due to many major updates released since July 2015.

…#12509. If release name is defined, return this as the version name e.g. if 'releaseName' is 'Windows 10 1511' for build 10586, return 'Windows 10 1511' instead of using release names to builds map and/or Windows Registry. Note that the implied 'else' block is not indented.

…ess#12509. Although release name texts are useful for Windows 10, apply this change to all constants (Windows 7 and 8.x also).

Note that on server systems, unless otherwise noted, client relesae names are returned. The first such exception is likely the erver counterpart of Windows 10 21H2 (Server 2022) which may have a different build than client releases.

Review by Reef Turner (NV Access): in winVersion.getWinVer() function, instead of opening Windows Registry to obtain Windows 10 each time the function is called, have the version string handy from the beginning. Note that Release Id and display version are not found on Windows 10 1507 (build 1024) or earlier.

Advised by Reef Turner (NV Access): define a unit test to compare release names, specifically to simulate winVersion.getWinVer but with a constant. Because repr(winVersion.getWinVer()) includes release name, major.minor.build, and product type in one go, use asertIn to test the expected string (in this case, 'Windows 10 1607' for Server 2016).