168 lines
5.4 KiB
Plaintext
168 lines
5.4 KiB
Plaintext
|
|
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.
|