[Project] Convert NVDA to 64 bit

[seanbudd]

Note: As usual with GitHub Discussions, please use thread replies via the GitHub interface rather than email based replies to keep discussion well structured.

Project Description

This project aims to migrate NVDA to becoming a 64 bit only application.
This means that NVDA would no longer run on 32 bit machines.

Once initial discussion has settled, we encourage the community to start and contribute to the conversion.

Reasoning

Less than 5% of NVDA users are on 32-bit machines, many of which are already left behind due to Win 7 deprecation.
Only 1.4% of Windows 8.1+ NVDA users are on 32-bit machines.

Many dependencies are dropping 32 bit support:

• Java access bridge stopped providing official builds a long time ago, now they have dropped support fully: https://openjdk.org/jeps/449
• py2exe are no longer testing their wheels: Is there still a need for win32 wheels? py2exe/py2exe#157
• wxPython briefly dropped building wheels: build wxpython to windows 32 bit wxWidgets/Phoenix#2246

Windows 11 only offers a 64 bit version. This means once Windows 10 goes EOL (end of 2025), the entire software ecosystem (including python) will likely move to 64 bit only.
Migration is likely to be a slow process, and we are increasingly risking being left behind as the software ecosystem migrates.

NVDA runs into errors with some 64bit applications:

• Cross-process reading/writing of 64 bit memory #3339
• Divvun third party SAPI5 voices not accessible #17661

We cannot build a magnifier built in to NVDA as a 32bit (WOW64) application:

• [WIP] Magnifier python sample #17416 (comment)

Project Goals

• Create a thorough smoke testing plan
• Build x32 and x64 versions of NVDA simultaneously over a long alpha period as an optional build artifact
• Create a stable x64 build to switch over for primary alpha testing
• Take the x64 build to beta
• Release a final x64 build

Objective

A stable final x64 build of NVDA

Backlog

User Story	Priority	Estimate	Uncertainty	Final Estimate
Investigate dependencies to check for 64bit options - DONE 1d	1	2d	x3	5d
Create a feature branch to begin x64 work	1	1d	x2	2d
Create an environmental flag so that the feature branch and PRs targeting it attempt to create an x64 artifact of NVDA in parallel to the 32bit version	1	5d	x2	10d
Create a thorough smoke testing plan	2	3d	x2	5d
Merge the feature branch to alpha to prevent branch drift	2	1d	x2	2d
Investigate various AI tools to perform refactoring automatically	2	5d	x1 (timeboxed)	5d
Create if/else statements in the build system and in NVDA to handle 32bit and 64bit cases where only the 32bit case is handled currently	1	30d	x4	120d
Switch alpha builds to using the x64 artifact primarily	1	10d	x3	30d
Create a 32bit backwards compatible API for synth drivers and braille displays	3	2d	x3	5d
Beta release, testing and fixes	1	5d	x3	15d
Stable release	1	1d	x3	3d

Total

65-200d

Engineering risks

Risk Description

Dependencies that are incompatible with x64 software.
We may have legacy dependencies that are 32bit only.

Management strategy

We should check all our dependencies and see if this will be an issue before embarking on the conversion process.
If essential dependencies are identified we may need to find alternative solutions or deprecate support for certain things.

Resulting severity

• Probability: medium
• Impact: high

Final severity: high

Risk Description

NVDA add-ons, synthesizers, and other external software may rely on NVDA's 32bit API.

Particular braille display drivers may rely on dlls from the manufacturer to communicate with the display. It may be possible that the company who made the braille display no longer exists (e.g. Baum) and therefore there is no chance that a 64 bit dll could be created without major reverse engineering. The vast majority of the braille display drivers in NVDA core do not rely on dlls, but there may be some add-ons. Generally we could say bad luck, times move on. However for a $10,000 investment on an older braille display, we would want to provide a solution if at all possible.

Management strategy

We should advertise these changes as early as possible, and provide testing builds once 64bit NVDA enters beta.
Some legacy software will unfortunately be left behind, and users relying on it may be stuck on older versions of NVDA.

A user story exists for creating a 32 bit legacy API for legacy drivers.
As we start to think about the secure add-on API, specifically for synth drivers and braille display drivers, these could run in their own isolated sub-processes, with our own custom IPC for communication with NVDA core. In this case, it would be possible to continue to provide 32-bit support by providing a 32-bit braille driver host process.

