Skip to content

Windows: run the tools with the UTF-8 code page, so non-ASCII paths work - #126

Open
timoncool wants to merge 1 commit into
ServeurpersoCom:masterfrom
timoncool:windows-utf8-manifest
Open

timoncool wants to merge 1 commit into
ServeurpersoCom:masterfrom
timoncool:windows-utf8-manifest

Conversation

@timoncool

@timoncool timoncool commented Oct 26, 2026 •

Copy link
Copy Markdown

On Windows the tools open files with the narrow APIs: FindFirstFileA for the models directory, CreateFileA for a GGUF, fopen for audio and adapters. Their char* paths are read in the system's ANSI code page, and argv reaches main converted to that code page too, so a path with characters outside it arrives as ?. Example: on a Russian Windows (code page 1251), --models "D:\Тест_音乐\models" prints Scanning models in D:\????_??\models, the registry stays empty and every synth job answers 501 "No synth models in registry". The same happens for a Chinese user folder on a Western Windows, and so on.

This embeds an application manifest that sets the process code page to UTF-8 (activeCodePage, Windows 10 1903 and later). argv then arrives in UTF-8, and the narrow file APIs take UTF-8 paths. The tools need no code change, and ggml's own ggml_fopen already expects UTF-8. On older Windows the setting is ignored, and nothing changes there.

  • tools/utf8.manifest: the manifest.
  • CMakeLists.txt: utf8_code_page(target) adds it to every executable built through link_ggml_backends, and to mp3-codec. MSVC only, because CMake embeds .manifest sources with the MSVC linker.

Checked with a release build on Windows 11 (code page 1251) and a models directory D:\Projects\TEMP\_rtest\Тест_音乐\models. Before: Scanning models in D:\Projects\TEMP\_rtest\????_??\models and no models. After: the path prints as it is, and the registry finds the LM, Text-Enc, DiT and VAE.

Summary by CodeRabbit

  • Bug Fixes
    • Improved UTF-8 compatibility in supported Windows applications by setting their active code page to UTF-8. This can help text containing non-ASCII characters display and process more consistently.

…the system's ANSI code page reaches fopen, CreateFileA and FindFirstFileA intact
@coderabbitai

coderabbitai Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

No actionable comments were generated in the recent review.

Recent review info
Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 45943bac-1250-4266-9804-2af2430e678e
Commits

Reviewing files that changed from the base of the PR and between de858d8 and 2aa0898.

Files selected for processing: 2
  • CMakeLists.txt
  • tools/utf8.manifest

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

Walkthrough

The change adds a Windows application manifest that sets UTF-8 as the active code page. CMake attaches the manifest to eligible MSVC executable targets, including mp3-codec.

Changes: Windows UTF-8 Code Page Support

Layer / File(s) Summary
Define and apply the UTF-8 manifest
tools/utf8.manifest, CMakeLists.txt
The manifest declares UTF-8 as the active Windows code page. CMake adds a macro to attach it to MSVC executable targets, calls the macro through link_ggml_backends, and calls it separately for mp3-codec.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: serveurpersocom

Merge Risk: Minimal · up to 2aa08

The UTF-8 manifest integration presents no identified merge-blocking risk.

Pre-merge checks: Passed 5
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title clearly and concisely describes the main change: enabling UTF-8 code pages for Windows tools so paths with non-ASCII characters work.
Docstring Coverage Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)

Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant