http://bugs.winehq.org/show_bug.cgi?id=13861
Summary: Use of stdio functions in wine programs Product: Wine Version: 1.0-rc4 Platform: All OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: P1 Component: programs AssignedTo: wine-bugs@winehq.org ReportedBy: wine@mkarcher.dialup.fu-berlin.de
Winelib applications get linked to native libc (not msvcrt), and thus use native stdio. This is a problem if these winelib applications are run from a wineconsole (user backend), as native linux libc does not send the output to stdio to wineserver, but to the terminal wineconsole was started from. This is, in my oppinion, an undesired effect.
Following programs use printf(...), fprintf(stderr,...) - uninstaller - msiexec - regsvr32 - net - winepath - winetest - icinfo - taskmgr (in dbgchnl.c) - expand - wordpad (one error message that should never appear)
Following programs print correctly to the console - reg - xcopy - winedbg - cmd - regedit (surprise!)
Following programs have commented (or #if 0) out printf(...), which should probably get deleted or converted to TRACE debug logs messages. - progman
I tested behaviour of all listed programs. The big surprise was regedit, which correctly outputs to the console despite of using printf. Probably this is some build option (it uses the msvcrt headers, for example).
If one looks at two programs that get it right, reg and xcopy, one sees the functions reg_printfW and XCOPY_wprintf respectively, that do approximately the same thing: Print a string into a wide char buffer (fixed length in both cases!), and then try WriteConsoleW, if that fails, WideCharToMultiByte and WriteFile(GetStdHandler(STD_OUTPUT_HANDLE),..). This function would have to be cut-and-pasted into the other 10 programs needing it. I don't think this is a good idea. (WCMD_output_asis_len is also a close match)
If the programs are crosscompiled to Windows/msvcrt, output is OK for all of them, because msvcrt's stdio is not based on unix/posix/K&R stdio, but on WriteFile(...)
How to handle this issue?