Re: [Qemu-devel] Win32 stdio not working if SDL is enabled

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Aug 14, 2015 at 12:14:15PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 13, 2015 at 07:48:47PM +0200, Stefan Weil wrote:
> > Am 13.08.2015 um 14:06 schrieb Daniel P. Berrange:
> > > When debugging some patches on Windows, I discovered that nothing printed
> > > to stderr ever appears on the console. Eventually I discovered that if I
> > > build with --disable-sdl, then stderr appears just fine.
> > > 
> > > Looking at the code in vl.c I see a hack for SDL introduced in
> > > 
> > >   commit 59a36a2f6728081050afc6ec97d0018467999f79
> > >   Author: Stefan Weil <weil@mail.berlios.de>
> > >   Date:   Thu Jun 18 20:11:03 2009 +0200
> > > 
> > >     Win32: Fix compilation with SDL.
> > > 
> > > 
> > > If I mostly kill the hack from vl.c, and just leave a plain '#undef main'
> > > then I get working console stderr once again.
> > > 
> > 
> > Hi Daniel,
> > 
> > that's a feature of SDL 1.2: stdout and stderr are by default
> > redirected to files stdout.txt and stderr.txt in the executable's
> > directory.
> > 
> > This redirection can be disabled by an environment variable
> > (SDL_STDIO_REDIRECT="no"). On my Linux machines, I always
> > set this variable, so when I run QEMU for Windows with
> > wine32 or wine64, stdout and stderr work.
> > 
> > Printing to stdout / stderr on Windows can be an adventure:
> > depending on your shell (command.exe, cmd.exe, MinGW shell,
> > MinGW rxvt, Cygwin shell, ...) it works different, and I also
> > had application crashes when a GUI application which was
> > not started from a shell tried to print to stdout.
> 
> I see it is something intentional done by SDL, but I don't think it is
> desirable in general.  I rather doubt it would crash as that would imply
> that code is checking the return value of fprintf() and taking some action
> on error. Instead we exclusive ignore fprintf() return values, so if the
> OS is reporting an I/O error we'll be ignoring it. In any case, it is
> possible to build QEMU on Win32 without SDL, or set that env variable,
> at which point QEMU will be printing to stdio anyway. So in the unlikely
> case there is a crash scenario, we need to fix that regardless.
> 
> IMHO we should be disabling this bogus behaviour of SDL so QEMU does not
> have different behaviour wrt stdio depending on what libraries you happen
> to build against, or what platform you choose. Expecting people to know
> about a magic env variable to make QEMU work as it does everywhere else
> is just broken.

A thought occurs to me - on Windows we actually build two copies of
the emulator

 - qemu-system-x86_64.exe - linked to the "console" subsystem
 - qemu-system-x86_64w.exe - linked to the "windows" subsystem [1]

With the 'windows' subsystem build it is reasonable to believe that the
user will not have any console generally available to view stderr/out.

So how about we make it such that when linked to the 'console' subsystem
we have stdout/stderr open by default, and when linked to the 'windows'
subsystem we have stdout/stderr redirected to a file (as SDL does). Except
that we make this redirection to a file happen in QEMU code, so it has
consistent behaviour even in non-SDL builds on Windows.

Regards,
Daniel

[1] '-mwindows'
     This option is available for Cygwin and MinGW targets.  It
     specifies that a GUI application is to be generated by instructing
     the linker to set the PE header subsystem type appropriately.
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|