Back to modern life

Modern workstations don't have separate hardware for the computer itself and one or more terminals. Instead, a CRT is usually directly attached to a graphics board, and input is done with keyboard and mouse, which relieves the necessity to do user input and output over a slow serial line.

Console drivers and virtual consoles

The model described above -- where the terminal is able to handle a certain set of commands -- still applies to modern console drivers. The console driver is a part of the kernel that handles input from the keyboard and output to the display. It passes data via a software terminal device, using the same interface inside the kernel as a serial device would, and that of course needs to be configured in /etc/ttys. Output to the console is interpreted, and just as ancient terminals, today's consoles handle a wide range of character sets, among them various VT100/VT220 variants, ANSI, or more specialized ones like the FreeBSD cons25 console.

Most popular PC operating systems offer another mechanism called a virtual console which allows a user sitting in front of a terminal to view more than one "virtual" console, usually by pressing CTRL+Alt and a function key (F1, F2, etc.). The system handles these as separate lines, and each must be configured in /etc/ttys.

The NetBSD operating system, which uses wscons as the console driver on many ports, offers a way to configure which terminal type it should emulate, with vt100 being used on most ports, and the Sun3, SPARC and SPARC64 port using sun.

Graphics

We have talked about text/console data being passed between computer and terminal, and displayed on the console. However, the question about how graphics work still stands unanswered.

Let's go back in time a bit for this. When terminal vendors added new capabilities to their hardware, one of the new features was to not only display 80x24 text information, but also bitmap data. Of course the command sequences for this were as non-standard as they could be. There was no application-level standard like terminfo or termcap that applications could use to make device-independent use of the capabilities of these graphic terminals.

Eventually, machines were built that had the main unit and graphics hardware connected with a faster connection than a serial line. At the same time, networking several main computer units to local area networks for data exchange and communication became common.

A group of researchers at MIT were exploring modern computer capabilities, and came up with a graphical user interface based on modular parts, just like the classic setup between a computer and terminals. It included an application process that issued commands like "clear screen" or "open window." The commands were sent to a "presentation server" that decoded the commands, and did whatever steps were necessary to clear a bitmap or draw a rectangular area with a border. The "presentation server" usually got its commands from a local or remote computer system, and it knew how to talk to the graphics board for output and keyboard and mouse for input. Events generated by the user operating the mouse and keyboard were sent back to the application process for interpretation and action.

The separation of presentation and application.

Calling names

Are you familiar with the scheme described so far? No? Maybe you will be when we call the components by their names:

The window system described above is the X Window System. The application process is usually known as "X client," and the "presentation server" handling access to devices is the "X server." Communication between X client and X server is done using the X Window System Protocol, which is based on the TCP/IP stack.

Using Unix's capability to run multiple processes, one machine running X clients can issue display requests to one or more X servers running either on the local machine using the local graphics board, the keyboard and mouse, or using an X server that's running on a remote machine.

And just as vendors started to sell VT220-compatible ASCII terminals when that was mostly a standard, there were other terminals called "X terminals." They were equivalent to their text-only cousins which only knew how to handle input and output, without any capabilities to run actual application code themselves. Usually, X terminals consisted of a monitor, a keyboard and a mouse, and a small box that ran only the X server process. The X terminal's X server knew how to talk to keyboard mouse and graphics card, and passed all input and output to an X client.

An alternative to X terminals are today's Unix workstations, which have the processor, graphics card, and I/O-hardware all built into a PC or a traditional workstation machine. The workstation then runs its local instance of Unix, including the X server process to talk to the hardware and a number of X client applications, all in one case.

An X terminal emulation application -- xterm

So far, we have talked about the classic terminal concept of Unix, and about the X Window System, which follows similar principles. Now that we have the X Window System, anyone can turn a PC into a workstation -- the base for modern user interfaces like GNOME and KDE is there. We can forget about all that old cruft about terminals that pass single characters back and forth, escape sequences, and more!

But... Can we really? Let's see how communication with the Unix system works today.

