What is a Screen, Really?

Posted to:

    http://lists.gnu.org/archive/html/guile-devel/2014-09/msg00145.html

> But it would nice to get some new major features. Screen is old.. 27 years
> is heck a lot of time. What about the next 27 years? ;)

As far as its apparent functionality goes, GNU screen is one of the best pieces of GNU software I know: there is an unmistakably twisted sort of genius to what it does. But what I only discovered a week or so ago is that Screen is actually only one quarter of an idea that is now over 45 years old. This suggests that what to do over the next 27 years is to implement at least another quarter of it :-)

Here is what I claim is the original expression of Screen, which was called "the message interpreter":

At level 2 we find the "message interpreter" taking care of the allocation of the console keyboard via which conversations between the operator and any of the higher level processes can be carried out. The message interpreter works in close synchronism with the operator. When the operator presses a key, a character is sent to the machine together with an interrupt signal to announce the next keyboard character, whereas the actual printing is done through an output command generated by the machine under control of the message interpreter. (As far as the hardware is concerned the console teleprinter is regarded as two independent peripherals: an input keyboard and an output printer.) If one of the processes opens a conversation, it identifies itself in the opening sentence of the conversation for the benefit of the operator. If, however, the operator opens a conversation, he must identify the process he is addressing, in the opening sentence of the conversation, i.e. this opening sentence must be interpreted before it is known to which of the processes the conversation  is addressed! Here lies the logical reason for the introduction  of a separate sequential process for the console teleprinter, a reason that is reflected in its name, "message interpreter."

Above level 2 it is as if each process had its private  conversational console. The fact that they share the same physical console is translated into a resource restriction of the form "only one conversation at a time," a restriction that is satisfied via mutual synchronization. At this level the next abstraction has been implemented; at higher levels the actual console teleprinter loses its identity. (If the message interpreter had not been on a higher level than the segment controller, then the only way to implement it would have been to make a permanent reservation in core for it; as the conversational vocabulary might become large (as soon as our operators wish to be addressed in fancy messages), this would result in too heavy a permanent demand upon core storage. Therefore, the vocabulary in which the messages are expressed is stored on segments, i.e. as information units that can reside on the drum as well. For this reason the message interpreter is one level higher than the segment controller.)

http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD196.PDF

The other layers of the THE multiprogramming system were equally radical, and still I think there are many people who interpret these ideas in terms of what they already know, and in so doing, they miss the point completely, which is that there is a core methodology that is being _mechanically unfolded_ into a whole coherent design for what we nowadays think of as "an operating system kernel." But modern kernels do not have this economy of principles: witness the insanity
that the Linux kernel device driver stack has mutated into!

When you read this, think of the sequential processes not as "processes" as we know them, but as "processors" or "virtual machines". And don't think of segments and pages in terms of segmented memory models with virtual page maps and swap space, think of them as a kind of storage area network.

So I think we should implement GNU Screen, layers 0 and 1 in addition to layers 2 and 3.