# Consoles in Wine

As described in the Wine User Guide's CUI section, Wine manipulates three kinds of "consoles" in order to support properly the Win32 CUI API.

The following table describes the main implementation differences between the three approaches.

## Function consoles implementation comparison

Function | Bare streams | Wineconsole & user backend | Wineconsole & curses backend
Console as a Win32 Object (and associated handles) | No specific Win32 object is used in this case. The handles manipulated for the standard Win32 streams are in fact "bare handles" to their corresponding Unix streams. The mode manipulation functions (`GetConsoleMode` / `SetConsoleMode`) are not supported. | Implemented in server, and a specific Winelib program (wineconsole) is in charge of the rendering and user input. The mode manipulation functions behave as expected. | Implemented in server, and a specific Winelib program (wineconsole) is in charge of the rendering and user input. The mode manipulation functions behave as expected.
Inheritance (including handling in `CreateProcess` of `CREATE_DETACHED`, `CREATE_NEW_CONSOLE` flags). | Not supported. Every process child of a process will inherit the Unix streams, so will also inherit the Win32 standard streams. | Fully supported (each new console creation will be handled by the creation of a new USER32 window) | Fully supported, except for the creation of a new console, which will be rendered on the same Unix terminal as the previous one, leading to unpredictable results.
`ReadFile` / `WriteFile` operations | Fully supported | Fully supported | Fully supported
Screen-buffer manipulation (creation, deletion, resizing...) | Not supported | Fully supported | Partly supported (this won't work too well as we don't control (so far) the size of underlying Unix terminal
APIs for reading/writing screen-buffer content, cursor position | Not supported | Fully supported | Fully supported
APIs for manipulating the rendering window size | Not supported | Fully supported | Partly supported (this won't work too well as we don't control (so far) the size of underlying Unix terminal
Signaling (in particular, Ctrl-C handling) | Nothing is done, which means that Ctrl-C will generate (as usual) a `SIGINT` which will terminate the program. | Partly supported (Ctrl-C behaves as expected, however the other Win32 CUI signaling isn't properly implemented). | Partly supported (Ctrl-C behaves as expected, however the other Win32 CUI signaling isn't properly implemented).

The Win32 objects behind a console can be created in several occasions:

- When the program is started from wineconsole, a new console object is created and will be used (inherited) by the process launched from wineconsole.

- When a program, which isn't attached to a console, calls `AllocConsole`, Wine then launches wineconsole, and attaches the current program to this console. In this mode, the USER32 mode is always selected as Wine cannot tell the current state of the Unix console.

Please also note, that starting a child process with the `CREATE_NEW_CONSOLE` flag, will end-up calling `AllocConsole` in the child process, hence creating a wineconsole with the USER32 backend.