[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: TeLeMan
Subject: Re: [Qemu-devel] [PATCH] w32: QEMU applications with SDL are always GUI applications
Date: Mon, 19 Dec 2011 17:31:09 +0800

On Mon, Dec 19, 2011 at 16:15, Stefan Weil <address@hidden> wrote:
> 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.
Why do you think so? Every configure option may generate one different variant.

> 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.
I did compile SDL with --disable-stdio-redirect.

reply via email to

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