There's a thing about the new Platform API that really irks me. And that is the usage of the *A functions for file access.
I understand Casey must draw the line somewhere and that he having control over the asset names can kinda shrug this off.
General and not HH specific speaking:
In some ways though this is a very American English thinking (ANSI is good enough) and often causes a lot of grief for people who are used to extended character sets.
It is often a source of Casey like rants for us and the mindset causes unacceptable behavior like GTA V falling flat on the face when using a windows username with extended characters.
(End not Handmade Hero specific)
I would not bring this up, but a lot of people enjoy the stream and listen to you and your advise Casey. I would really appreciate you showing people the "right" way. Not necessarily because it is super important for HH, but to set an example and make people aware of this.
I would suggest to encode/decode to UTF8 in the Win32, so the wide characters do not spill outside the platform layer. (Linux/Mac will use UTF8 pathnames anyway and pass them outside their platform layer)
I understand Casey must draw the line somewhere and that he having control over the asset names can kinda shrug this off.
General and not HH specific speaking:
In some ways though this is a very American English thinking (ANSI is good enough) and often causes a lot of grief for people who are used to extended character sets.
It is often a source of Casey like rants for us and the mindset causes unacceptable behavior like GTA V falling flat on the face when using a windows username with extended characters.
(End not Handmade Hero specific)
I would not bring this up, but a lot of people enjoy the stream and listen to you and your advise Casey. I would really appreciate you showing people the "right" way. Not necessarily because it is super important for HH, but to set an example and make people aware of this.
I would suggest to encode/decode to UTF8 in the Win32, so the wide characters do not spill outside the platform layer. (Linux/Mac will use UTF8 pathnames anyway and pass them outside their platform layer)
I despite UTF-16, so I don't know... I'll think about it :P
- Casey
- Casey
Everybody hates UTF-16 :)
What JohnL suggests is exactly what I do in my code - keep everything UTF8 so its cross platform and I can store everything in char array. Just before passing strings to Windows I convert them:
And WideCharToMultiByte for converting other way around - when I get UTF-16 string from Windows and need to convert UTF-8.
I found this is easiest way how to use Unicode API in Windows C/C++ code. All that TCHAR and _("...") define's are terrible.
In non US countries a lot of people use Windows in their native locale. On such machines it is very probable that either username won't be represented in ANSI encoding (C:\Users\āņšāģ\...) or "C:\Program Files" will have weird name. Or some other problem will happen where you can not open files using WinAPI *A functions.
What JohnL suggests is exactly what I do in my code - keep everything UTF8 so its cross platform and I can store everything in char array. Just before passing strings to Windows I convert them:
1 2 3 4 | char *src = ...; WCHAR dst[MAX_PATH]; MultiByteToWideChar(CP_UTF8, 0, src, -1 /* or strlen(src) if known */, dst, MAX_PATH-1); CreateFileW(dst, ...) |
And WideCharToMultiByte for converting other way around - when I get UTF-16 string from Windows and need to convert UTF-8.
I found this is easiest way how to use Unicode API in Windows C/C++ code. All that TCHAR and _("...") define's are terrible.
In non US countries a lot of people use Windows in their native locale. On such machines it is very probable that either username won't be represented in ANSI encoding (C:\Users\āņšāģ\...) or "C:\Program Files" will have weird name. Or some other problem will happen where you can not open files using WinAPI *A functions.