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

[TeLeMan]

--
SUN OF A BEACH



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.
>
> 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.
SDL-1.3 removed the stdio-redirect feature, so we should ignore it.

Blue Swirl, can you revert this commit?
>
>