Vtgyjfy

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).

"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

Two more slightly different situations from the past (well, everything in Retrocomputing is from the past...):

3270 Emulation

When I was at the University of Maryland, College Park in the early 1980s, there were some Vaxes, a Univac 1100/80 and some other non-IBM large systems, and there were some micros (my first networking course was on the then brand new IBM AT). But the bulk of the CS courses, the primary email system, etc. was all on IBM mainframes. However, except for system consoles (not accessible to undergrads) and a handful of experimental systems, we had no IBM terminals. There were some Decwriters but most of the terminals were ADM3As and similar video terminals, many (not all) running on the mainframes with a 3270 emulation. One day I was chatting with someone online and lamenting that my wonderful Wyse 100 was limited to glass TTY operation on the mainframes. Soon enough, I was down in the bowels of the CS building with my Wyse 100 and a few hours later it was working in 3270 emulation mode. It turns out they had an IBM Series/1 set up as a terminal/protocol server and it handled all the translation needed - whether a VT52 or an ADM3A or Wyse 100 or whatever. Unlike a lot of terminal drivers, this had to do everything on both input and output. Every function key, cursor key, etc. was translated, even if it was a multi-character key, into an equivalent 3270 code. The Series/1 maintained a screen buffer for each connected terminal and would send blocks of data to the mainframe when appropriate. That also allowed for screen redraw, which was useful in the days of sometimes flaky modem connections. As far as the mainframe was concerned, everything was either a full-blown 3270 or a plain TTY that only supported CR/LF/BS.

Concurrent DOS

Digital Research Concurrent DOS was the successor to MP/M-86 (which in turn was the 16-bit version of MP/M which was the multiuser version of CP/M). As with all those previous operating systems, most software had to manage its own "terminal drivers" in whatever way it chose to do so (as explained in other answers), with the operating system handling just the byte-level I/O (baud rate, parity, handshaking, etc.). However, Concurrent DOS added an IBM PC emulation mode using the magic of the 80386 processor (which could run multiple simulated 8086 sessions, each accessing 1 Meg. of RAM, etc., and could also trap any video memory accesses) and terminals such as the Wyse 60 with a "PC Mode" emulation. The PC Mode emulation sent keys as the scan codes normally sent from an IBM PC-compatible keyboard, thus allowing for full compatibility with software that understands the cursor keys, function keys, etc.as well as capturing "key down" vs. "key up" as needed for full interactive use of certain applications. The end result was a nearly complete monochrome text-mode (there was a color version at one time as well, but far less popular) on dozens of terminals on a single system (80386, 80486, I think I went as far as Pentium Pro before networked cheap computers became more practical). In this particular case, the operating system handled all the differences between terminal types. In reality, there were only a few relevant terminal types as taking a VT100 or ADM3A and trying to use it in PC Mode would be extremely limiting and have a number of problems. But at least for a small group of terminal types, this was a situation where the operating system truly did have terminal drivers and did not leave the configuration to the application at all. The applications - whether CP/M-86 or MS-DOS, whether using OS calls for I/O or blindly writing to video memory - could not tell which of the various "PC Mode" terminals (with their minor variations) was actually being used.

I guess that's a field one can come up with many views - and all presented answers so far give a valid view with lots of additional information. This is intended to break it down to a more general statements:

• No, at the core no OS offers terminal drivers. Just serial (or whatever) line drivers handling bare communication to a device connected. Input (and output) is mainly on a character by character base (mainframes do differ) This is also often called RAW mode.




• Many OS offer (very limited) on functionality for line editing and some escape functions (like program or input abort or escape to OS level). Here input was not on a character basis, but a whole line at once. Examples would be MS-DOS or CP/M function 0Ah. In some way this could be called a driver function. Other systems delegated this into user side libraries. This is usually called Cooked mode. (*1)




• Within the 'world' of a single provider (like DEC or IBM) terminal codes where usually kept upward compatible, so programmers just used the known sequences to control terminal output, marking a certain terminal as minimum requirement.



• 
  

  In heterogenous environments developers soon added tools based on databases assigning to be used code sequences to generalized (virtual) functions. Depending on the program model this was done

  
  
  
  
  
  • by calls into the data base handler for each occurrence when produced, or
  
  
  • by inserting virtual codes into a buffered output and then having the whole message translated into a message the terminal would understand.
  
  
  
  

  The eventually most prominent implementation here might be Unix' Termcap. A simple text data base structured by terminal-identifier and function-identifier.

  
  



• In the mainframe world existed some rather primitive OS side drivers for terminal agnostic handling of output, usually limited to things like line feed highlighting and locking/unlocking of input areas.

Bottom Line: Terminals were in most cases simple character based interfaces with usually no higher level support for output and optional (and rather minimal) support for input handling.

*1 - A few systems/libraries also offered something that could be called Rare mode where operation was character based, but certain, single character codes would be caught and interpreted before (or instead of) handed to the application.

The DEC VT100 itself did not have a driver. When you connect a terminal like a VT100 to a serial port it was a just tty device.

VAX/VMS used a utility to configure devices for the operating system. As a Field Engineer, I had to run the utility after adding a new controller like serial line multiplexer to a VAX system or MicroVAX. This was followed by reboot. That was all of the driver configuration that was done. So the answer is that yes a new driver was configured, but it was built in to the OS and if it was the first controller of a given type it usually was automatically configured. If it was the second controller of a given type an address and an interrupt vector had to be assigned.

There wasn't the plethora of devices that there are today on PC's. There were controllers made by other companies, especially disk controllers, but they emulated native DEC controllers.

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.

  
  

Back in the day I always added the DCL command "$Set Term/Inquire" to my login.com script to let VAX/VMS figure out the type of terminal I was using. I find it interesting that it seems at least once a week, I see references to DEC's VT100/VT101 in modern software.

I remember having a directory full of animated txt files and some txt files to make a Dectalk box sing :*)

Here are some links:

• 
  Ansi everthing


• 
  VT100 History and more


• 
  Microsoft almost brings back the VT100


• XTerm can do a lot!