Put console documentation in sync with current console status.
This commit is contained in:
Eric Pouech
Alexandre Julliard
parent
7da6e5c9a5
commit
0b36e34a80
|
|
@ -5,377 +5,176 @@
|
||||||
<title>Consoles</title>
|
<title>Consoles</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Written by &name-john-richardson; <email>&email-john-richardson;</email>
|
Written by &name-eric-pouech; <email>&email-eric-pouech</email>
|
||||||
Maintained by &name-joseph-pranevich; <email>&email-joseph-pranevich;</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>
|
||||||
<para>
|
<para>
|
||||||
(Extracted from <filename>wine/documentation/console</filename>)
|
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>
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
<sect2>
|
<sect1>
|
||||||
<title>Console - First Pass</title>
|
<title>Console creation</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Consoles are just xterms created with the
|
The Win32 objects behind a console can be created in several occasions:
|
||||||
<parameter>-Sxxn</parameter> switch. A
|
<itemizedlist>
|
||||||
<systemitem>pty</systemitem> is opened and the master goes
|
<listitem>
|
||||||
to the <filename>xterm</filename> side and the slave is held
|
<para>
|
||||||
by the wine side. The console itself is turned into a few
|
When the program is started from wineconsole, a new
|
||||||
<type>HANDLE32</type>s and is set to the
|
console object is created and will be used (inherited)
|
||||||
<varname>STD_*_HANDLES</varname>.
|
by the process launched from wineconsole.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
</listitem>
|
||||||
It is possible to use the <function>WriteFile</function> and
|
<listitem>
|
||||||
<function>ReadFile</function> commands to write to a win32
|
<para>
|
||||||
console. To accomplish this, all <type>K32OBJ</type>s that
|
When a program, which isn't attached to a console, calls
|
||||||
support I/O have a read and write function pointer. So,
|
<function>AllocConsole</function>, Wine then launches
|
||||||
<function>WriteFile</function> calls
|
wineconsole, and attaches the current program to this
|
||||||
<function>K32OBJ_WriteFile</function> which calls the
|
console. In this mode, the USER32 mode is always
|
||||||
<type>K32OBJ</type>'s write function pointer, which then
|
selected as Wine cannot tell the current state of the
|
||||||
finally calls <function>write</function>.
|
Unix console.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
</listitem>
|
||||||
<emphasis>[this paragraph is now out of date]</emphasis> If
|
</itemizedlist>
|
||||||
the command line console is to be inherited or a process
|
</para>
|
||||||
inherits its parent's console (-- can that happen???), the
|
<para>
|
||||||
console is created at process init time via
|
Please also note, that starting a child process with the
|
||||||
<function>PROCESS_InheritConsole</function>. The
|
<constant>CREATE_NEW_CONSOLE</constant> flag, will end-up
|
||||||
<literal>0</literal>, <literal>1</literal>, and
|
calling <function>AllocConsole</function> in the child
|
||||||
<literal>2</literal> file descriptors are duped to be the
|
process, hence creating a wineconsole with the USER32 backend.
|
||||||
<varname>STD_*_HANDLES</varname> in this case. Also in this
|
</para>
|
||||||
case a flag is set to indicate that the console comes from
|
|
||||||
the parent process or command line.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
If a process doesn't have a console at all, its
|
|
||||||
<varname>pdb->console</varname> is set to
|
|
||||||
<constant>NULL</constant>. This helps indicate when it is
|
|
||||||
possible to create a new console (via
|
|
||||||
<function>AllocConsole</function>).
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
When <function>FreeConsole</function> is called, all handles that the process has
|
|
||||||
open to the console are closed. Like most <type>K32OBJ</type>s, if the
|
|
||||||
console's refcount reaches zero, its <type>K32OBJ</type> destroy function
|
|
||||||
is called. The destroy kills the xterm if one was open.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Also like most k32 objects, we assume that
|
|
||||||
(<type>K32OBJ</type>) header is the first field so the
|
|
||||||
casting (from <type>K32OBJ*</type>to <type>CONSOLE*</type>)
|
|
||||||
works correctly.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
<function>FreeConsole</function> is called on process exit
|
|
||||||
(in <function>ExitProcess</function>) if
|
|
||||||
<varname>pdb->console</varname> is not
|
|
||||||
<constant>NULL</constant>.
|
|
||||||
</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>BUGS</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Console processes do not inherit their parent's handles. I
|
|
||||||
think there needs to be two cases, one where they have to
|
|
||||||
inherit the <filename>stdin</filename> /
|
|
||||||
<filename>stdout</filename> / <filename>stderr</filename>
|
|
||||||
from unix, and one where they have to inherit from another
|
|
||||||
windows app.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
<function>SetConsoleMode</function> -- UNIX only has
|
|
||||||
<constant>ICANON</constant> and various
|
|
||||||
<constant>ECHO</constant>s to play around with for
|
|
||||||
processing input. Win32 has line-at-a-time processing,
|
|
||||||
character processing, and echo. I'm putting together an
|
|
||||||
intermediate driver that will handle this (and hopefully
|
|
||||||
won't be any more buggy than the NT4 console
|
|
||||||
implementation).
|
|
||||||
</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>Experimentation</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
experimentation with NT4 yields that:
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term><function>WriteFile</function></term>
|
|
||||||
<listitem>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>does not truncate file on 0 length write</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
0 length write or error on write changes
|
|
||||||
<varname>numcharswritten</varname> to
|
|
||||||
<literal>0</literal>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>0 length write returns <constant>TRUE</constant></para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>works with console handles</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><function>_lwrite</function></term>
|
|
||||||
<listitem>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>does truncate/expand file at current position on 0 length write</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>returns 0 on a zero length write</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>works with console handles (typecasted)</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><function>WriteConsole</function></term>
|
|
||||||
<listitem>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>expects only console handles</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><function>SetFilePointer</function></term>
|
|
||||||
<listitem>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>returns -1 (err 6) when used with a console handle</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><function>FreeConsole</function></term>
|
|
||||||
<listitem>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
even when all the handles to it are freed, the
|
|
||||||
win32 console stays visible, the only way I could
|
|
||||||
find to free it was via the <function>FreeConsole</function>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Is it possible to interrupt win32's
|
|
||||||
<function>FileWrite</function>? I'm not sure. It may not be
|
|
||||||
possible to interrupt any system calls.
|
|
||||||
</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>DOS (Generic) Console Support</title>
|
|
||||||
|
|
||||||
<sect3>
|
|
||||||
<title>I. Command Line Configuration</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
DOS consoles must be configured either on the command line
|
|
||||||
or in a dot resource file (<filename>.console</filename>).
|
|
||||||
A typical configuration consists of a string of driver
|
|
||||||
keywords separated by plus ('+') signs. To change the
|
|
||||||
configuration on the command-line, use the
|
|
||||||
<parameter>-console</parameter> switch.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
For example:
|
|
||||||
</para>
|
|
||||||
<screen>
|
|
||||||
wine -console ncurses+xterm <application>
|
|
||||||
</screen>
|
|
||||||
<para>
|
|
||||||
Possible drivers:
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term>tty:</term>
|
|
||||||
<listitem>
|
|
||||||
<para>Generic text-only support. Supports redirection.</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>ncurses:</term>
|
|
||||||
<listitem>
|
|
||||||
<para>Full-screen graphical support with color.</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>xterm:</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Load a new window to display the console in. Also
|
|
||||||
supports resizing windows.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
</sect3>
|
|
||||||
|
|
||||||
<sect3>
|
|
||||||
<title>II. wine config file configuration</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
In the wine config file, you can create
|
|
||||||
a section called [console] that contains configuration
|
|
||||||
options that are respected by the assorted console
|
|
||||||
drivers.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Current Options:
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term>XtermProg=<program></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Use this program instead of
|
|
||||||
<command>xterm</command>. This eliminates the need
|
|
||||||
for a recompile. See the table below for a
|
|
||||||
comparison of various terminals.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>InitialRows=<number></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Attempt to start all drivers with this number of
|
|
||||||
rows. This causes xterms to be resized, for
|
|
||||||
instance.
|
|
||||||
</para>
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
This information is passed on the command-line
|
|
||||||
with the <parameter>-g</parameter> switch.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>InitialColumns=<number></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Attempt to start all drivers with this number of
|
|
||||||
columns. This causes xterms to be resized, for
|
|
||||||
instance.
|
|
||||||
</para>
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
This information is passed on the command-line
|
|
||||||
with the <parameter>-g</parameter> switch.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>TerminalType=<name></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Tell any driver that is interested (ncurses) which
|
|
||||||
termcap and/or terminfo type to use. The default is
|
|
||||||
xterm which is appropriate for most uses.
|
|
||||||
<command>nxterm</command> may give you better
|
|
||||||
support if you use that terminal. This can also be
|
|
||||||
changed to "linux" (or "console" on older systems)
|
|
||||||
if you manage to hack the ability to write to the
|
|
||||||
console into this driver.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
</sect3>
|
|
||||||
|
|
||||||
<sect3>
|
|
||||||
<title>III. Terminal Types</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
There are a large number of potential terminals that can
|
|
||||||
be used with Wine, depending on what you are trying to do.
|
|
||||||
Unfortunately, I am still looking for the "best" driver
|
|
||||||
combination.
|
|
||||||
</para>
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
'slave' is required for use in Wine, currently.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
|
|
||||||
<informaltable>
|
|
||||||
<tgroup cols="4">
|
|
||||||
<thead>
|
|
||||||
<row>
|
|
||||||
<entry>Program</entry>
|
|
||||||
<entry>Color?</entry>
|
|
||||||
<entry>Resizing?</entry>
|
|
||||||
<entry>Slave?</entry>
|
|
||||||
</row>
|
|
||||||
</thead>
|
|
||||||
<tfoot>
|
|
||||||
<row>
|
|
||||||
<entry>(linux console)</entry>
|
|
||||||
<entry>Y</entry>
|
|
||||||
<entry>N</entry>
|
|
||||||
<entry>?</entry>
|
|
||||||
</row>
|
|
||||||
</tfoot>
|
|
||||||
<tbody>
|
|
||||||
<row>
|
|
||||||
<entry>xterm</entry>
|
|
||||||
<entry>N</entry>
|
|
||||||
<entry>Y</entry>
|
|
||||||
<entry>Y</entry>
|
|
||||||
</row>
|
|
||||||
<row>
|
|
||||||
<entry>nxterm</entry>
|
|
||||||
<entry>Y</entry>
|
|
||||||
<entry>N</entry>
|
|
||||||
<entry>Y</entry>
|
|
||||||
</row>
|
|
||||||
<row>
|
|
||||||
<entry>rxvt</entry>
|
|
||||||
<entry>Y</entry>
|
|
||||||
<entry>?</entry>
|
|
||||||
<entry>N</entry>
|
|
||||||
</row>
|
|
||||||
</tbody>
|
|
||||||
</tgroup>
|
|
||||||
</informaltable>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
As X terminals typically use a 24x80 screen resolution
|
|
||||||
rather than the typical 25x80 one, it is necessary to
|
|
||||||
resize the screen to allow a DOS program to work
|
|
||||||
full-screen. There is a wine config file
|
|
||||||
option to work around this in some cases but run-time
|
|
||||||
resizing will be disabled.
|
|
||||||
</para>
|
|
||||||
</sect3>
|
|
||||||
</sect2>
|
|
||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -5,7 +5,7 @@
|
||||||
Written by &name-john-sheets; <email>&email-john-sheets;</email>
|
Written by &name-john-sheets; <email>&email-john-sheets;</email>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Extended by &name-mike-hearn; <email>&email-mike-hearn;</email>
|
Extended by &name-mike-hearn; <email>&email-mike-hearn;</email>, &name-eric-pouech; <email>&email-eric-pouech;</email>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1 id="basic-usage">
|
<sect1 id="basic-usage">
|
||||||
|
|
@ -124,15 +124,9 @@ Options:
|
||||||
<para>
|
<para>
|
||||||
(note the backslash-escaped "\" !)
|
(note the backslash-escaped "\" !)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you want to run a console program (aka a CUI executable), use
|
For details on running text mode (CUI) executables, read the
|
||||||
<command>wineconsole</command> instead of <command>wine</command>
|
<link linkend="CUI-programs">section</link> below.
|
||||||
to start it. It will display the program in a separate Window
|
|
||||||
(this requires X11 to be run). If you don't, you'll still be able
|
|
||||||
to run your program directly in the Unix console where you started it,
|
|
||||||
but with very limited capacities (so your program might work,
|
|
||||||
but your mileage may vary). This shall be improved in the future.
|
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
|
@ -361,6 +355,293 @@ winspool</><entry>wnet</><entry>x11</>
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="CUI-programs">
|
||||||
|
<title>Text mode programs (CUI: Console User Interface)</title>
|
||||||
|
<para>Text mode programs are program which output is only made
|
||||||
|
out of text (surprise!). In Windows terminolgy, they are
|
||||||
|
called CUI (Console User Interface) executables, by opposition
|
||||||
|
to GUI (Graphical User Interface) executables. Win32 API
|
||||||
|
provide a complete set of APIs to handle this situation, which
|
||||||
|
goes from basic features like text printing, up to high level
|
||||||
|
functionnalities (like full screen editing, color support,
|
||||||
|
cursor motion, mouse support), going through features like
|
||||||
|
line editing or raw/cooked input stream support
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Given the wide scope of features above, and the current usage
|
||||||
|
in Un*x world, Wine comes out with three different ways for
|
||||||
|
running a console program (aka a CUI executable):
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>bare streams</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>wineconsole with user backend</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>wineconsole with curses backend</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
<para>The names here are a bit obscure. "bare streams" means
|
||||||
|
that no extra support of wine is provide to map between the
|
||||||
|
unix console access and Windows console access. The two other
|
||||||
|
ways require the use of a specific Wine program (wineconsole)
|
||||||
|
which provide extended facilities. The following table
|
||||||
|
describes what you can do (and cannot do) with those three
|
||||||
|
ways.
|
||||||
|
<table>
|
||||||
|
<title>Basic differences in consoles</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>How to run (assuming executable is called foo.exe)</entry>
|
||||||
|
<entry><msgtext>
|
||||||
|
<screen><prompt>$</prompt> <userinput>wine foo.exe</userinput></screen>
|
||||||
|
</msgtext></entry>
|
||||||
|
<entry><msgtext>
|
||||||
|
<screen><prompt>$</prompt> <userinput>wineconsole -- --backend=user foo.exe</userinput></screen>
|
||||||
|
</msgtext></entry>
|
||||||
|
<entry><msgtext>
|
||||||
|
<screen><prompt>$</prompt> <userinput>wineconsole foo.exe</userinput></screen>
|
||||||
|
</msgtext>You can also use --backend=curses as an option</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Good support for line oriented CUI applications
|
||||||
|
(which print information line after line)
|
||||||
|
</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Good support for full screen CUI
|
||||||
|
applications (including but not limited to color
|
||||||
|
support, mouse support...)</entry>
|
||||||
|
<entry>No</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Can be run even if X11 is not running</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
<entry>No</entry>
|
||||||
|
<entry>Yes</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Implementation</entry>
|
||||||
|
<entry>Maps the standard Windows streams to the
|
||||||
|
standard Unix streams (stdin/stdout/stderr)
|
||||||
|
</entry>
|
||||||
|
<entry>
|
||||||
|
Wineconsole will create a new Window (hence
|
||||||
|
requiring the USER32 DLL is available) where all
|
||||||
|
information will be displayed
|
||||||
|
</entry>
|
||||||
|
<entry>
|
||||||
|
Wineconsole will use existing unix console
|
||||||
|
(from which the program is run) and with the help of
|
||||||
|
the (n)curses library take control of all the terminal
|
||||||
|
surface for interacting with the user
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Known limitations</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry>
|
||||||
|
Will produce strange behavior if two (or more)
|
||||||
|
Windows consoles are used on the same Un*x terminal.
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
</tbody>
|
||||||
|
</tgroup>
|
||||||
|
</table>
|
||||||
|
</para>
|
||||||
|
<sect2 id="CUI-programs-config">
|
||||||
|
<title>Configuration of CUI executables</title>
|
||||||
|
<para>
|
||||||
|
When wineconsole is used, several configuration options are
|
||||||
|
available. Wine (as Windows do) stores, on a per application
|
||||||
|
basis, several options in the registry. This let a user, for
|
||||||
|
example, define the default screen-buffer size he would like
|
||||||
|
to have for a given application.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
As of today, only the USER backend allows you to edit those
|
||||||
|
options (we don't recommend editing by hand the registry
|
||||||
|
contents). This edition is fired when a user right click in
|
||||||
|
the console (this popups a menu), where you can either
|
||||||
|
choose from:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Default: this will edit the settings shared by all
|
||||||
|
applications which haven't been configured yet. So,
|
||||||
|
when an application is first run (on your machine,
|
||||||
|
under your account) in wineconsole, wineconsole will
|
||||||
|
inherit this default settings for the
|
||||||
|
application. Afterwards, the application will have its
|
||||||
|
own settings, that you'll be able to modify at your will.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Properties: this will edit the application's
|
||||||
|
settings. When you're done, with the edition, you'll
|
||||||
|
be prompted whether you want to:
|
||||||
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Keep these modified settings only for this
|
||||||
|
session (next time you run the application, you
|
||||||
|
will not see the modification you've just made).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Use the settings for this session and save them
|
||||||
|
as well, so that next you run your application,
|
||||||
|
you'll use these new settings again.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Here's the list of the items you can configure, and their
|
||||||
|
meanings:
|
||||||
|
<table>
|
||||||
|
<title>Wineconsole configuration options</title>
|
||||||
|
<tgroup cols="2" align="left">
|
||||||
|
<thead>
|
||||||
|
<row>
|
||||||
|
<entry>Configuration option</entry>
|
||||||
|
<entry>Meaning</entry>
|
||||||
|
</row>
|
||||||
|
</thead>
|
||||||
|
<tbody>
|
||||||
|
<row>
|
||||||
|
<entry>Cursor's size</entry>
|
||||||
|
<entry>
|
||||||
|
Defines the size of the cursor. Three options are
|
||||||
|
available: small (33% of character height), medium
|
||||||
|
(66%) and large (100%)
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Popup menu</entry>
|
||||||
|
<entry>
|
||||||
|
It's been said earlier that wineconsole
|
||||||
|
configuration popup was triggered using a right
|
||||||
|
click in the console's window. However, this can
|
||||||
|
be an issue when the application you run inside
|
||||||
|
wineconsole expects the right click events to be
|
||||||
|
sent to it. By ticking control or shift you select
|
||||||
|
additional modifiers on the right click for
|
||||||
|
opening the popup. For example, ticking shift will
|
||||||
|
send events to the application when you right
|
||||||
|
click the window without shift being hold down,
|
||||||
|
and open the window when you right-click while
|
||||||
|
shift being hold down.
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Quick edit</entry>
|
||||||
|
<entry>
|
||||||
|
This tick box lets you decide whether left-click
|
||||||
|
mouse events shall be interpreted as events to be
|
||||||
|
sent to the underlying application (tick off) or
|
||||||
|
as a selection of rectangular part of the screen
|
||||||
|
to be later on copied onto the clipboard (tick on).
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>History</entry>
|
||||||
|
<entry>
|
||||||
|
This lets you pick up how many commands you want
|
||||||
|
the console to recall. You can also drive whether
|
||||||
|
you want, when entering several times the same
|
||||||
|
command - potentially intertwened with others -
|
||||||
|
whether you want to store all of them (tick off)
|
||||||
|
or only the last one (tick on).
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Police</entry>
|
||||||
|
<entry>
|
||||||
|
The Police property sheet allows you to pick the
|
||||||
|
default font for the console (font file, size,
|
||||||
|
background and foreground color).
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Screenbuffer & window size</entry>
|
||||||
|
<entry>
|
||||||
|
The console as you see it is made of two different
|
||||||
|
parts. On one hand there's the screenbuffer which
|
||||||
|
contains all the information your application puts
|
||||||
|
on the screen, and the window which displays a
|
||||||
|
given area of this screen buffer. Note that the
|
||||||
|
window is always smaller or of the same size than
|
||||||
|
the screen buffer. Having a stricly smaller window
|
||||||
|
size will put on scrollbars on the window so that
|
||||||
|
you can see the whole screenbuffer's content.
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Close on exit</entry>
|
||||||
|
<entry>
|
||||||
|
If it's ticked, then the wineconsole will exit
|
||||||
|
when the application within terminates. Otherwise,
|
||||||
|
it'll remain opened until the user manually closes
|
||||||
|
it: this allows seeing the latest information of a
|
||||||
|
program after it has terminated.
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry>Edition mode</entry>
|
||||||
|
<entry>
|
||||||
|
<msgtext>
|
||||||
|
<para>
|
||||||
|
When the user enter commands, he or she can
|
||||||
|
choose between several edition modes:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Emacs: the same keybindings as under
|
||||||
|
emacs are available. For example, Ctrl-A
|
||||||
|
will bring the cursor to the beginning
|
||||||
|
of the edition line. See your emacs
|
||||||
|
manual for the details of the commands.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Win32: this are the standard Windows
|
||||||
|
console key-bindings (mainly using
|
||||||
|
arrows).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
</msgtext>
|
||||||
|
</entry>
|
||||||
|
</row>
|
||||||
|
</tbody>
|
||||||
|
</tgroup>
|
||||||
|
</table>
|
||||||
|
</para>
|
||||||
|
</sect2>
|
||||||
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<!-- Keep this comment at the end of the file
|
<!-- Keep this comment at the end of the file
|
||||||
|
|
|
||||||
|
|
@ -234,13 +234,6 @@ WINE REGISTRY Version 2
|
||||||
;; set the "Windows" value in the [Version] section if you want that.
|
;; set the "Windows" value in the [Version] section if you want that.
|
||||||
"WineLook" = "Win95"
|
"WineLook" = "Win95"
|
||||||
|
|
||||||
[Console]
|
|
||||||
;"Drivers" = "tty"
|
|
||||||
;"XtermProg" = "nxterm"
|
|
||||||
;"InitialRows" = "25"
|
|
||||||
;"InitialColumns" = "80"
|
|
||||||
;"TerminalType" = "nxterm"
|
|
||||||
|
|
||||||
[Clipboard]
|
[Clipboard]
|
||||||
"ClearAllSelections" = "0"
|
"ClearAllSelections" = "0"
|
||||||
"PersistentSelection" = "1"
|
"PersistentSelection" = "1"
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue