[build] Compile generated Windows version resources with an explicit UTF-8 codepage

Open Beginner friendly
  • Is something wrong?
#1,466 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
build-system

Research direction

Start in src/mxc-sdk/build/build_mxc_build_common.rs, at embed_version_info_for_binary_windows, and read how the manual resource compiler invocation is assembled. Reproduce the reported failure and success with LLVM llvm-rc using the supplied UTF-8 resource and /c 65001; done means the manual path declares UTF-8 and the compiled resource preserves the copyright string. The issue requests maintainer confirmation before opening a draft PR, and Windows rc.exe validation is still needed.

Written by the indexing model from the issue text.

Description

Area-Build Issue-Bug Needs-Attention OS-MacOS OS-Windows

Relevant area(s)

Windows version-resource compilation. The compiler-level reproduction below was run on macOS ARM64 using LLVM's Windows resource compiler; a Windows-host build with Microsoft rc.exe has not been rerun.

Brief description of your issue

At microsoft/mxc commit c6f301d53a1430c4c921a05c57af838f7392348f (mxc-sdk 1.0.0), embed_version_info_for_binary_windows writes a version resource through winresource and invokes the selected compiler with /nologo /fo... resource.rc, without declaring the input codepage. The generated LegalCopyright value contains U+00A9 (©).

LLVM's resource compiler rejects this UTF-8 input under its default codepage. Specifying /c 65001 compiles it and preserves the string in the resulting Windows resource. This concerns the manual per-binary resource invocation, including a compatible compiler selected through RC_PATH; the ordinary WindowsResource::compile() path is outside the proposed change.

Observed with LLVM 22.1.8 on macOS 27.0.1 (26A434), Apple Silicon ARM64. This is a reduced resource-compiler reproduction, not a claim that a complete Windows MXC build was run on this host.

Steps to reproduce

Save the following complete file as UTF-8 named utf8-resource.rc:

1 VERSIONINFO
FILEVERSION 1,0,0,0
PRODUCTVERSION 1,0,0,0
FILEFLAGSMASK 0x3fL
FILEOS 0x40004L
FILETYPE 0x1L
BEGIN
 BLOCK "StringFileInfo"
 BEGIN
  BLOCK "040904b0"
  BEGIN
   VALUE "LegalCopyright", "© Microsoft Corporation. All rights reserved.\0"
  END
 END
END

Run with LLVM's llvm-rc (the switch syntax is also accepted by Microsoft rc.exe):

llvm-rc /nologo /fodefault.res utf8-resource.rc
llvm-rc /nologo /c 65001 /foutf8.res utf8-resource.rc

The first invocation exits 1; the second exits 0. To verify the text in the successful compiled resource:

python3 - <<'PYCODE'
from pathlib import Path
expected = "© Microsoft Corporation. All rights reserved.".encode("utf-16le")
assert expected in Path("utf8.res").read_bytes()
print("Compiled resource preserves the UTF-16 copyright string")
PYCODE

Expected behavior

The manually compiled version resource should preserve the UTF-8 source text independently of the resource compiler's default codepage.

Actual behavior

The default invocation returns 1 with:

llvm-rc: Error in VERSIONINFO statement (ID 1):
Non-ASCII 8-bit codepoint (...) can't be interpreted in the current codepage

The /c 65001 invocation returns 0, and the UTF-16 check above passes. The failing compiler writes an incomplete output file, so file existence alone is not a success check.

Proposed contribution

I would like to contribute the following small change to the manual invocation:

     let output = compiler
         .arg("/nologo")
+        // winresource writes UTF-8, including the copyright symbol. Neither
+        // the host ANSI codepage nor LLVM's default identifies that encoding.
+        .arg("/c")
+        .arg("65001")
         .arg(format!("/fo{}", compiled_path.display()))

It adds no dependency or lockfile change and does not alter version metadata, compiler selection, staging or sandbox policy. A previous non-English-Windows build report (#498, fixed in #499) concerned certutil output and NanVix feature gating, rather than VERSIONINFO input encoding.

Following CONTRIBUTING.md, could a maintainer confirm whether explicitly selecting codepage 65001 in this manual path is the preferred approach? I will open a draft PR after that confirmation. Windows rc.exe build validation and the upstream CI matrix would still be needed before marking that PR ready.

Dominant language
Rust
Stars
3.1k
Forks
171
Avg merge
2d 6h
Merged PRs (30d)
106

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/mxc

All issues in microsoft/mxc

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.