There are a couple of shortcomings in our current console
implementation. To name a few:
- the "bare console handles" concept has very short limitations (see
bug reports #5541, or #13189). Globally, bare handles are actually
handles to files, whereas lots of programs expect them to behave
like console handles. Among the known shortcomings:
+ A1: GetFileType() returns wrong value,
+ A2: the console functions should return correct/default values,
starting with codepage (in your xterm locale if UTF.8 for example,
cmd output is bogus).
+ A3: no line edition is supported on bare handles
There are also issues with the wineconsole back-ends:
- B1: wineconsole --backend=curses mypgm.exe doesn't support the
redirection of unix default handles (ie.
wineconsole --backend=curses mypgm.exe > foo
sends all ANSI escapes to the foo file, which isn't what we expect.
- B2: in Windows, a GUI program doesn't inherit the console of its
parent (it only does if it's a CUI program)
- B3: when being nasty, one could create several wineconsole instances
for the same TTY, whereas popular wisdom would claim that one is
(more than) sufficient
- B4: console allocation and inheritance is not properly managed.
Let's take the following example:
+ we have two exes (Cui and CuiChild), CuiChild being started by
Cui. Cui is started from command line.
+ Cui does, in this order:
FreeConsole
AllocConsole
CreateProcess("CuiChild")
ExitProcess
+ AllocConsole spawns an instance of wineconsole, inheriting the
Unix fd:s from Cui.
+ CuiChild inherits the wine console from it's parent
+ when Cui dies, it also, from the Unix standpoint detaches from the
Unix console, and wineconsole loses access to the TTY as it's Unix
parent has died. And we lose all input/output for all apps tied to
this wineconsole.
- B5: job control. We poorly interact with unix console job control
I'd like to get feedback on the best way to go in order to put console
management on a reliable architecture.
Scenario I (aka Client side)
----------------------------
Create simple wineserver objects (ie not linked to wineconsole) for
bare console handles. All the management would be done in kernel32, by
distinguishing bare console handles from wineserver console handles.
Scenario II (aka Wineconsole side)
----------------------------------
Extend the current console objects in wineserver and wineconsole to
support a line oriented mode (instead of current mode which takes
control of the full screen for both curses and user backends).
Comparison (for each criteria, scenarios are ranked best to worse):
Size of changes: I,II
ScI will require less changes
Maintainability: II,I
- for ScII, in kernel32, we only deal with console objects, we all
behave the same
- for ScII all term/termcap support is centralized in wineconsole (A3
would require term/termcap to get the correct keys)
Speed: I,II
- ScII will require app <=> wineserver <=> wineconsole messages in
order to work (ScI will read all fd:s directly). ScII could be
enhanced by having messages directly managed between app and
wineconsole and bypassing wineserver, but still would be slower
Inheritance: II,I
- all required mechanisms (except B4) would be similar
- for B4, ScI will be hard to implement, as we don't have an app that
will keep the control on the unix terminal until all children have
died. The most viable solutions (in the wording of B4 above):
+ don't exit Cui until all its children, grand children... have
died. Possible to do, but we may want at some point to hide
this running (Unix) app from the list of running (Windows)
app, and this will be tricky
+ create a (Unix) wrapper app that will be kept open until all
children have died. Possible but will hinder a lot the
tracking/debugging tools (gdb, valgrind)
- it may be a bit simpler for ScII, as wineconsole could play the role
of the controling app (but with potentially the same limitations)
Functionalities: II,I
- ScII will ease the job control integration, as wineconsole would
gain control of the unix terminal, and hence convert properly the
unix events to the windows one.
I'd rather favor ScII, but the differences are not that big, so your
comments are welcome.
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
