Windows version constants (API notice): deprecate Windows 7 SP1 and Windows 8 constants

[josephsl]

NOTE: edited based on comments to say "deprecate" rather than "remove".

Hi,

Stems from #12064 and #15167:

Introduction and rationale

As of NVDA 2024.1 alpha, NVDA is powered by Python 3.11. According to Python documentation, 3.11 supports Windows 8.1 and later.

While some in the NVDA community may advocate for preserving source code for historical reasons, code for enabling support for unsupported operating systems were removed in the past. In 2017, as part of 2017.4 development, NVDA stopped supporting Windows XP, Vista, and 7 without service pack 1 (SP1). Consequently, throughout 2017 and 2018 (and beyond), code supporting these unsupported Windows releases were removed. Now that NVDA 2024.1 (alpha) requires Windows 8.1, it would be best to declare in the source code that NVDA must march with the times by deprecating and removing support code for Windows 7 and 8.0.

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

NVDA source code contains support code for unsupported Windows releases. This includes Windows 7 SP1, unsupported by Microsoft in official capacity since 2020 and extended security updates ended in January 2023. Windows 8 is no longer supported by Microsoft for client systems since January 2016, with Windows Server 2012 and 2012 R2 (server version of Windows 8.1) supported until October 2023.

Describe the solution you'd like

Remove Windows 7/8.0 support code and deprecate usage of WIN7/WIN8 constants.

Describe alternatives you've considered

Leave code as is.

Additional context

As noted above, there would be community members who may object to this proposal. However, past code can be viewed by checking out Git tags representing specific releases. Comparing Git log and code diffs between tags (and branches) may offer one way to research NVDA's history. For now, 2024.1 development cycle offers a path forward in modernizing NVDA code by removing assumptions from Windows 7 era.

Specific steps:

I propose the following:

1. Remove code that mentions winVersion.WIN7_SP1 or winVersion.WIN8 throughout the source code. For example, remove status bar handling for File Explorer in Windows 7.
2. Possibly a separate issue: remove code that assumes Windows 7 or older is in use (say, Windows XP password field in LogonUI app module).
3. Mark WIN7/WIN7_SP!/WIN8 constants as deprecated.
4. Bonus: when structured pattern matching comes to NVDA Core, edit Windows version checks in winVersion.WinVersion class to use match/case statements.

Thanks.

[josephsl]

Hi,

Note the "API breaking" tag - add-ons must be edited to check for attributes if they wish to support 2023.x and earlier and 2024.1 and later.

Thanks.

[CyrilleB79]

Removing these constants may be a problem for add-ons importing them that want to remain compatible both with 2023.3 (Windows 7 included) and 2024.1.
I do not know however if there are any.

[josephsl]

Hi, this is why I suggest attribute checks for add-ons wishing to support 2023.x and 2024.1, and I don’t see add-ons using old Windows version constants at the moment (need to check source code of add-ons I have on a portable alpha with all add-ons from the store installed). Thanks.

[seanbudd]

We should not be breaking the NVDA API unless necessary or there is a notable maintenance cost.
Removing these symbols forces add-ons to immediately deprecate their Windows 7/8 code.
We should give add-on authors as much time as possible to update their code - clean up tasks like this do not need to be rushed.

If/when these get removed, add-on authors who wish to maintain long term Win 7/8 support could always do something like:

if version_year < 2024 and winV == winVersion.WIN7_SP1:

[josephsl]

Hi, as a compromise, could we mark WIN7 and WIN8 constants as deprecated throughout 2024.x and remove them in 2025.1? The code using these constants such as File Explorer status bar handling might be candidates for removal though. Thanks.

[seanbudd]

We can mark as deprecated, but there is no clear reason to remove these

[josephsl]

Hi,

Looks like deprecation is the way to go then (will edit the issue title). But first, I will send a couple PR's to remove WIN7 and WIN8 constants usage in places other than winVersion module.

Thanks.

[CyrilleB79]

If keeping these constants does not cause additional maintenance, what's the point of deprecating if there isn't a specific plan to remove these constants later?

If an add-on still wants to support NVDA 2023.3, it does not make sense to say, in 2025:
"Now, do not use these constants please; use something else"

Of course, add-on authors will still be able to use the workaround described in #15647 (comment). But why should we ask add-on authors to change their add-ons if there is no advantage for NVDA to remove these constants?

Of course, NVDA core code using these constants should be cleaned up, e.g. Explorer status bar.

[seanbudd]

@CyrilleB79 - you could make the same argument for any deprecation. Deprecations exist to warn people that alternative solutions are preferred, and that way we may remove them in future. It's an early warning system for code that has become redundant but has minimal maintenance.

[seanbudd]

it is likely that one day in the future these will be removed. 5-10 years in the future, supporting windows 7 like this will be as irrelevant as Win ME support is now.

[CyrilleB79]

I understand the mechanism of deprecation as an early warning.

@CyrilleB79 - you could make the same argument for any deprecation. Deprecations exist to warn people that alternative solutions are preferred, (...)

Why are alternative solutions preferred? Why force add-ons to implement an alternative solution if there is no maintenance cost of keeping them in NVDA?

it is likely that one day in the future these will be removed. 5-10 years in the future, supporting windows 7 like this will be as irrelevant as Win ME support is now.

I totally agree. What I do not understand is to deprecate these constants so early. It will force or encourage) add-ons supporting both 2023.3 and 2024.1 to change their implementation to avoid the warning.
If instead this deprecation is made, say in NVDA 2028.1 for a removal in NVDA 2029.1, it's very likely that most add-ons will have already withdrawn Windows 7 support (like add-ons supporting XP today); there will be only few add-ons which will need to be modified.

[josephsl]

Hi, turns out no add-ons use these constants – at least based on add-ons registered on the add-on store so far. The winVersion constants were introduced recently (I think in 2020.x), so add-ons supporting old and new NVDA versions would rely on sys.getwindowsversion to obtain major/minor/build. Thanks.

[CyrilleB79]

Hi, turns out no add-ons use these constants – at least based on add-ons registered on the add-on store so far. The winVersion constants were introduced recently (I think in 2020.x), so add-ons supporting old and new NVDA versions would rely on sys.getwindowsversion to obtain major/minor/build. Thanks.

It's an interesting information. I have checked the change log. It has actually been introduced in NVDA 2021.1.

Deprecating today means that add-on author will not be encouraged to use it (except for add-ons that have not a wide compatibility range): add-on authors will be encouraged to continue to use the old sys.getwindowsversion instead. And these constants will remain mainly aimed at NVDA code.

If it's what you want, I have no objection.

[josephsl]

Hi, at least for now, that’s the intention – remove usage of these constants at the level of NVDA Core for now and deprecate the actual constants. I expect we will revisit this once people start asking about supporting Windows 11 and later (dealing with constants representing end of life Windows 10 feature updates). Thanks.

[josephsl]

Blocked by #15665 and #15666