eric pouech eric.pouech@wanadoo.fr writes:
no, reading of input_records would be sone as it is today, with the specific console request 'read_console_input'
OK, we agree then.
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'm not sure we should be converting xterm input into INPUT_RECORD. It may be better to have two modes, a simple console that returns an fd to ReadFile and no input records (and then ReadConsoleInput could generate them on the fly if necessary), and a complex console that supports all the features but that doesn't have an associated fd at all.
IMO the current xterm-based console support is a ugly hack; we should do a proper Windows console using a normal Wine window with a message loop to retrieve input events. And usage of stdin/stdout should be limited to programs that don't need special console features, and should only support ReadFile/WriteFile.
-
Alexandre Julliard