Related issues, PRs or discussions

Related to #18571.

What is the current state of the codebase?

In NVDA 2026.1, user_docs/en/changes.md documents that the following symbols have been moved from hwPortUtils to winBindings.cfgmgr32:

• CM_Get_Device_ID
• CR_SUCCESS
• MAX_DEVICE_ID_LEN

source/winBindings/cfgmgr32.py exists in the release-2026.1 source tree, and hwPortUtils.__getattr__ points deprecated symbols to winBindings.cfgmgr32.

However, the installed NVDA 2026.1 binary package does not include winBindings/cfgmgr32.pyc in library.zip. As a result, add-ons cannot import the documented replacement module:

from winBindings.cfgmgr32 import CM_Get_Device_ID, CR_SUCCESS, MAX_DEVICE_ID_LEN

This raises:

ModuleNotFoundError: No module named 'winBindings.cfgmgr32'

Why are changes required?

The 2026.1 developer changes publicly document winBindings.cfgmgr32 as the replacement import path for deprecated hwPortUtils symbols. Since the module is omitted from binary builds, the documented migration path is unavailable to add-ons using installed NVDA builds.

This is likely because winBindings.cfgmgr32 is only referenced dynamically via utils._deprecate.MovedSymbol, so py2exe does not discover it through static import analysis.

What technical changes are required?

Explicitly include winBindings.cfgmgr32 in the py2exe build configuration, for example in source/setup.py under options["includes"]:

"winBindings.cfgmgr32",

A short comment may be useful:

# Referenced dynamically by hwPortUtils deprecation aliases.
"winBindings.cfgmgr32",

After building, verify that dist/library.zip contains:

winBindings/cfgmgr32.pyc

Are the proposed technical changes API breaking?

No

Are there potential risks or issues with the proposed implementation?

Risk should be low. This only adds an existing NVDA source module to binary builds so the documented developer API path is available. The module is small and wraps functions from the Windows system cfgmgr32.dll.