This only works if its thread has keyboard focus - e.g. The thing that's been messing everyone up I think is that there is a cmd.exe bug - if input is a standard console handle, it calls GetKeyboardState to decide whether to process the event. In unprocessed mode, you just need to write ^C. In processed mode, GenerateConsoleCtrlEvent should be enough. If it uses SendMessage, then it'll produce an unusual key event where wVirtualKe圜ode is 'C' but UnicodeChar is NUL.) (If winpty uses PostMessage, then it will be misinterpreted as an ordinary 'C' keypress.
It's a race, because winpty's WM_KEYDOWN will be misinterpreted if the user lifts Ctrl too quickly.
CMD C PAUSE POWERSHELL WINDOWS
I think it can be fixed by enabling winpty's desktop backgrounding for all Windows versions, not just XP and Vista.Īs a compromise, maybe a winpty user can indicate that they're using winpty in the foreground, and then winpty can use WM_KEYDOWN for Ctrl-C. Example: If I run a foreground SSH server somehow, then hold down Ctrl, while a remote user logs in and runs WSL mc, I expect the navigation keys to break. The existing use of WM_KEYDOWN for WSL navigation keys isn't quite right, as I commented in the code. Maybe a Sleep(1) would guarantee unique timestamps, preventing reordering.) (Maybe not, though? I see that SendInput uses KEYBDINPUT, which has a time timestamp in milliseconds. A Sleep(1) call "fixes" the issue, but might be introducing a race. On the other hand, when I tried sending four message with PostMessage (Ctrl-down, C-down, C-up, Ctrl-up), Windows reordered the messages to (Ctrl-down, Ctrl-up, C-down, C-up). I noticed that the KEY_EVENT_RECORD had a NUL UnicodeChar with SendMessage, but a non-NUL value if I used PostMessage. Even if it worked, a window station can have multiple desktops - window stations have independent keyboard state, but what about desktops? I don't want winpty to interfere with the keyboard state for other programs (including other winpty instances). This worked in a foreground desktop, but the SendInput call failed with an "Access Denied" error in the background desktop. I tried using SendInput and keybd_event to hold down Ctrl while sending just WM_KEY for a 'C' character. The SSH server uses a background window station/desktop, where the keyboard state is always "no keys pressed." Therefore, it's impossible to send a Ctrl-C WM_KEYDOWN message to a backgrounded console window. When the console sees a 'C' key-down message, it checks GetKeyboardState for modifiers keys.
When the event is dispatched, the event's keyboard state is made available through GetKeyboardState. When an event like WM_KEYDOWN is added to a message queue, Windows reads the entire keyboard state (256 bytes) and associates it with the event. I don't really know how Windows' input handling works - I'll describe what I think happens. Ctrl-C will cancel command input in new versions of PowerShell (e.g Win10), but not in cmd or in old versions of PowerShell (e.g.Ctrl-C will always interrupt a command.
CMD C PAUSE POWERSHELL HOW TO
I reopened this issue, but I don't know how to fix it, so maybe it's just a limitation. I reverted the first part of this issue's fix - winpty uses GenerateConsoleCtrlEvent again.
0 kommentar(er)
