Hallo,
investigating further, I found that winedbg uses ReadConsole to get what the debug-user typed in, however ReadConsole by far doesn't behave as expected, namely to give back the VT100 codes for what the user typed in. At present arrow key presses are never delivered to winedbg and if winedbg runs on the staring console, input is only delivered to winedbg after the user entered "Enter".
Bye
investigating further, I found that winedbg uses ReadConsole to get what the debug-user typed in, however ReadConsole by far doesn't behave as expected, namely to give back the VT100 codes for what the user typed in. At present arrow key presses are never delivered to winedbg
well I tested it on NT2000, and arrows are not given back to the app using ReadConsole. So, it's winedbg which is at fault and should use ReadConsoleInput instead, but it would mean that the line editing should be heavily revisited to switch from a VT100 to a input_record style of input... a nicer fix would be to implement the ENABLE_LINE_INPUT mode for the console (so that the line edition would be done in the Wine code). we would lost the emacs-like keys usage (unless we had a Wine specific ENABLE_EMACS_LINE_INPUT mode to the console)
and if winedbg runs on the staring console, input is only delivered to winedbg after the user entered "Enter".
yes. this is because, when the console is allocated on a current term, stdin is not set to raw mode. here again, it means another rewrite (the underlying stdin must be set to raw (at least resetting ICANON), and all the line editing logic must be taken care of by wine (including echoing the input characters)
so, not to restart the discussion, but the libreadline inclusion (if any) would be more appropriate in the wine core code rather than in winedbg :-(
A+
-
eric pouech -
Uwe Bonnes