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