It's kind of crazy how much work it takes to get an interface on the level of ancient software to work on modern systems.

It took even more work to get it to work on the ancient systems though, right?

Turbo TUIs were easy to make. You could make them asynchronous, non-blocking, include sound, and if you were using Borland's C compiler, all of that was built-in for you.

They probably went to efforts to make it work an ancient system. But you really didn't have to.

Turbo TUIs we're beautiful to my 13 year old self and still are to me.

Someone modernized Turbo Vision: https://github.com/magiblot/tvision

It’s also included with FreePascal if you prefer the Pascal flavor of Turbo Vision. It even comes with a fully featured clone of the Turbo Pascal IDE.

Speaking from experiences, it's kind of amazing how much work you have to do in order to talk to a modern VGA or xterm terminal using ncurses. You really feel each layer of crust that ncurses has accumulated over the entire history of the personal computer since it was first written in order to allow people to play rogue on their personal VT-100 terminals.

Tunneling through the layer of crust accumulated in order to support Unicode (several layers of crust as Unicode evolved) was probably the most interesting of all.

https://rerdavies.github.io/nwindows/

Generating ANSI escape sequences to program a display is significantly more clunky than just directly addressing the text framebuffer that existed in early PCs (and often still does, albeit emulated by the GPU). You have an 80x25 array of words. Low word is the ASCII character, high word’s low nibble the foreground colour, high nibble the background. Character set is fixed to CP437 which had a reasonable choice of graphics, math symbol, and other characters.

A competent programmer could fit the whole charset in their head and easily write a TUI from scratch in a day. But they didn’t need to: plenty of great libraries existed.

One thing that made an impression on me when reading the 1991 Blue Book About GW-BASIC (1991) earlier this year was the chapter on making a text-mode user interface, that recommended drawing a characters+attributes interface 80x25 using an external editor, save that as a raw 4 kB file, and then from the BASIC program just BLOAD the file straight into graphics memory to render the screen in one line.

Everything is so much easier when you have standardized hardware instead of layers upon layers of abstractions supporting all sorts of weird things, like we have to put up with this century.

https://github.com/robhagemans/hoard-of-gwbasic

It is, of course, a very simple system if you never plan to render anything that isn't an ASCII character, or a value in US dollars. Things get complicated pretty quickly in DOS/Windows world once you wander outside the ASCII character set range. And there are strange and wonderful things in EGA and VGA hardware (standard, non-standard, and outright genius-level hackery) that are ridiculously complicated that are hardly ever used if you are fortunate enough to be an American who never uses anything but DOS.

It's stranger than that. The Linux terminal runs VGA adapters in an EGA mode that is rarely if ever used in DOS/WIndows systems. The mode provides up to 512 characters. One of the high-byte bits if each word is sacrificed to select from the first or second set of 256 characters; and another is sacrificed to specify underline on or off. That leaves 8 foreground and background colors, instead of the 16 foreground and background characters that you would get on a PC. Linux doesn't appear to have any concept of code-page. Which characters can be displayed on the terminal depends entirely on which EGA font is loaded. And that is determined (by default) by the currently configured locale, although the choice of font can be manually overridden. Having 512 characters to choose from allows the Linux VGA terminal to include a superset of characters that would be provided in a DOS/Windows codepage, while also guaranteeing at least the single-line line-drawing characters in CP437.There are, for example, fonts that allow display of glyphs in all Eastern European codepages, and fonts that provide a superset of European codepages and Cyrillic.

ncurses renders to an underlying framebuffer which contains 32-bit Unicode characters, plus attributes (FG/BG color pair, and 8 additional attributes like underline, bold, blink). I'm not sure which layer of crust this framebuffer belongs to -- something related to TERMINFO, I think. The intermediate framebuffer is then rendered to the actual VGA framebuffer in a separate pass, which maps 32-bit unicode characters onto glyph indexes in the currently-loaded VGA font.

There are some provisions for Asian character sets (Vietnamese, for example, is plausibly supported). I'm not sure if Chinese or Japanese VGA terminals were ever adequately supported in Linux.

I’ve happily used python-dialog, a wrapper for dialog (and dialog-compatible alternatives) which provides the very basics but is extremely easy to work with.

https://pythondialog.sourceforge.io/

> Not gonna lie, it's still not a turnkey solution that transformed my clumsy scripts into a beautiful TUI without work but it's close!

Can you elaborate on that? Are your "clumsy scripts" written in Python, shell or another language? Have you tried Textual-based tools like Trogon [1] and Moulti? [2]

[1] https://github.com/Textualize/trogon [2] https://moulti.run/

Wow, I love TUIs but never delved into researching Textualize forks/alternatives.

Thanks a lot for sharing these, especially Trogon, which I think is a clever idea with high ROI.

Rereading myself it looks like I'm blaming Textual for being too much work to use but it's not the case! I wanted to say that powerful (T)UIs have inherent complexity coming with the territory: async, events, UI thread, reactivity, render frames, debugging... Works great, but it's UI work on top of the script.