True color support inside a console using VB.NET

Question

When working with a Console application, one can't help but to notice that the native commands BackgroundColor and ForegroundColor only support CGA color spectrum (Yellow, Red, Dark Yellow, Dark Red, etc)

What I would like to do is to expand on this so that I can use ANY color that is supported by my current resolution (aka, True Color, etc), and not just this limited color pool.

When writing a DOS application (yes. DOS --- ancient old-school DOS), I had no problems selecting pretty much ANY color going well beyond this limitation. I recall seeing something regarding how to do this in the infant years of .NET (year 2002), but I cannot locate it as every link regarding "console" and "color" in searches come up with how to color, and only in the absolute most basic colors as depicted in the image --- essentially showing people how to change the ForegroundColor and BackgroundColor properties.

TO CLARIFY - I Want to be able to use TRUE COLOR aka, the entire color spectrum available for the Font Color, and Background Color inside a Console application using VB.NET.

I found an article on here showing how to find the "closest" console color to any given color, but that won't work. The basic colors are missing many real colors such as Orange -- and well, at minimum 1000 other named colors.

I am OK with hacking the crap outta this via use of the Win32/etc API's, and logic deems this must be possible due to the vast number of applications that run inside the console allowing for true color or at least VGA support.

Answer 1

The console was only ever meant to provide a way to port text mode programs from older operating system versions. Your memory of what was possible is perhaps too hazy after all these years. MS-Dos never provided a way to directly set colors beyond the ANSI.SYS device driver, you had to send escape codes to alter text colors. Largely ignored, more common was to use the BIOS, interrupt 10h, function 9. The BL register specifies the attribute, 4 bits for the foreground color and 4 bits for the background color. The choice of colors was hardwired in the video adapter and monitor.

But by far the most common approach was to write directly into the video frame buffer, address 0xB800:0. Every cell on the screen was mapped by two bytes, 1 for the character and 1 for the attribute. Primarily necessary to do something about the horrible blinking that early video adapters suffered from when they scrolled the screen. CGA was not exactly a triumph of IBM engineering. Hercules was a company that made a very popular alternative, it practically set its own standard.

PC gaming got its boost from the VGA adapter, like Doom. The successor of the CGA and EGA adapter, it supported 256 color graphics modes. It required a different monitor, an analog one, and had a programmable DAC (Digital to Analog Converter) with 256 registers to select 256 colors from the possible 16 million. That introduced the world to the notion of a palette, quite a painful programming challenge. I very unfondly remember battling the RealizePalette() winapi function.

Windows was also the primary boost for true color 24bpp video adapters, breaking through the confines of the BIOS modes. Around 1994 they started to become affordable. That support was never back-ported to the BIOS, it stayed stuck in the 1980s.

What you remember from Windows 9x was not a console. Olden 16-bit DOS programs ran in an emulator. They continued to ab/use the video frame buffer, writing to 0xB800:0 for text mode and 0xA000:0 for graphics mode and twiddle the video adapter control registers directly. Primary support for intercepting that direct hardware access was provided by the processor, it ran in "virtual 8086" mode. An important sub-component for that emulator was the "video grabber", a driver that could map the virtualized video adapter memory to pixels in a window. It is that window that you remember seeing. Notable was the Alt+Enter key press, it could turn off the video grabber on-the-fly, switching back-and-forth between full screen and windowed view.

Long story short, the console window only ever attempted to emulate the BIOS text video modes. All that was needed. With its fixed interpretation of the "attribute", 4 bits to pick 1 of 16 colors for the foreground and 4 bits for the background. Programs that use the graphics video modes must run full-screen. Few still work, the 64-bit version of Windows is no longer capable of switching the processor into virtual 8086 mode, support for it was dropped by AMD/Intel.

There are some extensions to the BIOS text mode, the window isn't stuck to a fixed width and height and supports scrolling. And the notion of a palette is supported in a console window. You don't have to settle for the garish legacy colors, you can directly change them from the system menu. Properties menu item, Colors tab. Programmatically done with SetConsoleScreenBufferInfoEx(), CONSOLE_SCREEN_BUFFER_INFOEX.ColorTable member. An array of 16 RGB values. Otherwise another strong reminder that 16 is a rock-hard limit :) And the attribute was extended from 8-bits to 16-bits, providing 7 extra bits for special effects. Very rarely ever used, apis that wrap the winapi console functions tend to be based on the legacy BIOS capabilities as well.