3 ms·

ReadConsoleInput https://docs.microsoft.com/en-us/windows/console/readconsoleinput https://docs.microsoft.com/en-us/windows/console/readconsole... INPUT_RECORD

by adontz 8y ago

ReadConsoleInput https://docs.microsoft.com/en-us/windows/console/readconsoleinput https://docs.microsoft.com/en-us/windows/console/readconsole... INPUT_RECORD https://docs.microsoft.com/en-us/windows/console/input-record-str https://docs.microsoft.com/en-us/windows/console/input-recor... KEY_EVENT_RECORD https://docs.microsoft.com/en-us/windows/console/key-event-record-str https://docs.microsoft.com/en-us/windows/console/key-event-r... bKeyDown If the key is pressed, this member is TRUE. Otherwise, this member is FALSE (the key is released). Also, please note that INPUT_RECORD contains union of key, mouse, window buffer size, menu and focus event records. I do not want to say interface is more well thought per se, but it is definitely more rich.

int_19h 8y ago
The reason why Windows has this stuff is because it never was particularly supportive of remote terminals. Going back to DOS days, when writing a console app, it was either the kind that only needed print, or else you basically had full control over the screen area, changing individual characters, colors etc in a random access way. The first approach would use DOS output functions that allowed for things like stdout/stderr to work. The second approach couldn't be redirected properly. Windows inherited that model, and mostly just kept developing it until lately.