https://bugs.winehq.org/show_bug.cgi?id=48105
Bug ID: 48105 Summary: kernel32:console fails on Japanese and Chinese Windows Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
Running the kernel32:console test on Windows 10 1809 in Japanese or Chinese results in 6 failures:
console.c:867: Test failed: ReadConsoleOutputCharacterW failed console.c:869: Test failed: string does not match the pattern console.c:880: Test failed: ReadConsoleOutputCharacterW failed console.c:882: Test failed: string does not match the pattern console.c:889: Test failed: ReadConsoleOutputCharacterW failed console.c:891: Test failed: string does not match the pattern
These failures appear to be systematic but the w1064v1809_ja and w1064v1809_zh_CN VMs do not always succeed in submitting their WineTest results to test.winehq.org so the failures only appear intermittently there.
See https://test.winehq.org/data/tests/kernel32:console.html
https://bugs.winehq.org/show_bug.cgi?id=48105
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=48105
--- Comment #1 from François Gouget fgouget@codeweavers.com --- Nowadays there are only two failures per run but it impacts Korean too.
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
https://bugs.winehq.org/show_bug.cgi?id=48105
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- likely fixed by 35c65edcb92557e34c424c2026614adfff21b500 François: I let you confirm and close if ok.
https://bugs.winehq.org/show_bug.cgi?id=48105
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |35c65edcb92557e34c424c20266 | |14adfff21b500 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #4 from François Gouget fgouget@codeweavers.com --- Yep, this is fixed.
https://bugs.winehq.org/show_bug.cgi?id=48105
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.0-rc1.