root@raider.MFEE.TN.US (Bob Reineri) (01/05/90)
I noticed the other day, while poking around with the 'file' command on Xenix 386 2.3.1, that many of the binaries are 8086 and 80286 files ! Things like grep, and find are 8086 junk. Could someone tell me, why on earth would SCO not simply recompile these things to take advantage of the 80386 ? SCO ?? I almost can't believe my eyes. This is quality control ? Bob -- * RaiderNet Public Access *Middle Tenn's Unix Gateway* Murfreesboro, TN * * Data:(615)896-8716 896-7905 Voice:(615)684-4490 Mail:PO Box 2371 Zip 37133 * * Domain: root@raider.MFEE.TN.US UUCP: uunet!knuth!raider!root HAM: N4CDO *
rodeen@buddha.UUCP (Rick Odeen) (01/07/90)
In article <165@raider.MFEE.TN.US> root@raider.MFEE.TN.US (Bob Reineri) writes: >I noticed the other day, while poking around with the 'file' command on Xenix >386 2.3.1, that many of the binaries are 8086 and 80286 files ! Things like >grep, and find are 8086 junk. > >Could someone tell me, why on earth would SCO not simply recompile these things >to take advantage of the 80386 ? SCO ?? I almost can't believe my eyes. This is >quality control ? An interesting side note to this.. Recently there was discussion on the net about the lack of a 2.3.2 Xenix 286 version of the C. Well, the latest upgrade of the 2.3.2 Xenix 386, the 286 and dos cross development compiler is compiled for the 286. Hmmmm. -- Rick Odeen buddha!rodeen@umn-cs.cs.umn.edu Nutrition Coordinating Center AT&T: +1 612 627 4884 University of Minnesota
brothers@jetsun.WEITEK.COM (bill brothers) (01/09/90)
In article <165@raider.MFEE.TN.US> root@raider.MFEE.TN.US (Bob Reineri) writes: >I noticed the other day, while poking around with the 'file' command on Xenix >386 2.3.1, that many of the binaries are 8086 and 80286 files ! Things like >grep, and find are 8086 junk. > >Could someone tell me, why on earth would SCO not simply recompile these things >to take advantage of the 80386 ? SCO ?? I almost can't believe my eyes. This is >quality control ? > It is pretty simple: If it works, don't fix it. There are many utilities that will never need more data space, etc. Besides, anytime you touch a program it tends to break. An added benefit-- You don't have to have a somebody run 47 tests on the program if it hasn't changed. It was a concious, deliberate decision process on which programs to migrate to higher planes. Just because the module is marked 386 doesn't make it any better program than 8086. It just means it won't run on older platforms. Bill Brothers ISV Support Specialist brothers@weitek.COM {sun, pyramid}!weitek.COM!brothers >Bob >-- >* RaiderNet Public Access *Middle Tenn's Unix Gateway* Murfreesboro, TN * >* Data:(615)896-8716 896-7905 Voice:(615)684-4490 Mail:PO Box 2371 Zip 37133 * >* Domain: root@raider.MFEE.TN.US UUCP: uunet!knuth!raider!root HAM: N4CDO *
scott@bbxsda.UUCP (Scott Amspoker) (01/10/90)
In article <857@jetsun.WEITEK.COM> brothers@jetsun.WEITEK.COM (bill brothers) writes: >>Could someone tell me, why on earth would SCO not simply recompile these things >>to take advantage of the 80386 ? SCO ?? I almost can't believe my eyes. This is >>quality control ? >> > >It is pretty simple: If it works, don't fix it. There are many utilities >that will never need more data space, etc. Besides, anytime you touch a >program it tends to break. An added benefit-- You don't have to have a >somebody run 47 tests on the program if it hasn't changed. It was a >concious, deliberate decision process on which programs to migrate to >higher planes. Just because the module is marked 386 doesn't make it any >better program than 8086. It just means it won't run on older platforms. I'll second that. At first glance it seems like the proper thing to do just to keep everything nice and tidy. But when you have as many different environments to support as SCO, recompiling/testing/imaging the 'cat' command for no worthwhile reason would be rather low on the priority list. In the long run this probably improves quality control as well as keep the price down. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/10/90)
In article <857@jetsun.WEITEK.COM> brothers@jetsun.WEITEK.COM (bill brothers) writes: | In article <165@raider.MFEE.TN.US> root@raider.MFEE.TN.US (Bob Reineri) writes: | > [ ... ] | >Could someone tell me, why on earth would SCO not simply recompile these things | >to take advantage of the 80386 ? SCO ?? I almost can't believe my eyes. This is | >quality control ? | > | | It is pretty simple: If it works, don't fix it. There are many utilities | that will never need more data space, etc. They do the same thing with troff, too. They charge you for the "386 version" of troff, and then deliver an 8086 version which has not been updated to make it run with ksh. I reported the ksh problem four bloody years ago and sent them the diffs to fix it! Now they offer to sell me Elan, which they say *is* compiled for 386. However, not only do they charge more than Elan for the same product, but if you want man pages which come with their (8086) troff package, you can buy the whole troff all over again for $400. The man pages don't seem to be available as a separate product. Interestingly enough the troff with (another vendor's) UNIX, which *is* a 386 executable, runs about 50% faster. Some vendors care about their troff/nroff users, I guess. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
peter@ficc.uu.net (Peter da Silva) (01/10/90)
> >It is pretty simple: If it works, don't fix it. ...
But given the number of things in Xenix implemented as shell scripts, isn't it
reasonable to expect that having a bunch of programs running in emulation
mode, chopping up the bus with unaligned and byte-sized requests, would tend
to have a negative impact on the overall performance of the system?
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>
\_.--._/
v "Have you hugged your wolf today?" `-_-'usenet@carssdf.UUCP (UseNet Id.) (01/10/90)
In article <535@bbxsda.UUCP>, scott@bbxsda.UUCP (Scott Amspoker) writes: > >>Could someone tell me, why on earth would SCO not simply recompile these things > >>to take advantage of the 80386 ? SCO ?? > >somebody run 47 tests on the program if it hasn't changed. It was a The one utility that I think would benefit considerably from an environment free of 64K boundaries is the sort. Can any of theses people that analyze the passage of programs to higher forms tell me if any significant improv- ments have been made with sort? John Watson ...!rutgers!carssdf!usenet
palowoda@fiver.UUCP (Bob Palowoda) (01/11/90)
From article <857@jetsun.WEITEK.COM>, by brothers@jetsun.WEITEK.COM (bill brothers): > In article <165@raider.MFEE.TN.US> root@raider.MFEE.TN.US (Bob Reineri) writes: >>I noticed the other day, while poking around with the 'file' command on Xenix >>386 2.3.1, that many of the binaries are 8086 and 80286 files ! Things like >>grep, and find are 8086 junk. >> >>Could someone tell me, why on earth would SCO not simply recompile these things >>to take advantage of the 80386 ? SCO ?? I almost can't believe my eyes. This is >>quality control ? >> > > It is pretty simple: If it works, don't fix it. There are many utilities > that will never need more data space, etc. Oh bull hockey. If I buy a 386 version of UNIX or Xenix I expect everything to be compiled in the native compiler. I don't want to get in the arguement that some programs will benefit form better performance or not. One I doubt will ever know, SCO more than likely will never release a complete 386 Xenix package. Two I disagree with preformance claims made by the companys themself. If they break it I see no reason why they can't fix it. That's what you pay them to do when you upgrade right? > Besides, anytime you touch a > program it tends to break. An added benefit-- You don't have to have a > somebody run 47 tests on the program if it hasn't changed. Who's benefit are we takeing about? Besides a good QA department should have this automated. > It was a > concious, deliberate decision process on which programs to migrate to > higher planes. Just because the module is marked 386 doesn't make it any > better program than 8086. It just means it won't run on older platforms. True, but it would be nice to see some third party vendors that compared a complete 386 compiled version to a 286 compilied version. Also some of the file size comparisons, etc. ---Bob -- Bob Palowoda pacbell!indetech!palowoda *Home of Fiver BBS* login: bbs Home {sun|daisy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB Voice: (415)-623-7495 Public access UNIX XBBS