Console issues in recent git

[Eric Pouech]

Hi,

after the console patch series, it appears a couple of problems are left 
over:

to summarize, the problems with their status:

A/ when a program is running, no echo is seen for characters being typed.

B/ after running a wine program, the console is a bad shape and needs 
'reset' to get back in a sane state.

Status
A/ IMO, it's barely a bug as you can't make an hypothesis about what a 
program will do with character input. However, it's a change from 
previous behavior as one could see the echo. This only happens when the 
running program doesn't read its input. However, since now wine runs in 
raw console mode, it's likely the typed characters will not be useful to 
the shell when the program exits (as the shell will run in cooked mode 
and will start with an empty buffer). Low priority for a fix (if any)

B/ actually, it's likely a race (in the simple way of running one single 
program) about resetting the console in decent shape. Could the folks 
having the issue try the attached patch (file conclean) to see if it 
helps ? (I never could reproduce it here, tested with konsole & xterm. 
If you still see the issue, please detail console and shell program)
Clearly an annoying impact for most users, need fixing.

Actually, there's another issue with the same symptoms:
1- program A is launched from shell
2- program A starts another program B (for example winedbg when a fault 
occurs)
3- at this point, both A & B can read/write to the console
4- program A exits. As it way the group leader, B is set into the 
background and loses (read) access to the console.
5- When B exits, as it no longer has access to the console, the state of 
the console cannot be reset to normal

this was happening before the patch series, but as we didn't tweak the 
console, it was just fine (except that some program dies when in the 
background, eg winedbg)
fix will not be 100% easy

among the potential fixes:
S1: no longer do the console attribute management in server, but only in 
kernel32, and only for the livespan of the process creating the bare 
console. this means that the console will not be accessible to the 
children of this process after its death (but I don't see how to do it 
anyway)
S2: when the process that created the bare console, it's about to 
terminate it should wait for all its children to die. This would require 
a cloak of invisibility (from the win32 space) to let the other 
win32-process see that it actually died.
S3: combine S1 and S2
comments welcome

also, I may have forgotten (or misunderstood) some issue reports. Don't 
hesitate to jump in.

NB: I also have a patchset ready that shall enable key/arrows support in 
bare console mode (with history bells & whistles... handy for any 
program with a CLI)

A+



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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: conclean
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100906/502410c8/attachment.asc>