V.2 Job Control

[Guy Harris]

> Within the limitations of the terminal hardware, there is a lot of
> commonality between the functions needed to support a Blit and the code to
> provide Job Control.  In the case of the Blit, a lot of the code
> actually resides in the Blit, in the case of the "dumb" terminal using
> Job Control, the code resides in the kernel, but there is no excuse
> for the user having to see the difference, as long as s/he sticks to a
> prescribed subset of functions.

	The main difference between the Blit multi-layer support and the S5R2
"job control" multi-layer support is that the Blit is an intelligent terminal
with a lot of local memory and software specifically designed to support
multiple overlapping windows.

	A "virtual terminal" has several sorts of state information; the ioctl
modes of the terminal port, the current contents of the virtual screen of that
virtual terminal, and the internal state of that terminal.  An example of the
latter might be the the state of a VT100's line-wrap option (whether an attempt
to put a character in column 81 causes the cursor to move to the beginning
of the next line or not), of its keypad (whether it transmits numbers or
escape sequences), or of its current character set.

	The S5R2 "job control" mechanism does preserve the ioctl modes, but
it does *not* preserve the internal state of the terminal.  To do this, all
characters output to the terminal would have to pass through a routine which
knew *all* the character sequences that affected the terminal's internal state
and would have to interpret them; furthermore, it would have to know how to
save and restore that state.  It would also have to preserve the screen's
contents, so that when switching from one virtual terminal to another the screen
would be properly painted with the contents of the new virtual terminal's
screen. Another way to do this would be to provide a fake terminal type which is
designed for multi-windowing, and have the programs write character sequences
for this pseudo-terminal which would be interpreted by a program which knew
how to simulate those functions on the actual terminal.

	All this is difficult at best, and impossible at worst (there may
be terminals which simply can't support this).  The Blit is different, because
its software was specifically designed to make all this possible, so it's not
fair to assume that what's available transparently to processes talking to a
Blit can be made available to processes talking to arbitrary terminals.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy