Piping standard output to a common console window

[tenuti]

My issue should have been already discussed somewhere, but I didn't find anything about any approach.
Suppose I have a main executable file which calls some subroutines located in a pool of DLLs. All the executable code - the application and the dynamic libraries too - had been compiled with Intel Visual Fortran and calling conventions are compatible.
At now the standard output of each DLL is shown in an own console window which exploits the text, through the print command on the default output device:

write(*,100) myString

I would like that all the output is redirected on the same console window, instead of seeing each DLL opening and closing its own console window to show the output. It seems there's a mechanism that creates an instance of a console window, as soon as a printout on the device output is requested, but that console window is purged at sometime.

Is there any snipped code that shows how to share the same console window or some code that forwards the default output to another mechanism, as a pipe file? It would be very interesting giving the runtime module a pointer to a callback function, which is called each time a print on the console is done by any code at any level.

[Jugoslav_Dujic]

Hmmm. Normally, one would expect that one same console window is reused for the output of all modules. I think that the limit of one console per process is pretty hard-wired into Windows. See AllocConsole manual:

A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.

What might occur, on the other hand, is that each dll explicitly creates and removes the console. I'm puzzled though why should one do that.

Now, about the redirection: I recently posted a sample (Pipes) which uses pipes to redirect the standard output. There, pipes are used for talking between different processes though. If you use pipes within the same process, you will have a problem that the pipe can not be read until the routine which writes into it gets completed. If that's not suitable for you, and you want the output visible immediately, you can launch either the calculating/writing code, or the pipe-reading code in a separate thread (CreateThread); I prefer the first, especially if it's a GUI application (Thou shalt have only one GUI thread). If you launch a thread, the code structure basically will come down to the one in Pipes example. See this recent thread (at least, the beginning) for a thorough discussion about process/thread synchronization and link to Pipes.zip.

[tenuti]

Thank you Jugoslav for your reply. In the meanwhile I was reading the threads you pointed to. We had already had a well functioning approach in the past, without using threading in one process,but another interapplication communication mechanism based on the Win32 API described in another forum thread.

Suppose you have the GUI process (G process)and thelengthy processwithout GUI(Lprocess). L is aware of a handle of the G process: it's basically a window handle of an hidden window of G process. Each time L has to deliver some output, it makes:

rslt = SetWindowTextA(hwnd,msg)

rslt = SendMessageA(hwnd,notifyMsg,0,0)

The G process waits the notification in its own event loop andis able toprintout the message in the right way it only knows.

[Jugoslav_Dujic]

That approach is also OK; however, it has the potential disadvantage that the process L becomes (semi-)dependent on existence of process G. In other words, L (might) becomes useless if it's not spawned in the context of G. Plus, there's a portability issue, as you can't bring L to e.g. Linux and recompile it. None of the above might be important to you though.

"Pipes.zip" approach, on the other hand, requires no changes on L's source code, and it may well be a standalone 3-rd party console application.

But now, we strayed away from the original discussion; we were talking about .dll's called from one process rather than separate processes — did we? (Multiple spawned processes, each having its own console, are indeed possible).

[Steven_L_Intel1]

You need to make sure that the DLLs and the executable are all linked to the DLL form of the Fortran run-time library. Then they'll share the I/O units.

[tenuti]

Well, at now all the DLLs exploit their own output through write(*,*), but console initializationand termination is done by each DLL, because they are still somewhat older EXEs transformed to DLLs in this way:

MAIN.EXE

[tenuti]

Well, at now all the DLLs exploit their own output through write(*,*), but console initializationand termination is done by each DLL, because they are still somewhat older EXEs transformed to DLLs in this way:

MAIN.EXE

DLL1.DLL

AllocConsole

....

FreeConsole

DLL2.DLL

AllocConsole

....

FreeConsole

I should have found the cause of all those console windows.

Message Edited by tenuti on 04-04-200610:56 PM

[Steven_L_Intel1]

I think you have your answer, then....