The Magic of Curses 113 As a result, Unix never developed a rational plan or model for programs to interact with a VDT. Half-implemented hack (such as termcap) after half implemented hack (such as curses) have been invented to give programs some form of terminal independence, but the root problem has never been solved. Few Unix applications can make any use of “smart” terminal fea- tures other than cursor positioning, line insert, line delete, scroll regions, and inverse video. If your terminal has provisions for line drawing, protect- ing fields, double-height characters, or programmable function keys, that’s just too darn bad: this is Unix. The logical culmination of this catch-as- catch-can attitude is the X Window System, a monstrous kludge that solves these problems by replacing them with a much larger and costlier set of problems. Interestingly enough, the X Window System came from MIT, while the far more elegant NeWS, written by James Gosling, came out of Sun. How odd. It just goes to show you that the Unix world has its vision and it gets what it wants. Today, Unix’s handling of character-based VDTs is so poor that making jokes about it can’t do justice to the horror. The advent of X and bit- mapped screens won't make this problem go away. There remain scads of VDTs hooked to Unixes in offices, executives’ pockets, and at the other end of modem connection. If the Unix aficionados are right, and there really are many users for each Unix box (versus one user per DOS box), then well over two-thirds of the people using Unix are stuck doing so on poorly supported VDTs. The most interactive tool they’re using is probably vi. Indeed, the most often used X application is xterm, a VT100 terminal emulator. And guess what software is being used to control the display of text? None other than termcap and curses! The Magic of Curses Interactive programs need a model of the display devices they will control. The most rational method for a system to support display devices is through an abstract API (Application Programmer’s Interface) that supports commands such as “backwards character,” “clear screen,” and “position cursor.” Unix decided the simplest solution was to not provide an API at all.

114 Terminal Insanity For many years programs kludged around the lack of a graphical API, hard-wiring into themselves the escape sequences for the most popular terminals. Eventually, with the advent of vi, Bill Joy provided his own API based on a terminal descriptor file called termcap. This API had two fundamental flaws: 1. The format of the termcap file—the cursor movement commands included, those left out, and the techniques for representing complex escape sequences—was, and remains to this day, tailored to the idiosyncracies of vi. It doesn’t attempt to describe the different capabilities of terminals in general. Instead, only those portions that are relevant for vi are considered. Time has somewhat ameliorated this problem, but not enough to overcome initial design flaws. 2. The API engine, developed for vi, could not be used by other programmers in their own code. Thus, other programs could read the escape sequences stored in a termcap file but had to make their own sense of which sequences to send when to the terminal.1 As a result, Ken Arnold took it upon himself to write a library called curses to provide a general API for VDTs. This time, three problems arose. First, Ken inherited the vi brain damage when he decided to use the termcap file. Starting over, learning from the mistakes of history, would have been the right choice. Second, curses is not a very professional piece of code. Like most Unix tools, it believes in simplicity over robustness. Third, it’s just a library with no standing, just like /etc/termcap itself has no standing. Therefore, it’s not a portable solution. As a result of these problems, only part of the Unix community uses curses. And you can always tell a curses program from the rest: curses programs are the ones that have slow screen update and extraneous cursor movement, and eschew character attributes that could make the screen easier to understand. They use characters like “|” and “-” and “+” to draw lines, even on terminals that sport line-drawing character sets. In 1994, there is still no standard API for character-based VDTs. 1And if that wasn’t bad enough, AT&T developed its own, incompatible terminal capability representation system called terminfo.