Bugs

[Chip Rosenthal]

In article <1991Apr29.172335.573 at sbcs.sunysb.edu>
	jallen at 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.
<chip at chinacat.Unicom.COM>    |