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

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

[Stefan Weil]

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.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 configure |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index ac4840d..f2fdb1d 100755
--- a/configure
+++ b/configure
@@ -1522,9 +1522,6 @@ EOF
   if compile_prog "$sdl_cflags" "$sdl_libs" ; then
     sdl_libs="$sdl_libs -lX11"
   fi
-  if test "$mingw32" = "yes" ; then
-    sdl_libs="`echo $sdl_libs | sed s/-mwindows//g` -mconsole"
-  fi
   libs_softmmu="$sdl_libs $libs_softmmu"
 fi
 
-- 
1.7.2.5

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

[Blue Swirl]

Thanks, applied.

On Sat, Dec 3, 2011 at 21:32, Stefan Weil <sw@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.
>
> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> ---
>  configure |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index ac4840d..f2fdb1d 100755
> --- a/configure
> +++ b/configure
> @@ -1522,9 +1522,6 @@ EOF
>   if compile_prog "$sdl_cflags" "$sdl_libs" ; then
>     sdl_libs="$sdl_libs -lX11"
>   fi
> -  if test "$mingw32" = "yes" ; then
> -    sdl_libs="`echo $sdl_libs | sed s/-mwindows//g` -mconsole"
> -  fi
>   libs_softmmu="$sdl_libs $libs_softmmu"
>  fi
>
> --
> 1.7.2.5
>
>

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

[TeLeMan]

On Sun, Dec 4, 2011 at 05:32, Stefan Weil <sw@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.

> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> ---
>  configure |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index ac4840d..f2fdb1d 100755
> --- a/configure
> +++ b/configure
> @@ -1522,9 +1522,6 @@ EOF
>   if compile_prog "$sdl_cflags" "$sdl_libs" ; then
>     sdl_libs="$sdl_libs -lX11"
>   fi
> -  if test "$mingw32" = "yes" ; then
> -    sdl_libs="`echo $sdl_libs | sed s/-mwindows//g` -mconsole"
> -  fi
>   libs_softmmu="$sdl_libs $libs_softmmu"
>  fi
>
> --
> 1.7.2.5
>
>

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

[Stefan Weil]

Am 16.12.2011 04:24, schrieb TeLeMan:
> On Sun, Dec 4, 2011 at 05:32, Stefan Weil <sw@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?

Regards,

Stefan Weil

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

[TeLeMan]

On Sat, Dec 17, 2011 at 07:12, Stefan Weil <sw@weilnetz.de> wrote:
> Am 16.12.2011 04:24, schrieb TeLeMan:
>
>> On Sun, Dec 4, 2011 at 05:32, Stefan Weil <sw@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.

> Regards,
>
> Stefan Weil
>
>

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 <sw@weilnetz.de> wrote:
>> Am 16.12.2011 04:24, schrieb TeLeMan:
>>
>>> On Sun, Dec 4, 2011 at 05:32, Stefan Weil <sw@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.

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

[TeLeMan]

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

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

[Andreas Färber]

Am 19.12.2011 09:15, schrieb Stefan Weil:
> 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.

Java and Mono used xyz.exe for the console version and xyzw.exe for the
Windows GUI version. I'd suggest to stick with that convention.

Andreas

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 <sw@weilnetz.de> wrote:
> Am 19.12.2011 03:12, schrieb TeLeMan:
>
>> On Sat, Dec 17, 2011 at 07:12, Stefan Weil <sw@weilnetz.de> wrote:
>>>
>>> Am 16.12.2011 04:24, schrieb TeLeMan:
>>>
>>>> On Sun, Dec 4, 2011 at 05:32, Stefan Weil <sw@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?
>
>

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

[Stefan Weil]

Am 22.12.2011 02:50, schrieb TeLeMan:
> SDL-1.3 removed the stdio-redirect feature, so we should ignore it.
>
> Blue Swirl, can you revert this commit?

I'd prefer to keep it. There are good reason why SDL applications
are linked as Windows applications by default, so we should use
this default.

Yes, it's no perfect solution, but even for developers who want
to see stdout and stderr, it works when you use a rxvt console
or something equivalent.

You said that you use a self-compiled SDL library.
Then you can change your sdl-config or sdl.pc so that it
sets the SDL linker options according to your needs.

What about my proposal to create each system emulation in two
variants (qemu-system-i386.exe, qemu-system-i386w.exe)?
Do you think this might be a solution which fits everybody's
needs?

Regards,
Stefan Weil

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

[TeLeMan]

