while we're at talking about the ReadFile implementation with overlapped data, there's (an unrelated) point about ReadFile I'd like to discuss I've started looking at implementing proper console input in Wine (mainly the line mode editing). Apart from providing the functionnality, it would also allow to remove this unneeded code from the debugger
the Win32 console input API is made of two layers 1/ the low level : each input event is stored into an INPUT_RECORD struct 2/ the high level which uses the low level events to make strings of them
1/ two functions are used: ReadConsoleInput(A|W) 2/ three functions are used: ReadFile and ReadConsole(A|W)
the current implementation in Wine, makes the handle to the console input a file handle to the fd gotten from the console
hence, the current implementation is broken in several ways - ReadFile is implemented as a raw read on the input fd, whereas it should be a higher level of function (forwarded from ReadFile to ReadConsole) - wait operations on handle are wrong: currently the handle is signaled as soon as a char is read (at the unix level) from the stdin fd, whereas it should be done at the level of the INPUT_RECORD queue
to implement properly this (mainly the ability to forward ReadFile calls to ReadConsole for console handles), I'd like to do the following: - extend the get_handle_fd to also return an id corresponding to the type fd being used. As of today, handle / fd relationship mainly assumes that we can map a Windows operation on a handle onto a similar operation on a unix fd. The ReadFile/ReadConsoleInput doesn't fit in this category. - this type of feature would help in other areas too. For example, we never check that Comm functions really get a Comm handle...
would such a mechanism be acceptable ? if so, should we do for every handle in the server, or just the ones we might convert into unix fd (file, consoles, pipes, sockets, "serials"...)
A+