RFC: gfortran on Windows - handling of no console / pausing before end-of-program console destruction

[Tim Prince]

On 04/23/2013 12:02 PM, Tobias Burnus wrote:
> The following email is motivated by Lahey/GNU Fortran. Their gfortran 
> version is modified to do:
>
> "We added a couple of things to the compiler mainly to support 
> situations where the program has no console, or where the console is 
> created to run the program and is destroyed when the program 
> terminates. In the first case, changes were made to the Fortran 
> runtime to test for the existence of a console, and if there is none, 
> publish errors via message box. In the second case, we implemented an 
> awkward "pause" compiler feature that notifies the user that the 
> program has terminated execution, and to allow the user to inspect 
> results before the console is destroyed. This feature was partially 
> written into the Fortran runtime and partially in the mingw runtime, 
> and only works when there is a console present."
>
>
> Question to our Windows users: Does such a change or something similar 
> makes sense? (For MinGW/MinGW-w64 only  - or also for 
> Cygwin/Cygwin64?) What kind of behaviour do you expect here?
>
>
> I think the "no console - show message box" feature should be 
> relatively simple. At least I'd expect that something like
>   if (!GetConsoleWindow())
>     MessageBox(NULL, "no console", "Information", 
> MB_OK|MB_ICONINFORMATION);
> would do the work. (I probably missed something and it won't be that 
> simple.)
>
> Pausing is more complicated (as already indicated in the text above). 
> I think the hard part is to know whether the console is destroyed 
> after the program exits or not - and that's probably the reason that 
> MinGW(-w64?) has/have been modified.
>
> Thus, what do you think of either of the two features?
>
> * * *
>
> Thinking myself of the second feature, I recall some program (a TeX 
> editor?) which fired off a console to run another program - the 
> console popped up for a second - and one was back in the editor. In 
> that case, I didn't want to see the console at all - and in 
> particular, I didn't want to manually close it (which wasn't needed). 
> Thus, the feature might not always be wanted. (In my case, I think the 
> program did not even write anything to the "con".)
>
> Thus, it might well be that one does not want to have neither feature 
> - at least not in a simple minded implementation. For instance, the 
> message box could be restricted to the case where one tries to read 
> from stdin or writes to stdout (or stderr, which is the same under 
> MinGW[-w64]). Similarly, for the pausing before the console is 
> destructed. (I don't know how Lahey's old compiler handled that nor 
> how Lahey/GNU Fortran does it.) - And regarding the message-box code: 
> Warning and continuing (at least if there is no stdin code) or 
> erroring and exiting would be possible solutions. [I have no idea how 
> gfortran currently reacts to this.]
>
> Tobias
>
> PS: If we would like to have the feature, Lahey will cleanup their 
> patch, do the copyright assignment formalities and submit it. For the 
> MinGW/MinGW-w64 (Cygwin/Cygwin64?) change, it might be more difficult, 
> unless we find a way which does not require to modify those libraries.
I don't have any expectations about behavior of a text program which is 
not started inside a shell window (usually cygwin bash).
I noticed the sudden appearance of good gcc/gfortran 4.8 binaries for 
cygwin64 and mingw-w64.  I think the OpenMP is working better in the 
cygwin64 version.

It may be difficult to get agreement about behavior of mingw inside or 
outside cygwin, as the cygwin people don't support it.
Some of the announcements gave the impression that Lahey made an 
interface to Visual Studio debugger, which may have financial costs to 
the customers and require a different run-time.

I'll mention here that my employer made non-submission of anything 
involving invoking my old copyright assignments to gcc/gfortran a 
condition associated with testing their beta compilers.

-- 
Tim Prince