Web lists-archives.com

Re: [Mingw-users] putwchar not working




Well, as an experiment I tried the mingw64, and it works fine and prints unicode both Arabic and English in the command window, as shown in the attached png image.
Here is the listing of the program that worked, it prints an 'a' next to my first name in Arabic, to show that it prints both latin and other non-latin (Actually my guess any valid utf8 character, or may be just the BMP).
Note however that from the options menu I changed the font from Lucida console (the default and which did not work) to courier new.

So I am not sure how they did it in the mingw64,project  but clearly this takes the blame off Microsoft...

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <wchar.h>
#include <locale.h>
int main(void)
{
    char s1[] = "a\uFEEB\uFEB8\uFE8E\uFEE1"; // or "a\u\U"
    char s2[] = u8"a\uFEEB\uFEB8\uFE8E\uFEE1";
    //setlocale(LC_ALL, "en_US.utf8");
    printf("%s\n", s1);
    printf("%s\n", s2);
return 0;
}

 
hisham...


On Friday, September 9, 2016 6:08 PM, Eli Zaretskii <eliz@xxxxxxx> wrote:


> From: Yongwei Wu <wuyongwei@xxxxxxxxx>
> Date: Fri, 9 Sep 2016 22:41:53 +0800
> Cc: "mingw-users@xxxxxxxxxxxxxxxxxxxxx" <mingw-users@xxxxxxxxxxxxxxxxxxxxx>
>
> > 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.
>
> It is a luxury to talk about this, when we have problems dealing with the BMP.

When using the wide APIs, there are no such problems.

> > 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.)

Localization the gettext way has a very limited utility on Windows
anyway, because most Posix programs nowadays assume UTF-8, which is
compatible with "char *" strings, something that on Windows is
possible only with single-byte codepages and a small number of
codepages that support DBCS.  If we want localization on Windows that
really works, the only practical way is to provide replacements for
setlocale and all the multibyte and wide-character functions in the
CRT to support UTF-8 and work with 32-bit wchar_t data type.  Anything
less than that is no more than an illusion of non-ASCII support, and
breaks as soon as you try it in a locale outside Western Europe.

So if we want to fix MSVCRT in this area, we need to come up with a
much larger library than just a replacement for putwchar.  If someone
volunteers to do that job, I think it would allow the MinGW project to
become a much better environment for porting Posix programs that deal
with non-ASCII than it is today, including localization in the likes

of GCC.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe


Attachment: ExampleWchar_Mingw64.png
Description: PNG image

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe