Path: utzoo!attcan!uunet!husc6!think!ames!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.unix.questions
Subject: Re: Splinter Unix?
Message-ID: <1011@cresswell.quintus.UUCP>
Date: 24 May 88 07:37:49 GMT
References: <556@n8emr.UUCP> <10650027@hpisod2.HP.COM> <236@pvab.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 19

In article <10650027@hpisod2.HP.COM>, decot@hpisod2.HP.COM (Dave Decot) writes:
> What is "Application Binary Interface"?  A marketing strategy.

Maybe, but there is also a very good technical reason: an ABI is actually a
lot easier to define (but still not easy) than a library-level standard.
I have seen two ABI drafts, which impressed me as solid and useful.  With
the aid of such a definition, it would be possible for someone to write a
Lisp compiler and run-time that didn't have a shred of C in them, yet would
still have access to POSIX calls, and would still be portable within that
class of machines.  In particular, a VAX ABI would permit someone to come
up with a new C compiler and library which used a more efficient calling
sequence.  Note that a system which can run applications which conform to
an ABI doesn't have to be able to do anything _else_ with such applications:
there is no need to provide a linker, disassembler, nm, strip, &c which
understands that format.  For example, given an M680x0 ABI, Interactive
Solutions could extend their kernel to run such things without having to
change else in their system, e.g. without having to fully support COFF.

Sounds to me as though everyone wins the ABI game.