187 lines
5.2 KiB
Plaintext
187 lines
5.2 KiB
Plaintext
<chapter id="consoles">
|
|
<title>Consoles in Wine</title>
|
|
|
|
<sect1 id="wine-consoles">
|
|
<title>Consoles</title>
|
|
|
|
<para>
|
|
Written by &name-eric-pouech; <email>&email-eric-pouech</email>
|
|
</para>
|
|
|
|
<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>Fonction 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
|
|
unpredictible 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>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Console creation</title>
|
|
|
|
<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>
|
|
</sect1>
|
|
</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:
|
|
-->
|