First line of output is not colored despite VT color codes

[heaths]

Windows Terminal version (or Windows build number)

1.10.2383.0

Other Software

No response

Steps to reproduce

1, Clone and checkout PR microsoft/vswhere#244 (a minimal repo would be to enable VT and write the first line of text with colors).
2. Build and run vswhere.exe -color -format xml

Despite enabling virtual terminal processing, the first line of output - if it's otherwise supposed to be colored - is not - not for the first Write call to the console.

Example: the processing instruction should be colorized and is written in a single call:

If I write a blank line prior to that - any text, really - it is colored as expected:

Expected Behavior

VT-colored output is always colored as shown below:

Actual Behavior

The first line - if no other text was written first (even a blank line, so just any call to Write) - is in the default foreground color.

[zadjii-msft]

Just to be sure - does this work just fine when running in conhost.exe? If it does, then this must be a particularly weird conpty bug. Presumably this is the bit that writes out that first line, yea?

const LPCWSTR XmlFormatter::ColorTag = L"\033[38;2;86;156;214m";

void XmlFormatter::StartDocument()
{
    Console().WriteLine(
        L"%1$ls<?xml%4$ls %2$lsversion%4$ls=%3$ls\"1.0\"%1$ls?>%4$ls",
        Console().Color(ColorTag),
        Console().Color(ColorName),
        Console().Color(ColorValue),
        Console().ResetColor());

(link)

[heaths]

It does, yes.

Thinking about this more, since I know I'm writing to a console, would it be so bad to write out a character and then overwrite it with content (or is there a better way that would be supported at least in Win7 if not older)?

And what exactly is the "trigger" that is flipping color on? It's clearly not a new line, since in the default TextFormatter only the first thing I write using my Console::Write() method is non-colored, but subsequent text on the same line does. It seems that the console is doing something toward the end of the call to the likes of _vwprintf_p to "really turn on" the set console mode. Is that something we can do further up the stack?

[j4james]

And what exactly is the "trigger" that is flipping color on?

There is no trigger. The color escape sequences should be working immediately, as long as you've set the ENABLE_VIRTUAL_TERMINAL_PROCESSING mode, and on Windows Terminal that mode is enabled by default. Even if the mode wasn't set, you still shouldn't just get text without color - you'd see the actual escape sequences being written out instead.

Here's a simple test case attempting to reproduce your problem:

#include <windows.h>
#include <stdio.h>

void main() {
    HANDLE handle = GetStdHandle(STD_OUTPUT_HANDLE);
    DWORD mode;
    GetConsoleMode(handle, &mode);
    mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
    SetConsoleMode(handle, mode);

    printf("\033[38;2;86;156;214m<?xml\033[m \033[38;2;156;220;254mversion\033[m=\033[38;2;206;145;120m\"1.0\"\033[38;2;86;156;214m?>\033[m\n");
}

And here's what the output looks like:

So there's got to be something strange about your code that is causing it to fail. Can you not narrow it down to a minimal test case?

[j4james]

As a simple test, try redirecting the output to a file to check that the escape sequences for the colors are actually being set for that first line. If they are, then you can also check if it works when you type that file. And if it doesn't work, then at least you'll have simple test case you can upload to a gist or something which we can more easily investigate.

[heaths]

Output redirected to a pipe will not emit escape sequences, and I do have tests for that that simply force the escape sequences to be emitted. However, after writing up a simple demo that made all the same basic calls, I realized my previous debugging was looking in the wrong spot: the variadic arguments had already called the Color() function when the console hadn't been initialized yet. 🤦‍♂️ (Of course I know they are evaluated first, but hadn't put 2 and 2 together till now.)

Thanks!

[zadjii-msft]

Glad we could help figure it out, (and even more glad that it wasn't a secretly hard to trigger bug in my code 😝 )