Preview: what's included in Joseph Lee's add-on updates in January 2023


 

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


Cyrille
 

Hi Joseph

You had already communicated about the compatibility restrictions about to come for add-ons you are maintaining. But I just realize their impact today. Better late than never...

I am a bit concerned by the fact that you will allow add-ons to update only for users running the last versions of Windows, specifically Windows 10 22H2. Looking at supported versions of Windows, you can see that windows 10 20H2 and 21H2 are supported until mid-2023 and mid-2024 for Enterprise versions. When NVDA 2023.1 will be released, maybe around April 2023, people in corporate environment who do not have the choice of the Windows version will need to choose between NVDA upgrade or using your add-ons. I have specially in mind:
- Office Desk, since Office is widely used in corporate environment
- Sound splitter, since it is often used during online meetings

Is there a reason why you put some restrictions on supported versions of Windows? Given the explanations above, would you mind reconsidering your quite aggressive requirement related to Windows versions?
Thanks.

Happy holiday, merry Christmas and happy new year.
Cheers,

Cyrille





On Sat, Dec 17, 2022 at 07:09 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


enes sarıbaş
 

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


David Lenton
 

On Sat, Dec 17, 2022 at 06:09 PM, Joseph Lee wrote:
Visible and invisible changes: visible changes include letting you reassign additional touch commands in Enhanced Touch Gestures
Joseph

My son is really pleased that you will add the above functionality. It will help greatly help him, as he cannot bend his finger enough to do three and four finger gestures

He asked could you possibly include multi direction gestures like those used in Android's talk back screen reader. His examples were 1) "Swipe left then up", "Swipe up, then swipe down again". It was just a suggestion to consider if you have the time. Thank you for your support. 

David 


 

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,

If only NVDA had support for multi-directional gestures, then yes, I might have added it. Keep in mind that most two-finger gestures are already assigned, so the space is limited at this time (as in not many open gestures are left for two fingers). Note that this change will be done in two phases: version 23.01 will show additional touch command descriptions in Input Gestures dialog in English at first, then an update later in 2023 will present localized descriptions. You don't have to wait until the second phase to reassign gestures.

Cheers,

Joseph


enes sarıbaş
 

Hi Joseph,

What justifiable reason is there to use Windows7?  Windows 7 is only in  ESU support to my knowledge, and even that will end next month.

For Arm, how did Freedom Scientific achieve ARM compatibility with 64 bit Jaws?  Could NVAccess have two builds of NVDA, for ARM and Windows X64?

On 12/17/2022 6:56 PM, Joseph Lee wrote:

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,

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


enes sarıbaş
 

Hi Joseph,

I do recall Jaws did have a majority of features working in arm, and braille, and vocalizer, as well as working with 32 bit arm were only limitations currently.

Thank you for the very detailed post.  All of this makes sense now, when I read this, and I understand based on what you describe that a 64 bit build of NVDA will require a very substantial amount of work.  For addressing arm though,  can't NVAccess drop support for Win10 ARM when microsoft sunsets Windows 10?  That would only require the x86 bit bridge the way you described it.  And would there exist performance improvements when interacting natively with x64 apps?

As for addons, how much work would addon developers have to do to port 32 bit addons to 64 bit?


On 12/17/2022 8:57 PM, Joseph Lee wrote:

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


 
Edited

Hi,

I think NVDA may as well end support for Windows 10 around say, 2027 or 2028, but things can change without notice and the decisoin is ultimately that of NV Access - 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


enes sarıbaş
 

Hi Joseph,

This indeed sounds like a lot of work.  One final question though.  You mention in your post that NVDA's 64 bit bridge does code injection into processes for browse mode.  Doesn't injecting into another process open a security hole in the browser process itself?  I have also read that Edge/Chromium prohibits, or is planning to prohibit any app from injecting into the process.  Would it be possible for NVDA/other screen readers to interact with a browser if injecting was no longer possible? Would UIA in Edge deliver all information NVDA needs to interact with the app?

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

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,

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


Brian's Mail list account
 

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

--
bglists@...
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "enes sarıbaş" <enes.saribas@...>
To: <nvda@nvda.groups.io>
Sent: Saturday, December 17, 2022 10:27 PM
Subject: Re: [nvda] Preview: what's included in Joseph Lee's add-on updates in January 2023


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





enes sarıbaş
 

Hi Brian,

I too work in an environment where a lot of legacy software is used. However,  such environments an older version of Jaws/NVDA can be used to maintain support in those situations.  Those organizations really do need to upgrade, but they're reasons for remaining on legacy OS are different than those of a consumer. Most likely, if it is a government organization, they do not have funding enough to upgrade software/web apps etc or hardware for new OS, or have legacy apps that only work on said OS.

On 12/18/2022 5:30 AM, Brian's Mail list account via groups.io 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. 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


enes sarıbaş
 

Joseph,

I do remember this option  came around in 2019.  I have always used development NVDA versions to be able to  test and get new features and fixes sooner.  Is there a reason it is optional rather than on by default?

On 12/18/2022 4:25 AM, Joseph Lee wrote:

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


 

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


enes sarıbaş
 

Agree with all this.  This should also hold true for office 2013, 2010, 2007, XP and 2003.   Same for IE, Outlook Express, Windows Live Mail.  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.

On 12/18/2022 1:42 PM, Brian Vogel wrote:

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


 

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


enes sarıbaş
 

Brian I do think there should bve a software support lifecycle that is publically available, and which is always enforced.  Moreover, support for an operating system should only include the mainstream support, not extended support or ESU support.  NVDA is falling behind compared to the other screen readers, even narrator in some aspects because of changes in Windows 11, and office as well as other apps.

On 12/18/2022 2:26 PM, Brian Vogel wrote:

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


 

Hi,

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

Cheers,

Joseph