msvcrt: Make the first call to fwrite bufferred (try2)

Andreas Fuchs anduchs at gmail.com
Thu Oct 2 04:43:10 CDT 2014


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
> 
> 





More information about the wine-devel mailing list