NVDA state: add enumerations for processor-NVDA app architectures for use in architecture-sensitive parts of NVDA

[josephsl]

Hi,

Stems from #16304:

Background:

At the moment NVDA runs as an x86 program because it uses 32-bit Python runtime. As proposed in #16304 and with the first step done via #16432, it is proposed to add enumerations to detect processor (machine) and NVDA ( app) architectures for use in architecture-sensitive parts such as 64-bit app detection and NVDA helper initialization.

Is your feature request related to a problem? Please describe.

While NVDA can handle 32-bit and 64-bit systems thanks to x86 architecture in use, when it comes to transitioning to 64-bit architecture, additional considerations should be made. This includes making sure NVDA is working with 32-bit and 64-bit applications just like it does in May 2024, as well as choosing the right code path based on ap and processor architecture. For example, when accessing Windows Registry (such as in COM registration fixing tool), native and/or compatibility keys (WoW64) should be accessed depending on the system/processor architecture as described below:

• Once (native only): 32-bit x86 NVDA, 32-bit x86 Windows
• Twice (WoW64): 32-bit x86 NVDA, 64-bit Windows on Intel/AMD systems
• Twice (compatibility): 64-bit x64 NVDA, 64-bit Windows for Intel and AMD
• Three times (Windows 10 on ARM): x86 NVDA, ARM64 Windows (native ARM64, x86, 32-bit ARM)
• Three times (Windows 11 on ARM without 32-bit ARM support): x86 or x64 NVDA, ARM64 Windows (native ARM64, x86 (32-bit), x64 (64-bit)
• Four times (Windows 11 on ARM with 32-bit ARM applications support): x86 or x64 NVDA, ARM64 Windows (native ARM64, 32-bit x86, 32-bit ARM, 64-bit x64)

In summary, in addition to native instructions, NVDA must be aware of how many architectures are emulated (via hardware or emulation) for a given Windows system.

Describe the solution you'd like

Create an enumeration recording how many architecture-specific paths NVDA can and should support. This, together with a function to compute architecture-specific paths, allows NVDA to determine which code paths should be executed after handling the native architecture. This is useful in places such as COM registration fixing tool where architecture-specific code paths must be used.

Describe alternatives you've considered

Leave code as is - check processor architecture and NVDA's architecture to determine code paths.

Additional context

At the moment NVDA's source code assumes x86 Python runtime for nvda.exe. For example, COM registration fixing tool enters WoW64 code path if it is running on 64-bit systems. Obviously, this assumption and code path doesn't make sense or refinements are needed if a 64-bit NVDA (x86 or ARM64) is run on top of 64-bit Python runtime, in which case 32-bit specific code paths must be traversed later (like what 64-bit systems code path does today). An enumeration, rather than a function, helps with readabiilty, follows the trend of using enumerations to define records, and makes it easy to extend later (of course the function traversing the enumeration should be edited then) to support or drop architectures. For optimization (way later during 32-bit to 64-bit transition), the architecture-specific code paths flag should be defined only once so the enumeration and the accompanying function does not have to be traversed each time architecture-specific code is executed.

Thanks.