Support Unicode file paths in the Windows CLI

[gregbenz]

Summary

• Enable UTF-8 paths in ultrahdr_app through the Windows active-code-page manifest.
• Add the manifest directly for MSVC and through a resource file for MinGW.
• Add an end-to-end test using CJK and emoji input/output paths.

Why

The Windows CLI otherwise interprets narrow command-line arguments and file paths using the legacy system code page. Valid Unicode filenames may therefore be changed or rejected.

Using the UTF-8 application manifest fixes this without custom command-line parsing or per-path conversions. This follows the same approach used by libavif.

Compatibility

This affects only ultrahdr_app; the library API/ABI and non-Windows behavior are unchanged.

Full Unicode path support requires Windows 10 version 1903 or newer, including Windows 11. Earlier Windows versions can still run the CLI, but arbitrary Unicode paths remain limited by the legacy system code page.

Long-path policy and Windows-reserved filenames are outside this change.

Addresses #379.

Validation

Google’s native Windows CI passed:

• UHDRUnitTests
• UHDRWindowsUnicodeCliPaths

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[kmilos]

As already Windows 10 is EOL, it might not be worth carrying this wide vs narrow legacy cruft around. A more elegant/modern solution is to use ultrahdr apps (and other clients of the library) in the native UTF-8 code page.

See e.g. AOMediaCodec/libavif@3ec01ce

[gregbenz]

Thanks for the suggestion—the UTF-8 manifest is a cleaner approach for modern Windows, and the libavif precedent is helpful.

There is one compatibility tradeoff:

• The current PR explicitly converts the native UTF-16 command line and therefore supports Unicode paths across older Windows versions, including Windows 10 LTSC 2019 and Windows Server 2019.
• The manifest approach requires Windows 10 version 1903 or newer. It substantially reduces the application code, but Unicode paths would remain unsupported on older builds. LTSC 2019 and Server 2019 are based on version 1809 and remain supported until 2029.

Microsoft documents the version requirement here:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

@DichenZhang1 Would the maintainers prefer the simpler manifest approach and effectively require Windows 10 1903+, or retain the explicit conversion for broader Windows compatibility? I’m happy to revise the PR either way and will keep the existing Windows Unicode regression test to verify the chosen implementation.

[kmilos]

• LTSC 2019 and Server 2019 are based on version 1809 and remain supported until 2029.

Only on mission critical equipment like medical devices etc. I don't think they'd be deploying new (read "not yet withstood the test of time") features and libraries like libultrahdr on those.

[gregbenz]

@kmilos Thank you, helpful context. I like your proposal and agree it seems simpler and a good approach. I would like to hear if the maintainers have a preference, I'm happy to revise the approach but just want to confirm direction.