Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!agate!shelby!rutgers!mcdchg!motmpl!ron
From: ron@motmpl.UUCP (Ron Widell)
Newsgroups: comp.sys.m88k
Subject: Re: ABI vs Apple Toolbox
Message-ID: <1892@motmpl.UUCP>
Date: 4 Dec 90 22:50:48 GMT
References: <43399@mips.mips.COM> <14099@mcdphx.phx.mcd.mot.com> <4585@auspex.auspex.com>
Reply-To: ron@motmpl.UUCP (Ron Widell)
Organization: Motorola Semiconductor, Minneapolis, MN.
Lines: 55

While this could (and probably will) be better answered by someone from 88Open,
I am rarely able to resist the temptation to stick my foot in my mouth :-).

Guy Harris (guy@auspex.auspex.com) writes:
> >The 88open ABI, a.k.a. BCS,
> 
> I thought BCSes were S5R3.x-based, and specified the system interface in
> terms of "system calls", i.e. traps to the kernel, while ABI's were
> S5R4-based, and specified the system interface in terms of procedure

My (probably obsolete) copy of the 88Open BCS (1.0, dated Feb. '89) seems
to pretty well address this in paragraph 3. of the Foreword. Namely,
that AT&T has endorsed major portions of the BCS as an Interim System V ABI
for System V, Release 3.2. And that their (AT&T's) endorsement will ensure a
logical migration path to a full ABI based on System V, Release 4. The criteria
for this endorsement are specified in a, b, c , and d of paragraph 3; with
sub-paragraph 3.c being of interest for this discussion. It states that 88Open
has agreed to migrate its future definitions of the BCS to conform to the
SVR4.0 ABI published by AT&T. It then goes on to state that "The largest
conceptual differences for the future are:" (1) ELF vs. COFF files; (2) system
calls via dynamic shared libraries vs. direct traps; (3) library interfaces
to avoid naming of and specifications for system files.
> 
> A BCS-compliant application, however, would have its access method for
> the password file linked into the executable, and would always try to
> use the mechanism provided by the system on which it was linked, even if
> that was inappropriate for the system on which it's being run or
> unavailable on that system.)
> 
While this is true for a program which is compliant to my copy of the BCS,
this is an area which is explicitly guaranteed to change in some future
definition of BCS.
> 
> At least that's what the 88K ABI document seemed to say when I
> read it (I forget whether the 88K BCS specified system calls or
> procedure calls to an S5R3-flavored shared library)....

My copy specifies trap-type system calls, and says that shared libraries will
be implemented in the future.

So, the way I read it, the BCS is an "Interim ABI", and will become (I don't
know when, maybe it already is) a fully conformant ABI. Applications which
use facilities noted in the BCS as subject to change will be required to change
in order to remain compliant to future definitions of the BCS and to the ABI
for SVR4.0. Those applications which don't use those facilities can migrate
without change. Section 1 (Scope) also specifies those facilities which will
not change (at least not without an earlier and/or attendant change in the
underlying standard; POSIX, SVID, etc.).

(Open mouth, remove foot :-))
-- 
Ron Widell, Field Applications Eng.	|UUCP: {...}mcdchg!motmpl!ron
Motorola Semiconductor Products, Inc.,	|Voice:(612)941-6800
9600 W. 76th St., Suite G		| I'm from Silicon Tundra,
Eden Prairie, Mn. 55344 -3718		| what could I know?