Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cs.yale.edu!yarvin-norman
From: yarvin-norman@CS.YALE.EDU (Norman Yarvin)
Newsgroups: comp.sys.att
Subject: Re: More X foolishness
Message-ID: <15903@cs.yale.edu>
Date: 16 Feb 90 04:49:22 GMT
References: <1089@icus.islp.ny.us> <15523@cs.yale.edu> <15830@cs.yale.edu> <3220@umn-d-ub.D.UMN.EDU>
Sender: news@cs.yale.edu
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 59

In article <3220@umn-d-ub.D.UMN.EDU> rhealey@ub.d.umn.edu.UUCP (Rob Healey) writes:

>	The BIG problem is the UNIX PC's virtual address space, not the
>	amount of physical memory.

Exactly the opposite, in my book.  The Unix PC's virtual address space is
2.5 MB per process; that's big enough for X.  And all the processes don't
have to fit in 4 MB; some can be swapped out -- and your swap partition can
be pretty big.  On the other hand, virtual memory is _slow_.  If your
program doesn't fit in real memory, it's not going to run fast: witness the
case of those .5M/20M machines which took 5 hours to compile programs that
took 30 minutes to compile on 3b1s.

>				 Why try to make the UNIX PC run both
>	clients and server? Start out small and have it run a special
>	server. Work out the applications later...

You are proposing using the Unix PC as an X-terminal.  That would certainly
be possible, but doesn't do much for the local machine.  And you'd have to
run through the serial port, unless you had an Ethernet card -- the serial
port would slow things down further.

A comparison to a 4 MB diskless 3/50 (68020 machine) is much less valid than
a comparison to a Sun/2 (68010 at 12 MHz).  And X was too big for the Sun/2,
at least in one friend's experience.

Now, about what can be done.  For my uses, the current window driver has 3
main drawbacks.

1) You can't use the bottom lines of the screen.  (You can use the top line,
if you try hard enough.)

2) Window borders are _way_ too big.

3) Window resize/move/select is too hard.

How to fix these? Well:

1) This would require some serious hacking of the window driver: one would
have to disable routines that wrote to the bottom of the screen, and modify
bounds checking for window creation.  Possibly one would have to expand the
amount of memory allocated to each window -- but changing that would be
incredibly hard.

2) This would require even more serious hacking of the window driver, to fix
properly.  A workaround, though, is to always use borderless windows; that's
how my system runs.  (You get used to it -- and it helps a lot if the
windows are misaligned by half a character size.)

3) Yet more hacking of the window driver... but there is an alternative:
changing Mike Ditto's keyboard driver to output to a user process when mouse
buttons are pressed and the meta key is down (for instance).  This user
process would then resize windows, etc.

Well, sounds like it'd be easier to port Mgr...

		Norman Yarvin		yarvin-norman@cs.yale.edu
  "I can't really represent the size of the sun on the blackboard,
   but this should give you a good idea."