Kdjykuj

I'm wondering if terminals (like, e.g. the VT100) required the installation of a driver on the host system in order to work with that host?

I looked at the documentation of the VT102, and there is nothing mentioned about a driver.

I imagine that the setup of a terminal connected to an application on a host computer looks something like this:

The terminal is connected over an RS-232 communication line to the computer (of course, there might also be two modems and a public carrier line between the two RS-232 interfaces, but it shouldn't matter here).

On the host computer is the application that must get its input from the terminal, and send its output to the terminal. To this end, the application must somehow be connected to the RS-232 interface to which the terminal is connected. In the end, the application must read characters from this interface and write characters to it.

Now the question is, what is between the application and the RS-232 interface?

• Is there nothing at all, and the application must be programmed to directly listen on and write to the RS-232 interface (through the kernel)?


• Is there a driver for this specific terminal, and the application communicates with this driver?


• Is there a generic "terminal controller" in the kernel that works with all terminals and provides a common API for applications (like the TTY subsystem in UNIX)?

In other words, if you write a terminal application, what is the mechanism that you get notified about incoming data from the terminal, and how do you write output to the terminal?

In the latter two cases, the driver or controller could do some processing on the input, like line editing, and only send full lines to the application (as it is done by TTY in UNIX). This would offload a lot of complexity from the application.

The protocol that allows applications to control terminals consists usually just of characters (control characters and escape sequences intermixed with display characters). Furthermore, if we assume that all terminals use the ANSI escape sequences (from the VT100 onwards), the same "control language" works with every terminal. So, I'm not sure if each terminal really needs a dedicated driver on the host computer.

Different terminals didn’t (and don’t) use different kernel-level drivers. In Unix-style systems, the kernel does provide some terminal-related features, called line disciplines and the TTY layer which you mention; there is typically at least a raw line discipline (which doesn’t perform any translation), and a cooked line discipline (which provides more-or-less line-level buffering, handling backspace etc. locally). Anything beyond that is handled inside each individual application, and early applications were hard-coded for specific terminals. (It was also common for applications to be terminal-specific, or support a limited number of terminals, on non-Unix-like operating systems such as CP/M.)

However developers quickly realised that it would be useful to share terminal information, such as screen size, escape sequences for various common functions, etc. The first of these is termcap (terminal capability), developed by Bill Joy in 1978 for BSD; terminfo followed in the early eighties.

Another layer of libraries provides more advance screen-handling features for programs which require that; the earliest common library of this type was curses, and the library currently used is ncurses.

See The TTY demystified for more details.

This was not done by a “driver” at the OS level as you are thinking of it.

In Unix, there were drivers that dealt with the RS232 interface and these were surfaced as /dev/tty* devices and dealt with things like speed, echo, etc.

As for escape sequences controlling the display of the terminal, that is not done at the “driver” level as you are thinking of it.

This was done at the application level through a library like curses, and escape sequences were defined in a database like /etc/termcap or later, terminfo.

Some apps used curses, others used termcap/terminfo to get the sequences but used their own code instead of curses. Some even had their own version of a termcap.

(Termcap = Terminal Capabilities or something like that)

Even though there was an ANSI standard for escape sequences, there were still variations and quirks, and some terminals simply used an entirely different scheme (like Wyse 50).

We have to distinguish between different cases, but in most cases the answer seems to be "no":

• 
  

  In "early" systems (like the Altair 680 in home computing or 1960s professional computers) programs simply wrote bytes to the serial port and they read bytes from there.

  
  
  

  In fact, such machines often did not even have an operating system.

  
  
  

  If you used VT-100 (as an example), your application had to be written in a way that VT-100 compatible output was written to the terminal and that the application could understand VT-100 compatible input.

  
  


• 
  

  Using Linux (the same is true for Solaris; I'm not sure about other OSs) on modern computers have an operating system with a driver for the RS-232 hardware; but there is no driver for VT-100 or similar.

  
  
  

  Just like on "early" systems the application has to communicate in a VT-100-compatible way.

  
  
  

  However there are some libraries (e.g. "ncurses") that can be used by the applications. These libraries provide functions that "translate" "high-level" commands (like: "move the cursor to the upper left corner of the screen") into the correct byte sequences for a lot of different terminal types (e.g. VT-100, xTerm, ...).

  
  
  

  Please note that these are libraries, not drivers. At least in Linux such libraries are handled completely on application level; the OS kernel does not know about the existence of libraries at all.

  
  


• 
  

  Theoretically it would be possible to provide terminal support on OS level. In this case a driver for a certain terminal type (e.g. a VT-100 driver) would be necessary.

  
  
  

  I doubt that such an OS is currently existing.

  
  

"It depends".

I'm answering this in the context of DEC timesharing systems, since that's the natural habitat of a DEC VT100.

There's a hardware device such as a DZ11 terminal multiplexer (8 lines) that controls terminal lines by some physical protocol, such as RS232 or 20mA current loop. The physical protocol is a matter for the hardware. But the OS needs a driver for the hardware device.

The driver does not know the terminal type, but it will contain a variety of settings that depend on the terminal or settings in the terminal: bits per character, parity use, required number of stop bits, and so on.

Over that, but still in some driver, there's common functionality that all terminals need: character/line erase, special keys to generate signals (like ctrl/c = abort or interrupt, depending on OS), and so on. These could be in the same driver as directly handles the hardware (which means a lot of code replication) or in another driver layered on top of the first. Most such functions are terminal independent, but there's a fuzzy edge where we want (for example) character erase to operate differently on screen-based terminals (output backspace, overwrite with space, backspace) than on hardcopy (output backslash, characters being erased, backslash). That requires some knowledge of the terminal type, but it generally falls short of needing to know the explicit type, merely what it can do.

The unqualified term "terminal driver" generally refers to the above level of interface.

Once you get to details that are (or were at the time) highly terminal-specific, such as how to move the cursor around a screen, those are not in a driver. Early on, in my personal experience around 1980, application code would need to include knowledge of specific terminal types. This wasn't too burdensome if you were writing code for DEC since there were basically only 2 main types to deal with: VT52 and VT100, with minor details such as whether the particular VT1xx model had programmable LEDs or not. However, it was burdensome enough such that eventually common libraries would show up: SMG ("screen management") for VMS being an example.

So: to sum up:

• Kernel driver handles specific hardware device independent of terminal type


• Kernel driver handles common user-interaction functions largely independent of terminal type


• User-mode libraries can implement mapping from generic to type-specific operations


• Application code can use such libraries when available or do it all itself