ABIs and the futurrrr of UNIX(tm)

[Doug Gwyn]

In article <431 at micropen> dave at micropen (David F. Carlson) writes:
>What this
>in effect will say is that there are preferred hardware platforms for UNIX,
>the portable operating system, in that software vendors using popular ABI 
>platforms will be able to sell more software that those using perhaps
>technically superior but not a popular ABI would.  In turn, buyers will
>bypass a technically superior solution in favor of a popular ABI option
>solely because of binary interchange:  exactly why we rejected popular software
>platforms to choose UNIX in the first place.

I think you're drawing false conclusions, perhaps because you're working
from false premises.  There is no reason that other architecture families
could not also follow their own binary standards, and in fact there are
efforts underway to do so for some families, for example the 386.  The
only real significance for UNIX as such is that the porting base will
change from 3B2 to SPARC, which may result in the sale of a few more
Sun-4s to UNIX VARs but otherwise is of little consequence for most VARs.

Arguing that people will buy ABI products because it is to their benefit
to do so seems pretty strange -- of course they would.  There is much
more to system evaluation than "technical superiority", as witness the
IBM PC.

>Furthermore AT&T has announced that the VAX will no longer 
>be a primary port engine:  SUN's SPARC will be.

I'm afraid you're behind the times.  The porting base has been 3B2
for quite some time.

>No sooner than these ABIs 
>become real standards will vendors stop supporting non-ABI architectures.  

No, vendors will stop supporting architectures only when they cease to
be a significant segment of the market.  Even on the improbable
assumption that SPARC will take the world by storm, it would be many
years before it would substantially displace current architectures.

>COFF has conversion routines for correctly ordering big-endian vs. 
>little-endian data sections.

COFF files imported from a system with the wrong byte order are unusable.
I had to write a COFF converter to deal with this.  (The one AT&T has in
their SGS only works on the source machine, not on the destination.)
COFF also falls apart miserably on 64-bit machines etc.  It was a nice
attempt but it needs improvement.