[…Continued]
The direct VRAM access version was not portable, obviously.

The high-level console API was only portable to OS/2. Windows NT initially didn't even support terminal control sequences, and only finally got that a few years ago.

The low-level console API worked with OS/2's Vio subsystem, and Windows NT had a similar low-level console API from the start. It has it to this day.

If you have an operating system with the "console" paradigm and a low-level console API, treating it as a DEC Video Terminal from 1978 using high-level console I/O was historically a terrible choice, and is a bad choice even today.

#ComputerProgramming #TUIs #SoftwarePortability #ConsoleAPI

A salutary tale:

Many years ago I wrote a full-screen TUI program, with pretty colours, arrows, and line/box drawing, for a business client to run on MS-DOS.

Having done this sort of thing in the Unix world, I made it draw its TUI using character output via the ANSI.SYS CON device, the high-level console API. This was slow. One could watch it visibly drawing the entire screen at startup.

I did a version that used the underlying PC firmware API for writing to the display adapter, the low-level console API. This was significantly faster, although it still flickered a little.

I did a version that accessed the video memory directly. This was blazingly fast compared to both of the others, but I had to worry about MDA versus CGA/VGA (and VGA's mono mode).

#ComputerProgramming #TUIs #SoftwarePortability #ConsoleAPI
[Continued…]