Re: [Qemu-devel] [PATCH] w32: QEMU applications with SDL are always GUI applications

[Stefan Weil]

Am 19.12.2011 03:12, schrieb TeLeMan:
> On Sat, Dec 17, 2011 at 07:12, Stefan Weil <address@hidden> wrote:
> > Am 16.12.2011 04:24, schrieb TeLeMan:
> >
> > > On Sun, Dec 4, 2011 at 05:32, Stefan Weil <address@hidden> wrote:
> > > > Since commit 1d14ffa97eacd3cb722271eaf6f093038396eac4 (in 2005),
> > > > QEMU applications on W32 don't use the default SDL compiler flags:
> > > >
> > > > Instead of a GUI application, a console application is created.
> > > >
> > > > This has disadvantages (there is always an empty console window) and
> > > > no obvious reason, so this patch removes the strange flag modification.
> > > >
> > > > The SDL GUI applications still can be run from a console window
> > > > and even send stdout and stderr to that console by setting environment
> > > > variable SDL_STDIO_REDIRECT=no.
> > >
> > > Did you test it? Windows GUI applications can not send stdout to the
> > > startup console window unless they create their own console window.
> >
> >
> > I did, but obviously not good enough:
> >
> > in an msys rxvt console the QEMU executables work as I wrote
> > in the commit message. So msys-rxvt and some other applications
> > (SciTE for example) allow running GUI applications with
> > stdio channels.
> >
> > The Windows command prompt (cmd.exe) is different, and so is
> > the normal MSYS console. Here console output does not work,
> > and I also noticed problems when running an emulation with
> > latest QEMU (application hangs).
> >
> > It seems to be difficult to get a solution which works for
> > several scenarios:
> >
> > * It should be possible to create a link which starts
> >  an emulation with parameters and only one window (SDL,
> >  no extra console window). This needs a GUI application
> >  (or is it possible for a console application to suppress
> >  or close the console window?).
> >
> > * It must be possible to see stdout and stderr output.
> >  Default today: both are written to files in the program
> >  directory. This is bad because normally users have no
> >  write access there. It also does not allow running
> >  more than one emulation with separated output.
> >
> > * It should be possible to get stdout and stderr directly
> >  to the console. This is needed for running with curses,
> >  and it is useful when asking for -help.
> >
> > * It must be possible to run QEMU executables from cmd.exe.
> >
> > * It should be possible to run QEMU executables from other
> >  shells (msys command line, msys rxvt, cygwin command line,
> >  ...).
> >
> > What would you suggest?
> Add a configure option and let users decide which one is better.

Then you get executables with same name but different behavior,
so it's always necessary to specify which configure options were used.
It makes documentation and support more difficult.

My favorite solution would be executables which work for all
(or at least most) typical use cases.

If that is impossible, maybe pairs of executables (a windows gui
and a console version for each system emulation) would also be
a reasonable choice. This only needs an additional objcopy (which
makes a copy and changes the subsystem) to get qemu-system-i386c.exe
from qemu-system-i386.exe.

There still remains the problem with stdout.txt and stderr.txt
which are used by default for any console output. This is
unusual for console applications, and it does not work when
QEMU was installed because of missing write access.