First of all I committed a patch as revision 47477 that calls FreeConsole.
This results in a console window being created by Windows but will disappear
in no time. As Mono is currently using batch files the console window will
remain open because cmd.exe waits for the executable to finish.
From: Jonathan Gilbert
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.
I did not mean that it is because somebody wants to be so but it's by design
because mono.exe is a console executable. Furthermore it's funny that
mono.exe prints a lot of things to console even for GUI applications while
it shows asserts as message boxes even for console applications.
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 :-)
Unfortunately this is the only reasonable solution.:) AttachConsole could be
good but it requires XP or alter and cmd.exe (and probably others) waits for
CUI executables to exit while not for GUI executables. This will result in
waiting even if you detach the console and will result in output right after
the C:\> prompt when you attach a GUI application to the console that looks
ugly.
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. :-)
I personally don't care about a PE with com extension altough I think the
same (ugly and lame) but I don't like the fact to have two executables
altought it is the only way to solve the problem correctly. And it's by
design on Windows.:))
Kornél
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
