Hi,

Note: PR based on beta branch as master branch was merged into it last week.

Thanks.

My general thoughts are that:

1. As much as possible, drop references to Windows versions, directly, at all. There needs to be an understanding, in the age of Windows as a Service, and with Windows 7 now being dead, that "currently supported versions of Windows" is what Windows, not otherwise categorized, means. With Microsoft ditching it's, "Windows 10 is the final version of Windows," stance, we have no idea how long it will be until Windows 12 (or something else, will follow). It makes sense to me to avoid version specification to the greatest extent possible.
2. Bit depth of Windows is very rapidly becoming irrelevant. It has been ages since 32-bit hardware was produced. 32-bit software routinely runs under 64-bit hardware and, as you note, very soon even 32-bit hardware will not be supported by the very latest version of Windows.

There needs to be an acknowledgement that being too specific with regard to Windows versions makes documentation a nightmare. One could put something either at the beginning, or end, of the documentation that says something like, "Windows is construed to mean Windows 10 (32 or 64-bit), Windows 11 (64-bit only), and any successors."

The main body of the documentation should strive to be as broadly applicable as possible, with specifics defined once, wherever is felt appropriate.

I would generally support @britechguy's changes here, but perhaps they should be in a follow up PR as this might be contentious.

We do need to be specific with versions we support somewhere, as it can be why someone may or may not upgrade or buy a device.

I would support changing this documentation to be more general, but maybe by specifically defining "Legacy Windows (<10)" and "Modern Windows (10+)". That way we can minimise changes for support being dropped for Legacy Windows or new Windows being supported. Most of the changes here used groups of "Modern Windows" or "Legacy Windows". Windows 7 support will be dropped with the next Python upgrade. While these changes occur fairly rarely, it might be helpful for readers to be able to track the changes consistently all in one place.

I'm not sure the value is in specifying the Bit depth of in Windows, other than confirming that all available versions are supported. However, I'm also hesitant to change this, as 32bit support is getting worse as we progress into the future. For example, the screen curtain does not currently work on Windows 7 due to the Windows API not fully supporting WOW64 (Windows 32bit programs running on 64bit Windows) (it's possible this is the cause of the Windows 11 problem too, I'm currently investigating this). In fact, in general the API we use for screen curtain is (now) no longer supported for WOW64: "The Magnification API is not supported under WOW64; that is, a 32-bit magnifier application will not run correctly on 64-bit Windows.". We currently cannot update to python3.8+ due to a bug with 32bit support.

@seanbudd wrote, in part, " Windows 7 support will be dropped with the next Python upgrade."

If I am not mistaken, this will be a part of 2022.1, so in terms of development pipeline that's the very near future. I know that Freedom Scientific's changes in the same time frame will even drop support for Windows 8.x. Essentially, everything we consider to be Windows Legacy is going to be completely out of support in the clearly foreseeable and not-too-distant future. I don't know when NVDA might have Windows 8.x fall out of support. Might it be even before January 2023?

Perhaps another PR is needed, I'm not arguing about that, or anything, really. But the days of Windows Legacy are numbered, and very, very close to their end. Focus should be more on how these references will be purged going forward rather than maintained.

We are so far in to the Windows 10 era (and I include the forthcoming Windows 11 as part of that) and so near the end of all that came before that planning for the demise of all that came before really does need "front and center" consideration.

@britechguy - the upgrade to Python3.8+ is currently blocked by the issue Joseph described. Python 3.8, which is the last version that supports Windows 7, has an EOL of 14 Oct 2024. So we will drop Windows 7 support sometime before then, but it may not be in 2022.1

@seanbudd,

Thanks for the clarification.

If there's a choice between positioning NVDA to move "boldly into the future" that breaks backward compatibility with Windows 7, and maintaining that compatibility, I fall firmly in support of the former.

Any compatibility, of anything, with Windows 7 at this point in time should not be a priority and should only occur if it is a an accidental compatibility maintenance. There are lots of things that remain compatible because the next major update that would break it has not occurred yet. But Windows 7 is dead, and no hoops should be jumped through to maintain backward compatibility.

To follow-on to Joseph's comment, and knowing that the SAPI4 issue is separate from this one, I have been down the road of endlessly trying to extend compatibility with dying technologies at many junctures in the past. It is, no matter how well someone or some group likes something, just not worth doing.

When the writing is clearly on the wall that support for a given thing is going to go away, sometimes so clearly written that a date has been given, it is always better to plan for a clean break in advance of the actual "drop dead" date.

I can't count the number of things I've loved that I've lost over the years in the world of technology, but that's part and parcel of the arena. And smart development teams plan for graceful departures, which often means bowing out before something literally gets pulled away from you.

I've seen a couple of instances where projects essentially decided they were going to keep clutching a metaphorical corpse, and the results are invariably not pretty.