Personally I'm not a C#/.NET developer so wouldn't know where to look for the source code, but to check you can run the program in the examples of the post with the compiled binary on the other side (in place of the SHELL) and see what output you get.
I'm 99% sure it's inserting ANSI escape codes (I'm maintaining a terminal emulator myself, and really that's how everything works), but I could of course be wrong.
The Windows console is a bit more sophisticated than the traditional *nix "shuffle text back and forth" approach; the Windows Command Line blog goes into some detail here (and in the rest of this series): https://devblogs.microsoft.com/commandline/windows-command-l...
Short version: there is support for ANSI and VT sequences in the Windows console (which relatively recently got substantially expanded), but that's not what it speaks "natively"-- for Win32 console applications, there's a native console API that works by passing IOCTLs back and forth between the app and console driver.
(If you're writing a terminal emulator for Windows, you don't necessarily see this-- the new ConPTY mechanism you use to build these as of Windows 10 abstracts away the Windows specifics so you see text and VT sequences just as you would on *nix.)
WAY back in the DOS days Qbasic and command.com could both change foreground and background colours via system hooks (INT bios calls) without using ANSI. I know this because Qbasic console apps could be colourful without having to load ansi.sys in config.sys
I am thinking that .foregroundColor and .backgroundColor do the same thing via legacy emulation in conhost.
Most likely it was writing text and attribute data directly to video memory. You didn't even need to call into the BIOS to do that shit (though the BIOS may have helped from a convenience standpoint to set the video mode).
True, but you could also get the address of the screen buffer and define a structured type to overlayed it that allowed you to put values directly into memory.
Each screen location was two bytes, one byte for the character value, and one for the character attributes which were a set of bits that controlled red, green, blue and intensity for both the foreground color and background color.
Then you could write routines that would fill in a rectangular region with a color, scroll the text of a region up or down, and do all sorts of other windowy things. There were also interrupt routines you could call that did some of these, and certainly routines in Crt that did some of this. Then you were on your way to developing your own TUI library!
Alternatively, you would issue an interrupt call to put the screen into 320x200 256 color mode, get the address of that buffer ($B800 if memory serves), similarly overlay it with a typed grid, then start poking byte values in and getting all sorts of nice colors out of it. Super fun!!
Maybe I'm biased, but I think learning to code in that environment was way better than today's Javascript-based in-browser graphics environment. I didn't know a damn thing about coding, but I was still able to make a rudimentary GUI paint program in one semester of high school.
I looked recently to see if an equivalent of Crt is still out there, but it doesn't look like any of the modern Pascal versions support it.
A000:0000 was the VGA graphics buffer. B800:0000 is the text mode buffer though. (Including the segment and offset since that works out to A0000 I believe.)
I'm 99% sure it's inserting ANSI escape codes (I'm maintaining a terminal emulator myself, and really that's how everything works), but I could of course be wrong.