Most interaction with the operating system today still happens via a command-line interface, which is used to type commands, start processes, and view their output, either via X or on the command-line environment that the command was started from. That "command-line environment" is usually a shell running either on the system's console, one of its virtual consoles as described above, or a terminal window on the X desktop.

If the system console or virtual consoles are used, it's quite obvious that the traditional terminal handling is still needed, as it is the base for input and output done by all commands. This applies to both line-oriented programs like ls(1) or cat(1) as well as so-called "screen-oriented" programs like the "vi"sual editor vi(1) and the top(1) process monitor, which still use system libraries like termcap or terminfo to address the console's capabilities.

But we just agreed that no one needs consoles anymore, and that we have the X Window System to interact with the system. There, we open up a terminal window, using programs like xterm, or one of its newer cousins like the KDE "konsole" or GNOME's "gnome-terminal." The programs' names make it quite obvious what they do, and if we take a closer look at how things work, it will be even more obvious where they got their names from.

In the following example, we will use xterm, but others do about the same. When you are using the X Window System and start xterm, a rectangular window opens, with a "shell" command-line interpreter running. You can type commands into the shell window, and output from the shell commands will be displayed in the xterm window. What's happening in more detail is, that the X server takes the keyboard events, and sends them to the xterm process.

The xterm process has a shell process connected to it. The ASCII presentation of the keys pressed are sent from the xterm process to the shell process -- just like virtual consoles and ancient, dumb serial hardware terminals. The shell process reads its standard input, processes the commands given, and output is sent back to the xterm via the standard output channel.

What happens if you run a program that needs to clear the screen or move the cursor to a certain position? Just as in the cases described above, the application knows which terminal type it's connected to, it uses the termcap or terminfo libraries to query that terminal's capabilities, and then sends the necessary escape sequences to the xterm. The xterm process recognizes the command sequences and interprets them, but does not send character-generating events to the X server for display. Instead it does what the command sequence says -- a "clear screen" sequence is sent to the X server as a command to draw a plain white rectangle, and another small black rectangle in the upper-left corner, representing the cursor.

Two apps using the X Windows protocol.

Two details are worth having another look here. First, communication between the xterm and shell process. This is done via Unix's ordinary terminal input/output routines -- no special mechanism was invented in the X Window System for user interaction between the X server and an application running in a command-line environment, with the xterm program "translating" between the two environments. This means that the terminal handling that the Unix operating system has had for more than 30 years now is still useful even in modern environments.

The other detail that's interesting here is the interaction between the xterm process and the X server. The xterm process is just like any graphical application, it sends drawing requests to the X server -- a big white-filled rectangle, a small black-filled rectangle, commands to move parts of the on-screen image around (such as scrolling), of course use the X font mechanism to use a certain font and display characters from it on the X "presentation" server. Although the xterm terminal program does not provide special command sequences, xterm allows you to change the font the X server to use, and a number of other things. To try this, hold down the control-key and press one of the three mouse buttons at the same time -- you'll see that the pop-up-menu of CTRL+left mouse allows selecting the font that the xterm process asks the X server for.

The circle closes

As you see from the previous discussion, graphical user interfaces did not supersede the traditional concepts of the Unix operating system, but interact with them so that existing applications can be used in window environments without any migration effort. The concept of terminals once used as hardware and now mostly as software continues to live on, and the circle closes, giving both "old" and "new" technology an equal right to exist. They do not compete but play together perfectly well.

The simplicity and usefulness of Unix has allowed the system to grow and gain maturity over all these years.

I'd like to close this overview by mentioning that I left some things like networking out deliberately -- the (pseudo) terminals that are used in communication between xterm processes and their shells are also involved in network communication for things like rsh and ssh, and to pass data between different machines as if the data source and destination are processes on the same machine. Also, the description of the X Window System left out many of the concepts of the window system. Window managers and session management are only two of many things that come to mind, but I'll leave these subjects for another time. I hope you had as much fun reading this as I had writing it. Enjoy!

Hubert Feyrer
works on operating systems, databases, and artificial intelligence at the Fachhochschule Regensburg.