Hi Piotr,
thanks for clearing this up for me... I was caught so off guard by the change in behavior that it did not occur to me that this was actually a correction...
Sorry for the trouble...
Cheers, Andreas
Am Donnerstag, den 02.10.2014, 11:01 +0200 schrieb Piotr Caban:
Hi,
On 10/02/14 10:28, Andreas Fuchs wrote:
Hi Piotr, Hi all,
I traced down this commit as the origin of the regression, where I cannot parse stdout of wine correctly anymore. See also https://bugs.winehq.org/show_bug.cgi?id=37345
I hope, sombody knowledgable (Piotr maybe you as the author) could help me figure this out or even provide a fix...
Description: When calling wine from another process after redirecting stdout to a pipe, wine does not flush the stdout-buffer correctly anymore (Wine 1.6 did correctly).
Attached is a usecase. To test do: i686-w64-mingw32-gcc helloworld.c gcc callwine.c ./a.out
What will happen is:
- on a buggy wine it will take 10 seconds and then all of the stdout-buffer is flushed on the exit of the child. (imagine the child would run longer than the 10 seconds)
- on a good wine we will see some stdout-content then 10 second sleep and then the rest of the content.
this is not a bug. The pipes are supposed to be buffered on windows.
The simple way of reproducing it is following: i686-w64-mingw32-gcc helloworld.c wine a.exe |more (linux) a.exe |more (windows) In both cases you will see all of the output after 10 seconds.
Cheers, Piotr