Xref: utzoo unix-pc.general:2127 comp.sys.att:5358
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!mimsy!haven!umbc3!alex
From: alex@umbc3.UMBC.EDU (Alex S. Crain)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: MGR on the 3b1
Summary: (maybe not MGR....)
Message-ID: <1615@umbc3.UMBC.EDU>
Date: 28 Jan 89 04:46:02 GMT
References: <124@bsadrc.UUCP>
Reply-To: alex@umbc3.umbc.edu.UMBC.EDU (Alex S. Crain)
Distribution: usa
Organization: University of Maryland, Baltimore County
Lines: 83

In article <124@bsadrc.UUCP> dcarver@bsadrc.UUCP (Darrel R. Carver) writes:
>Anyone working on a port of this package?  It would seem to be a
>canidate for replacing wmgr, smgr and relatives (look ma, source!).  

	I scanned through MGR awile ago (its been available from bellcore
for some time) and regected it because:

     1)	It's pretty sun specific. getting it to run on a 3b1 would probably
mean building it *over* the existing interface (Yeech!).

     2)	I'm not sure that it would buy you anything. There are almost no tools
available for it and you would lose the existing 3b1 tools (texview, etc), in
exchange for a nicer programming interface. little or no gain for alot of work.

     3) because of 2, I doubt that there would be a mass interest in it among
unix-pc'rs. lack of support means that few clinets would be written, which 
would dampen support, a vicious circle.

	Admittedly, there is not much in the way of alternatives. I have been 
tossing around an idea, though:

	The X server could be ported to the 3b1 pretty easily. the mfb code
is straight forward, and with the lowlevel access available, it could even
run fast. I expand:

	The two hard parts of the server port are the screen/kbd/mouse
interface and the socket code. The first is not trivail, but its not
too painful either. One could allocate a signal (say SIGWIND) and
rework the keyboard driver to write into some shared memory and
generate a signal on input. Add a listening deamon that would listen
for IPC on some kind of port setup (ala more shared memory) and
generate a SIGWIND on input. Use semaphores as queuing flags, and have
the X server wait on SIGWIND for an event. On an event, the X server
reads the shared segment, processes the event, and goes back to sleep.

	Ironically, this is far superior to the existing sun code, which
loops doing non-blocking reads (barf!). 

	So if its so easy, why arn't I coding away? well, there's a few issues
here.

	-1) Do this and kiss off everything that uses the existing wmgr. I 
personally wouldn't miss it, but alot of people use that stuff (like the UA,
texview, picture, 3b1tools, even the fancy font for nethack).

	-2) There is now way that this is not a huge project. the X11R3 
distribution and contrib files is right around 100 Mb of source. The X server
is a 400Kb+ process that runs all the time. I have no idea how much of it
could be stripped out or could stay swapped out, but its still alot of
resources.

	-3) X11 is slow on a VAX, it's got to be pretty slow on a 3b1.

	-4) 740x320 is pretty small for a windowed environment.

On the plus side:

	1) I fully intend to put another 2meg in this machine as soon as I can
scrape up the bread, and with 4meg RAM, the server should run ok.

	2) there's alot of stuff available for X, like Tex and troff 
previewers, drawing programs, icons, windows with adjustable borders, 
window managers, etc.

	3) X is a great programmers interface (sure beats wrastop()). loads
of graphics primitives, neat wiget sets, etc.

	4) X is mega popular, and growing.

Notice that I did not mention networking. Its my opinion that the 3b1 is 
not a fast network machine, given the popularity (or lack of) of ethernet 
cards. I'm sure that those in possesion of such cards feel differently, but
for most of us, network means 1200-19200 baud. (nobody runs 300 baud for
anything anymore, do they?)

	I figure that stripped sources would run about 10-20 megabytes, so
the multiple drive cards make this somewhat more attractive. Anybody care to
comment on the idea?
-- 
					:alex
Alex Crain
Systems Programmer			alex@umbc3.umbc.edu
Univ Md Baltimore County		nerwin!alex@umbc3.umbc.edu (NEW DOMAIN)