Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: force UTF-8 code page for app and samples #2951

Merged
merged 3 commits into from
Sep 27, 2024
Merged

Conversation

kmilos
Copy link
Collaborator

@kmilos kmilos commented Apr 12, 2024

See https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

This should make Windows behaviour almost identical to *nix w.r.t UTF-8 everywhere, and simplifies/improves on the "wmain" wrapper solution.

NB: bumps minimum requirement to Windows 10 1903 (w/ 5th gen Broadwell HW cca 2015 and later), as well as building using UCRT only (default for MSVC for a while already; for MSYS2 this means UCRT64 or CLANG64 environments; cross-building from Ubuntu/Fedora is suspended due to missing UCRT toolchains).

Could be left in the backlog until these changed requirements are deemed to be acceptable.

(This doesn't address the missing wchar_t API in the library in any way - clients would expected to run in the UTF-8 code page as well.)

@kmilos kmilos requested a review from piponazo April 12, 2024 13:48
@kmilos kmilos added i18n Internationalisation windows Windows Specific issues labels Apr 12, 2024
@kmilos
Copy link
Collaborator Author

kmilos commented Apr 12, 2024

Looks like we'll need equivalent changes for meson...

@neheb
Copy link
Collaborator

neheb commented Apr 14, 2024

Heh, Windows 10 LTSC is on 1806.

Fedora has a UCRT toolchain. Pretty barebones though.

@kmilos
Copy link
Collaborator Author

kmilos commented Apr 14, 2024

Heh, Windows 10 LTSC is on 1806.

Active/mainstream support ended for 1809 LTSC. I don't think it's reasonable to hold back (not only for this, but other possible Windows features) until 2029 when security/extended support for mission critical only devices ends?

21H2 is the oldest Windows 10 LTSC being actively supported ATM.

Mind you, this will not stop the app from working, it just won't have non-ASCII support. Then again, it doesn't really have it today either since wchar_t was removed from the API...

@neheb
Copy link
Collaborator

neheb commented May 5, 2024

Just noticed this was for the executable and not the library. Fine with me.

As far as the library goes, the removal of the wstring API ended up alienating many users as they build exiv2 with MinGW on Windows.

@kmilos
Copy link
Collaborator Author

kmilos commented May 6, 2024

Correct, this has no impact on the library itself. However, in the absence of the wstring API in the library, client apps are expected to do the same trick as well if they want to support non-ASCII filenames, meaning Windows 10 1903 is effectively the minimum supported version.

As far as the library goes, the removal of the wstring API ended up alienating many users as they build exiv2 with MinGW on Windows.

I don't think this is limited to MinGW - MSVC users would need to use the same manifest trick to force apps to run as UTF8. This is a platform thing, not a GCC vs MSVC thing.

@kmilos kmilos force-pushed the kmilos/win_utf8 branch 2 times, most recently from 074a688 to b37759a Compare September 27, 2024 13:22
@kmilos kmilos marked this pull request as ready for review September 27, 2024 13:34
@neheb neheb merged commit 93f0078 into main Sep 27, 2024
63 checks passed
@neheb neheb deleted the kmilos/win_utf8 branch September 27, 2024 19:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n Internationalisation windows Windows Specific issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants