Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news.idt.net!mr.net!newshub.tc.umn.edu!fu-berlin.de!news.belwue.de!news.uni-ulm.de!borchert From: borchert@turing.mathematik.uni-ulm.de (Andreas Borchert) Newsgroups: comp.unix.solaris,comp.unix.bsd.misc,comp.unix.internals,comp.unix.osf.osf1 Subject: Re: Solaris 2.6 Date: 3 Dec 1996 18:06:49 GMT Organization: University of Ulm, SAI, Germany Lines: 97 Distribution: inet Message-ID: <581q7p$klv@arktur.rz.uni-ulm.de> References: <x7917mx5gx.fsf@dumbcat.codewright.com> <57shh0$o3u@web.nmti.com> <57ui72$4li@arktur.rz.uni-ulm.de> <5811fl$gj4@usenet.pa.dec.com> NNTP-Posting-Host: turing.mathematik.uni-ulm.de X-Newsreader: slrn (0.9.0.0 (BETA) UNIX) Xref: euryale.cc.adfa.oz.au comp.unix.solaris:91386 comp.unix.bsd.misc:1675 comp.unix.internals:11450 comp.unix.osf.osf1:16846 On 3 Dec 1996 11:04:21 GMT, Burkhard Neidecker-Lutz <neideck@kar.dec.com> wrote: > In article <57ui72$4li@arktur.rz.uni-ulm.de> borchert@turing.mathematik.uni-ulm.de (Andreas Borchert) writes: > >There may be arguments how the transition is done best. But DEC > >is surely not a good example for binary compatibility: Not that > >they only are trying to support multiple OSes they also offer multiple > >hardware platforms as well. > > We are an excellent example of binary compatibility. Even *with* > changing hardware architecture we have provided ways of using > old binaries on newer platforms. The change from Ultrix (32-bit little > endian MIPS to 64-bit Alpha) was supported by binary translation that > helped me at least to run packages as complex as Framemaker for years. You may have done some excellent work for some of the transitions but it is impossible (at reasonable cost) to provide such paths for all combinations which may arise from such a huge number of OSes and hardware platforms. And companies with such a large number of variants are more likely to stop the developments of one of these variants if the associated market share shrinks. Believe me, it was quite hard for us to say good bye to our good old PDP11s :-) So, it was a more general argument which came into play when Peter da Silva compared Sun against DEC. Similar problems hold for IBM (was there an initial upgrade plan for the first RISC architecture to the RS/6000 architecture?) or HP (if I understand it correctly, they plan now to stop the further development of the HP-PA). > > The future > >of Sun is bound to SPARC and Solaris (which is at least now > >binary compatible to the previous versions) and customers trust on this > >(at least we do). > > Sun didn't even manage to be binary compatible on the *same* hardware > platform until Solaris 2.4 (at least we had major trouble here with > our SUNos 4.1.x stuff on all version from Solaris 2.0-2.3. Well, Sun did never state that the earlier releases were fully binary compatible. They explicitly said that just binaries which rely on shared libraries will work (I know there have been some exceptions, though). At the same time, Sun was still developing SunOS 4.1.x and there was no need to do the transition earlier as necessary. Like many other sites, we decided to install Solaris 2.x on new machines only and to continue SunOS 4.1.x on the older machines for some time. Consider the early Solaris releases as an opportunity of a long-term preparation and Solaris 2.0 was surely not meant as an immediate replacement of all SunOS 4.1.x installations. And, yes, Sun was able to learn from its customers that there is a larger need in binary compatibility than initially expected. > >Sun at least tries to think carefully about its customer needs. > > Such as in the Sun 3 to Sun4 transition ? Indeed, this was a hard transition. But Sun had just two hardware platforms now (despite the minor architecture variants and yes, I exclude the more experimental road runner, and the hardware which is supported by SunSoft but not sold by Sun does not count here). Is is clearly seen that Sun has a completely different policy than most of its competitors. Instead of offering a huge number of solutions they offer fewer system variants but with more support (compare, for example, the Ultrix development with SunOS [34].x) and continuation. This is a quite natural policy for late-coming competitors -- remember that IBM, HP and DEC are far much older than Sun. > Such as in the introduction > of 64-bittedness in Solaris past 2.5 which will sure spell fun for any > machine that doesn't have an UltraSparc in it ? Or are you going to > do all the 64-bit APIs via code that will also run backward compatible > on 32 bit machines ? If I understand Casper correctly (after all, I do not run Solaris 2.6 yet), you will still be able to generate code on these machines which will run not only on the whole hardware range of Sun but also on earlier versions of Solaris. As explained earlier, you can give compilation flags (preprocessor defines) which specify whether the code should use the 64-bit variants of the system calls or the older ones. An application which contains references to 64-bit system calls will not run on older releases (as long you don't add a backward compatibility library). But is is quite natural that you are able to generate binaries on newer releases which are not backward-compatible. You will come into trouble only if you are enforced to use older releases to generate code for them -- but this is obviously not the case. And, Sun didn't propose the new interface on its own but in cooperation with a large number of other companies including DEC (see http://www.sas.com/standards/large.file/x_open.20Mar96.html). Andreas. -- Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm, Germany E-Mail: borchert@mathematik.uni-ulm.de WWW: http://www.mathematik.uni-ulm.de/sai/borchert/ PGP key available via ``finger borchert@laborix.mathematik.uni-ulm.de''