Cannot set custom palette colors through the Windows API

[MCJack123]

When using the Windows API to set color information, the colors do not get changed. Instead they remain the same as the theme set. (This might conflict with user settings, but it breaks programs that rely on changing colors.)

I'm using PDCurses to set the colors, which I believe uses the Windows API. I haven't looked through the source very deeply, but it seems to call SetConsoleScreenBufferInfoEx, or sends a WM_SETCONSOLEINFO message to the console window if that isn't available.

Environment

Windows build number: 10.0.19042.631
Windows Terminal version (if applicable): 1.4.3243.0

PDCurses 3.9
CraftOS-PC v2.5 beta

Steps to reproduce

Compile this C program with PDCurses (available through vcpkg):

#include <curses.h>

static char hexstr[16] = "0123456789abcdef";
static unsigned char palette[16][3] = {
    {0xf0, 0xf0, 0xf0},
    {0xf2, 0xb2, 0x33},
    {0xe5, 0x7f, 0xd8},
    {0x99, 0xb2, 0xf2},
    {0xde, 0xde, 0x6c},
    {0x7f, 0xcc, 0x19},
    {0xf2, 0xb2, 0xcc},
    {0x4c, 0x4c, 0x4c},
    {0x99, 0x99, 0x99},
    {0x4c, 0x99, 0xb2},
    {0xb2, 0x66, 0xe5},
    {0x33, 0x66, 0xcc},
    {0x7f, 0x66, 0x4c},
    {0x57, 0xa6, 0x4e},
    {0xcc, 0x4c, 0x4c},
    {0x11, 0x11, 0x11}
};

int main() {
    initscr();
    start_color();
    if (can_change_color()) {
        for (int i = 0; i < 16 && i < COLORS; i++) {
            init_color(i, palette[15-i][0] * (1000/255), palette[15-i][1] * (1000/255), palette[15-i][2] * (1000/255));
            init_pair(i, i, i);
            addch(hexstr[i] | COLOR_PAIR(i));
        }
    } else printw("Can't change colors on this terminal!");
    getch();
    endwin();
    return 0;
}

(Warning: this will mess with the colors of CMD!)

Then run the program in both Windows Terminal and CMD. Notice the difference between the colors. One noticeable difference is that you can see the 7 in Windows Terminal, but not in CMD (since the colors are properly set in CMD).

Expected behavior

The colors are set as written in the code.

Actual behavior

The colors are not changed.

---

Here's a comparison between the two in a real program:

[j4james]

I believe this is a duplicate of #2985. When you change the console palette with SetConsoleScreenBufferInfoEx it needs to convert those colors into OSC escape sequences to propagate the changes over conpty to the Windows Terminal. That hasn't been done yet.

[MCJack123]

Yeah, that does appear to be the case. However, that doesn't mention the function or message explicitly - might be a good idea to mention both if necessary.

[DHowett]

Programs that rely on being able to redefine color indices 0-15 really just... shouldn’t do that. It was our mistake to allow applications destructive runtime access to the user’s preferences back when we did (about 30 years ago.)

Applications that want to specify arbitrary colors at runtime in a way that does not damage the user’s selected palette should use the 24-bit RGB SGR control sequences. They stand a better chance of working and looking the same across platforms and when remoted using technologies like SSH and Telnet.