Windowing systems

[P. D. Guthrie]

In article <2644 at brl-smoke.ARPA> gregg%a.cs.okstate.edu at csnet-relay.arpa writes:
>	The biggest problem with windowing seems to be the lack of knowledge
>that the kernel has about the users environment.  It seems that several
>people have essentially indicated that a more generic communications means
>should exist between the kernel and the users terminal.
>
>	It seems most natural to develope some sort of protocol for the kernel,
>and have much smarter terminals to decipher it.  A protocol including info
>about the process doing the I/O, as well as other data would be needed.
I often see in this group postings that draw the conclusion that the
magic solution to many problems is to put the code in the kernel.  This
simply is not so.  The beauty of UNIX  (I alreay here a lot of groans
and "no, not another programming-as-art nut") is that the kernel
contains the minimum ammount of code to do what a good operating system
should do ; "Hardware provides `raw computing power'.  Operating systems
make this power conveniently available to users."  (Operating Systems, 
Harvey M. Deitel).  Unix provides a set of low level OS interfaces
(system calls)  to allow the writing of system and applications
software.  The question here should be,  "Does Unix provide the
necessary facilities to create windowing software?".  If I was asked
this about other operating systems (Pick, HP3000-MPE)  I would have to
say `no',  but as it has been shown, to various degrees between the
versions,  UNIX  *does*  provide adequate,  and in the case of Version 8
(which I have not used, only read about) very good, facilities for
windowing systems.  I am not opposed to the idea above,  rather
generically opposed to the idea of solving *applications* problems in
the kernel.  Version 8  seems to provide a very good alternative with
the streams package.  You say that the `biggest problem with windowing
seems to be the lack of knowledge that the kernel has about the users
environment'.  This simply is not a problem,  but rather a benefit.  By
providing a virtual (and generic) interface in the kernel,  the layers
of applications above can be provided by the proper level of control, 
the user (applications) software.  This way the kernel does not have to
be tailored to meet specific requirements.  Also,  to see how difficult
your suggestion would be to implement,  ask anyone who has had to
implement a tricky device driver (tailoring protocols would probably be
more difficult)  on a *single* Unix machine - it is *very* time
consuming with the amount of time spent recompiling the kernel and
rebooting.
>
>	This gives rise to the question of terminal type.  This provides quite
>a few problems because EVERYBODY would want to define their own protocol.
>I have seen a SUN workstation, and imagine that something of this nature
>is used there.  Picking a very flexible workstation as a terminal is the
>logical choice.
>
You have hit the major problem with your scheme on the nose.  If
everyone did define their own protocol at the kernel level the size and
complexity of the code would greatly increase and we have to be Hahvahd
grads to know what would happen to the speed.  Why should the user on
a non-windowing terminal suffer a degradation of performance for this?
You suggest picking a `flexible workstation'.  If a workstation can be
made flexible enough to comprehend many (and often changing - so
therefor user definable)  protocols,  then it should not be so hard to
instead have a workstation that  interprets  non-kernel signals  (ie
multiplexed output and input,  and new downloaded software and
administrative commands)  from a user process.  It's more or less the
same thing,  so why implement it at such a low level?
-- 

Paul Guthrie				`When the going gets weird,
ihnp4!ihdev!pdg				 The weird turn pro'
					  - H. Thompson