Re: [screen-devel] GSoC 2015 and GNU Screen

[Ian Grant]

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

Ian