1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
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.
|
