Re: [Mingw-users] putwchar not working
- Date: Fri, 9 Sep 2016 22:41:53 +0800
- From: Yongwei Wu <wuyongwei@xxxxxxxxx>
- Subject: Re: [Mingw-users] putwchar not working
On Friday, 9 September 2016, Eli Zaretskii <eliz@xxxxxxx> wrote:
> > From: Yongwei Wu <wuyongwei@xxxxxxxxx>
> > Date: Fri, 9 Sep 2016 09:35:02 +0800
> > Cc: MinGW Users List <mingw-users@xxxxxxxxxxxxxxxxxxxxx>
> > > 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
It is a luxury to talk about this, when we have problems dealing with the BMP.
> > 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.
I see your point, but I need to point out that it means completely
different porting efforts, if the original application uses putchar
etc. Just take the example of GCC: Oh, it outputs garbage information
if it detects the environment is Chinese! I have to force the language
to English to make it work. (I am not sure whether the current version
of MinGW GCC ships with Chinese localization, since I am mainly on Mac
now. It used to be the case....)
Do you want to tell the GCC guys that they need to replace all
occurrences of putchar etc.? (Maybe the easier approach is rid MinGW
of all localization.)
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: