112 Terminal Insanity control sequences to accomplish similar functions. Programmers had to find a way to deal with the differences. Programmers at the revered Digital Equipment Corporation took a very simple-minded approach to solving the heterogenous terminal problem. Since their company manufactured both hardware and software, they sim- ply didn’t support terminals made by any other manufacturer. They then hard-coded algorithms for displaying information on the standard DEC VT52 (then the VT100, VT102, an so on) into their VMS operating system, application programs, scripts, mail messages, and any other system string that they could get their hands on. Indeed, within DEC’s buildings ZK1, ZK2, and ZK3, an entire tradition of writing animated “christmas cards” and mailing them to other, unsuspecting users grew up around the holidays. (Think of these as early precursors to computer worms and viruses.) At the MIT AI Laboratory, a different solution was developed. Instead of teaching each application program how to display information on the user’s screen, these algorithms were built into the ITS operating system itself. A special input/output subsystem within the Lab’s ITS kernel kept track of every character displayed on the user’s screen and automatically handled the differences between different terminals. Adding a new kind of terminal only required teaching ITS the terminal’s screen size, control characters, and operating characteristics, and suddenly every existing appli- cation would work on the new terminal without modification. And because the screen was managed by the operating system, rather than each application, every program could do things like refresh the screen (if you had a noisy connection) or share part of the screen with another pro- gram. There was even a system utility that let one user see the contents of another user’s screen, useful if you want to answer somebody’s question without walking over to their terminal. Unix (through the hand of Bill Joy) took a third approach. The techniques for manipulating a video display terminal were written and bundled together into a library, but then this library, instead of being linked into the kernel where it belonged (or put in a shared library), was linked with every single application program. When bugs were discovered in the so-called termcap library, the programs that were built from termcap had to be relinked (and occasionally recompiled). Because the screen was managed on a per-application basis, different applications couldn’t interoperate on the same screen. Instead, each one assumed that it had complete control (not a bad assumption, given the state of Unix at that time.) And, perhaps most importantly, the Unix kernel still thought that it was displaying information on a conventional teletype.

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.