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 <w...@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 :|
