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 eric.pouech@orange.fr writes:
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.
This seems preferable, if it can be done without making the kernel32 code too ugly.
Le 10/05/2010 12:06, Alexandre Julliard a écrit :
Eric Pouecheric.pouech@orange.fr writes:
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.
This seems preferable, if it can be done without making the kernel32 code too ugly.
what I foresee is: - some extensions in server for managing the objects (wineconsole-less console handles) - evolution in kernel32 limited (except when dealing with line edition where it will include libterm and/or termcap support for translating the TTY character into windows keycode)
the most impacting issue IMO is the impact of matching unix way of controling the terminal with what windows does as explained, if process B is a child of process A, and A is started from command line - under windows, if A dies, B is still attached to cmd and can get input from it (even if from a process point of view it's not reparented to cmd) - under unix, normally if A dies, B can still output to the shell, but it will no longer be able to get input from it
the solutions ???? - let A run until all of its children have died (tricky it we want to hide A from the windows process list) - have another program be the parent of all processes started from command line (and wineconsole could do the trick)
A+
-
Alexandre Julliard -
Eric Pouech