How should applications behave when running under Windows Terminal if they want to maximize functionality?

[marchelzo]

Hi, I'm working on a cross-platform readline-esque library and one of the goals is to take full advantage of the capabilities of whatever terminal emulator is being used.

From what I understood reading the Console API docs on MSDN, Windows Terminal seems to be trying to move away from the Win32 Console API and behave more like terminals on other platforms, supporting various CSI and DCS escape sequences etc., but I have some questions:

• Since termios and ioctl don't exist in Windows, do we still use the Console API for things like getting Windows Terminal out of line-input mode, or requesting the window size?

• I made a small test program which sets the console mode to ENABLE_VIRTUAL_TERMINAL_INPUT | ENABLE_PROCESSED_INPUT and then reads KEY_EVENT_RECORDs using ReadConsoleInputA(). Under conhost.exe, the KeyEvent.dwControlKeyState field seems to be populated correctly, but under Windows Terminal it's always zero. Is there a way for applications to handle arbitrary keyboard input in Windows Terminal? If not, what approach should we be using to handle a many different key events as possible?

Sorry if this is all documented somewhere and I missed it. Any links to further reading would be appreciated!

[lhecker]

Since termios and ioctl don't exist in Windows, do we still use the Console API for things like getting Windows Terminal out of line-input mode, or requesting the window size?

Yes. For anything where there's a VT equivalent, I'd try to use VT, but otherwise the console APIs are just fine.

Under conhost.exe, the KeyEvent.dwControlKeyState field seems to be populated correctly, but under Windows Terminal it's always zero.

If there's a behavior difference between conhost and Windows Terminal, I'd consider that a bug. But not necessarily a bug in Windows Terminal: When you request ENABLE_VIRTUAL_TERMINAL_INPUT we'll give you an UNIX-style stdin that cannot for instance represent pressing a modifier key (Ctrl/Shift/Alt) on its own without pressing another key. As such the dwControlKeyState should always be 0. If your goal is to be cross-platform I'd personally recommend not trying to make these Windows-specific features available.

I'm not sure how familiar you are with ENABLE_PROCESSED_INPUT but if you need some documentation about how modifier-key combinations are represented there you can read this, for instance: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Special-Keyboard-Keys
(There's a ton of other sources out there as well.)

FYI: If you'd like to be performant, please try to avoid emitting small stdout writes as much as possible. The overhead of small writes on Windows is a lot higher than on Linux/macOS (large writes are unaffected).