Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!att-ih!ihnp4!ho95e!wcs
From: wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>)
Newsgroups: comp.unix.wizards
Subject: Re: Binary standards for UNIX
Message-ID: <2050@ho95e.ATT.COM>
Date: 9 Mar 88 04:32:08 GMT
References: <1636@tulum.UUCP> <3168@phri.UUCP> <497@taux01.UUCP> <1588@thorin.cs.unc.edu>
Reply-To: wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 24
Keywords: ABI

In article <497@taux01.UUCP> yuval@taux01.UUCP (Gideon Yuval) writes:
>The new ABI standard, which is supposed to be the Unix standard for object-code
>distribution, is (a variation of) COFF for SPARC. How much hardware-indpendence
>is going to survive the changeover to ABI?

You're mixing up the AOE Application Operating Enviroment work with the
ABI Application Binary Intersomething standard.  ABI basically requires
that all Sparc object code be compatible, just as similar work is going
on for the 386 and 680[23]0 worlds.  What this means is that if you
develop code on one brand of sparc-machine, you won't have to recompile
and re-port for each other brand of machine out there.  Today in the
680*0 world, you can't do this; if two 68000-box hardware vendors got
their UNIX OS ports from different software vendors, you probably can't
share binaries, so supporting multiple machines costs you a lot more.

This is the big strength of the MS-DOS world - if you stick to a
reasonable set of assumptions, your software will work on almost every
clone out there, without you having to buy the boxes and test them.
This makes it easy to reach a large market for your applications, so
you can afford to develop good applications.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our profilers and debuggers and editors and various other
# implements of destuction and went off to clean up the tty driver...