-- SUN OF A BEACH
On Mon, Dec 19, 2011 at 16:15, Stefan Weil <s...@weilnetz.de> wrote: > Am 19.12.2011 03:12, schrieb TeLeMan: > >> On Sat, Dec 17, 2011 at 07:12, Stefan Weil <s...@weilnetz.de> wrote: >>> >>> Am 16.12.2011 04:24, schrieb TeLeMan: >>> >>>> On Sun, Dec 4, 2011 at 05:32, Stefan Weil <s...@weilnetz.de> 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? > >
