Re: Problems with the "mwindows" switch

["Randy Brukardt" <randy@rrsoftware.com>]

<sbelmont700@gmail.com> wrote in message 
news:00836c9e-9ed0-4638-9d0b-0b3cd4e07c65@googlegroups.com...
>A Win32 executable is either 'console' or 'windows' (CUI or GUI).  This is, 
>effectively,
>what the -mwindows switch controls, with its omission indicating CUI.

>Essentially, a CUI executable gets its standard output handle from its 
>parent console; so
>if you spawn a CUI from the shell, it uses the same console for output, and 
>you get it in
>the same window as the shell.  Not so with a GUI app, that has no default 
>output, and
>would open a new window should you try (via AllocConsole()).

Right so far.

>So, if you use the -mwindows switch, you get no default console and your 
>text goes
>nowhere.  If you remove it, you will always get a console whether you want 
>it or not.
>There is, officially, no way to create a windows executable that is 
>dynamically both.

Of course there is, you just need some support from the runtime. For 
Janus/Ada we attempt to write to Text_IO for a GUI program create a console, 
else it's impossible to see what is going on when there is a problem at 
start up. I can't quite imagine how one could figure out anything without 
that, because its not at all unusual to have an exception raised during 
package elaboration, and there is no possible way to handle such an 
exception.

There is a weird effect with those windows, through, in that they appear and 
go away in a hurry when displaying unhandled exceptions. On some Windows 
systems, redirection works and you can capture the text that way. On other 
systems, it doesn't. I've never been able to figure out what controls that 
so I can suggest it to people (and set it myself).

                                      Randy.