Returning console ownership to parent process

Question

Is it possible to detach a running process from its console and hand ownership of that console back to the parent process?

That is, I would like a process started from cmd.exe to detach itself from the console (i.e. closing the console doesn't kill the process) and keep running in the background, while control of the standard input, output and error streams are handed back to cmd.exe so that the user can continue running commands.

In essence, I'm trying to roughly approximate the appearance of calling fork on Linux.

I'm currently doing:

#include <windows.h>

int main() {
    FreeConsole();
    Sleep(10000);
    return 0;
}

This keeps the process alive even if the console window is closed, but control of the standard streams is not handed back to cmd.exe until the sleep times out and the process terminates.

EDIT: the functionality is part of a cross-platform library and may be called from an arbitrary point in the user's code, so refactoring the application into something more Windows-y, calling external commands, restarting the process (or starting the process from another parent process in a two-step launch sequence), creating a Windows service, etc. are unfortunately not viable solutions.

Answer 1

Windows does not have a notion of fork; its process model is very different from Linux, and as such, you should design your application architecture differently for the two operating systems. There isn't enough information given in the question for me to be able to suggest alternative designs, however.

In the specific case that you described, you might be able to get away with calling FreeConsole to detach the console window from the process. Now, the problem with this is that the console is automatically destroyed if it is not shared with any other processes. So you will need to call AttachConsole from another process first so that the console is shared between the two processes, then detach the console (by calling FreeConsole) from the original process. I have no idea if that would actually work; I've never attempted something like it. It also doesn't solve the problem of transferring ownership of streams.

If you want an application that sometimes displays output in a console window but is not tied to that console window (and can keep running in the background), consider creating a standard Windows application instead of a console application, and then allocating and freeing the console as needed.

Answer 2

Your question is based on a misunderstanding. Windows does not have the concept of stream ownership or of console ownership. (When multiple processes are running on the same console, console input may be fed to any process that asks for it; under most circumstances, only one process will have a read pending on the console at a time.)

What you're observing is that, by default, cmd.exe waits for console applications to exit. (When running a batch file, it also waits for GUI applications to exit.) There is no way for the application to change this behavior.

The usual solution is for the executable to launch another copy of itself as a child process (typically with the CREATE_NO_WINDOW option) and then exit, which works because cmd.exe only waits for the process it launched to exit rather than the entire process tree. Unfortunately, this approach is typically only useful if it is the first thing the program does (because you can't sensibly implement fork in Windows) and it sounds as if that's not your situation.

If you must implement this feature, you could perhaps provide the programmer with a function to call at process startup that on Windows relaunches the executable and then never returns. In this scenario, you wouldn't use the CREATE_NO_WINDOW option (since the child may want to talk to the console up until the point where it backgrounds itself) and after calling FreeConsole() you'd use IPC to make the parent process exit. (It will also have to exit if the child does. And you might want to reverse that logic too and have the child die if the parent process is killed, if this happens before the program backgrounds itself.)

Personally, I'm of the opinion that cross-platform libraries should typically only attempt to implement functionality that actually makes sense on all the relevant platforms. Native Windows applications never work this way, so it arguably doesn't make sense to worry about making cross-platform applications do so when running on Windows. YMMV.