[MiniRML]

What

On Windows, the NID patcher loses characters outside the active ANSI code page before opening its input or export-reference library. Valid Chinese/Cyrillic paths become question marks and fail with cannot open. Use the wide Windows entry point, convert arguments to UTF-8 once, and construct native filesystem paths explicitly from UTF-8 for both patch files and export references. Other platforms retain their normal entry point.

The wide-argument entry point is described in Microsoft's wmain documentation.

Tested

Windows 11, MinGW-w64 GCC 15.2, CMake 4.3.1, Ninja, Release. All three new synthetic-file cases fail on main and pass with the fix: patching a Unicode directory/filename, reading a Unicode --preserve-exports reference without modifying it, and correctly naming a missing Unicode input while preserving unrelated files. The resulting symbol names are checked in the patched Mach-O fixture. No game files or PS5 hardware needed.

• Full all libs build passed, including actual library patching with the new entry point.
• New nid_patcher_native_paths and existing nid_patcher_macho tests passed.
• Conventions and whitespace checks passed.
• Refreshed all 437 open PR changed-file lists/patches; no competing path fix found. Merge simulations were clean against fix(nid): validate buffer ranges and string terminators #4550, feat(libs): implement VSH WebAppLauncher shims #4198, fix(agc): defer write tracking for fresh Windows shared imports #4535, feat(aot): run source-built graphics on native Apple ARM64 #3891 and fix(libkernel): harden DirectMemory validation and tests #3870.
• Windows runtime tested locally; Linux/macOS runtime not tested locally.

Checklist

• Based on current main; no other open PR implements the same fix
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw; no runtime stubs changed
• No notes, investigation files or images added to the repository
• New third-party code is a submodule built from source; none added
• Generic behaviour, not specific to one title
• Depends on: none
• Unblocks: none
• AI-assisted: yes

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#4721	core/libs/nid/src/ExportExclusions.cpp L5

[xXPBSXx]

Windows test: head 63022e23c merged onto current main 0f2683cb7, together with 5 other open pull requests in one build (the merges were conflict-free); a failure would have been bisected per PR. Windows 10, MinGW GCC (WinLibs), Ninja Release, -j2: full build 0 errors; ctest for the tests this change adds or touches: nid_patcher_native_paths passed; python tools/check_conventions.py --base upstream/main passed for the combined tree. I did not run the new tests against main without the change.

AI-assisted (Claude Code).

[adriadam10]

Checked the merge onto current main: core/libs build and ctest 25/25 green. The wmain/-municode entry point is Windows-only, other platforms keep main, and the UTF-8 NativePath is used for every input, output and --preserve-exports open. The new test is confirmed on Windows 10/MinGW by @xXPBSXx. Merging once the full Build is green.

[adriadam10]

Checked the merge onto current main: core/libs build and ctest 25/25 green. The wmain/-municode entry point is Windows-only, other platforms keep main, and the UTF-8 NativePath is used for every input, output and --preserve-exports open. The new test is confirmed on Windows 10/MinGW by @xXPBSXx. The full Build's only failures were guest_math (linux) and guest_kqueue (windows), both aborts in tests the diff doesn't touch; re-running them. Merging once the full Build is green.