| <chapter id="consoles"> |
| <title>Consoles in Wine</title> |
| |
| <para> |
| 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. |
| </para> |
| <para> |
| The following table describes the main implementation |
| differences between the three approaches. |
| |
| <table> |
| <title>Function consoles implementation comparison</title> |
| <tgroup cols="4" align="left"> |
| <thead> |
| <row> |
| <entry>Function</entry> |
| <entry>Bare streams</entry> |
| <entry>Wineconsole & user backend</entry> |
| <entry>Wineconsole & curses backend</entry> |
| </row> |
| </thead> |
| <tbody> |
| <row> |
| <entry> |
| Console as a Win32 Object (and associated |
| handles) |
| </entry> |
| <entry> |
| 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 |
| (<function>GetConsoleMode</function> / |
| <function>SetConsoleMode</function>) are not |
| supported. |
| </entry> |
| <entry> |
| 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. |
| </entry> |
| <entry> |
| 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. |
| </entry> |
| </row> |
| <row> |
| <entry> |
| Inheritance (including handling in |
| <function>CreateProcess</function> of |
| <constant>CREATE_DETACHED</constant>, |
| <constant>CREATE_NEW_CONSOLE</constant> flags). |
| </entry> |
| <entry> |
| Not supported. Every process child of a process |
| will inherit the Unix streams, so will also |
| inherit the Win32 standard streams. |
| </entry> |
| <entry> |
| Fully supported (each new console creation will be |
| handled by the creation of a new USER32 window) |
| </entry> |
| <entry> |
| 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. |
| </entry> |
| </row> |
| <row> |
| <entry><function>ReadFile</function> / <function>WriteFile</function> operations</entry> |
| <entry>Fully supported</entry> |
| <entry>Fully supported</entry> |
| <entry>Fully supported</entry> |
| </row> |
| <row> |
| <entry> |
| Screen-buffer manipulation (creation, deletion, resizing...) |
| </entry> |
| <entry>Not supported</entry> |
| <entry>Fully supported</entry> |
| <entry> |
| Partly supported (this won't work too well as we |
| don't control (so far) the size of underlying Unix |
| terminal |
| </entry> |
| </row> |
| <row> |
| <entry> |
| APIs for reading/writing screen-buffer content, |
| cursor position |
| </entry> |
| <entry>Not supported</entry> |
| <entry>Fully supported</entry> |
| <entry>Fully supported</entry> |
| </row> |
| <row> |
| <entry> |
| APIs for manipulating the rendering window size |
| </entry> |
| <entry>Not supported</entry> |
| <entry>Fully supported</entry> |
| <entry> |
| Partly supported (this won't work too well as we |
| don't control (so far) the size of underlying Unix |
| terminal |
| </entry> |
| </row> |
| <row> |
| <entry> |
| Signaling (in particular, Ctrl-C handling) |
| </entry> |
| <entry> |
| Nothing is done, which means that Ctrl-C will |
| generate (as usual) a <constant>SIGINT</constant> |
| which will terminate the program. |
| </entry> |
| <entry> |
| Partly supported (Ctrl-C behaves as expected, |
| however the other Win32 CUI signaling isn't |
| properly implemented). |
| </entry> |
| <entry> |
| Partly supported (Ctrl-C behaves as expected, |
| however the other Win32 CUI signaling isn't |
| properly implemented). |
| </entry> |
| </row> |
| </tbody> |
| </tgroup> |
| </table> |
| </para> |
| |
| <para> |
| The Win32 objects behind a console can be created in several occasions: |
| <itemizedlist> |
| <listitem> |
| <para> |
| When the program is started from wineconsole, a new |
| console object is created and will be used (inherited) |
| by the process launched from wineconsole. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| When a program, which isn't attached to a console, calls |
| <function>AllocConsole</function>, 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. |
| </para> |
| </listitem> |
| </itemizedlist> |
| </para> |
| <para> |
| Please also note, that starting a child process with the |
| <constant>CREATE_NEW_CONSOLE</constant> flag, will end-up |
| calling <function>AllocConsole</function> in the child |
| process, hence creating a wineconsole with the USER32 backend. |
| </para> |
| </chapter> |
| |
| <!-- Keep this comment at the end of the file |
| Local variables: |
| mode: sgml |
| sgml-parent-document:("wine-devel.sgml" "set" "book" "part" "chapter" "") |
| End: |
| --> |