[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH] w32: QEMU applications with SDL are always GUI applications
Date: Mon, 19 Dec 2011 09:15:21 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110921 Thunderbird/3.1.15

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]