X Windows and UNIX 386 compatibility

[Jeff Barber]

In article <3140 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>>The System V 386 ABI allows me to accomplish this - my binary runs
>>unchanged on all compliant versions.
>
>Are you talking S5R3 or S5R4?  In at least some cases I've seen "ABI"
>used for S5R4-based interfaces and "BCS" used for S5R3-based interfaces,
>but I don't know if that's the case here....

Please correct me if I'm wrong -  I thought that the UNIX-386 ABI
existed now (i.e. in UNIX System V Release *3*).  See also below for R4.


In article <261e80b8:1076.1comp.unix.i386;1 at tronsbox.UUCP> tron1 at tronsbox.UUCP (HIM) writes:
>>There are obviously at least a few different ways the IPC could
>>be implemented on System V (shared memory, fifo's, etc.).
>
>Yes, but it is >my< impression that your program doesn't care. There is a
>standard X-Windows supplied IPC that handles the translation to whatever the
>native IPC is. Thus , you don't care what the physical IPC method is.

You miss the point.  Maybe I can restate the problem:

You are correct that from a source code standpoint, my program
does not care what IPC method is used.  However, I don't want
to have *just* a single version of source, I want to have a single
version of *object*.

Here's an example:
Let's assume that I am using Interactive's UNIX (i.e. 386/ix)
to develop my application.  Interactive has chosen System V style
shared memory (i.e.  shmget, shmop, etc.) as their Xlib-
to-X-server IPC mechanism (I don't know if this is what they
use - it's just an example).  After compilation and linking, I
now have an executable program.  It runs just fine on a 386 PC
with *Interactive's* version of UNIX and *Interactive's* X-server.

Now, according to the UNIX 386 ABI, I can take my executable
to another 386 PC running (for example) SCO's UNIX System V.
SCO, however, when they developed *their* Xlib and X-server
decided to implement the IPC using named pipes (again, this
is just an example).  So, even though the executable *runs*
on SCO's version of UNIX, it is unable to locate and communicate
with the X-server on the target machine (remember, it's trying
to utilize shmop's to talk to the server).  The XtInitialize
function aborts with a nasty message to the effect that it
can't find the X-server.

See?  My program is binary compatible and yet worthless on the
alternate version of the operating system.  I have to go re-link
(at least) with SCO's Xlib.

Further along, in article <3140 at auspex.auspex.com>, Guy writes:
>For S5R4, the question may not be relevant if Xlib is a shared library,
>since binary programs won't include the code that does the IPC - it'll
>link to it at run-time.  (It may also be true for S5R3 as well, if Xlib
>is a shared library.  The difference is that I think all S5R4-based ABIs
>include dynamic linking as an integral part, and are based on dynamic
>linking, although I don't know that they *insist* that Xlib be a shared
>library.)

I agree that *if* Xlib is a shared library this is not a problem.
However, the version of X I'm using now (X11R3 on Interactive's
S5R3) does *not* use a shared library implementation (though perhaps
I missed some installation instructions for this option hidden in
a manual somewhere?).

So, the first question is:
Does anyone know if there is a problem?  That is, can someone
(perhaps from Interactive, SCO, Dell, Everex, etc.) state
whether the current UNIX 386 vendors use the same or different
IPC mechanisms for the Xlib-X-server connection?

The next question is:
Will this be addressed for S5R4?  Either by using a shared-library
implementation of Xlib or by establishing a "standard" IPC
mechanism for X-windows?

Jeff