eric pouech eric.pouech@wanadoo.fr writes:
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.
I'm not sure I understand you right; are you suggesting that get_handle_fd should return an fd from which you can read input records in the case of a console? It would seem preferable to have get_handle_fd simply fail with a special error code saying that the handle is a console, and then ReadFile can fall back to using ReadConsoleInput which doesn't require an fd at all.
- this type of feature would help in other areas too. For example, we
never check that Comm functions really get a Comm handle...
Well, we check by the fact that we then do a serial ioctl on the fd, which will fail if it isn't serial. I'm not sure we need more checks.
I'm not sure I understand you right; are you suggesting that get_handle_fd should return an fd from which you can read input records in the case of a console?
no, reading of input_records would be sone as it is today, with the specific console request 'read_console_input'
It would seem preferable to have get_handle_fd simply fail with a special error code saying that the handle is a console, and then ReadFile can fall back to using ReadConsoleInput which doesn't require an fd at all.
ReadFile should (if we do so) fall back to ReadConsoleA (not ReadConsoleInput), but it doesn't matter here
the only thing we'd have to have is another request to get the fd from a console input handle (get_handle_fd would no longer work), and we still need a (background) mechanism to convert the unix xterm characters into INPUT_RECORD (a get_console_fd should do). Anyway, those fd are even rather static (they only change on Alloc|Free Console and at process startup if we inherit them from parent), so we can savely keep them around, process wide
I'll try that.
- this type of feature would help in other areas too. For example, we
never check that Comm functions really get a Comm handle...
Well, we check by the fact that we then do a serial ioctl on the fd, which will fail if it isn't serial. I'm not sure we need more checks.
agreed.
A+
-
Alexandre Julliard -
eric pouech