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: <1183@auspex.UUCP>
Date: 20 Mar 89 20:35:29 GMT
References: <27385@apple.Apple.COM> <1909@oakhill.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 56

>And now for a word on terminology. Motorola started calling their binary
>interface standard the BCS. AT&T calls their interface the ABI-- Application 
>Binary Interface. As far as I know, the ABI is a specification AT&T chooses to 
>apply only to System V Release 4. On the other hand, Motorola felt the need to 
>begin binary standards work and apply it to System V Release 3. Hence Motorola
>has a BCS for System V Release 3. Motorola also plans to work with AT&T and 
>have an ABI for the 88k and 68k families for System V Release 4. The BCS and 
>ABI documents are different and perhaps someone from AT&T can talk about the
>ABI. Either way, I expect that the answers for the ABI will be the same as I
>have given for the BCS.

I expect the bottom line - namely, an ABI-conformant program using X11
should run on any ABI-conformant system (assuming the CPU for which the
program was built, and the CPU that the system uses, are in the same
family) - will be the same.  I do *not*, however, expect the answers to
be the same in detail; at least, I very sincerely hope they won't be. 

If the S5R4 ABI's are done right, they *will* care what high-level
libraries you use, at least for some libraries, and *won't* care as much
what the OS interface looks like.  They will not be done at the system
call trap level; they'll be done at the library level, with the ABI
specifying 1) the way ABI-compliant applications dynamically link to
routines in a library and 2) the way particular procedures in those
libraries are called. 

The advantage of this is that the ABI is specified at a much higher
level; for instance, "getpwent"/"getpwnam"/"getpwuid" are interfaces in
the ABI, so an ABI-conformant program can run on systems with "getpw*"
implemented as dumb routines scanning "/etc/passwd", routines using a
4.3BSD-style "ndbm" index, routines using Hesiod/BIND, routines using
the Apollo Registery, or routines using Sun's YP, and will use the
appropriate routines on the appropriate systems.  The routines will not
be incorporated into the binary image of the program.

The dynamic linking technology in question wasn't in S5R3, but will be
provided for S5R4, based on the technology in SunOS 4.0 and later
releases; that's why they only apply to S5R4.

In the particular case of the X11 libraries, I would expect Xlib to be
one dynamically-linked library included in the ABI specification, so
that an ABI-conformant application would e.g. fill a rectangle by making
a call to a procedure named "XFillRectangle" in a library named "X" (or
"X11" or whatever), passing it the appropriate arguments.  The layout of
any structures to which the declarations of those arguments refer will
also be specified by the ABI.

The net result is the same, so that any ABI-conforming program should
run on any ABI-conforming implementation (as long as the machine
architectures are the same, of course - no guarantees that an 80*86
program will run on an 88K implementation, even if both are
ABI-conformant!), since the ABI-conforming program will link to the
right dynamically-linked library and make ABI-conforming calls, and the
ABI-conforming implementation will supply an ABI-conforming library that
behaves (or should behave - one would hope the implementation isn't
buggy) properly when ABI-conforming calls are made to routines in the
library.