crisp@mips.COM (Richard Crisp) (11/20/90)
I am curious if someone out there can shed some light on how Apple might continue to support their toolbox scheme for dealing with hardware and yet offer an 88open ABI compliant system assuming they are building an 88K based Macintosh. Not being an expert in programming or the Mac or the 88K, maybe I'm missing something, but it would appear to me that they would be able to do one or the other; not both. -- Richard Crisp crisp@mips.com MIPS Computer Systems !decwrl!mips!crisp 928 Arques MS 2-02 (408) 524-8177 Sunnyvale, Ca 94086
geranen@phx.mcd.mot.com (Scott Geranen) (11/22/90)
In article <43399@mips.mips.COM> crisp@mips.COM (Richard Crisp) writes: >I am curious if someone out there can shed some light on how Apple might >continue to support their toolbox scheme for dealing with hardware and >yet offer an 88open ABI compliant system assuming they are building >an 88K based Macintosh. Not being an expert in programming or the Mac >or the 88K, maybe I'm missing something, but it would appear to me that >they would be able to do one or the other; not both. > The 88open ABI, a.k.a. BCS, defines the lowest common denominator for compliant systems. An application that uses only BCS system calls will execute on any BCS certified platform. Currently, the basic operating system, networking, and X11R3 are defined by the BCS. Apple could make a BCS compliant system that includes toolbox support. An application written to use the toolbox would probably not run on any other vendor's hardware. However, any BCS certified application would still run on the 88k Mac. Disclaimer: I have no idea if Apple is working on an 88k Mac, I'm just trying to make a point. Motorola's BCS compliant systems have several system calls that are not in defined by the BCS, but it is BCS compliant none the less. -- Scott Geranen geranen@phx.mcd.mot.com
guy@auspex.auspex.com (Guy Harris) (11/30/90)
>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
calls to a dynamically-linked shared library - in other words, while a
BCS, in effect, says "the way you get the password database entry for a
user is that you do an 'open' call on '/etc/passwd', which is a file in
thus-and-such a format, and scan it for a line with that user's login
name", an ABI says "the way you get the password database entry for a
user is that you call 'getpwnam()' with the user's login name as an
argument".
(In other words, one ABI-conformant system could implement "getpwnam()"
by scanning "/etc/passwd", another could implement it with a BSD-style
"ndbm" database, another could use the ONC NIS (formerly known as YP),
another could use the NCS Registry, and another could use Project
Athena's Hesiod, and any ABI-conformant application would, when run on
any of those systems, use whatever implementation that system provided.
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.)
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)....ron@motmpl.UUCP (Ron Widell) (12/05/90)
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?