Xl1200 as x server

[rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM (Richard Lamson)]

    Date: Thu, 2 Aug 90 18:55 EDT
    From: miller@GEM.cam.nist.gov (Bruce R. Miller)

	Date: Thu, 2 Aug 90 17:35 EDT
	From: Barry Margolin <barmar@Think.COM>

	    Date: Thu, 2 Aug 90 14:23 EDT
	    From: miller@GEM.cam.nist.gov (Bruce R. Miller)

	    Just how does  this work  (for the  X naive)?

	It's all done through the magic of object-oriented programming.  ...
							barmar
    Well, I didn't mean That naive ! :>  (but thanks anyway)
    What I had in mind was the following:

    Not knowing the X protocol, it  is not inherently obvious that  the full
    protocol used by  TV and  DW CAN  be (practically)  translated into  the
    appropriate X.  

It's actually much simpler than you realize.  The window-system layer was
essentially unmodified except for parts of the locking strategy (you can't
use WITHOUT-INTERRUPTS to do locking if you're using the network).  The
protocol between the window system and the screen has been pretty well
defined in the last couple of releases.  The X client replaces the entire
screen protocol implementation with one which is functionally equivalent
but implemented in terms of X.  All of the crufty old window system kludges
and all of DW goes through this relatively narrow protocol.  I haven't seen
it in about a year, but the last time I saw this code it was called the "X
Screen" system; now you know why.

		    That is to say, although equivalent functionality  could
    most likely be achieved in X at some level in the application, the TV/DW
    protocol has been decomposed into certain operations, some of which  may
    have no equivalents.   Take some random old TV-style application and  it
    is throwing all  sorts of  random messages,  high-level and  low, at the
    window-stream.  

Yes, but all of those random things you can do to the window stream are
implemented in terms of a relatively limited set of operations; that set is
implemented for both (B&W and color) hardware screens and for X-based
screens.  [In fact, color was the impetus for this protocol's original
implementation; the window<->screen interface was quite muddy before.]

[...]
    On the basis of other replies, though, it seems that most things DO work.

The things which don't work have problems with shared data structure or
places which KNOW which screen to expose themselves on, rather than because
the window system doesn't work.  For example, you can't use Zmail because
it's full of special variables.  I think you can't use the Inspector
because it "knows" that the only place you ever want to use the Inspector
is on TV:MAIN-SCREEN.

    I just dont want to fork over the bucks, install it, and have Macsyma come
    up saying

    Command: Macsyma
    You cannot do plotting in this context.You cannot do plotting in this context.You cannot do plotting in this context.
    This is Macsyma 416.15 for Symbolics 3640 Series Computers.

Macsyma doesn't do anything interesting to the window system.  The last
time I looked at the innards of Macsyma, it, too, was full of special
variables, but perhaps that's been cleaned up when it was converted to
Common Lisp.