Xref: utzoo unix-pc.general:2925 comp.sys.att:6517
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!uflorida!haven!umbc3!wolf.umbc.edu!alex
From: alex@wolf.umbc.edu (Alex Crain)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: resash of X-windows and 3b1/7300's
Message-ID: <2067@umbc3.UMBC.EDU>
Date: 21 May 89 22:01:31 GMT
References: <636@flatline.UUCP>
Sender: newspost@umbc3.UMBC.EDU
Reply-To: alex@wolf.umbc.edu.UUCP (Alex Crain)
Distribution: na
Organization: University of Maryland Baltimore Co.
Lines: 50

In article <636@flatline.UUCP> erict@flatline.UUCP (J. Eric Townsend) writes:

>Ok, I remember at one point in the past the statement "X windows won't
>happen on a 3b1/7300" being made.
>
>Why?  I've just read some stuff on X-Windows, and it seems the whole
>point of X-Windows is that you can make it work on a C64, if you try
>hard enough. :-).  Seriously, tho, what's stopping a port to the 3b1?

	THere are a couple of deficencies in X windows that make it a dubious
investment for the 3b1.

	1) The size of the investment. X windows is *huge*, and based entirely
on network hardware and a good interface to a large screen device. The 3b1 has
an expensive network interface that most of us do not possess, and minimal
access to the screen hardware in the form of Fords vidio driver. Most of the
workstations tha X runs on are either BSD or BSD extended, so the sysV process
communication stuff has never been written (and we don't have streams anyway).

	2) Even if you did write an IPC interface that is flexable enough
for X, the X server is *huge* (something like .5 meg) and runs all the time.
In my humble opinion, the unix-pc just doesn't have the cpu bandwith to run
X at a tolerable speed as anything other then a network terminal.

	Now, some food for thought now that summer is apon us and there are
bored hackers afoot. IF two things happened, a replacement window manageer
might become a viable option. #1 - we need a public domain IPC mechanism
for this machine, on the order of sockets or streams. The ability to deal
with network I/O is a definate plus hear. #2 - we need a good general purpose
screen driver, that can over ride the existing screen driver for development.

	I've been working on #1 for awhile, and I have a whole buch of code 
that needs some debugging but will be released shortly. The code is based
in the berkley socket code, and implements most of the socket calls except
for select(), which I'm saving for later. I shelved the project about a month
ago in favor of pressing schoolwork and the PDP-11 I aquired :-), but I'll
be getting back into it this week and should have something released by the
time USENIX comes around.

	I also have some ideas for #2, but I don't have time to write it. What
I will do is write a very basic screen driver with documented hooks for
kernal hackers (and would be kernal hackers) to play with, and get it out
either mid june or before if there is the demand.

	I think that an X subset is doable, if enough code shortcuts are
taken. But somebody is going to have to write it...
					:alex
Alex Crain
Systems Programmer			alex@umbc3.umbc.edu
Univ Md Baltimore County		umbc3.umbc.edu!nerwin!alex