documentation/console

Console - First Pass
--------------------

Consoles are just xterms created with the -Sxxn switch.
A pty is opened and the master goes to the xterm side
and the slave is held by the wine side.  The console
itself it turned into a few HANDLE32s and is set 
to the STD_*_HANDLES.

It is possible to use the WriteFile and ReadFile commands
to write to a win32 console.  To accomplish this, all K32OBJs 
that support I/O have a read and write function pointer.
So, WriteFile calls K32OBJ_WriteFile which calls the K32OBJ's
write function pointer, which then finally calls write.

[this paragraph is now out of date]
If the command line console is to be inheirited or
a process inherits its parent's console (-- can that happen???),
the console is created at process init time via PROCESS_InheritConsole.
The 0, 1, and 2 file descriptors are duped to be the
STD_*_HANDLES in this case.  Also in this case a flag is set
to indicate that the console comes from the parent process or
command line.

If a process doesn't have a console at all, its 
pdb->console is set to NULL.  This helps indicate when
it is possible to create a new console (via AllocConsole).


When FreeConsole is called, all handles that the process has
open to the console are closed.  Like most k32objs, if the 
console's refcount reaches zero, its k32obj destroy function
is called.  The destroy kills the xterm if one was open.

Also like most k32 objects, we assume that (K32OBJ) header is the
first field so the casting (from K32OBJ *to CONSOLE *)
works correctly.

FreeConsole is called on process exit (in ExitProcess) if 
pdb->console is not NULL.


BUGS
----
Console processes do not inherit their parent's handles.  I think
there needs to be two cases, one where they have to inherit
the stdin/stdout/stderr from unix, and one where they have to
inherit from another windows app.

SetConsoleMode -- UNIX only has ICANON and various ECHOs
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 then the NT4 console implementation).


================================================================

experimentation with NT4 yields that:

WriteFile
---------
	o does not truncate file on 0 length write
	o 0 length write or error on write changes numcharswritten to 0
	o 0 length write returns TRUE
	o works with console handles

_lwrite
-------
	o does truncate/expand file at current position on 0 length write
	o returns 0 on a zero length write
	o works with console handles (typecasted)

WriteConsole
------------
	o expects only console handles


SetFilePointer
--------------
	o returns -1 (err 6) when used with a console handle


FreeConsole
-----------
	o 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 FreeConsole


Is it possible to interrupt win32's FileWrite?  I'm not sure.
It may not be possible to interrupt any system calls.


DOS (Generic) Console Support
-----------------------------

I. Command Line Configuration

   DOS consoles must be configured either on the command line or in a dot
   resource file (.console). A typical configuration consists of a string
   of driver keywords separated by plus ('+') signs. To change the 
   configuration on the command-line, use the -console switch.

   For example:

      wine -console ncurses+xterm <apllication>
   
   Possible drivers:

      tty	- Generic text-only support. Supports redirection.
      ncurses	- Full-screen graphical support with color.
      xterm	- Load a new window to display the console in. Also
                  supports resizing windows.


II. Wine.conf Configuration

   In the wine.conf file, you can create a section called [console] that
   contains configuration options that are respected by the assorted
   console drivers.

   Current Options:

      XtermProg=<program>

         Use this program instead of xterm. This eliminates the need for a
         recompile. See the table below for a comparison of various
         terminals.

      InitialRows=<number>

         Attempt to start all drivers with this number of rows. This
         causes xterms to be resized, for instance.

         Note: This information is passed on the command-line with the
         -g switch.

      InitialColumns=<number>

         Attempt to start all drivers with this number of columns. This
         causes xterms to be resized, for instance.

         Note: This information is passed on the command-line with the
         -g switch.

      TerminalType=<name>

         Tell any driver that is interested (ncurses) which termcap
         and/or terminfo type to use. The default is xterm which is
         appropiate for most uses. "nxterm" 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.

III. Terminal Types

   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.

   Note that 'slave' is required for use in Wine, currently.

   Program     | Color? | Resizing? | Slave?
   -----------------------------------------
   xterm	   N          Y         Y
   nxterm          Y          N         Y
   rxvt            Y          ?         N
   
   (linux console) Y          N         ?

   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.conf option to work
   around this in some cases but run-time resizing will be disabled.