2009/12/27 Mimu Bunnylin :

This is basically how linux works. The child process of a terminal inherits the standard input/output/error pipes of the terminal. If the process is called from outside the terminal, the standard output pipes are re-directed to ~/.xsession-errors by the desktop environment (in my experience, at least).

I've got some code at work for that. What you would have to do is to detect this, then attach the parent process' console to your app. I haven't tried this, but it sounds achievable.

Henry

FPC doesn't do the console handling, this is done by windows depending on exectuable flags which are set depending on apptype during linking.

So, basically, make a GUI-mode application, let FPC release the console during its normal startup initialisations, then detect that the parent process was a console, and recapture the console... This could work,

You will also have to pause the execution of the terminal, since otherwise it will still be active and take commands. Read about the console functions on msdn.

Henry

Mimu Bunnylin wrote

But suppose I want a program that will continue running in a console if run from a console, but will not automatically create a new one if run from outside a console.

You can declare a program as $apptype GUI, and then try using standard file handles. If this succeeds, then the program runs in a console (or has one of the standard handles explicitly redirected to a pipe etc.). I'm using such approach to get a little Unix-like behavior under Windows.

This goes like

  Handle := GetStdHandle(STD_OUTPUT_HANDLE);
  if (Handle  INVALID_HANDLE_VALUE) and
     (Handle  0) then
    StdOutStream := THandleStream.Create(Handle) else
    StdOutStream := nil;

Then write to StdOutStream. In my experiments, you should be prepared that even when StdOutStream nil, still StdOutStream.WriteBuffer may raise EWriteError, and then you should assume that stdout is not available (you can free and nil StdOutStream then, as it's useless).

It would probably be possible to extend this approach, such that standard Pascal Input / Output / ErrorOutput would use these handles also, so that you could use standard Read[ln], Write[ln]. I was happy enough with my StdOutStream approach, didn't bother to make Read[ln], Write[ln] working.

For concrete code that initializes all three streams (for stdin, stdout, stderr), for both Unix (where it always succeeds) and Windows (using above approrach), you can take a look at my code, it's at the end of http://vrmlengine.svn.sourceforge.net/viewvc/vrmlengine/trunk/kambi_vrml_game_engine/src/base/kambiclassutils.pas (look for InitStdStreams procedure). Look also at the comments after "@section(Variables to read/write standard input/output using TStream classes." in the interface.

Hope this helps,
Michalis

Currently, programs for Windows have to be specified as either $APPTYPE Console or GUI.

If the user runs a console-mode program from a console, the existing console is kept; run outside a console, a new console is created.

If the user runs a GUI-mode program outside a console, no console is created, and if run inside a console, the console is immediately released.

But suppose I want a program that will continue running in a console if run from a console, but will not automatically create a new one if run from outside a console. (Eg. without command-line arguments, launch the program's GUI, otherwise print a list of valid arguments in the console.)

Would this be hard to implement? Presently I have to compile a console-mode application, and use the Windows API call FreeConsole to eliminate the console if it is not needed. This still makes a useless console pop up for a moment, which looks silly. This could be as simple as adding a check somewhere in the system unit for whether a console is associated with the process or not, and decide the appropriate $APPTYPE at runtime.

As far as I can tell, this is an issue with FPC, but the feature request was redirected for discussion here.

-Mimu

Right. Now, how to achieve the same under Windows...

So, basically, make a GUI-mode application, let FPC release the console during its normal startup initialisations, then detect that the parent process was a console, and recapture the console... This could work, thanks. It would still seem far simpler to alter the FPC system unit to not release the console in the first place, but I could not find the relevant part in the source code. (Too many files, not enough idea of where to look.)

Ahh, I think with all this information I can get it working. Many thanks for your explanations, Henry, and Florian, and Michalis! :)

-Mimu