http://bugs.winehq.org/show_bug.cgi?id=27229
Summary: printf() newline missing with multibyte strings Product: Wine Version: 1.3.20 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: itakingiteasy@gmail.com
Created an attachment (id=34797) --> (http://bugs.winehq.org/attachment.cgi?id=34797) Code example making case for missing newline in wine printf when multibyte string is printed
Wine's printf is missing newline when "Multibyte string пукпукпук\n" is supplied to printf(). Attached code is a test-case reproducing the bug. When same binary exectued on windows, or same code compiled for- and executed on- linux - all goes fine. Only when executed under wine newline is missing. It results in that printed string shares same line with next PS1 prompt here is screenshot illusrating the problem (FIG1):
(FIG1) ftp://neverb.net/images/special/screenshot/wine_issue/linux_wine_cmd_exe.png
Note that extra newline in wine cmd.exe is missing.
Here is refference windows screenshot (FIG2) showing where this extra newline should be:
(FIG2) ftp://neverb.net/images/special/screenshot/wine_issue/native_windows.png
Known possible workarounds for this problem:
* add '\r' before '\n' * use only ascii (non-multibyte) characters in printing string * use WCHAR instead of wchar_t * use wprintf(L"%ls\n"~ instead of printf("%s"~
But all this workarounds are just a sideways. I hope that there is some real solution.
Thanks.
http://bugs.winehq.org/show_bug.cgi?id=27229
--- Comment #1 from Alexander Tumin itakingiteasy@gmail.com 2011-05-20 09:28:12 CDT --- Created an attachment (id=34798) --> (http://bugs.winehq.org/attachment.cgi?id=34798) (FIG1) Screenshot illusrating missing newline in wine printf() multibyte string
http://bugs.winehq.org/show_bug.cgi?id=27229
--- Comment #2 from Alexander Tumin itakingiteasy@gmail.com 2011-05-20 09:29:22 CDT --- Created an attachment (id=34799) --> (http://bugs.winehq.org/attachment.cgi?id=34799) (FIG2) Native windows newline refference screenshot
http://bugs.winehq.org/show_bug.cgi?id=27229
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase
http://bugs.winehq.org/show_bug.cgi?id=27229
--- Comment #3 from Alexander Tumin itakingiteasy@gmail.com 2011-05-21 13:04:37 CDT --- It is confirmed that wines 1.0.1-ubuntu14 and 1.2.2-0ubuntu6 are not affected by this bug.
http://bugs.winehq.org/show_bug.cgi?id=27229
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Status|UNCONFIRMED |NEW CC| |eric.pouech@orange.fr Ever Confirmed|0 |1
--- Comment #4 from Austin English austinenglish@gmail.com 2011-05-21 18:00:31 CDT --- Confirming. Regression testing points to: 45ade6c2f57adaa9bde009063d3d5b9294dc5d35 e4d090277b3f4f76b39e55480e5d1387798dbabe
Before these two commits, it works fine. After 45ade6c2f57adaa9bde009063d3d5b9294dc5d35, nothing is printed to the terminal, except for a newline. After e4d090277b3f4f76b39e55480e5d1387798dbabe, characters are printed, but are missing a newline.
http://bugs.winehq.org/show_bug.cgi?id=27229
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |45ade6c2f57adaa9bde009063d3 | |d5b9294dc5d35
http://bugs.winehq.org/show_bug.cgi?id=27229
--- Comment #5 from Eric Pouech eric.pouech@orange.fr 2011-10-08 03:48:14 CDT --- to add a couple of more tests: - if you replace the MBCS string by a 7bit ANSI string, you get the same behavior - if you print several strings in the tests program (instead of a single one), you don't get extra new lines between the strings (only a missing newline is to be seen at the end of the output) - if you run the test program under cmd and not under a unix shell, you get the expected behavior - cmd rightfully (as windows' cmd does) start any prompt by a \r\n sequence
therefore, I conclude that: - wine printf & console code is correct (doesn't miss any conversion) - unix shell (at least bash) doesn't start the prompt by a new line unlike cmd - I don't see an easy fix (except printing the newline at program exit when it knows it's run from a unix shell - ie it doesn't have a windows' parent)
Alexander => can you confirm this on your side (just to be sure I didn't misunderstand you bug report) ?
A+
http://bugs.winehq.org/show_bug.cgi?id=27229
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
--- Comment #6 from Austin English austinenglish@gmail.com 2013-08-07 20:52:59 CDT --- Still in 1.7.0.
https://bugs.winehq.org/show_bug.cgi?id=27229
--- Comment #7 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #6)
Still in 1.7.0.
Somewhere between 1.7.0 and 1.7.10 it stopped printing anything at all. That behavior persists in 1.7.30.
https://bugs.winehq.org/show_bug.cgi?id=27229
Thomas Faller tfaller1@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tfaller1@gmx.de
--- Comment #8 from Thomas Faller tfaller1@gmx.de --- printf is not the problem. Due to gcc optimizations printf is optimized to a puts -> \n will be removed.
If I use the switch -fno-builtin-printf the whole line (including \n) is printed.
The problem that nothing is printed should be a fwrite (called by puts) issue.
Trace:
Call msvcrt.puts(00241868 "\xd1\x82\xd0\xb5\xd0\xba\xd1\x81\xd1\x82 \xe6\x97\xa5\xe6\x9c\xac\xe8\xaa\x9e") ret=00401695 trace:msvcrt:_lock (29) trace:msvcrt:MSVCRT__isatty :fd (1) Call KERNEL32.WriteFile(00000017,0061fc0b,00000001,0061fbb8,00000000) ret=7ebafee0 trace:file:WriteFile 0x17 0x61fc0b 1 0x61fbb8 (nil) get_console_input_info( handle=0000 ) get_console_input_info() = 0 { history_mode=0, history_size=50, history_index=0, edition_mode=0, input_cp=0, output_cp=65001, win=00000000, title=L"" } nls:MultiByteToWideChar cp 65001 "\xd1" -> (null), ret = 0 get_console_input_info( handle=0000 ) get_console_input_info() = 0 { history_mode=0, history_size=50, history_index=0, edition_mode=0, input_cp=0, output_cp=65001, win=00000000, title=L"" } nls:MultiByteToWideChar cp 65001 "\xd1" -> L"", ret = 0 console:WriteConsoleW 0x17 L"" 0 0x61fbb8 (nil) ntdll:NtWriteFile (0x14,(nil),(nil),(nil),0x61f9f4,0x118a90,0x00000000,(nil),(nil))! ntdll:NtWriteFile = SUCCESS (0) Ret KERNEL32.WriteFile() retval=00000001 ret=7ebafee0 msvcrt:MSVCRT__write WriteFile (fd 1, hand 0x17) failed-last error (87), num_written 0 msvcrt:_unlock (29) Ret msvcrt.puts() retval=ffffffff ret=00401695
https://bugs.winehq.org/show_bug.cgi?id=27229
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #9 from joaopa jeremielapuree@yahoo.fr --- Is still a bug in current wine(3.20)?
https://bugs.winehq.org/show_bug.cgi?id=27229
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #10 from Jacek Caban jacek@codeweavers.com --- Works fine for me with current git.
https://bugs.winehq.org/show_bug.cgi?id=27229
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.0-rc4.