locales, unicode and ansi with msvcrt (bug 8022)

Kirill K. Smirnov lich at math.spbu.ru
Mon Apr 16 19:19:25 CDT 2007

I've tried the test with winelib and got:

$ winegcc test.c
$ ./a.out > nya
$ od -x nya
0000000 3f3f 3f3f 3f3f 3f3f 0066

This output differs from previous. I tried this under several locales, the 
results are the same.
When I applied the patch, EXE version (I used mingw32 instead of VC 6), works 
OK, but no changes with winelib. Buggy winegcc???

Next test.
Here I use localized strings.
#include <windows.h>

void main() {
    /* "Это тест" ("this is a test" in Russian) */
    WCHAR russtr[]={0x044d, 0x0442, 0x043e,
                    0x0020, 0x0442, 0x0435,
                    0x0441, 0x0442, 0x0000};
    wprintf(L"test with wprintf");

Result of mingw32-gcc version:

0000000 6574 7473 7720 7469 2068 7077 6972 746e
0000020 fd66 eef2 f220 f1e5 00f2

The localized string has been written in cp1251.
The results are the same "wine cmd a.exe" and "wine /k a.exe". 
winconsole --backend=user does not work.

The same test under windows (mingw32 version): Only "test with wprintf" has 
been printed.
No localized string. Mystic? Wine works, but windows does not???

Under simple "wine cmd /k ..." windows programs and wine produce the same 
output (now). Under wineconsole embedded cmd commands like 'help' still does 
not work. Windows The Native Ones - works OK. I suspect we output them in the 
wrong way.

Thus, the bug where xcopy was writing out characters padded with gaps is 
but invalid codepage bug is still present. pf_vsnprintf is buggy??? (yes, it 
sounds blasphemic, but it is the one thing I can imagine).

Thanks a lot!

More information about the wine-devel mailing list