https://bugs.winehq.org/show_bug.cgi?id=48105
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #2 from Eric Pouech eric.pouech@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