Allow using unicode characters in world names regardless of system language on Windows 10 1903 and newer versions

[Qrox]

Summary

Bugfixes "Allow using unicode characters in world names regardless of system language on Windows 10 1903 and newer versions"

Purpose of change

Windows by default uses the code page corresponding to the system language as the active code page. Many code pages use charsets that support limited unicode characters. For example, the simplified Chinese charset GBK is missing the copyright symbol "©". So when you try to ridicule Windows by asking it to create a world with the name in the image, it throws a fit and miserably fails.

Describe the solution

According to this article, as of Windows 10 1903 you can use an application manifest to switch an application to the utf-8 code page. For older Windows versions, it falls back to using the default system-language-specific code page, and the game will still work, but only characters in the active code page can be used for world names.

Testing

Created worlds with names containing English, Chinese, the copyright symbol ©, and the cow emoji 🐂 (U+1F402, outside the basic multilingual plane), all of which succeeded. (The font doesn't render the cow emoji correctly though)

Game still runs on Windows XP, but it fails as before when saving/loading files with paths containing characters not in the active code page, as expected.

Additional context

Maybe we can make it fail more gracefully when creating a file with a character not in the active code page on older Windows versions.

As a bonus, the application manifest now makes the crash popup more consistent with the system UI style. It's always more comforting when you see a prettier crash window, I guess.

[BrettDong]

Does this also solve the problem of not being able to create world with CJK characters on English version Windows 7, or the world name will then be empty?

[Qrox]

Only Windows 10 1903 onwards supports setting the active code page this way. I didn't test it but I think on older versions including Winodws 7 it will behave as before. I.e. the folder is created because the code calls the wide char version of the Windows filesystem functions, but file creation fails in MinGW-compiled versions because the path is mangled after converting from utf-8 to the active code page.

[Night-Pryanik]

Should this close #28756?

[Qrox]

Hard to say, the OP didn't provide enough detail. Anyway, the ultimate fix would be using the wchar_t * constructor of fstream from c++17, and this is just a temporary fix that works for newer Windows versions.