It should be sufficient to add activeCodePage to the manifest of the .exe file since it is an element for application manifests. See Application Manifests. Also, since this is a process-wide setting it makes sense that it is determined by the executable and not by any dynamic link library.
Should I set `activeCodePage` to `UTF-8` on both an EXE and its DLLs?
I’m currently working on contributing to Descent 3. Specifically, I’m trying to make sure that Descent 3 uses UTF-8 everywhere. I’ve already confirmed that Descent 3 has at least one character-encoding-related bug, and I suspect that it has more.
One of the things that I want to do is make sure that Descent 3 uses a UTF-8 code page. According to “Use UTF-8 code pages in Windows apps”:
As of Windows Version 1903 (May 2019 Update), you can use the ActiveCodePage property in the appxmanifest for packaged apps, or the fusion manifest for unpackaged apps, to force a process to use UTF-8 as the process code page.
That same page goes on to say:
Add a manifest to an existing executable from the command line with
mt.exe -manifest <MANIFEST> -outputresource:<EXE>;#1
.
Here’s the problem: building Descent 3 produces more than just an EXE file. It also produces several DLL files that the game loads while you’re playing. The DLLs that I’m talking about only get used by Descent 3. They don’t get used by any other applications.
I’m definitely going to use a fusion manifest with activeCodePage
set to UTF-8
on Descent3.exe
. Should I also use a fusion manifest with activeCodePage
set to UTF-8
on the game’s DLL files?