a bit of documentation about consoles
Eric Pouech
eric.pouech at wanadoo.fr
Sat Mar 8 15:12:06 CST 2003
A+
--
Eric Pouech
-------------- next part --------------
Name: doc_con
ChangeLog: put console documentation in sync with current console status
License: X11
GenDate: 2003/03/08 21:10:24 UTC
ModifiedFiles: documentation/running.sgml documentation/consoles.sgml documentation/samples/config
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/documentation/running.sgml,v
retrieving revision 1.15
diff -u -u -r1.15 running.sgml
--- documentation/running.sgml 26 Feb 2003 04:33:29 -0000 1.15
+++ documentation/running.sgml 8 Mar 2003 20:55:51 -0000
@@ -5,7 +5,7 @@
Written by &name-john-sheets; <email>&email-john-sheets;</email>
</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>
<sect1 id="basic-usage">
@@ -124,15 +124,9 @@
<para>
(note the backslash-escaped "\" !)
</para>
-
<para>
- If you want to run a console program (aka a CUI executable), use
- <command>wineconsole</command> instead of <command>wine</command>
- 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.
+ For details on running text mode (CUI) executables, read the
+ <link linkend="CUI-programs">section</link> below.
</para>
</sect1>
@@ -361,6 +355,293 @@
</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>
<!-- Keep this comment at the end of the file
Index: documentation/consoles.sgml
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/documentation/consoles.sgml,v
retrieving revision 1.3
diff -u -u -r1.3 consoles.sgml
--- documentation/consoles.sgml 24 Jul 2002 03:00:02 -0000 1.3
+++ documentation/consoles.sgml 8 Mar 2003 18:14:20 -0000
@@ -5,377 +5,176 @@
<title>Consoles</title>
<para>
- Written by &name-john-richardson; <email>&email-john-richardson;</email>
- Maintained by &name-joseph-pranevich; <email>&email-joseph-pranevich;</email>
+ Written by &name-eric-pouech; <email>&email-eric-pouech</email>
</para>
+
<para>
- (Extracted from <filename>wine/documentation/console</filename>)
+ 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.
- <sect2>
- <title>Console - First Pass</title>
-
- <para>
- Consoles are just xterms created with the
- <parameter>-Sxxn</parameter> switch. A
- <systemitem>pty</systemitem> is opened and the master goes
- to the <filename>xterm</filename> side and the slave is held
- by the wine side. The console itself is turned into a few
- <type>HANDLE32</type>s and is set to the
- <varname>STD_*_HANDLES</varname>.
- </para>
- <para>
- It is possible to use the <function>WriteFile</function> and
- <function>ReadFile</function> commands to write to a win32
- console. To accomplish this, all <type>K32OBJ</type>s that
- support I/O have a read and write function pointer. So,
- <function>WriteFile</function> calls
- <function>K32OBJ_WriteFile</function> which calls the
- <type>K32OBJ</type>'s write function pointer, which then
- finally calls <function>write</function>.
- </para>
- <para>
- <emphasis>[this paragraph is now out of date]</emphasis> If
- the command line console is to be inherited or a process
- inherits its parent's console (-- can that happen???), the
- console is created at process init time via
- <function>PROCESS_InheritConsole</function>. The
- <literal>0</literal>, <literal>1</literal>, and
- <literal>2</literal> file descriptors are duped to be the
- <varname>STD_*_HANDLES</varname> in this case. Also in this
- 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>
+ <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>
- <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>
+ <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>
Index: documentation/samples/config
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/documentation/samples/config,v
retrieving revision 1.40
diff -u -u -r1.40 config
--- documentation/samples/config 4 Mar 2003 04:33:22 -0000 1.40
+++ documentation/samples/config 4 Mar 2003 06:47:49 -0000
@@ -234,13 +234,6 @@
;; set the "Windows" value in the [Version] section if you want that.
"WineLook" = "Win95"
-[Console]
-;"Drivers" = "tty"
-;"XtermProg" = "nxterm"
-;"InitialRows" = "25"
-;"InitialColumns" = "80"
-;"TerminalType" = "nxterm"
-
[Clipboard]
"ClearAllSelections" = "0"
"PersistentSelection" = "1"
More information about the wine-patches
mailing list