Repository navigation
Windows: 非 ACP 工作目录下 mcpp --version 静默退出 0xC0000409（先修进程边界，再验证构建链） #693
Description
实测现象
在 Windows（本机 GetACP() == 936）上，mcpp 2026.9.25.1 从含有当前 ANSI 代码页无法表示的字符的工作目录启动时，连 --version 都会无输出地退出：
PS D:\VSProj> mcpp --version
mcpp 2026.9.25.1
PS D:\VSProj\mcpp-unicode-repro-🧪> mcpp --version
PS D:\VSProj\mcpp-unicode-repro-🧪> $LASTEXITCODE
-1073740791 # 0xC0000409同一目录下 mcpp build --configure-only 也是无输出、同一退出码。目录里放了最小的 mcpp.toml 和 src/main.cpp，但 --version 已能复现，因此故障发生在读取源码之前。ASCII 工作目录下同一 mcpp.exe 正常。这个签名比 #518 A 中的“没有源文件”更早，也不能靠改进 glob 的诊断覆盖。
同机的 mcpp 自带 Ninja 1.12.1 在该目录能正常运行，ninja.exe -t wincodepage 输出 Build file encoding: UTF-8。Ninja 上游也随 Windows 版本提供 UTF-8 activeCodePage manifest。这说明当前复现至少不是 Ninja 首先拒绝工作目录；其他编译器和构建工具仍需逐一验证。
与已有问题的关系
- Windows 解压包含 UTF-8 路径的归档时因多字节代码页转换失败 #516 解决了遇到不能窄化的路径时直接抛异常的问题；
- Windows: 进程 ACP 之外的路径,mcpp 只能跳过而不能构建 #518 已记录项目根目录路径失配、以及为 mcpp 加
activeCodePage=UTF-8的方向，并明确指出仅给 mcpp 加 manifest 不等于端到端支持 Unicode 路径。
这个新复现聚焦进程启动/命令分派阶段的静默终止，并希望把修复和后续验证的边界写清楚。
建议方案
- 先修 mcpp 自己和 mcpp 生成的
build.mcpp.exe。 在 Windows PE 产物里嵌入activeCodePage=UTF-8manifest（Windows 10 1903+ 支持），让 MSVC STL 的窄路径转换与构建图中的 UTF-8 字符串一致。mcpp.exe可走现有[resources]构建能力；build.mcpp.exe是单独的 host 编译/链接路径，需要单独接入。同一阶段修掉--version的静默退出，失败时至少给出准确诊断。Microsoft 的应用程序 manifest 文档说明了这个设置及系统版本要求。 - 把 mcpp 的 Unicode 边界显式化。 内部/
build.ninja/CDB 的路径字节约定为 UTF-8；进入 Win32 文件、命令行和环境 API 时使用 UTF-16/W API，或明确做 UTF-8↔UTF-16 转换。目前 Windows bounded process 路径仍使用CreateProcessA、GetEnvironmentStringsA；只依赖进程 ACP 会让这个约定隐含在 manifest 和 OS 版本里。这个重构可以分阶段做，不必阻塞第 1 步的止血。 - 按实际工具链验证下游，而非要求所有第三方工具统一补 manifest。 先检查 mcpp 固定使用的 Ninja（例如
-t wincodepage），再分别测试编译器驱动、链接器、资源编译器和项目声明的 host tool/action。第三方可执行文件的代码页不会因为 mcpp 的 manifest 自动改变；如果某一环不能消费 Unicode 路径，应点名该环和失败的路径，而不是宣称整个构建已受支持，也不宜静默修改第三方 exe。
建议验收
- Windows CI 测试先确认
GetACP() != 65001，否则该回归用例不构成证据；在含🧪的工作目录运行mcpp --version和mcpp build --configure-only，均应正常退出并有预期输出。 - 在相同目录构建最小
build.mcpp项目，再测试含非 ACP 字符的成员目录和源文件名；验证 Ninja 构建文件、CDB 与子进程收到的路径没有乱码。至少对一条固定的 Windows 工具链实测端到端成功；其他工具链若有边界，应给出分阶段诊断。 - 保留 Windows: 进程 ACP 之外的路径,mcpp 只能跳过而不能构建 #518 的“跳过不可窄化路径时必须报告”行为，作为旧系统或未支持的下游工具的退路；只有完整构建链通过后，才把验收描述为“支持非 ACP 路径”。
Activity
2026.9.26.1: paths in UTF-8, a C standard per package, a graph link w…
docs: #693-#696 records landed, with the release and ecosystem readin…
speak-agent commentedon Sep 25, 2026
Fixed by openxlings/xlings#613, released as xlings 2026.9.26.2, and by #698, released as mcpp 2026.9.26.1 (commit
f61b46632), which bundles that xlings. This issue closed automatically when #698 merged; this note records what changed.The silent
0xC0000409came from the xlings shim in front ofmcpp.exe: it threw during start-up in a directory outside the ANSI code page and had no exception boundary.mcpp.exeitself printed its version (measured onwindows-latest, ACP 1252, through the temporary PR #697). Behind it was a larger defect the report did not reach: with the project or the mcpp home under a non-ASCII name, every build failed with an internal exception, including names the ANSI code page can represent.The fix is one text model, UTF-8 throughout:
xlings.exeandmcpp.exedeclareactiveCodePageUTF-8 in an embedded manifest, and xlings'smainhas an exception boundary.windows_code_page = "utf-8" | "legacy", and a manifest the package embeds itself takes precedence.cl.exe,link.exeandlib.exeread a response file without one as ANSI (measured).Criteria: Windows CI builds every toolchain row in non-ASCII project directories (
.github/tools/check_unicode_paths.sh), andtests/e2e/776_a_path_with_no_utf8_spelling_is_named.shfails on 2026.9.25.1 and passes on 2026.9.26.1. The releasedmcpp.exeand its bundledxlings.exeboth carry the manifest, read from the release archive.Update with
xlings update mcpp -y.Record:
.agents/docs/2026-09-25-issues-693-696-triage-and-repair-plan.md§6.