Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bbncc5.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!bbnccv!bbncc5!sdyer
From: sdyer@bbncc5.UUCP (Steve Dyer)
Newsgroups: net.unix,net.unix-wizards,net.micro
Subject: Re: Re: Binary Compatibility 80286
Message-ID: <853@bbncc5.UUCP>
Date: Thu, 24-Oct-85 14:55:30 EDT
Article-I.D.: bbncc5.853
Posted: Thu Oct 24 14:55:30 1985
Date-Received: Sat, 26-Oct-85 04:06:47 EDT
References: <248@omen.UUCP> <10764@ucbvax.ARPA> <175@maynard.UUCP> <2380@brl-tgr.ARPA>
Organization: Bolt Beranek and Newman, Cambridge, MA
Lines: 31
Xref: watmath net.unix:6023 net.unix-wizards:15429 net.micro:12484

> No, we're not.  Those of us who think of UNIX as an
> operating system and not as a marketplace appreciate
> its freedom from machine architectural constraints.

Blather, blather.  Can we please discuss some issues based on facts rather
than this kind of irrelevant knee-jerk rubbish?  The particular problem
here does not concern itself with constraints imposed by a machine
architecture; rather we're discussing the often needlessly arbitrary
software interface architectures chosen for implementations of UNIX on the
same machine architecture.  It's hard to discount the problems which have
been mentioned so far, unless one chooses to ignore the problem entirely,
as Mr. Gwyn does.  I wonder why he chooses to comment at all?

> This need not even imply running the particular target
> systems; cross-targeted software generation systems can
> be used.  I routinely compile code for my DMD on a host
> with a totally different architecture.

Yeah, and where do you test it? :-) (Seeing that you're from the Ballistic
Research Lab, maybe I'd better remove that smiley-face!)  It's hard to
ignore the fact that different test environments are needed for different
versions of UNIX, even those which are based on the same chip.  One might
not compile a system on the target, but it needs to be tested on the target
if it is to be considered a professional package.  In a sense, this
underscores the point that binary compatibility isn't a panacea by any
means.  But the benefits mentioned before (packaging, economies of scale,
source and binary control, convenience of development) still hold.
-- 
/Steve Dyer
{harvard,seismo}!bbnccv!bbncc5!sdyer
sdyer@bbncc5.ARPA