[angt]

Overview

Following #30417, we want to keep UTF-8 strings throughout the application. Relying on explicit conversions such as u8path() is fragile. It compiles without warnings but breaks Unicode paths on Windows.

This PR embeds a manifest that selects UTF-8 as the windows process code page, aligning default handling with our internal encoding. It also opts into long-path support (see #31102) and preserves decoding of legacy child-process output.

Conversions required by reusable libraries (ggml, llama, mtmd) and explicit wide Win32 APIs remain where needed.

Additional information

This prepares a follow-up cleanup of application code:

• Replace repetitive u8path() / .u8string() conversions with ordinary paths and strings.
• Replace Windows-specific file-opening branches with standard file streams where possible.
• Remove redundant Windows argument and environment conversion wrappers.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES

[ggerganov]

Giving the green light, though I'm not familiar with how the manifests in Windows work.

[angt]

Also I removed the ggml-vulkan changes, which was technically correct but useless in practice

[angt]

@ggerganov Im not familiar with them either. I found this while looking for a clean way to keep char * in function prototypes without having to put u8path() everywhere.

[angt]

To test on windows:

$env:LLAMA_BUCKET = "angt/install.sh"
$env:LLAMA_VERSION = "g01e69c109"
irm https://llama.app/install.ps1 | iex

[ServeurpersoCom]

I test it on a dedicated Windows 11 machine...

[ServeurpersoCom]

Tested on Windows 11 with MSVC and CUDA: the manifest is in all 83 exes, a model loads and generates from a 350 char path and from non ASCII paths, the router spawns its child with an accented model path, and exec_shell_command still decodes the CP850 output of cmd. ctest behavior 30/30. LGTM!