Resulting severity

• Probability: high
• Impact: medium

Final severity: medium

Risk Description

Uncommon code paths.
Many functions relying on 32bit infrastructure may be uncommon code paths and hard to pick up from testing or as a developer.

Management strategy

Use AI to analyse NVDA codebase for remaining code that needs conversion. AI may get better at this once we have performed some conversion and have examples.

Thorough alpha testing and beta testing will help here.

Resulting severity

• Probability: high
• Impact: low

Final severity: low

[seanbudd]

As usual with GitHub Discussions, please use thread replies via the GitHub interface rather than email based replies to keep discussion well structured.

Please use replies to this comment to group and identify places where conversion needs to occur (e.g. build system components, API calls, etc)

[mwhapples]

For Java Access Bridge there is a separate DLL for 64-bit assistive technologies, so NVDA should ensure it uses that. As far as I remember there is no differences in the API calls once the DLL is loaded. Also should a user have some legacy Java code relying upon a 32-bit JVM, then the 64-bit DLL which would be used by NVDA would still be able to access that JVM (providing no incompatible changes are made to Java Access Bridge internal communication between the JVM and NVDA's access bridge DLL, but I think that has been fairly stable for a long time).

[lukaszgo1]

As pointed out by @LeonarddeR in #12064 (comment)

Re 64-bit NVDA, that will be a long journey. Quick research revealed that al ctypes calls involving pointer types would require explicit parameter annotations. ctypes seems to assume 4 bytes for a parameter by default, so throwing an 64 bit pointer at it will result in an OverflowError to be raised.

[josephsl]

Hi,

I can think of following places in NVDA Core that would benefit from at least detection of 32-bit versus 64-bit Python runtime and responding accordingly:

• COM registration fixing tool
• Various Windows Registry/WoW64 calls
• Details around AppModule.is64bitProcess and friends

I think a way to detect 32-bit/64-bit Python runtime would be the first step - sys.maxsize > 0x7fffffff would work, but we may need something a bit more concise for use by add-ons and other parts.

Thanks.

[seanbudd]

Please use replies to this comment to discuss the smoke testing plan

[seanbudd]

Please use replies to this comment to discuss NVDA dependencies which do / do not have 64bit alternatives

[seanbudd]

Java Access Bridge, wxPython, and py2exe are known dependencies migrating to x64 only

[lukaszgo1]

Note that py2exe currently does not support Python 3.12 or later see py2exe/py2exe#191. It looks like due to various CPython internal changes making it work is going to be quite difficult.

[seanbudd]

Research has been completed: https://docs.google.com/spreadsheets/d/1uDO-8LOweolb1kyL5sAgJECNtfRQ3YE2J7iYnXLmMdA/edit?gid=0#gid=0

[josephsl]

Hi,

I would assume that a 32-bit remote loader will be used to let the core code and add-ons talk to 32-bit processes? The remote loader is needed by soe add-ons to communicate with 32-bit processes using Windows API calls.

Thanks.

[seanbudd]

I believe that is part of it yes

[mzanm]

Would it be possible to consider an arm 64 build as well? Currently NVDA runs on emulation on arm which may have a performance and battery life impact on arm devices.

[josephsl]

Hi,

This should be a bit easier on Windows 11 thanks to ARM64EC. Keep in mind that Windows 10 on ARM does not natively emulate AMD64 binaries. This, combined with considerations for portable NVDA usage scenarios, is the reason for me to propose going all the way with AMD64 with ARM64 layer (remote loader) added.

Thanks.

[lukaszgo1]

Windows 11 only offers a 64 bit version. This means once Windows 10 goes EOL (end of 2025), the entire software ecosystem (including python) will likely move to 64 bit only. Migration is likely to be a slow process, and we are increasingly risking being left behind as the software ecosystem migrates.

Please don't forget corporate users on LTSB / LTSC versions of Windows 10 - these are supported until the beginning of 2029. While I don't thing they should hold us back, it would be nice to know how many windows 10 users on 32-bit are running these extended support editions. Sadly our statistics gathering does not cover OS information in that detail.

[...] or deprecate support for certain things.

Is there anything other than Braille display driver you have in mint here?

NVDA add-ons, synthesizers, and other external software may rely on NVDA's 32bit API.

To be clear I assume that there is no intention to remove 32-bit controller client for external applications?
I agree synthesizer drivers will be problematic especially Eloquence and Vocalizer, where distributing companies don't have access to the sources. I also don't think removing support for these is really an option - they have a lot of users and other screen readers on various platforms support them natively. Have you reached out to Code Factory and Tiflotecnia yet?

Particular braille display drivers may rely on dlls from the manufacturer to communicate with the display.

I'd say this risk is quite small - most (probably all) displays are supported via BRLTTY, which means that users can use it indirectly, but more importantly that source code of the driver which does not rely on the manufacturer dll is available, so we can use it to create native Python driver.

Some legacy software will unfortunately be left behind, and users relying on it may be stuck on older versions of NVDA.

Is this only about stuff relying on NVDA's API? This sentence may also mean that 32-bit programs will no longer be supported which, I hope, is not an intent here.

A user story exists for creating a 32 bit legacy API for legacy drivers. As we start to think about the secure add-on API, specifically for synth drivers and braille display drivers, these could run in their own isolated sub-processes, with our own custom IPC for communication with NVDA core. In this case, it would be possible to continue to provide 32-bit support by providing a 32-bit braille driver host process.

I'd say this is really a must for synthesizer drivers. For just one example of a user who disagreed with an idea of dropping support for, very popular, 32-bit synthesizers see #12064 (comment)

[beqabeqa473]

Just to clarify, vocalizer doesn't suffer from this and x64 driver will be provided after nvda move to x64

[seanbudd]

Please don't forget corporate users on LTSB / LTSC versions of Windows 10 - these are supported until the beginning of 2029. While I don't thing they should hold us back, it would be nice to know how many windows 10 users on 32-bit are running these extended support editions. Sadly our statistics gathering does not cover OS information in that detail.

We are not discussing dropping windows 10 support here, that is something that is driven by python not us. Just a reflection on where the software ecosystem is moving

[...] or deprecate support for certain things.

Is there anything other than Braille display driver you have in mint here?

This isn't really about braille displays drivers, rather dependencies we rely on like py2exe, diff match patch etc. for example, if there was no 64bit support for diff match patch, we may have to remove support for using that algorithm if no alternatives could be found. If BRLTTY didn't work (it should work fine), we'd have to end support for that protocol.

NVDA add-ons, synthesizers, and other external software may rely on NVDA's 32bit API.

To be clear I assume that there is no intention to remove 32-bit controller client for external applications?
I agree synthesizer drivers will be problematic especially Eloquence and Vocalizer, where distributing companies don't have access to the sources. I also don't think removing support for these is really an option - they have a lot of users and other screen readers on various platforms support them natively. Have you reached out to Code Factory and Tiflotecnia yet?

That's correct. We haven't looked at working with external organisations yet, it is still very early days discussing this migration as developers.

Some legacy software will unfortunately be left behind, and users relying on it may be stuck on older versions of NVDA.

Is this only about stuff relying on NVDA's API? This sentence may also mean that 32-bit programs will no longer be supported which, I hope, is not an intent here.

Correct, only legacy software relying on the NVDA API

[lukaszgo1]

There are some things which IMO should be clarified in the initial comment, so that we all share the same expectations:

• When you're planning to start the migration? Obviously early research wouldn't hurt, but releasing first 64-bit version will going to cause some instabilities and issues for sure. I may be overly conservative here, but I'd say 2026.1 is a realistic first 64-bit release
• What is the plan for the C++ code which is injected into various processes? My initial thought is that we will reverse the current situation i.e. bundled DLL's will be injected into 64-bit processes and the remote loaders will support injection into 32-bit and ARM ones, but it will be nice to state this explicitly in the project description

[seanbudd]

The migration can start now if anybody wishes to take it on, this announcement was designed to help clear the way for beginning work as soon as possible. It is unlikely NV Access will contribute significant work until late 2024 or early 2025.

2026.1 is our aim for the release of a final 64bit version.

@michaelDCurran - do you have any thoughts on in-process injection?

[seanbudd]

I thought this may have been clarified here, let me know if wording can be improved:

Once initial discussion has settled, we encourage the community to start and contribute to the conversion.

[Adriani90]

Just to note a practical example, #3339. There is also a PR referenced.

[seanbudd]

This comment is for discussing handling the migration of NVDA's C++ code.

Resources:

• https://learn.microsoft.com/en-gb/windows/win32/winprog64/migration-tips
• https://pvs-studio.com/en/blog/posts/cpp/a0004/
• https://www.ibm.com/docs/en/xcfbg/121.141?topic=guide-porting-from-32-bit-64-bit-mode

[gexgd0419]

About 32-bit/64-bit interoperations

As we start to think about the secure add-on API, specifically for synth drivers and braille display drivers, these could run in their own isolated sub-processes, with our own custom IPC for communication with NVDA core. In this case, it would be possible to continue to provide 32-bit support by providing a 32-bit braille driver host process.

I wonder how this would be implemented.

Usually add-ons are written in Python code that runs in the NVDA's process, so that they can use all the public APIs in NVDA (or even monkey-patch some internal functions, albeit not recommended), and use some external DLLs, which will also be loaded inside the NVDA process.

If we want to split the NVDA main process and the add-on code into two processes, and want to require as less changes to the existing add-on code as possible, we could implement proxy objects to allow the add-on to transparently perform remote calls to the NVDA APIs. This way, the add-on doesn't need to be aware that it is doing remote calls, because the code to use the API is exactly the same, unless, for example, the add-on wants to monkey-patch some internal functions.

The problem is, how many proxies would we need?

NVDA has lots of modules/classes/functions that can be categorized as "public API". When an add-on runs in-process, it has access to all those APIs. But when an add-on runs out-of-process, it only has access to the APIs that can be proxied to the main process. Do we need to provide proxies for every single public API, in order not to break existing add-ons? Although we only need one proxy class for each class, and we can reuse the same implementation, there are still a lot of classes, and we will have to create the same module structure to make importing work.

Another way is to provide (or recommend) a set of RPC/IPC facilities for add-ons to use, but all the NVDA APIs are still only in the main process. Then, it will be the add-on's job to split out the part that needs to run in a 32-bit environment, and run the part in a separate process using the facilities.

About ARM64

ARM64 is also considered 64-bit, unless you want to explicitly distinguish x64 and ARM64. However, x64 and ARM64 are different.

x86 and x64 have different Program Files folder path and registry path, but x64 and ARM64 share the same location, including COM registry keys, which can make things difficult.

Windows 11 ARM supports these architectures: x86, x64, ARM64 and ARM64EC. ARM64 programs contain "pure" ARM64 code and are the most efficient, however they are incompatible with existing x64 dependencies. ARM64EC, on the other hand, is designed to be somewhat compatible with x64, and also be efficient by running native ARM64 code when possible. In other words, ARM64EC is "ARM64 in x64's clothing". However, the "clothing" makes ARM64EC incompatible with "pure" ARM64, so ARM64EC becomes another "architecture".

As a process can have any of those architectures, NVDA should be prepared for all of them. When you build a DLL, you can also make an ARM64X DLL, which contains both ARM64 code and ARM64EC code, and can be used as either an ARM64 DLL or an ARM64EC DLL.

The compatibility among different architectures is as follows.

• x86 processes can load x86 DLLs.
• x64 processes can load x64, ARM64EC and ARM64X DLLs.
• ARM64EC processes can load x64, ARM64EC and ARM64X DLLs.
• ARM64 processes can load ARM64 and ARM64X DLLs.
• On x64 systems, neither ARM64EC nor ARM64X is supported.
• ARM64X DLLs will be seen as ARM64 DLLs on systems that do not support ARM64X.

So on an ARM64 system, ARM64X DLLs have the best compatibility and can be loaded into any 64-bit process. If you want to hook/patch functions in an ARM64EC process, you can treat it as an x64 process, as ARM64EC code is specifically structured to look like x64 code.

However, all the DLLs an ARM64X DLL links against should also be ARM64X DLLs. System DLLs are usually ARM64X, but third-party DLLs might not. If there's only an x64 version and an ARM64 version of a third-party DLL with no way to recompile it into ARM64X, you may have to split your ARM64X DLL into x64 and ARM64, then use an ARM64X DLL only as a forwarder.

If you use x64 NVDA on an ARM64 system, it can mostly work, as x64 DLLs can be loaded in x64 and ARM64EC processes. But x64 DLLs cannot be loaded in ARM64 processes, although they both seem to be 64-bit.

[seanbudd]

To be more specific, the interface described initially is just for synth and braille drivers, which often communicate via a 32bit process. We don't plan to create a cross 64/32bit interface for general python add-on code.