Console issues in recent git
eric.pouech at orange.fr
Mon Sep 6 15:00:19 CDT 2010
after the console patch series, it appears a couple of problems are left
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.
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
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
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
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)
"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...
More information about the wine-devel