ReadFile and other issues

[eric pouech]

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+
-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle