Skip to content

windows: Clarify unicode characters in RC files

Martin Storsjö requested to merge mstorsjo/dav1d:rc-wide-string into master

Windows RC files can have strings expressed either as narrow chars expressed in a specific codepage, or as wide unicode strings. Regardless of which way they are expressed, they are converted into unicode strings in the compiled resource files.

When using narrow strings, even if using escaped chars like \251, those chars are interpreted according to a specific codepage. The codepage can be specified with arguments to the RC/windres tool (or with a pragma, but not all tools support the pragmas), but when no codepage is specified, the exact interpretation varies.

llvm-rc uses a hard stance of defaulting to only accepting ANSI chars unless something else has been specified (and pragmas aren't supported). llvm-windres defaults to CP 850 though, for compatibility with what most people probably intend to.

However, GNU windres and MS rc.exe actually default to what the system's current default codepage is. That means that if the resource file is built on a machine with e.g. Japanese as the default locale, the file gets built differently, with a different Unicode character than what was intended.

By converting the strings to wide strings, it is unambiguous that \251 refers to the Unicode code point u00A9 (octal 0251), i.e. copyright sign.

This fixes building the RC files with llvm-rc. With GNU windres, llvm-windres and rc.exe, the files still generate the bitwise exact same output as before.

Merge request reports