3 ms·
The IBM PC text mode buffer was mapped into memory, so you could quickly update any part of the screen and easily do things like double-buffering (for rock-soli
by pavlov 4y ago
The IBM PC text mode buffer was mapped into memory, so you could quickly update any part of the screen and easily do things like double-buffering (for rock-solid screen updates), composing the screen out of floating windows held in separate memory buffers, etc.
The Unix terminal is derived from line printers (teletype), a fundamentally different kind of TUI.
I don’t know how much this realistically affects today’s terminals since we have extremely fast connections. But it’s the original reason why those DOS text UIs had such a distinct snappy feel.
- pjmlp 4y agoStill, back on the Slackware 2.0 days there were plenty of TUI applications. Here for the younger generations, https://en.wikipedia.org/wiki/Ncurses https://en.wikipedia.org/wiki/Ncurses
- zozbot234 4y agoThere are some *nix programs with complex TUI's, where a "snappy feel" is sought after (e.g. the `aptitude` TUI for package management in Debian and its derivatives) and they're just as snappy as any old DOS app. The overhead from using a terminal-based API is just too low to matter.
- pavlov 4y agoAs it ought to be since the lowliest Raspberry Pi is tens of thousands of times faster than the IBM PC. Filling a screen shouldn’t be an issue regardless of the protocol in the middle. But design decisions made in the 1980s still linger in a lot of Unix software.
- BirAdam 4y agoThis is exactly correct. As far as affecting the state of TUI/CLI programs today, it becomes part of the culture as well as part of the overall look and feel of the system. Yet, there are programs that break from convention: JOE, Dit, irssi, etc.