Ah yes, and the joys of windows ce (compact edition) for mobile devices ironically supporting widechar Win32 API only.
The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
31–40 of 73 posts
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#32> Windows adopted Unicode before most other operating systems. [citation needed] Windows multibyte / mbcs is not unicode.
Windows NT uses actual Unicode under the hood (originally UCS-2, now UTF-16). Windows NT started development in 1989 and was released in 1993. Considering the Unicode standard was first published in 1991/2, I think Windows NT can be counted as an early adopter.
Well, UCS-2 is not UTF-16
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#33Earlier quoted context omitted.
No, I'm fully aware of it being a variable-length encoding. Yet as such it is still simpler to work with than UTF-8. So if we are to use a variable-length encoding anyway then UTF-16 is a reasonable choice. It is not compatible with ASCII and old APIs, that's true, but I cannot judge how important this is. I guess that for some projects the efficiency of UTF-16 should outweigh the inconveniences of that incompatibili…
Can you show some concrete instances of it being easier to work with compared to UTF-8? As far as I can see you gain variable length encoding (albeit in a potentially confusing way) while losing ASCII support and also not gaining the pure simplicity of UTF-32. Oh and also endianness, although personally that's probably never an issue I will run into.
(Please see my reply to a sibling comment.)
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#34Earlier quoted context omitted.
Can you show some concrete instances of it being easier to work with compared to UTF-8? As far as I can see you gain variable length encoding (albeit in a potentially confusing way) while losing ASCII support and also not gaining the pure simplicity of UTF-32. Oh and also endianness, although personally that's probably never an issue I will run into.
(Please see my reply to a sibling comment.)
Perfect, thanks for the heads up!
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#35I am kinda surprised how much Windows likes its wchar's. Windows had support for multi-byte codepages since early days, and it has ways to indicate compatibility level for individual apps. It seems the solution would be simple: once UTF-8 introduced (back in 1996!), add new "UTF-8" codepage, add new "SetDefaultCodepageToUnicode()" function, and tell everyone that wchar_t is legacy and should not be used anymore. They…
> and finally got the proper support in Windows 10
Not quite, you still can't use some features like longPathAware with the "ANSI" APIs. The preferred APIs for file paths are still the ones using wchar, although the UTF8 codepage is apparently the preferred method for non-path APIs and console IO, at least on the GDK.
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#36Earlier quoted context omitted.
Windows NT uses actual Unicode under the hood (originally UCS-2, now UTF-16). Windows NT started development in 1989 and was released in 1993. Considering the Unicode standard was first published in 1991/2, I think Windows NT can be counted as an early adopter.
Well, UCS-2 is not UTF-16
But it is Unicode.
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#37I remember this hoopla. And windows wasn't the only victim of using "two bytes for a char" for unicode support. Java fell in this trap too. The team was split in deciding "whether to waste a single byte per character for string" -- that's in their words, and then decided to rather be ready for the future. That's in 1995. And then everyone later watched UTF-8 take over the world. The PHP team also wasted their version…
> Why didn't they go the UTF-8 round?
The original Unicode marketing / position statement from 1988[1] may provide a clue:
“In the Unicode system, a simple unambiguous fixed-length character encoding is integrated into a coherent overall architecture for text processing.”
“Unicodes [sic] are the most straightforward multilingual generalization of ASCII codes: - Fixed length of character code (16 bits); [...]”
“Are 16 bits [...] sufficient to encode all characters of all the world’s scripts? [...] Yes.”
“[A] fixed length-encoding is flat-out simple, with all the blessings attendant upon that virtue.”
Etc., etc.
The hypothetical possibility of more than 2^16 characters was introduced in Unicode 2.0 (1996), while actual such characters didn’t appear until Unicode 3.0 (1999). Windows NT shipped in 1993, OpenStep in 1994, Java and JavaScript in 1995. UTF-8 was presented at USENIX in January 1993; a contemporary exposition[2] says that “the 4[!], 5 and 6 byte sequences are only there for political reasons” (presumably referring to the fact that Unicode committed to 2^16 code points while the new, Unicode-compatible draft of ISO 10646 stuck with 2^31).
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#38Think of all the time, money, and effort wasted on Unicode.
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#39Think of all the time, money, and effort wasted on Unicode.
What is your recommended alternate solution?
Re: The sad history of Unicode printf-style format specifiers in Visual C++ (2019)
#40The fact that in Windows-speak 'unicode' and 'UCS-2' (an encoding) have been used as synonyms has caused a universe of confusion. Even after I grokked the difference I still had arguments with colleagues who remained bamboozled by it. The fact that for a brief time there were only 64k code points, so that you could sort-of fudge the distinction, only made things worse in the long run.
Note that Windows uses UTF-16, not UCS-2.