Guide: getting community add-ons ready for 64-bit NVDA (2026.1)

[joseph....@gmail.com]

Hi all,

A copy of the below guide was sent to the add-ons community. While parts of it are geeky, the overall message is that add-ons are crucial for the relevance of NVDA and the community must collectively work on getting add-ons ready for 64-bit NVDA (2026.1):

 

The following guide is designed for folks getting started with porting their add-ons from 32-bit NVDA to 64-bit NVDA. While some of what I will discuss is applicable for every compatibility breaking release (year.1), NVDA 2026.1 presents additional considerations because we are doing three years’ worth of work in one release: deprecated NVDA code paths, 32-bit to 64-bit transition, Python 3.11 32-bit to 3.13 64-bit upgrade. I know that some of us have been preparing our add-ons for 64-bit NVDA for some time. However, I believe documenting the process and best practices can benefit not only add-on authors and NVDA users, but to help folks outside of this community understand the work done to move a screen reader project from 32-bit to 64-bit, including extensions. Also, to get the NVDA community on the same page, a version of this guide will be sent to users as well so others can collaborate on getting add-ons working with NVDA 2026.1.

For the first twenty years of its existence, NonVisual Desktop Access was a 32-bit screen reader, running on 32-bit Python runtime and supporting 32-bit Windows releases. As the last 32-bit Windows release for consumers (Windows 10) is no longer supported by Microsoft in the mainstream sense, coupled with the mainstream status of 64-bit computing, NV Access and the NVDA community decided to transition the screen reader to become a 64-bit software with bridges to support 32-bit applications and speech engines. As NVDA community add-ons are integral part of NVDA experience, getting add-ons ready to work with 64-bit NVDA is critical to offering equal access to technology via the NVDA screen reader and countless extensions/add-ons.

As of February 7, 2026, of the 350 add-ons registered on the NV Access add-on store, at least 46 add-ons are incompatible with NVDA 2026.1 beta. While most are related to using deprecated NVDA code paths, at least 16 add-ons require more work, including using 64-bit binaries and updated Python dependencies. While some of these add-ons received updates at the code level within the past twelve months (based on GitHub repository data), some have become abandonware. While most add-ons were created to address specific segment of the NVDA community population, some, including speech engines, have become critical add-ons depended by users.

Because add-ons are integral part of the NVDA experience, it is critical to keep add-ons updated from time to time. NV Access is using year.1 releases to introduce backwards incompatible changes to modernize outdated code and to respond to changes in the technology development landscape such as wide adoption of artificial intelligence. While add-ons are not expected to respond to every compatibility breaking release (some add-ons do work once incompatibility is overridden), it is important to respond to major changes every two to three years; ideally add-on authors should test their add-ons, respond to changes if any, and update their manifests to declare compatibility with year.1 releases. This is so that the add-on code can remain relevant and to keep users engaged with add-ons.

Given the significant changes introduced in NVDA 2026.1, getting add-ons updated is a “to do”, not “to be done”. The below process is to get folks to “to do the thing” i.e. update add-ons sooner than later, preferably now that NVDA 2026.1 beta is available for testing. By the end of this process, you will have an add-on that is ready to be tested by users of NVDA 2026.1.Follow these steps to port add-ons to 64-bit NVDA:

Step 1: obtain the needed dependencies: to test add-ons, you need the following software:

• NVDA 2026.1 beta
• Python 3.13 64-bit (for x64 architecture) for some add-ons
• 64-bit versions of binary dependencies
• Python dependencies compatible with Python 3.13 64-bit

For best testing scenario, have both NVDA 2025.3.2 and 2026.1 beta handy. 2025.3.2 is the last 32-bit NVDA release (unless 2025.3.3 is in the works), and you obviously need a 64-bit NVDA to test your add-on porting work.

Step 1.1: contact add-on authors: some add-on authors have been working on 64-bit NVDA transition and have prepared their add-ons. However, not all add-on authors (can) do this, so remind them about NVDA 2026.1 changes and ask about their add-on development status.

Step 2: determine initial compatibility by overriding incompatibility: some add-ons will work without any problems once 2026.1 incompatibility is overridden via the add-on store. If add-ons do work as advertised (hopefully all features do work), then wait until NVDA 2026.1 API is finalized (typically when the release candidate (RC) is released) before releasing a manifest update. If add-ons do not work after overriding incompatibility, depending on the information recorded in the log, perform one or more of the below steps.

