blob: 14dbcc28f026df9d308ef260808f90a9be3655bf [file] [log] [blame]
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.
XtermResolution=<cols>x<rows>
(Example: XtermResolution=80x25)
Start your xterm program with this text resolution. 80x25 is
recommended, a NULL value will mean to use the terminal's default
resolution, determined however your specific terminal figures
that out. Most console-based programs expect eother 80x25 or
80x40 displays.
Note: The default for many terminals is 80x24. One row smaller
than what the console subsystem generally expects.
Note 2: This information is passed on the command-line with the
-g switch.
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. Soon, I will add an option to the
configuration to set this up at run time. On the fly resizing will
still be disabled however.