Re: Fix xcopy so output is either unicode (console) or oem (file)
В сообщении от 23 апреля 2007 16:11 вы написали:
"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote:
The written strings in 866 and 1251 code pages are only readable when output console code page matches the string encoding.
This is in wine. In windows only cp866 is readable regardless of ConsoleOutputCP.
As I said I tested under Windows (XP) only, and SetConsoleOutputCP does change the behaviour of WriteConsoleA for me. If it wouldn't I'd call it a bug.
I tested under Windows 2003 and SetConsoleOutputCP does NOT change the behaviour of WriteConsoleA for me. Does Windows play us a trick?
No the difference in observed behaviour was caused by the fact that I ran the test under FAR, once I run it under cmd.exe I see what you do.
Ahhh, I understood!!! You test does not return codepage back to 866. My version of your test does it. Far Manager somehow checks codepage and converts characters accordingly. I've removed the last convertion back to cp866 and observed the same behaviur as you. Thus, I can proclaim WriteConsoleA buggy. -- Kirill
В сообщении от 23 апреля 2007 16:11 вы написали:
"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote:
The written strings in 866 and 1251 code pages are only readable when output console code page matches the string encoding.
This is in wine. In windows only cp866 is readable regardless of ConsoleOutputCP.
As I said I tested under Windows (XP) only, and SetConsoleOutputCP does change the behaviour of WriteConsoleA for me. If it wouldn't I'd call it a bug.
I tested under Windows 2003 and SetConsoleOutputCP does NOT change the behaviour of WriteConsoleA for me. Does Windows play us a trick?
No the difference in observed behaviour was caused by the fact that I ran the test under FAR, once I run it under cmd.exe I see what you do.
Ahhh, I understood!!!
You test does not return codepage back to 866. My version of your test does it. Far Manager somehow checks codepage and converts characters accordingly. I've removed the last convertion back to cp866 and observed the same behaviur as you.
Thus, I can proclaim WriteConsoleA buggy.
The final result: 1) WriteConsoleA is OK - while preparing the tests the truth was revealed. 2) The main issue is hidden in Windows console renderer. I've tried three different ways: windowed with TrueType font (lucida), windowed with Fixedsys font and fullscreen mode. a) Lucida Console font: the behaviour in wine and windows the same. (Dmitry observed this). b) Fixedsys: wine - the same as with Lucida Console font - nothing changed. windows - only cp866 is OK. (I observed this) c) Fullscreen. In this case font codepage is changed immediately: previously written text is changed. This behaviour in unique for fullscreen mode. Thus I can conclude that console codepages are used by console renderer too, not just by WriteConsoleA. Should this windows behaviour be implemented in wine? I think no, it is too insane and needless. But this should be kept in mind, maybe update docs? -- Kirill
Kirill K. Smirnov a écrit :
В сообщении от 23 апреля 2007 16:11 вы написали:
"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote:
> The written strings in 866 and 1251 code pages are only readable > when output console code page matches the string encoding. > This is in wine. In windows only cp866 is readable regardless of ConsoleOutputCP.
As I said I tested under Windows (XP) only, and SetConsoleOutputCP does change the behaviour of WriteConsoleA for me. If it wouldn't I'd call it a bug.
I tested under Windows 2003 and SetConsoleOutputCP does NOT change the behaviour of WriteConsoleA for me. Does Windows play us a trick?
No the difference in observed behaviour was caused by the fact that I ran the test under FAR, once I run it under cmd.exe I see what you do.
Ahhh, I understood!!!
You test does not return codepage back to 866. My version of your test does it. Far Manager somehow checks codepage and converts characters accordingly. I've removed the last convertion back to cp866 and observed the same behaviur as you.
Thus, I can proclaim WriteConsoleA buggy.
The final result: 1) WriteConsoleA is OK - while preparing the tests the truth was revealed. 2) The main issue is hidden in Windows console renderer. I've tried three different ways: windowed with TrueType font (lucida), windowed with Fixedsys font and fullscreen mode. a) Lucida Console font: the behaviour in wine and windows the same. (Dmitry observed this). b) Fixedsys: wine - the same as with Lucida Console font - nothing changed. windows - only cp866 is OK. (I observed this) c) Fullscreen. In this case font codepage is changed immediately: previously written text is changed. This behaviour in unique for fullscreen mode.
Thus I can conclude that console codepages are used by console renderer too, not just by WriteConsoleA. Should this windows behaviour be implemented in wine? I think no, it is too insane and needless. But this should be kept in mind, maybe update docs?
just a dummy question... does the different fonts your tests refer to have all the glyphs required ? (or said differently, isn't this a font issue about the required glyphs for russian ?) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
participants (2)
-
Eric Pouech -
Kirill K. Smirnov