Skip to content

Create experimental 64-bit dual builds#18207

Merged
seanbudd merged 134 commits intomasterfrom
wip-buildX64
Aug 26, 2025
Merged

Create experimental 64-bit dual builds#18207
seanbudd merged 134 commits intomasterfrom
wip-buildX64

Conversation

@SaschaCowley
Copy link
Copy Markdown
Member

@SaschaCowley SaschaCowley commented Jun 2, 2025

Link to issue number:

Summary of the issue:

NVDA needs to move to being a 64-bit application.

Description of user facing changes

None.

Description of development approach

  • Move ctypes declarations of Windows APIs into their own subpackage (this is a work in progress)
  • Fix issues with type declarations to enable running under 64-bit python.
  • Identify a strategy for supporting 32-bit builds and 64-bit builds from the same source.
  • Create architecture-specific directories under lib.

Testing strategy:

Run from source and use NVDA.

Known issues with pull request:

Various, including:

  • Launcher doesn't work for updates (32-bit version will be left behind, regkeys won't be migrated, system config won't be migrated) - to be tackled in a follow-up PR

Code Review Checklist:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

@coderabbitai summary

SaschaCowley and others added 30 commits May 5, 2025 13:52
…s based on whether or not the target archetecture is the NvDA core archetecture or not, rathr than hardcoding x86 or x86_64 etc.
…ns explicit ctypes declarations for all nvdaHelperLocal functions.
…PARAM as this gives us the greatest flexibility of accepting various argument types while still ensuring the right size.
…t. The only thing that depends upon this is some old code to fetch the label of an embedded object in windows Live Mail / Outlook Express. Probbly not relevant anymore.
Copy link
Copy Markdown
Collaborator

@LeonarddeR LeonarddeR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How broadly has the current code been tested on X86? I'm a bit worried that merging this in its current state might also have unexpected side effects to x86 builds. Wouldn't it be better to do the x64 specific work on wip-buildX64 and create x64 builds from there, then merge wip-buildX64 to master when x86 snapshots are ready to be dropped?

@seanbudd
Copy link
Copy Markdown
Member

seanbudd commented Aug 25, 2025

@LeonarddeR - it's not feasible to maintain a such a large diff for such a long period of time, and manage conflicts and reviews cleanly. Any instabilities in x86 machines will be resolved if possible as we transition to 64bit, but this is tested well enough to be stable enough for alphas. Merging this in ensures all future work in NVDA is 32 and 64bit compatible. Alphas should remain stable until we transition, but with alpha builds there are always risks of instability, particularly around risky changes like this. Getting this to alpha ensures our code for supporting both builds is well tested while we transition.

@LeonarddeR
Copy link
Copy Markdown
Collaborator

Thanks @seanbudd, sounds reasonable to me.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

This partially reverts commit 000f182.
This removes fixes to the change log for problems that weren't introduced in this PR, so they can be fixed on master.
# Conflicts:
#	user_docs/en/changes.md
@seanbudd seanbudd merged commit 9cc7ed6 into master Aug 26, 2025
40 checks passed
@seanbudd seanbudd deleted the wip-buildX64 branch August 26, 2025 00:31
@github-actions github-actions bot added this to the 2026.1 milestone Aug 26, 2025
@seanbudd seanbudd restored the wip-buildX64 branch August 26, 2025 05:41
seanbudd added a commit that referenced this pull request Aug 26, 2025
## Link to issue number:
Follow up to #18207 

### Summary of the issue:

We have merged the branch from #18207, we no longer need branch specific
CI/CD builds for 64bit
@seanbudd seanbudd deleted the wip-buildX64 branch August 26, 2025 06:05
@SaschaCowley SaschaCowley mentioned this pull request Aug 26, 2025
5 tasks
SaschaCowley added a commit that referenced this pull request Aug 27, 2025
Follow-up to #18207

Summary of the issue:
Alphas are broken due to a problem with touch handler.

Description of user facing changes:
Alphas work again.

Description of developer facing changes:
None.

Description of development approach:
Cast `TouchHandler._wca` to `LPCWSTR` when passing to `CreateWindowExW`.

This is needed because the `lpClassName` parameter of `CreateWindowExW`
can accept a class atom, but ctypes doesn't know this.
This wasn't previously a problem because ctypes didn't have type
information for `CreateWindowExW`, so happily sent the arguments.

Testing strategy:
Built and self-signed NVDA. Installed and observed that NVDA didn't
crash and my touchscreen worked.

Known issues with pull request:
None.
SaschaCowley pushed a commit that referenced this pull request Sep 2, 2025
Related to #18207 

Summary of the issue:
There is unused code at `nvdaHelper/sconscript` instead we use
`nvdaHelper/archBuild_sconscript`

Description of user facing changes:
none

Description of developer facing changes:
none

Description of development approach:
remove dead legacy code for potentially handling 64bit builds.

Testing strategy:
CI/CD

Known issues with pull request:
none
Comment on lines +342 to +343
if not isinstance(data, bytes):
data = string_at(data, size)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this line added? Is it to prevent some errors/bugs when migrating to 64-bit?

string_at creates another copy of the data buffer stored as bytes, which is not needed, since it will only be passed to wasPlay_feed. As many built-in synths pass in c_void_p or a ctype array instead of bytes, this would create a lot of unnecessary memory copies.

data should be passed to wasPlay_feed directly if possible.

ctypes.moryview_at can be used to get a memoryview without copying the data. But it's added in Python 3.14, and wasPlay_feed doesn't need a memoryview anyway.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you consider opening an issue or PR? we don't really track conversations on closed PRs very well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.