On Thu, Dec 22, 2011 at 14:45, Stefan Weil <sw@weilnetz.de> wrote:
> Am 22.12.2011 02:50, schrieb TeLeMan:
>
>> SDL-1.3 removed the stdio-redirect feature, so we should ignore it.
>>
>> Blue Swirl, can you revert this commit?
>
>
> I'd prefer to keep it. There are good reason why SDL applications
> are linked as Windows applications by default, so we should use
> this default.
>
> Yes, it's no perfect solution, but even for developers who want
> to see stdout and stderr, it works when you use a rxvt console
> or something equivalent.
Now the MinGW default shell is a console application and rxvt is unmaintained.

> You said that you use a self-compiled SDL library.
> Then you can change your sdl-config or sdl.pc so that it
> sets the SDL linker options according to your needs.
>
> What about my proposal to create each system emulation in two
> variants (qemu-system-i386.exe, qemu-system-i386w.exe)?
> Do you think this might be a solution which fits everybody's
> needs?
Yes, I agree this solution. But because qemu-system-i386.exe will be
also a console application, we can revert your commit at first.

> Regards,
> Stefan Weil
>
>

[Qemu-devel] [PATCH] w32: Build windows and console executables

[Stefan Weil]

System emulation executables with SDL are typically windows
executables. Sometimes console executables are more useful,
so create both variants if linker option -mwindows was detected.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 Makefile.target |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 3261383..489a80c 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -27,10 +27,19 @@ ifdef CONFIG_USER_ONLY
 QEMU_PROG=qemu-$(TARGET_ARCH2)
 else
 # system emulator name
+ifneq (,$(findstring -mwindows,$(LIBS)))
+# Terminate program name with a 'w' because the linker builds a windows executable.
+QEMU_PROG=qemu-system-$(TARGET_ARCH2)w$(EXESUF)
+QEMU_PROGC=qemu-system-$(TARGET_ARCH2)$(EXESUF)
+else # windows executable
 QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF)
+endif # windows executable
 endif
 
 PROGS=$(QEMU_PROG)
+ifdef QEMU_PROGC
+PROGS+=$(QEMU_PROGC)
+endif
 STPFILES=
 
 ifndef CONFIG_HAIKU
@@ -406,6 +415,11 @@ obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o
 $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y)
 	$(call LINK,$^)
 
+ifdef QEMU_PROGC
+# The linker built a windows executable. Make also a console executable.
+$(QEMU_PROGC): $(QEMU_PROG)
+	$(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROG) $(QEMU_PROGC),"  GEN   $(QEMU_PROGC)")
+endif
 
 gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh
 	$(call quiet-command,rm -f $@ && $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES),"  GEN   $(TARGET_DIR)$@")
-- 
1.7.0.4

Re: [Qemu-devel] [PATCH] w32: Build windows and console executables

[TeLeMan]

On Thu, Dec 22, 2011 at 16:03, Stefan Weil <sw@weilnetz.de> wrote:
> System emulation executables with SDL are typically windows
> executables. Sometimes console executables are more useful,
> so create both variants if linker option -mwindows was detected.
>
> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> ---
>  Makefile.target |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile.target b/Makefile.target
> index 3261383..489a80c 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -27,10 +27,19 @@ ifdef CONFIG_USER_ONLY
>  QEMU_PROG=qemu-$(TARGET_ARCH2)
>  else
>  # system emulator name
> +ifneq (,$(findstring -mwindows,$(LIBS)))
> +# Terminate program name with a 'w' because the linker builds a windows executable.
> +QEMU_PROG=qemu-system-$(TARGET_ARCH2)w$(EXESUF)
> +QEMU_PROGC=qemu-system-$(TARGET_ARCH2)$(EXESUF)
> +else # windows executable
>  QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF)
> +endif # windows executable
>  endif
I prefer QEMU_PROG & QEMU_PROGW.

>  PROGS=$(QEMU_PROG)
> +ifdef QEMU_PROGC
> +PROGS+=$(QEMU_PROGC)
> +endif
>  STPFILES=
>
>  ifndef CONFIG_HAIKU
> @@ -406,6 +415,11 @@ obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o
>  $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y)
>        $(call LINK,$^)
>
> +ifdef QEMU_PROGC
> +# The linker built a windows executable. Make also a console executable.
> +$(QEMU_PROGC): $(QEMU_PROG)
> +       $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROG) $(QEMU_PROGC),"  GEN   $(QEMU_PROGC)")
> +endif
>
>  gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh
>        $(call quiet-command,rm -f $@ && $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES),"  GEN   $(TARGET_DIR)$@")
> --
> 1.7.0.4
>