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+