[Mono-list] Re: [Gtk-sharp-list] Dos window - when launch app on Win32 OS - how to remove it ?

[Dmitry Kostenko]

Hello, everyone.

I have also encountered such a problem and even worse: Gtk+ may force
opening a new console window to output its assertion failures even in GUI
application, so changing subsystem to GUI won't always help.

I have found the following workaround using VBS file:
 1. Sample .bat file to start application:

---- START Tomboy.bat ----

@echo off
set HOME=.
call M:\Mono-1.0.6\bin\setmonopath.bat
mono --debug tomboy.exe

---- END Tomboy.bat ----

 2. Sample .vbs file to start .bat file to start application:

---- START Tomboy.vbs ----

Dim WSHShell
Set WSHShell = WScript.CreateObject("WScript.Shell")

WSHShell.run "Tomboy.bat ",0,0
WScript.sleep(1000)

---- END Tomboy.vbs ----

tomboy.exe is a /target:exe application.

This way you can launch bat file explicitly if you want to see console messages and
.vbs file is you don't want to. Much like Linux way :)

I have taken this VBS from http://sourceforge.net/projects/miniserver project.

With best regards,
Dmitry Kostenko


Message: 7
Date: Sat, 16 Jul 2005 20:48:57 -0400
From: "Jonathan Gilbert" <2a5gjx302 at sneakemail.com>
Subject: Re: [Mono-list] Re: [Gtk-sharp-list] Dos window - when
	launchapponWin32 OS - how to remove it ?
To: mono-list at lists.ximian.com
Message-ID: <20471-73916 at sneakemail.com>
Content-Type: text/plain; charset="us-ascii"

At 10:20 PM 15/07/2005 +0200, Kornel wrote:

>>>>Does this mean that using mono on windos will imply to have allways a
>>>>dos box, no matter the value used for the /target option?
>
>>
>>Yes, all the things I have written means this single fact.:) The console
>>window is dependent on the executable used to create the process (mono.exe
>>in this case) rather than the managed exe that is loaded by mono.exe
>>
>
>>>>Does this also mean that in the future, mono runtime on windows will
>>>>allways generate a dos box withtout being a bug, according to your
>>>>description?
>
>>
>>This is not a bug because this is by design.:)


I don't think anyone actively made a design decision to always display a
console window for the mono process. I think it probably was considered,
but I would call it more a "design concession". Mono aims for seamless
compatibility, to the extent that it is possible, with MS .NET, and this
issue should not, I think, be an exception.


>>Normally this nice solution could be used on Windows XP and 2003 and the
>>ugly FreeConsole sholution could be used on earlier Windows' but the problem
>>is that mono.exe itself has to be marked with different subsystem and thus
>>this would require two separate mono.exe that is a bad solution.


For what it's worth, Java on Windows has two separate interpreter binaries.
'java.exe' attaches to the console (i.e., specifies the console subsystem
in the header), while 'javaw.exe' detaches from the console (i.e.,
specifies the Windows subsystem). This also has two executables, but
doesn't try to do any hackery involving AttachConsole and/or FreeConsole.
I'm certainly not in the camp that believes mono should blindly copy Java
in every aspect, but the people at Sun researched this problem as well and
weighed the alternatives and this is what they came up with. It makes sense
to me  :-)

>>There is some explanation by someone else:
>>http://msdn.microsoft.com/msdnmag/issues/04/02/CQA/#QA3
>>
>>Note that he suggest to use a com and an exe file but I think this is a more
>>lame solution that calling FreeConsole.


I haven't read the article, but I agree that anything that uses COM files
as containers for PE images is horrifically ugly.  :-)

Jonathan Gilbert