Hi,

Ideally, that's the plan Microsoft is gearing towards (from what I can gather from a recent GitHub discussion).

Cheers,

Joseph

Hi,

To answer both messages:

• Windows 10 20H2/21H2: I understand the need to support 21H2 at least. Not 20H2 as it will be no more by the time NVDA 2023.1 becomes widely available or close to it (if NV Access follows the schedule from earlier this year). I chose 22H2 as it is available to everyone at the moment, with Microsoft asking enterprises to upgrade to it sooner than later. Besides, I plan to end support for Windows 10 21H2 from Windows App Essentials add-on by June 2023 to align with support policy for this add-on (the add-on supports Windows 10/11 releases that are supported for consumers i.e. Home, Pro, Pro for Workstations), so I decided to align other add-ons to follow suit for consistency. I will at least reconsider adding 21H2 back to supported Windows list if I do hear justifications from corporate users, but my intention is: we are still living in the era of Windows as a Service where timely upgrading is essential.
• NVDA and older Windows releases (I'm answering this from the perspective of a third-party contributor, not NV Access): we do have developers using Windows 7, providing development and test data. Part of the reason for delaying Python upgrade to early 2024 is because the bug fix for stack corruption on certain 64-bit Windows didn't make in time for NV Access and contributors to test the newer Python release (specifically, Python 3.11.0 did not include the stack corruption bug fix but was included in 3.11.1 which came out last week). There is another issue that was found that is preventing NV Access from moving to newer Python, and that has to do with communicating with COM (component object model) functions (Mick Curran brought this up last week). Moving to say, Python 3.11 will mean we will be saying goodbye to Windows 7 and 8.x.
• 64-bit NVDA (again speaking from the viewpoint of a contributor, not NV Access): we cannot simply move to 64-bit Python because: A. Windows 10 on ARM64 cannot run x64 code (some would say this is nothing to worry about but this then would not explain why I and some folks became excited in 2017 when NVDA provided early support for ARM64), B. this requires checking the source code to make sure screen reader (and add-on) code is architecture-neutral as much as possible (a pull request I'm coordinating with NVDA add-ons community for NVDA screen reader, designed to help NVDA detect ARM64 Windows releases better, is planned to cover both 32-bit and 64-bit Python possibilities in one move), and more importantly, C. there is no known 32-bit/64-bit hybrid NVDA add-on, and using 64-bit Python means we need to build a bridge to let you all continue to use 32-bit speech synthesizers without serious problems (you cannot load 32-bit dll's inside 64-bit executables and vice versa unless a bridge like what we have with NVDA today (NVDA loader helper executable designed to communicate more effectively with certain 64-bit apps) is implemented). 64-bit is the norm these days, but also think about Windows 10 which will be the last 32-bit Windows release, so we will see 32-bit systems until at least 2031 (if you count Windows 10 Enterprise LTSC as something people should use, which I disagree as LTSC (long-term servicing channel) is meant for mission-critical devices).

There is another reason for ending support for unsupported Windows releases, including releases that have gone beyond consumer-level support (by the way, Windows 10 21H1 has just exited support): I am about to reduce the scope of some add-ons (some involving features, some involving supported Windows releases) as part of a plan to slowly reduce my presence in NVDA community. This has been ongoing somewhat, and I expect to accelerate this plan in 2023 to make way for the next group of users and developers who are more passionate about NVDA like I was ten years ago.

Cheers,

Joseph

Hi,

It is optional because of issues with UIA implementation in Chromium web browsers (hope the situation has improved by now).

Cheers,

Joseph

On Sun, Dec 18, 2022 at 03:03 PM, enes sarıbaş wrote:

Brian I also believe t maintaining support intentionally is also a waste if dropping support would have enabled enhancements to the experience for users on supported operating systems and such fixes aren't being implemented to preserve the support.

-
But given the ethos of NVDA, there will be these trade-offs, at least during transition periods.  But the transition periods should be no more than 3-years, max, preferably two, and any backward compatibility after that that is not the result of nothing breaking (yet) as development progresses is all that should be expected.

This has, literally, always been the way virtually everywhere.  The screen reader world should be no exception and, I'd say, that it's way more imperative for screen readers to do their best to keep up with "what's happening now, and coming down the line, soon," than it is to maintain backward compatibility for long periods.

To this day you can download unsupported earlier versions of NVDA if you need them for "exception environments" where unsupported Windows and/or other software is involved.  And if your choice is to maintain an exeption environment, part of that is collecting and keeping the software that is compatible with it.  That's not the job of the software houses, though some, like NVAccess, do keep archival downloads available (which is great, and other than a tiny bit of server space really requires virtually no effort after being placed).
--

Brian - Virginia, USA - Windows 10 Pro, 64-Bit, Version 22H2, Build 19045; Office 2016, Version 16.0.15726.20188, 32-bit

"Be Yourself" is the worst advice you can give to some people.

       ~ Tom Masson

On Sun, Dec 18, 2022 at 06:30 AM, Brian's Mail list account wrote:

I do not agree, At least here in the UK there are certain environments still using Windows 7, I'll not go into the whys and wherefores her, but basically, older software and hardware would not be cost effective to update until they are unusable. This tends to apply to healthcare and charity environments mostly.

-
The thing is, they can stick with "the last compatible version" of NVDA just as they're doing for all the other software they're using.

I have no objection to backward compatibility that "is simply there" because changes have not broken it.  But when it comes to intentional, ongoing support for out-of-support operating systems, that's a waste of resources past a certain transition point.  Seven years after the introduction of Windows 10 is way more than enough time to keep supporting Windows 7; it is, in my opinion, way too much time.

NVDA is still compatible with Windows 7, and expecting people, at some point, to accept the consequences of their actions - which means having obsolete versions of all kinds of things - if they elect to stay with out-of-support OSes is a direct, logical, and reasonable consequence of that choice.

And what you (or I, or anyone else) likes or prefers has never been, and will never be, something that Microsoft, the folks at the various Linux distros, or Apple take into account.  Operating systems are not bespoke software, made to fit you (any you) like a glove.  They are Swiss Army knife style software intended to allow multiple, diverse demographics to get done what they need to do.  Everyone is subject to compromises.  'Twas ever thus, and ever shall be, unless you develop your own personal OS.
--

Brian - Virginia, USA - Windows 10 Pro, 64-Bit, Version 22H2, Build 19045; Office 2016, Version 16.0.15726.20188, 32-bit

"Be Yourself" is the worst advice you can give to some people.

       ~ Tom Masson

Hi,

These are good questions, and based on discussions on GitHub and elsewhere, NVDA developers do know about the need to use something other than code injection to obtain browse mode information. In fact, that's one of the reasons for the existence of an option in NVDA settings screen under Advanced settings panel to let folks try UIA support in Edge and other Chromium based browsers.

Cheers,

Joseph

I do not agree, At least here in the UK there are certain environments still using Windows 7, I'll not go into the whys and wherefores her, but basically, older  software and hardware would not be cost effective to update until they are unusable. This tends to apply to healthcare and charity environments mostly. If the Ethos of NVDA was to support those who cannot afford the likes of Jaws, then it is a valuable fall back giving more time to those in countries and employment where the older environments still have to persist.

Myself, I don't really like the interfaces of 10 or 11 very much, I have to say, but you can get used to them. I really do think Microsoft missed a trick by not allowing skinning of newer windows to allow the learning curve to be much lower if somebody wants windows to work a certain way, forcing a change seems to me to be just not very smart marketing.
Brian

Hi Joseph,

It really does make sense for you to drop support for obsolete
OS/software. But what specific reason does NVAccess have for
continueing support for legacy OS and software, such as MS Office 2007,
Internet Explorer, Windows 7 etc? The python transition was yet again
pushed back to 2024.1. Freedom scientific got rid of 32 bit Jaws
installs, as well as dropped support for anything older than Win10 in
Jaws 2022. At this day and age NVDA should also do away with the 32 bit
version, and have a natively 64 bit version that runs on a modern
version of python, and have an official support lifecycle policy that
would be followed for all legacy software. The time that is spent
maintaining support for old software is taking away the time that could
have been spent on improving support for modern software, browsers and
operating systems. For the last year or so I have been contemplating
switching screen readers due to this.

On 12/17/2022 12:08 PM, Joseph Lee wrote:

Hi all,

Hope you are celebrating holidays safely (remember that we are still
going through a once in a century pandemic).

Before taking a holiday break myself (Christmas and New Year), I would
like to talk about what to expect with my add-ons in January 2023 (at
least give you a preview of new and changed features in various
add-ons; add-ons include Add-on Updater, Enhanced Touch Gestures,
Event Tracker, GoldWave, Object Location Tones, ObjPad, Office Desk,
Resource Monitor, Sound Splitter, StationPlaylist, Windows App
Essentials). But first, a few important reminders:

* Windows release requirement: this is another (and hopefully my
last) reminder that, effective January 3, 2023, all of my add-ons
except Add-on Updater will require Windows 10 or later,
specifically Windows 10 Version 22H2 (2022 Update) or later.
Although version 23.01 of my add-ons will tell you that Windows 10
or later is required, updates scheduled to be released shortly
after NVDA 2023.1 beta 1 is released will actually enforce Windows
10 22H2 requirement. This is done for consistency across my
add-ons and to get you to use supported Windows releases. The only
exception is Add-on Updater as it will support older Windows
releases in case you do need to use Windows 7, 8.1, or older
Windows 10 releases with various add-ons (only use older Windows
releases if you must, more so if your computer is part of a
corporate domain; for others, PLEASE UPGRADE SOONER THAN LATER, IN
2022 RATHER THAN WAITING UNTIL MIDDLE OF 2023!); by the way, as a
tangent note, in case you didn’t hear, Chrome (and Firefox if I
remember correctly) will end support for soon to be unsupported
Windows releases (7 and 8.x) in early 2023.
* NVDA version requirement: currently most of my add-ons (mostly
ones I’m no longer actively maintaining) are running happily on
NVDA 2021.x, but that has come to a close; in recent days I have
committed a set of changes to several add-ons, especially
StationPlaylist add-on that will use features introduced in NVDA
2022.x. Version 22.12 of the add-ons I have released a few days
ago are the last releases to support NVDA versions earlier than
2022.3; come January 2023, and you will be asked to use 2022.3 or
later.

As for what’s included in upcoming add-on releases, these can be
roughly divided into three parts:

* Dependency updates: Resource Monitor and Sound Splitter will use
the latest version of psutil dependency.
* Visible and invisible changes: visible changes include letting you
reassign additional touch commands in Enhanced Touch Gestures
(most notably touch keyboard toggle, currently four finger flick
right by default), minimum Windows version check in Add-on Updater
(only some repositories), and a change to announce exactly which
system architecture Windows is reporting in Resource Monitor (x86
= 32-bit Intel/AMD processors, AMD64 = 64-bit Intel/AMD systems,
ARM64 = 64-bit ARM processors). In particular, the change to be
made to Resource Monitor add-on serves as a test for a change to
be submitted to NVDA source code. StationPlaylist add-on has been
significantly updated, with one notable change being removal of
first/last playlist viewer column commands (Control+Alt+Home/End
keys) as NVDA 2022.2 and later includes these commands.
* Bug fixes: mostly applicable to Windows App Essentials. A number
of bugs found while using apps such as Maps app were fixed, as
well as preparing NVDA to support future Windows 11 Version 22H2
(2022 Update) features (currently tested by Windows Insiders). In
particular, NVDA will let you use mouse and/or touch to interact
with parts of Windows 11 22H2 user interface that will be changing
in 2023 (if you are curious, do a Google search for Windows 11
22H2 redesigned taskbar).

Add-on release schedule and follow-up activities:

* December 26, 2022: NVDA 2022.3 requirement will be turned on from
Add-on Updater for my add-ons.
* January 3, 2023: version 23.01 of my add-ons will be released.
People using soon to be unsupported Windows releases (7, 8, 8.1)
will see an installation message, telling you that the add-on
requires Windows 10 or later.
* No later than January 10, 2023: minimum Windows version
requirement will be turned on from Add-on Updater if add-on update
source is set to community add-ons website.

Hope this helps. Have a safe and healthy holiday season (Merry
Christmas and Happy New Year). See you in 2023!

Cheers,

Joseph

Hi,

I think NVDA may as well end support for Windows 10 around say, 2027 or 2028, but things can change without notice - Windows Server 2022, the last substantial "Windows 10" release from Microsoft, will go out of support in 2031, with Windows 10 Enterprise LTSC 2021 for IoT going out of support a few months later (early 2032).

As for performance improvement on x64 if NVDA is running as a 64-bit Python interpreted app, I expect some improvements but not much, as the bottleneck here is CPython. But in theory, because NVDA does not have to ask a bridge to talk to 64-bit apps, I expect some improved performance as long as Python keeps up with it.

As for steps for add-on authors: any add-on that fall under one or more categories are affected:

• Add-ons working with 32-bit DLL's or pyd files
• Add-ons needing to deal with differences between 32-bit and 64-bit apps

This mostly affects speech synthesizer add-ons as some load 32-bit DLL's, so they need a 32-bit to 64-bit bridge to run under 64-bit NVDA/Python. This gets complicated if we're talking about ARM64 Python/NVDA as it will then need to go through Wow64 emulator (called xtacache, or x86 to ARM instruction cache) if the add-on components are not recompiled for ARM64. This would be feasible if the DLL in question is open-source, otherwise a bridge is one of the ways to get them to talk to 64-bit NVDA. And since commercial synthesizers (at least many of them) come with closed-source DLL's, the best route is asking synthesizer vendors for 64-bit DLL's and bundle them alongside 32-bit DLL's, in effect creating a hybrid architecture (32-bit/64-bit) NVDA add-on.

For others: a good analogy that summarizes the latter part of this thread is multilingual translation and interpretation. Suppose you are having a conversation with somenoe who may not speak the same language as you. You can go about it in a number of ways:

• Speak a common language: globally, English is one of the common languages for communication among speakers of different languages. This is akin to exchanging data via protocols when a 32-bit app wishes to talk to 64-bit application, using a common data that both apps can understand.
• Ask for an interpreter or a translator: the translator or interpreter should be familiar iwth language, customs, and cultures of speakrs. This is akin to a bridge where a 32-bit app asks the bridge it has brought to talk to 64-bit apps on its behalf, with the bridge translating wht 64-bit apps are saying to the 32-bit app. This is the approach taken by portions of NVDA when it needs to communicate with certain 64-bit apps in a method that involves code injection, most notably browse mode generation.

P.S. I'm sure some of you can feel my enthusiasm whenever I talk about computer hardware and operating systems. After all, these are important subfields of computer science and engineering, and that's the area I was interested in studying back when I was an undergraduate student. I didn't get a chance to study computer architecture in college, but writing NVDA code helped me understand bits of it here and there. Even though I have moved on from engineering in graduate school, I still return to computer science from time to time to keep up with things and to exercise storytelling skills (one more semester to go before I can append an M.A. to my name).

Cheers,

Joseph

Hi,

What I say is strictly my own opinion (for others, the below message will get quite geeky, so please hold on):

There is really no justification for using Windows 7 in 2022 unless the corporate environment requires it for running specific tasks and apps (Visual Studio 2022 does allow compiling an executable to run on Windows 7).

As for ARM64 support by JAWS: jfw.exe (JAWS executable) is an x64 application, meaning that it does require Windows 11 on ARM64 in order to run on ARM64 processors. Because Windows 11 on ARM64 can run 32-bit and 64-bit x86/x64 applications, JAWS must be given an opportunity to hook into x86/x64 apps, similar to how NVDA can support ARM64 apps on Windows 10 and 11 on ARM64. Vispero did say that some features are unavailable in ARM64 JAWS, and I think because not all modules used by JAWS are 64-bit compatible yet.

As for two 64-bit NVDA releases (again speaking from the viewpoint of a third-party contributor, not NV Access): I'm sorry to say that this cannot be done easily for now. This requires a native ARM64 version of Python, and this came about with Python 3.10 or 3.11 (not sure at the moment). At least this may allow folks to think about that possibility from 2024 onwards. But not all Python dependencies are ARM64 ready, most importantly wxPython - there is no known ARM64 build, so you can't just squeeze in AMD64 CPython extension (.pyd file) inside an ARM64 Python interpreter. Also, because there is no known ARM64 port of wxPython, it must be built from scratch under ARM64 Python, which may introduce compilation issues. The lengthy compilation step has been worrisome for NV Access and contributors because Appveyor, the continuous integration provider NVDA developers use, impose a 60 minute time limit to compile a software build (recent NVDA alpha builds took about 30 minutes or more to compile and run tests).

Also, as I noted in an earlier reply, some parts of NVDA source code are not really architecture neutral - take NVDA Helper, for instance which starts a remote helper loader executable if running on 64-bit systems, one per instruction set architecture or processor architecture (ISA; an ISA is a collection of commands and machine language that describes a central processing unit (CPU), and Intel/AMD ISA is different than ARM's). For example, on a Windows 11 on ARM64 machine such as Microsoft Surface Pro X, NVDA is seen as a 32-bit x86 application, so Windows runs a part of WoW64 (32-bit Windows on 64-bit Windows) that is really an x86 emulator - the emulator starts BEFORE NVDA itself starts. NVDA, running inside the x86 emulator, detects that you've got an ARM64 computer, so the NVDA Helper portion starts the Remote Helper loader executable compiled for ARM64. There is an obvious flaw on Windows 11: what happens if someone runs an AMD64 application? This is the problem described by the following GitHub issue and a fix is in the works: https://github.com/nvaccess/nvda/issues/14397

So what if a native ARM64 port of NVDA runs inside Windows 11? No WoW64 to worry about, but then a bigger problem arises (well, two problems really): how can NVDA work with x86/x64/32-bit ARM code (and for NVDA, x86/x64 add-on code)? This means two or more NVDA Helper loader executables must run, one per processor architecture: x86, and x64 (32-bit ARM if NV Access decides to compile the helper loader executable for it). The advantages and disadvantages of what I'm talking about are summarized below:

NVDA processor architecture	Natively supported architecture	Supported Windows releases	NVDA Remote loader executables	Processor architecture for add-ons and notes
x86 32-bit	32-bit x86 programs	All Windows versions released so far	AMD64, ARM64	32-bit add-ons will work natively
x86 64-bit (x64)	x64 programs	64-bit Windows releases except Windows 10 on ARM64	x86, ARM64	A 32-bit bridge must be created to run 32-bit add-ons, x64 add-ons will run natively
ARM64	64-bit ARM programs	ARM64 Windows 10 and later	x86, x64	A 32-bit bridge must be run at all times to work with 32-bit add-ons with extra steps involved

I will talk about how NVDA gets compiled in a future post (upon request). Again my apologies for going too geeky in this post.

Cheers,

Joseph