Hello Garlar,
Here is another way that doesn't require changing the APPTYPE to CONSOLE. Do note that there are some disadvantages with it. The advantage of keeping it as APPTYPE GUI is that the console isn't monopolized until the program ends.
the basic code goes like this:
if AttachConsole(ATTACH_PARENT_PROCESS) then
begin
{ we were started from a console }
ConsoleWindow := GetConsoleWindow();
writeln(ProgramVersion);
writeln;
// these are needed for the console's prompt to re-appear
FlushConsoleInputBuffer(GetStdHandle(STD_INPUT_HANDLE));
PostMessage(ConsoleWindow, WM_KEYDOWN, VK_RETURN, 1);
PostMessage(ConsoleWindow, WM_KEYUP, VK_RETURN, 0);
FreeConsole(); { release the console - CTRL-C will not affect the window }
end;
That is a brutally abbreviated piece of code for a GUI app to control its parent's console for its purposes. The one major problem it doesn't solve is that if multiple instances of the program are started and every instance writes to the console then the output on the console screen will be all jumbled. It's somewhat rare for that situation to take place, the user has to make it happen.
The one thing that is a minor problem and the solution is not overly complicated is that the "version" string is displayed along with the console's prompt instead of in a line by itself, as it would be, if it were a real console app. The solution is for the GUI app to write directly to the console's buffer instead of using writeln (which I used to keep the example simple.)
Running the program as a console app has one downside that is easily solved. If the user presses CTRL-C then your "gui" app is gone. A real GUI app is immune to CTRL-C. The solution to that problem is easy, just put a CTRL-C handler that ignores the CTRL-C. That might make the user unhappy though.
Attached is a complete sample of a program that can run as a GUI or a console. Comment and uncomment the $define at the top to play with it.
Also attached is a screenshot showing what happens when multiple instances of the sample are started in quick succession, look at how the output is "jumbled". That's because there are three programs writing to one window without any synchronization between them. The easy but limiting solution is to ensure there can only be one instance of the program running at any time. The other way is to make the first instance the manager of console window and have all output to the console window go through it so its properly synchronized.
HTH.
ETA:
I should have mentioned that this solution is totally Windows specific.
I should have also mentioned that if the loop start several hundred instances (instead of 3 as I showed), things get royally messed up.
If you want to see what happens to Windows when it's running a few _thousand_ processes, this is a way to do it.