Windows version: introduce winVersion.WinVersion class to serve as a hub of Windows version information for the system

[josephsl]

Hi,

Stemming from PR #11796 discussion:

Background

Python provides sys.getwindowsversion(), returning Windows version information as a named tuple. By default, the first five fields (major, minor, build, platform, service pack) are printed. NVDA uses this name tuple in a variety of places, including Windows version text (log output), build checks in various places, and more recently, winVersion.isWin10 function returning if the system is running a given Windows 10 release or later.

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

Until early 2020, Windows 10 feature updates can be represented as integers, such as 2004 for May 2020 Update (build 19041). This changed officially with October 2020 Update when the feature update version is designated "20H2". For an extensive discussion surrounding this, see #11795

In addition, Microsoft released Windows 10 in S mode (formerly Windows 10 S), which was optimized for schools. Among other things, it does not allow installation of third-party classic (Win32/desktop) apps apart from repackaged apps published to Microsoft Store (NVDA is one of them now). Although NVDA will know about running as a converted desktop app, it doesn't know if it is truly running on regular or S mode of Windows 10. Making matters complicated is upcoming Windows 10 X, which will try to use virtualization to run desktop apps, impacting NVDA and accessibility.

Describe the solution you'd like

To help mitigate #11795 and to support detection of specific editions and feature sets, introduce WinVersion structure as part of winVersion module. This class will serve as a hub of Windows version information for the system NVDA is running on. Attributes can include whether or not this is a Windows 10 system, if it is a server running Desktop Experience (servers only), sub-edition in use (S mode, X, etc.) and so on.

The biggest benefits are:

• Allowing NVDA to truly detect if it is running on Windows 10 in S mode or as a virtualized app under Windows 10 X.
• Eases comparison between ideal and actual Windows 10 feature updates, useful for checking if the system is running a specific feature update.

Required attributes and methods

• Major (integer property): major version of Windows
• Minor (integer property): the minor Windows version
• Build (integer property): the current build number
• Platform (integer property): what kind of platform the system is presenting as (client, server, etc.)
• Service pack (integer property): service pack level
• isWin10 (method): a boolean method, replacing winVersion.isWin10 function
• Windows 10 feature update to build map (map): transfer the dictionary defined in winVersion module to the class
• win10Release (string property): the actual feature update version in use by the system (either look up Windows Registry or use feature update to build map)
• isWin10S (boolean property): if the system is running Windows 10 in S mode
• isWin10X (boolean property): same principle as isWin10S
• Comparison operators (magic methods): useful for comparing current Windows version with an arbitrary WinVersion class instance

The constructor can take an optional "versionn" argument (string). It can accept:

• Nothing, in which case WinVersion will construct version information for the current system.
• "7", "8", "8.1": will set appropriate major/minor/build/service pack info and such.
• "10" or any feature update string (such as "1507" and "20H2"): set major to 10, minor to 0, look up the build from feature update to build map, throwing errors if the build is not present.

At a minimum, comparison operators must check major, minor, build, and service pack.

Describe alternatives you've considered

Either:

• Leave the code as is
• Refine winVersion.isWin10 function as described in PR winVersion.isWin10: accept both int and str for Windows 10 version parameter #11796

Additional context

See #11795

Thanks.

[feerrenrut]

This looks good, but I think more thought should be put into the construction:

• Rather than creating a WinVersion for the running OS when no args provided (an implicit behavior), I'd prefer an explicit behaviour, Eg a method on the module getRunningWinVersion() or getActiveWinVersion() or getOSWinVersion().
• I'd prefer dedicated keyword arguments in order to construct from the different types of version information. Otherwise it could become really painful when there is some ambiguous case. We could add a helper to the module to construct from string and raise on ambiguous cases. When this happens it's good to be able to fall back on the explicit version with multiple keyword args.

[josephsl]

Hi, the first item can be done via a new winVersion.getWinVersion or similarly named function, and the second will require some thought and employing regular expressions (or maybe not a regexp; it turns out Add-on Updater does include this possibility, so I can donate that portion of that add-on to Core). Thanks.

[feerrenrut]

I'd leave the tricky part as a "nice to have". It could be added subsequently. Getting the core of this in place is more important.

[josephsl]

Hi, thankfully it can be tested as a standalone Python module, and using functools.total_ordering decorator means we don’t have to define all rich comparison operators (all that we need is __eq__ and _ge__). I’ll submit a pull request that will introduce this class and getWinVer function once 2020.4 beta is released (I think the new code should target 2021.1 cycle). Thanks for the reminder.