RFC on console management

[Eric Pouech]

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)