https://bugs.winehq.org/show_bug.cgi?id=52223
Bug ID: 52223 Summary: activeCodePage utf-8 in application manifest not respected Product: Wine Version: 6.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fusion Assignee: wine-bugs@winehq.org Reporter: terinjokes@gmail.com Distribution: ---
Starting[1] with Windows 1903 (Windows 10 May 2019 update), Windows has allowed applications to opt-in to supporting the UTF-8 code page by defining "activeCodePage" in their application manifest. When in this mode, the "ANSI" -A WinAPI functions operate in UTF-8 mode.
<activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
WINE, even when winver is set to "win10", does not respect this application manifest key, resulting in the application starting with a legacy code page.
This can cause issues if the user expects to work with files or strings not supported in the active legacy code page. Often characters that cannot be represented in the code page are replaced by question marks.
I am using the staging release of 6.22.
[1]: https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-co...
Expectation:
When an application with activeCodePage set to "UTF-8" in the application manifest calls GetACP(), the number 65001 (CP_UTF8) is returned. Strings returned by WinAPI functions (eg, file paths) are encoded in UTF-8. Strings provided to WinAPI functions are UTF-8 and display appropriately in the UI.
Observed:
GetACP() returned a number representing a legacy code page (eg, 1252). Strings returned by WinAPI functions are in that code page. Characters that cannot be represented are replaced by question marks.