It seems that this patch (ntdll/kernel32: #27 take III) makes console input handles use edge triggered semantics. Which means that these handles only signal when new input is queued and not when console input buffer has unread data.
This breaks winedos console handling, which would have been rather easy to fix if I had not found out that MSDN quite clearly states that console input handles use level triggered semantics:
http://msdn.microsoft.com/library/en-us/dllproc/base/synchronization_objects...: Console input: Created when a console is created. The handle to console input is returned by the CreateFile function when CONIN$ is specified, or by the GetStdHandle function. Its state is set to signaled when there is unread input in the console's input buffer, and set to nonsignaled when the input buffer is empty.
So, it looks like the kernel patch is wrong and introduces a regression. It could be that MSDN documentation is incorrect but I would like to see some test reports before I'm prepared to believe that. As far as I know, Win95 console handles really may use edge triggered semantics (or no signalling at all), but I think Wine consoles ought to follow NT semantics.
Jukka Heinonen wrote:
It seems that this patch (ntdll/kernel32: #27 take III) makes console input handles use edge triggered semantics. Which means that these handles only signal when new input is queued and not when console input buffer has unread data.
there's a bug but because I use a semaphore to keep track of input record queue len, but this semaphore is decremented twice: - a first time in the wait operation - a second time while actually reading an input event whereas it should be actually only decremented once (I'm still looking for my worn out brown paper bag)
I'll send a fix later on today.