Written by John Richardson <jrichard@zko.dec.com>
Maintained by Joseph Pranevich <jpranevich@lycos.com>
(Extracted from wine/documentation/console)
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 is 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 inherited 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
.
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
ECHO
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).
experimentation with NT4 yields that:
WriteFile
does not truncate file on 0 length write
0 length write or error on write changes numcharswritten to 0
0 length write returns TRUE
works with console handles
_lwrite
does truncate/expand file at current position on 0 length write
returns 0 on a zero length write
works with console handles (typecasted)
WriteConsole
expects only console handles
SetFilePointer
returns -1 (err 6) when used with a console handle
FreeConsole
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 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 <application> |
Possible drivers:
Generic text-only support. Supports redirection.
Full-screen graphical support with color.
Load a new window to display the console in. Also supports resizing windows.
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:
Use this program instead of xterm. This eliminates the need for a recompile. See the table below for a comparison of various terminals.
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.
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.
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. 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.
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: 'slave' is required for use in Wine, currently.
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.