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+