OSC 10, 11, 12?

[vefatica]

Will they be documented, maybe here?

With specific regard to OSC10 and OSC11 (defaultForeground and defaultBackground) ... How are they used in general ... by ESC[0m? ... by ESC[39m? ... by ESC[49m ... any others? If they're not mentioned in HKCU\Console (or a subkey) do (and how do) they get default values?

Thanks!

An observation (which I might have made before): "chaining" OSC 10, 11, and 12 (all three inside one OSC/ST) doesn't work with the current "stock" Windows 10 conhost.exe and does work with the current openconsole.exe packaged with Windows Terminal.

[j4james]

Most of the time when you're working with terminal colors, you're using a palette-based system. For example, when you do ESC[31m you're setting the foreground output color to palette entry 1. That's typically red, but the actual shade of red will be determined by your color scheme, and can be controlled at runtime with escape sequences like OSC 4 and DECRSTS.

The default colors have an additional level of indirection on top of that. They have palette numbers assigned to them, but those numbers can change (internally we refer to those assignments as color aliases). In the legacy console, the default background color alias was assigned to palette entry 0, and the default foreground color to palette entry 7, but you can change those assignments in the properties dialog.

At some point in time the console got an option to set the foreground and background colors separately from the basic 16 colors (this is on the Terminal tab of the properties dialog) But what's happening there is we're just pointing the foreground and background aliases to two special entries at the end of the color table (technically 261 and 262). And these are the aliases that Windows Terminal uses by default.

Now when you do ESC[39m, you're setting the text output color to the default foreground palette entry (typically aliased to 7 in the old console, or 261 in Windows Terminal), and when you do ESC[49m, you're setting the background output color to the default background palette entry (typically aliased to 0 or 262). ESC[0m sets both of those at the same time, but also resets all the rendition attributes (bold, underline, etc.).

OSC 10 does two things: First it assigns 261 as the alias for the default foreground color, and then it also sets the actual RGB value for palette entry 261. Similarly OSC 11 assigns 262 as the alias for the default background color, and then sets the RGB value for entry 262. These alias reassignments would typically not be necessary in Windows Terminal, since those are the defaults, but in the legacy console this makes sure the standard 16 colors won't be overwritten.

In HKCU\Console, the palette entries for 261 and 262 are stored in DefaultForeground and DefaultBackground, and if set to something other than 0xFFFFFFFF, the default foreground and background colors will be aliased to 261 and 262. But if they are set to 0xFFFFFFFF, then the default foreground and background aliases are determined by the ScreenColors value (high nibble is the background, low nibble the foreground), so they'll map to one of the basic 16 colors.

[vefatica]

Thanks, @j4james. That was pretty thorough. Still a few questions.

What's DECRSTS? Will it and OSC 10 (11,12) make it into the docs?

I gather ScreenColors is ignored if DefaultForeground and DefaultBackground have valid RGB values. Is that right?

[j4james]

What's DECRSTS?

DECRSTS is a sequence used to restore various terminal state reports that would typically have been saved with a DECRQTSR sequence. As far as I can recall there are two report types: the generic terminal state (this includes things like the cursor position, margins, mode settings, tab stops, etc), and the color table report (this includes the palette definitions for all the colors).

For now we only support the color table report, and we don't yet support the ability to query the colors (with DECRQTSR), but you can use the restore operation (DECRSTS) to set the palette colors. This is the way you would have updated the palette on the original DEC terminals, but note that modern terminal emulators are more likely to use the XTerm OSC sequences.

Will it and OSC 10 (11,12) make it into the docs?

That would probably depend on someone volunteering to write the documentation. There is separate issue tracker for that here: https://github.com/MicrosoftDocs/Console-Docs

However most of these sequences are existing standards, so you're probably better off referring to their official documentation, i.e. the DEC manuals for anything with DEC in the name, and the XTerm docs for most of the OSC operations. That said, we should at least be documenting which of these sequences we support. We used to track that here, but that's a bit out of date now.

I gather ScreenColors is ignored if DefaultForeground and DefaultBackground have valid RGB values. Is that right?

I believe so, yes.

[vefatica]

Thanks again.

[DHowett]

An observation (which I might have made before): "chaining" OSC 10, 11, and 12 (all three inside one OSC/ST) doesn't work with the current "stock" Windows 10 conhost.exe and does work with the current openconsole.exe packaged with Windows Terminal.

Broadly speaking, this will be true of all bugs we fix and all new features we implement. They will remain broken or unimplemented on Windows 10, and will be fixed or implemented in OpenConsole.exe and Windows Terminal.

[vefatica]

Hasn't the Windows10 conhost.exe come a long way precisely because of the development of OpenConsole.exe? I had Windows 7 right up to 2019 so my question is based on only 3 years with Windows 10.

[DHowett]

Oh, it absolutely has! It's just that Windows 10 conhost stopped receiving updates a while ago. The code for OpenConsole in this repo gets checked into the Windows source tree and built as conhost; it just so happens that the Windows source tree is now being used to produce "Windows 11".

[vefatica]

Hmmm! I've got nothing against WIndows 11 but I won't update until I'm confident that it's just that ... an update (same userid & credentials, same installed software, same user-defined scheduled tasks). I can't find good info on that. My status is this: I asked Windows Update to search and now I have a tray icon ... "Windows 11 is ready for your PC".

[DHowett]

For all intents and purposes, Windows 11 is just an upgrade from Windows 10. Same kernel, same shell, same services, etc., etc., etc. and upgrading from 10 to 11 will preserve your user directory, applications, scheduled tasks, et al.

You can always give it a shot and roll back if it doesn't work out. There are definitely some things that will annoy specifically you, like being able to move the taskbar away from the bottom of the screen or configure how it displays multiple windows from the same application.

Some stuff is different, but a whole lot of stuff is the same. I mean, hey, it's technically just version 10.0.22000 (note the 10!)

[vefatica]

That would probably depend on someone volunteering to write the documentation.
[...]
However most of these sequences are existing standards, so you're probably better off referring to their official documentation, i.e. the DEC manuals for anything with DEC in the name, and the XTerm docs for most of the OSC operations.

I don't know! If you're expecting those programming for the Windows console to follow the "ecosystem roadmap" I suppose the roadmap should be up-to-date (and keeping it so not done on a volunteer basis). What's the alternative ... scrounging around in DEC and XTERM (et al.) docs and then experimenting to see if something is actually implemented? That's precisely how I found these:

ESC[?1049h (enable alternate buffer) and ESC[?1049l (disable alternate buffer). They are mentioned here but only in the examples. A question: Not knowing how an XTERM works, is the alternate buffer meant to be static in any sense (disable/(re)enable and find it intact)?

Right next to those was ESC[?47h/l (save/restore screen), apparently not implemented.

[j4james]

There are over a thousand open issues in this repo, and a limited number of people to work on them. I can't speak for MS, but I really wouldn't expect a technical documentation issue like this to make it to the top of the priority list any time soon. It's not like there are hundreds of people asking for docs. But if you want to show your interest, I suggest voting on the issues in the documentation repo that I linked above.

is the alternate buffer meant to be static in any sense (disable/(re)enable and find it intact)?

If I remember correctly, it depends on which sequences you use to turn it on and off, but I'm fairly sure it will always be cleared by mode 1049 (which is the only one we support).