On Windows, how does console window ownership work?

Question

When a console application is started from another console application, how does console ownership work?

I see four possibilities:

1. The second application inherits the console from the first application for its lifetime, with the console returning to the original owner on exit.
2. Each application has its own console. Windows then somehow merges the content of the two into what the "console" visible to the user
3. The second application get a handle to the console that belongs to the first application.
4. The console is placed into shared memory and both applications have equal "ownership"

It's quite possible that I missed something and none of these four options adequately describe what Windows does with its consoles.

If the answer is close to option 4. My follow-up question is which of the two processes is responsible for managing the window? (Handling graphical updates when the screen needs to be refreshed / redrawn, etc)

A concrete example: Run CMD. Then, using CMD, run [console application]. The [console application] will write to what appears to be the same console window that CMD was using.

Answer 1

Each application will run in it's own AppDomain. Each AppDomain should be running it's own console.

Ah, you're right. I was thinking about running executables within a process and forgot they start their own process - I didn't drill down far enough.

Answer 2

My guess is somewhere between 3 and 4. The console is a self-standing object, which has standard input, output and error streams. These streams are attached to the first process that uses the console. Subsequent processes can also inherit these streams if not redirected (e.g. running a command with redirect to a file.)

Normally there is no contention, since parent processes usually wait for their child process to complete, and asynchronous processes typically start their own console (e.g. try "start cmd" in a command prompt) or redirect standard output.

However, there is nothing to stop both processes writing to the output stream at the same time - the streams are shared. This can be a problem when using some runtime libraries since writes to standard output/error may not be immediately flushed, leading to mixed garbled output. In general, having to processes actively writing to the same output stream is usually not a good idea, unless you take measures to co-ordinate their output through concurrency primitives like Mutexes, Events and the like.

Answer 3

CMD 'owns' the console. When it creates a process for an app, that app inherits handles to the console. It can read and write those. When the process goes away, CMD continues ownership.

Note: I'm not entirely sure that 'ownership' is the right word here. Windows will close the Console when CMD exits, but that may be a simple setting.

Answer 4

The way the SDK talks about it strongly resembles 1. It is an option with CreateProcess, described as follows:

CREATE_NEW_CONSOLE
The new process has a new console, instead of inheriting its parent's console (the default). For more information, see Creation of a Console.

Output however happens through handles, you'd get one with GetStdHandle(). Passing STD_OUTPUT_HANDLE returns the console handle, assuming output isn't redirected. Actual output is done through WriteFile() or WriteConsole/Output(). If both processes keep writing output to the handle then their output will be randomly intermingled. This is otherwise indistinguishable from what would happen when two programs write to the same file handle.

Logically, there's a screen buffer associated with a console. You can tinker with it with SetConsoleScreenBufferXxx(). From that point of view you could call it shared memory. The actual implementation is undiscoverable, handles abstract them away, like any Win32 API. It is sure to have changed considerably in Vista with the new conhost.exe process.

Answer 5

I think it's spelled out fairly well in the documentation.