Thread: One process with two console windows

I want to have a console process then this process should create another console window. The first process should have access to this new window handles so it can read from and write into it.
you can create a console window for a process that hasn't have it by AllocConsole() you can also create a console process by calling CreateProcess() and setting CREATE_NEW_CONSOLE. But last one needs a module. It doesn't give us a new window but a new process. But I just need a console window.

One process can only have one console - the only option beyond that is to do your own windows (not console ones, but regular windows) - or have multiple processes that use for example shared memory to access data from a common process, of course.

--
Mats

or have multiple processes that use for example shared memory to access data from a common process, of course.

Yeah I should create a console application that gets output from and sends input to another proccess. This way one process can virtualy have multiple console windows by executing that module and somehow (pipe, shared memory, etc) comunicate with that.

I think a process can't use console handles of another process. Am I right?

Correct, a console is owned by a particular process, and other processes can not use that console (except when the current process creates a new process, the new process becomes the owner until it either relinquishes access to the console, or it exits).

--
Mats

A process can be attached to at most one console. If the calling process is already attached to a console, the error code returned is ERROR_ACCESS_DENIED (5). If the specified process does not have a console, the error code returned is ERROR_INVALID_HANDLE (6). If the specified process does not exist, the error code returned is ERROR_GEN_FAILURE (31).

It is from your link. I will be glad to see your framework.

The "illusion", I assume, is achieved by attaching to the console you wish to manipulate. Which means the "surrogates" would have to detach from their consoles. So you attach, back and forth, as needed to manipulate one console at a time.

May not be ideal, due to potential bottle-neck, if you plan on spawning a thread per-console - which do constant updates. The advantage is that you can use the Win32 console API's directly, instead of using some home-grown API (which uses IPC under the hood).

gg

>> Which means the "surrogates" would have to detach from their consoles.
That's not right. A console can be attached by many processes. But a process can only attach to one console. So the "surrogates" would be just for creating another console - and keeping the attachment count >= 1.

gg

Originally Posted by Codeplug

The "illusion", I assume, is achieved by attaching to the console you wish to manipulate. Which means the "surrogates" would have to detach from their consoles. So you attach, back and forth, as needed to manipulate one console at a time.

Which means you need 3 processes for having 2 consoles. 2 processes are the "hosts" for the consoles and the third one is the real application which switches between them.