The move was from termcap to terminfo. Termlib was the library for termcap.
There were two problems with termcap. One was that the two-character
name space was running out of room, and the codes were becoming less and
less mnemonic.
But the big motivator was performance. Reading in a termcap entry from
/etc/termcap was terribly slow. First you had to scan all the way
through the (ever-growing) termcap file to find the correct entry. Once
you had it, every tgetstr (etc) had to scan from the beginning of the
entry, so starting up a program like vi involved quadratic performance
(time grew as the square of the length of the termcap entry.) The VAX
11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
was shared among dozens of timesharing users, and some of the other
machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
It took forever to start up vi or more or any of the termcap-based
programs people were using a lot.
I wrote a paper about it for Usenix in 1982, but it seems to be lost to
Google. Here is a nice write-up Pavel Curtis posted about it with more
detail about the motivation:
http://www.informatica.co.cr/unix-source-code/research/1982/0711.html
Mary Ann
On 01/01/2015 07:03 AM, Johnny Billquist wrote:
On 2015-01-01 02:29, Erik E. Fair wrote:
All those terminal quirks made writing termcap
entries challenging
(I wrote a few), and made the comments in the termcap file interesting
reading for the frustration and cursing of terminal firmware authors.
All kinds of history of the evolution of terminals is captured therein.
The removal of the ability to read the source is - IMHO - what
greatly impeded adoption of the AT&T "termlib" replacement for
termcap: they stopped distributing the terminal database source
(they distributed just the binary "compiled" versions), and made it
harder to write new entries.
I was way to removed from the action to know, but why did people
slowly move over to termlib? Was there really any advantages over
termcap?
Johnny