[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.

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	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.

[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.