4 ms·
Most of the post talks about how Windows made a poor design decision in choosing 16bit characters. No debate there. However, advocating "just make windows use
by optimiz3 13y ago
Most of the post talks about how Windows made a poor design decision in choosing 16bit characters.
No debate there.
However, advocating "just make windows use UTF8" ignores the monumental engineering challenge and legacy back-compat issues.
In Windows most APIs have FunctionA and FunctionW versions, with FunctionA meaning legacy ASCII/ANSI and FunctionW meaning Unicode. You couldn't really fix this without adding a 3rd version that was truly UTF-8 without breaking lots of apps in subtle ways.
Likely it would also only be available to Windows 9 compatible apps if such a feature shipped.
No dev wanting to make money is going to ship software that only targets Windows 9, so the entire ask is tough to sell.
Still no debate on the theoretical merits of UTF-8 though.
- angersock 13y agoNothing worth doing is easy. Anyways, the FunctionA/FunctionW is usually hidden behind a macro anyways (for better or worse). This could simply be yet another compiler option.
- gamacodre 13y agoWe "solved" (worked around? hacked?) this by creating a set of FunctionU macros and in some cases stubs that wrap all of the Windows entry points we use with incoming and outgoing converters. It's ugly under the hood and a bit slower than it needs to be, but the payoff of the app being able to consistently "think" in UTF-8 has been worth it. Of course, we had to ditch resource-based string storage anyway for other cross-platform reasons, and were never particularly invested in the "Windows way" of doing things, so it wasn't a big shock to our developers when we made this change.