Xref: utzoo comp.unix.i386:1750 comp.windows.x:15883
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!sally!plocher
From: plocher@sally.Sun.COM (John Plocher)
Newsgroups: comp.unix.i386,comp.windows.x
Subject: Re: Shrink Wrapping X Windows Clients on Intel Hardware
Message-ID: <129232@sun.Eng.Sun.COM>
Date: 14 Dec 89 04:01:53 GMT
References: <1989Dec8.005923.23810@pcrat.uucp>
Sender: news@sun.Eng.Sun.COM
Reply-To: plocher@sun.UUCP (John Plocher)
Organization: Sun Microsystems, Mountain View
Lines: 57

+-- In <1989Dec8.005923.23810@pcrat.uucp> Rick Richardson writes
| In UNIX SVR3.2 no standard exists for a client to connect to
| a local X server.
| You folks *must* agree on the mechanism(s) to be used by local
| clients when connecting to a local server.  It's too late for
| SVR3.2.  Don't repeat the mistake in SVR.4.
+--

As one of the team delivering the Sun X11/NeWS server source to
AT&T for the Vr4 source tape, I feel I can comment on this issue
with a bit of authority.  Nevertheless, this posting is NOT an
official statement by Sun or AT&T.  Caveat Emptor. :-)

The 3.2 world is an ungodly mess when it comes to this problem;
I agree with Rick here, it is almost beyond hope.

One workaround may be to set 
	DISPLAY=localhost:0
and force the client to use the loopback network interface
for connections to the server.  Slow, but faster than not
working at all :-)

Using the above method will only work IF THE NETWORKING
LIBRARIES on the systems ARE COMPATABLE.  Since networking
is also not a standard, you can't even move clients that use
networking between systems!

For remote clients, the picture is consistant:
The Vr4.0 AT&T XWIN server uses a connection method based on 
TLI and nameserver daemons which (on an ethernet, but not
starlan) gets mapped to a TCP/IP connection to port 600x
on the server.  Other X servers implement a socket emulation
library and graft that directly onto the X code from MIT
which again talks to the TCP/IP port 600x on the server.

When you get to local clients, the picture changes a lot:
XWIN and X11/NeWS use ptys to do local connections; other
servers use Unix Domain sockets; still others use shared
memory.  The libraries are usually statically linked to
the clients, so that there is no way to modify them without
the source.

Vr4 won't necessarily solve the problem of systems using
different local connection methods; it WILL, however,
    - make the networking interface standard (TLI
      with a socket emulation library on top of it)
    - make the libX11 XLib library DYNAMIC

This means that AT&T can use their XLib, ISC can use theirs,
and Everix can go their way; clients are developed as usual
except that they are dynamically linked to libX11.

This is a win when you realize that the library that the client
actually uses is the one provided with the server that is resolved
at run time!

  -John Plocher