Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!lll-winken!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: ABI (or whatever the (proposed?) binary executable standard is
Keywords: ABi X
Message-ID: <1184@auspex.UUCP>
Date: 20 Mar 89 20:39:43 GMT
References: <27385@apple.Apple.COM> <1909@oakhill.UUCP> <27430@apple.Apple.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 17


 >Well maybe.  The problem here is that there is no standard for local X
 >communication.  There is the X protocol standard but at a level below this
 >I have seen several very different ways of talking to your local server (i.e.
 >shared memory, streams, socket libraries that use streams, socket libraries
 >that use a pseudo tty driver, etc.).  Which one was a BCS compliant X app
 >built for?  Which one does the local server accept?

If the ABI is done right (see my previous message), this will not be a
problem with the ABI.  XOpenDisplay will be part of the ABI, as will,
presumably, some specification of what strings are valid display names
in which circumstances; the ABI application will call Xlib routines to
do the work, and as long as the Xlib implementation does the right
thing, the code in the application's binary image will neither know nor
care what mechanism is used to talk to the server - that'll all be
hidden in Xlib, which will *not* be part of the application's binary
image (note: "application's binary image" is not what ABI stands for).