Re: [Mingw-users] putwchar not working

[Eli Z. <el...@gn...>]

> From: Yongwei Wu <wuy...@gm...>
> Date: Fri, 9 Sep 2016 09:35:02 +0800
> Cc: MinGW Users List <min...@li...>
> 
> > My point is whatever you do, it won't solve the problem completely.
> > Even if putwchar will eventually do what the MS VS static libraries
> > do, some basic problem will remain.  For example, you cannot display
> > anything with putwchar that is beyond the BMP, because a single
> > wchar_t argument can only express characters in the BMP.  And that is
> > only one of the fundamental problems with non-ASCII support on the
> > Windows console.
> 
> Not supporting characters beyond the BMP does not look a big problem
> to me.

Maybe for you personally it isn't.  But being able to support just the
BMP in the year 2016 is a huge disadvantage IME.  We have already a
lot of character sets entirely in Unicode blocks beyond the BMP, and
each new version of the Unicode standard adds more.  Moreover, Windows
itself adds fonts to support these new character sets with each new
Windows version.  Being unable to support that is far from a Good
Thing.

> To me, the big problem is anything compiled by MinGW is broken
> in non-ASCII support, and, in comparison, MSVC looks much better....

Not everything compiled by MinGW is broken in this regard.  I think
Texinfo's info.exe isn't, for example (it uses WriteConsoleW).  You
just need to avoid the CRT functions like putwchar and all the rest,
because (a) they only support the BMP, and (b) they only "work" with
non-ASCII characters supported by the current codepage.  The latter
part means that (1) you need to call setlocale each time you want a
character outside of the current codepage, and (2) worse, you cannot
support Unicode at all, because UTF-8 and other Unicode encodings can
never be a codeset specified in a setlocale call.

The upshot of all this is that any program which needs to support
non-ASCII characters in a sound way has no choice but to avoid the CRT
functions entirely, and instead use the "wide" Win32 APIs (such as
WriteConsoleW) directly and convert characters from and to UTF-16 by
hand, using MultiByteToWideChar and WideCharToMultiByte.  Any program
that relies on CRT functions for that is fundamentally broken on
Windows, and the main reason is NOT the MinGW libraries.