Skip to content

Support coloured terminal output on Windows

First try the modern Windowsy way, where we can directly query if escape sequences will be processed. The function is available as far back as Windows 2000, but it just won't return the right flag until the Windows version is new enough.

If that fails, fall back to the Unixy way, as not all colour-supporting terminal emulators for Windows use the Win32 API to declare that capability.

MinTTY (Unix-style)

image

Windows Terminal (Win32-style)

image

CONHOST.EXE (which leaves VT emulation off by default)

image

There is a potential alternative approach here. CONHOST could be made to work if instead of checking if the ENABLE_VIRTUAL_TERMINAL_PROCESSING mode is enabled, we checked if the Windows version was new enough to support that setting, and then set it, then unconditionally emitted colour if the output stream is FILE_TYPE_CHAR. I feel like this might upset non-colour-supporting terminals that have intentionally avoided setting this mode and intentionally left TERM blank, but maybe I'm worrying about nothing.

This MR does not address the existing problem where redirecting stdout without redirecting stderr causes the redirected file to end up with ANSI escape sequences in it, or the problem where redirecting stderr without redirecting stdout causes stdout to be written to the terminal without colour. This is because only the state of stderr is checked for both streams.

It also doesn't address the existing problem where redirecting stdout causes Release builds of OpenMW (but not RelWithDebInfo ones, even when USE_DEBUG_CONSOLE is disabled so they should be identical) causes it to freeze on launch. I haven't got to the bottom of this.

Merge request reports