Step 3: move away from deprecated NVDA code paths: each NVDA releases include code deprecations, and in case of year.1 version, code removals. These deprecations and removals are documented in NVDA’s what’s new document. Read “changes for developers” sections (including information on deprecated and/or removed code), then change your add-on source code to use replacements or alternatives. For NVDA 2026.1, the following changes are necessary:

• versionInfo.* e.g. versionInfo.version_year: use buildVersion.* e.g. buildVersion.version_year instead.
• Config.conf[“documentFormatting”][“reportSpellingErrors”]/bool ->  config.conf[“documentFormatting”][“reportSpellingErrors2”]/int
• Windows API dll lookup: win*.* -> winBindings.*.dll e.g. winUser.user32 -> winBindings.user32.dll

There are more deprecations and removals. If your add-on has not been maintained since 2024, you have more work to do.

Step 4: include 64-bit Python dependencies compatible with Python 3.13: some add-ons include .pyd (Python binary library) files, most of which are 32-bit binaries. 64-bit NVDA, specifically 64-bit Python runtime, CANNOT import these modules. You must bundle 64-bit pyd files compatible with Python 3.13 in your add-ons. If supporting 32-bit and 64-bit NVDA, you must bundle both the 32-bit pyd files and 64-bit pyd files and load the appropriate binary.

One way to include 32-bit and 64-bit binaries is create a dedicated 64-bit lib folder inside the same folder where your main add-on code resides. Then do one of the following:

• Try importing one architecture binary, and if it doesn’t work, fall back to the other module e.g. try: import lib; except ModuleNotFoundError: import somelib as lib.
• Check NVDA architecture (one way is os.environ[“PROCESSOR_ARCHITECTURE”], add the appropriate library folder, then import modules.

Once the 64-bit Python dependencies are included, test the add-on to make sure it is loading under NVDA 2026.1. If it works, test to make sure add-on feature do work as advertised. If planning to support NVDA 2025.3.2 and earlier, make sure to test the add-on on NVDA 2025.3.2 and note if the 32-bit dependencies are being imported.

Step 5: include 64-bit binaries: some add-ons include 32-bit binaries that are not necessarily Python binary modules, including executables (exe) and libraries (dll). Some are used by add-ons directly while others are loaded through Python dependencies or another intermediary. After overriding incompatibility and the log records “%1 is not a valid Win32 application”, chances are that the add-on is using 32-bit binary modules. To resolve this, the add-on MUST ship with 64-bit binaries or a bridge to talk to 32-bit modules from 64-bit Python/NVDA.

Step 6: check differences between 32-bit and 64-bit data expectations, specifically ctypes: if your add-on uses ctypes to talk to other binary modules and you notice strange behavior or results under 64-bit NVDA, then double-check the data you are getting from third party modules. For example, you may notice overflows or flipped bits, indicating that Python is trying to understand 32-bit data as 64-bit and vice versa. Check for these so add-ons can work as advertised under 64-bit NVDA/Python runtime.

Step 7: test the add-on: once the above steps were taken to port add-ons to 64-bit NVDA, test the add-on to make sure it actually work as advertised.

Step 8: publish add-on changes: make sure to publish the hard work you did to port your add-ons somewhere, including to the NV Access add-on store.

Step 9 (and beyond): listen to and incorporate feedback from the community.

The above guide can be summarized this way: keep up with changes as much as possible, including investigating tasks to do when moving from one architecture to another. Do not wait till the last minute, especially if your add-on is viewed as critical for users.

Transitioning from one world to another is hard and requires careful planning and execution. This is more so for critical piece of software that is depended on by users. While NVDA is a critical software for screen content access, add-ons are just as important for the NVDA community. The transition from 32-bit to 64-bit architecture is a good opportunity to assess the state of NVDA add-ons and update them, including taking steps to get them to work with NVDA 2026.1 just as they did in 2025.3.2 and earlier. The NVDA community is counting on us – add-on authors and testers - to carry out this work. I would go further and declare that getting add-ons to work on NVDA 2026.1 through 32-bit to 64-bit porting effort is critical and necessary for the continued relevance of NVDA and its add-ons. The greatest thing that can happen to the community in the midst of celebrating NVDA’s twentieth anniversary is discovering the joys of using add-ons once again thanks to the compatibility work we do, have done, and will do.

Let’s get the add-ons porting going!

Cheers,

Joseph