Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: ABIs and the futurrrr of UNIX(tm) Message-ID: <7534@brl-smoke.ARPA> Date: 23 Mar 88 22:32:41 GMT References: <431@micropen> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 45 Keywords: ATT SPARC ABI UNIX In article <431@micropen> dave@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.