Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!ukma!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: Why DEC doesn't need an ABI Message-ID: <8166@brl-smoke.ARPA> Date: 26 Jun 88 20:05:45 GMT References: <8185@ncoast.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 20 In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Thus, for DEC to register an ABI would be pointless, and if so doing would >create work for AT&T that would have no effect on portability then AT&T has >no reason to accept a VAX ABI. It's not at all pointless! The lack of COFF support on VAX 4BSD has caused me vast amounts of otherwise unnecessary extra work. Also, we have sometimes acquired libraries (e.g. for DBMS systems) from third- party vendors, but since they've been for native 4BSD, they haven't been usable with our applications that are developed in the System V (emulated) environment running on 4BSD, even though I went through the trouble of adapting our System V environment to use 4BSD object formats so that the library is at least linkable (that's not enough to guarantee that it works right). Based on such experience, I would say that a good object or binary standard would be of considerable practical value. Perhaps DEC tried to register a COFF- or SVID-incompatible format as part of the VAX ABI? That would be good grounds for AT&T rejecting it.