RFC on console management

[Eric Pouech]

Le 10/05/2010 12:06, Alexandre Julliard a écrit :
> Eric Pouech<eric.pouech at 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+

-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)