Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!chinacat!chip From: chip@chinacat.Unicom.COM (Chip Rosenthal) Newsgroups: comp.unix.xenix.sco Subject: Re: Bugs Message-ID: <1971@chinacat.Unicom.COM> Date: 30 Apr 91 16:08:14 GMT References: <1991Apr29.172335.573@sbcs.sunysb.edu> Organization: Unicom Systems Development, Austin, TX Lines: 102 In article <1991Apr29.172335.573@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: >Here's some bugs I've noticed in xenix 2.3.2. I'm posting them to see if >others have them and to see if they've been fixed (there's a version 2.3.3 out >now yes?). There actually has been a 2.3.3 for a while. If you installed VP/ix onto 2.3.2 the included kernel updates gave you what was called 2.3.3. The free xnx155b SLF also results in a kernel level 2.3.3. I talked to SCO yesterday and was told that 2.3.4 started shipping last week, and an upgrade should be available in a week or so. The most exciting part about 2.3.4 is that it includes ksh. Unless the update is outrageously priced, it should be worth it just to get ksh. >- Ultra Rogue core-dumps when you use a scroll of electrification in a room > where monsters sponaneously get created. Every screen-orientated adventure game SCO has ever shipped has had bugs which could dump core. If you just consider it part of the game, i.e. a spell of instant dungeon decimation trap, it adds to the game :-) >- 'badtrk' says: "couldn't malloc" when I try to do a "thorough scan" on > 200MB and 380MB disks. Is this because I only have 4MB of ram? (I did > allocate the maximum space on the disk for badtrk when I installed xenix) Known problem. Fixed by the xnx155b SLF. >- If you use '-ltermcap' in cc and use tgetent and friends you'll find that > a function "bclr" is missing $ nm /lib/386/Slibtermcap.a | grep bclr || echo not there not there $ grep rel= /etc/perms/dsmd #rel=2.3.2f Nothing calls bclr() in my termcap library?? >- Many things are screwed up with the /usr/include files. My two biggest problems with the include files are the broken strerror() in string.h, and redefinitions. I hate header files including other header files. What's so sad is that finally, after years of mucking around, SCO has a correct definition for NULL in the XENIX header files, but broke it again with the UNIX development system. >- Stop trying to be SYSV and BSD at the same time! (just like HPUX). Just > pick one... This isn't fair. If you go back a few years, before SysVr3.2 was a reality for 386 boxen, SCO XENIX really provided you the best of both worlds. You had HDB uucp, and you had the dbm libraries. Furthermore, SCO seemed to be headed towards tightening things up. Look at the note on the telinit man page sometime. Somehow, I now doubt that `a full integration of these two approaches' will ever happen in XENIX. As they say, if you want System V you know where to go. >- Although it was supposed to be fixed in this version, I still have trouble > with parallel printers with no (or small) buffers printing very slowly. I do think this is more likely due to lost interrupts rather than a small buffer problem. You might want to try xnx155b and see if that fixes it. If not, SCO does provide minor device numbers for polled printer devices. That would probably also fix the problem. I seem to recall that these minor numbers are documented in the release notes. >So. Are any of these fixed in recent versions? What should I expect with >SCO UNIX? I think some of the complaints are either unfair (e.g. be SysV or BSD) or fixed (badtrk'ing big disks). Others truly are problems (e.g. the crappy Microsoft cc optimizer). Some are fixed in xnx155b. Given that it's free, doesn't it makes sense to install it? (Hold that thought for a moment...) I think SCO UNIX does address most of the other issues, or at least as well as any SysV/386 does. I would not be surprised if the optimizer bugs remain with the default compiler (again Microsoft). You do get the AT&T compiler as well. There are two things to be aware of with xnx155b. First, as mentioned here recently, if you've got a system name with >7 chars, uucp is going to break. (The fix is simple - see my note of a few days back.) Second, one of the xnx155b enhancements is better memory parity error checking. If you have a system which would get flaky from time to time with earlier releases, you might see hard panics instead with xnx155b. I have run into two systems which crapped out under xnx155b. One was chinacat - and putting in a better power supply fixed the problem. One was a client machine. They are running a full blown system (8MB RAM, two 150MB ESDI's, 150MB tape, and a CompuCrap serial card) all in Compaq with a teeny 150W power supply. Anytime you tried to start the tape motor the machine would panic. Unfortunately, the Compaq power supplies aren't the usual form factor, so it isn't just a matter of dropping in a heftier supply. I told them they needed to get either a new machine or an external case for some of these peripherals. Their solution was to instead fire me and hire another consultant who down-leveled them to 2.3.2. Caveat hacker. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. |