https://bugs.winehq.org/show_bug.cgi?id=48105 Eric Pouech <eric.pouech(a)orange.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)orange.fr --- Comment #2 from Eric Pouech <eric.pouech(a)orange.fr> --- More traces show that the returned buffer is 2 WCHAR:s long instead of the expected length of 4, but the two first chars in buffer are correct. Tried a couple of ideas to understand what was going wrong: - incomplete write to console: tested writing twice the buffer; produces the same errors; not the right idea - unsupported character in test_cp866 (replaced the third char with first) => produces the same errors; not the right idea - bogus locale information: tried MultiByteToWideChar(866, test_cp866) => result is the expected test_unicode; not the right idea So finally, assumed that ReadConsoleOutputCharacters was using incorrect output buffer size information: using (where the test fails) as parameter to ReadConsoleOutputCharacterW a buffer twice as large lets the tests pass => it looks like ReadConsoleOutputCharactersW in this context (locale + cp) interprets output buffer size incorrectly (using size in bytes, while documentation says size in TCHAR). I'll send a MR implementing a work around. *BUT* I don't have no idea - why it behaves this way with cp866, but behaves as documented with cp1251, which is tested just afterwards with equivalent pattern - why the number of errors (as reported in #1 and #2) has evolved over time -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.