X Windows and UNIX 386 compatibility
Jeff Barber
jeff at samna.UUCP
Wed Apr 11 04:45:30 AEST 1990
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
More information about the Comp.unix.i386
mailing list