jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (04/30/91)
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?).
- Ultra Rogue core-dumps when you use a scroll of electrification in a room
where monsters sponaneously get created. This is really the most significant
bug I've discovered :-)
- '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)
- Using '-Ox' in cc is very very broken. Here are some examples:
for(x=10;x;x--) a[x]=b[x];
This gets optimized to a "rep movsb" and is set up to do
a reverse move but doesn't generate a 'std'.
do { f(j); j=0; } while(--x);
This gets optimized to:
j=0; do f(j); while(--x);
Which is quite wrong (actually I think it does this one
even with just -O)
- If you use '-ltermcap' in cc and use tgetent and friends you'll find that
a function "bclr" is missing (tgetent works if you provide a block clear
function yourself: bclr(char *block,int size))
- Many things are screwed up with the /usr/include files. I fixed these
myself so I don't remember all the problems exactly.
- Reliable signals were added, but nothing generates SIGIO (there's no
ASYNC flag for fcntl or open).
- I know this is a problem with UNIXs in general, but since SCO tried to
fix this problem partially, I'd like to prompt them to finnish the job.
The basic problem is that there's no consistancy or compatibily between the
different I/O methods. For example, there's file I/O, events, message
passing, signals and the beginnings of streams. I would be happy if each of
these I/O methods could generate either a signal, a message or an event.
Since they don't, I have to use forks (big 'threads') and message passing if
I want to wait for a clock tick, a keypress and IPC from my database server
all at the same time. And that has problems because you can't search
through messages (to pick the one you want) and because message queues and
buffers easily overflow.
- There seems to be shared libraries (/bin/shlib) but no documentation for
it.
- Stop trying to be SYSV and BSD at the same time! (just like HPUX). Just
pick one...
- 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.
This crude printer driver fixes the problem (and allows me to cut & jumper
$10 printer boards so I can more than 3 printers on my system):
int ports[]= { 0x378, 0x3bc, 0x278, 0x278 };
ww(){}
llp(minor,c) /* Write character to port number 'minor' */
{
int x=0;
while(!(0x80&inb(ports[minor]+1))) if(x++==100) delay(1), x=0;
outb(ports[minor],c);
outb(ports[minor]+2,5);
for(x=0;x!=10;x++) ww();
outb(ports[minor]+2,4);
}
llwrite(minor) /* Device driver write function */
{
int x,c;
while(-1!=(c=cpass()))
{
if(c=='\n')
if(minor&4) c='\r';
else if(minor&8) llp(minor&3,'\r');
llp(minor&3,c);
}
}
minor device number: 0-3 is printer number, add 4 for LF to CR translation,
add 8 for LF to CR-LF translation. You'll have to rework the minor device
numbering scheme if you want more than 4 printers. Also, the delay loops
might have to increased if you use a 486 (works on 386SX - 33Mhz 386).
So. Are any of these fixed in recent versions? What should I expect with
SCO UNIX?
To be honest, I would very quickly switch to ESIX except for one feature that
SCO xenix has: A product called the "Unterminal" from Advanced Micro Research
lets me have more than one console (using normal IBM keyboards and displays).
This and KERMIT for the few real serial terminals I have solve many human
interface problems.
--
#define h 23 /* Height */ /* jallen@ic.sunysb.edu (129.49.12.74) */
#define w 79 /* Width */ /* Amazing */
int i,r,b[]={-w,w,1,-1},d,a[w*h];m(p){a[p]=2;while(d=(p>2*w?!a[p-w-w]?1:0:0)|(
p<w*(h-2)?!a[p+w+w]?2:0:0)|(p%w!=w-2?!a[p+2]?4:0:0)|(p%w!=1?!a[p-2]?8:0:0)){do
i=3&(r=(r*57+1))/d;while(!(d&(1<<i)));a[p+b[i]]=2;m(p+2*b[i]);}}main(){r=time(
0L);m(w+1);for(i=0;i%w?0:printf("\n"),i!=w*h;i++)printf("#\0 "+a[i]);}ronald@robobar.co.uk (Ronald S H Khoo) (04/30/91)
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > - 'badtrk' says: "couldn't malloc" Fixed in the xnx155b support level supplement. > - Using '-Ox' in cc is very very broken. Heh. Does it matter ? -Ox is "unsafe" anyway. It implies -Oa which will break perfectly good C code even if it worked perfectly. > - Reliable signals were added, but nothing generates SIGIO (there's no > ASYNC flag for fcntl or open). Well, that's two separate issues. At least, with the advent of reliable signals, the race condition in sleep(3) doesn't exist anymore. SIGIO's a nasty kluge anyway. Reliable signals, on the other hand, are rather vital -- I'm very grateful that they were added. > Since they don't, I have to use forks (big 'threads') and message passing if > I want to wait for a clock tick, a keypress and IPC from my database server > all at the same time. And that has problems because you can't search > through messages (to pick the one you want) and because message queues and > buffers easily overflow. Why not use pipes instead? Then you can select() on which pipe to read from (but you need the kernel fix in either xnx141 or xnx155b to make this work) -- yes, the Xenix select() is a real BSD select. > - There seems to be shared libraries (/bin/shlib) but no documentation for > it. To generate shared library applications, you'll need a Development System that can generate them. This means that you'll have to buy a COFF development system, like the SCO UNIX one. (Or use the reverse engineering kit that PGD posted a while back, maybe?). -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
chip@chinacat.Unicom.COM (Chip Rosenthal) (04/30/91)
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. <chip@chinacat.Unicom.COM> |
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (05/04/91)
In article <1991Apr30.103044.10663@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: Thanks for the information. Now I wonder why havn't I heard anything from SCO about these updates- I am registered. I guess they only give you fixes if you ask for them. I seem to remember that there's supposed to be a SCO uucp site. Are these fixes there, and if so, how do I contact the site? >> - Reliable signals were added, but nothing generates SIGIO (there's no >> ASYNC flag for fcntl or open). >Well, that's two separate issues. At least, with the advent of reliable >signals, the race condition in sleep(3) doesn't exist anymore. SIGIO's >a nasty kluge anyway. Reliable signals, on the other hand, are rather >vital -- I'm very grateful that they were added. The only problem with SIGIO (when it's implemented) is that you have to do a lot of polling after you get one. But "select", with its bit-maps, is also a nasty kludge. (now if only SIGIO passed the descriptor to the signal handler- but then I guess you'd have "tiny" messsage passing :-) >Why not use pipes instead? Because how do you make a pipe between unrelated processes? (Oops, no sockets and streams don't seem to be done (or at least they're not documented)) Also I've found that the message passing system calls are very fast (I don't have experience with streams but BSD sockets were always a bit slow). -- /* jallen@ic.sunysb.edu */ /* Amazing */ /* Joe Allen 129.49.12.74 */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
mike@bria.UUCP (mike.stefanik) (05/05/91)
In an article, jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: >I seem to remember that there's supposed to be a SCO uucp site. Are these >fixes there, and if so, how do I contact the site? [ excerpt from sosco!/usr/spool/uucppublic/info ] UUCP Connection information: Machine name: sosco Phone numbers: (408) 425-3502 (2 lines, 300-9600 baud V.32 standard) (408) 429-1786 (9600 baud Telebit) Login name: uusls (fourth character is the letter "l" rather than numeral "1") No password Below is a list of the Support Level Supplements available for UUCP request in the directory /usr/spool/uucppublic/SLS. The files ending in .Z have been reduced in size using the SCO XENIX compress(C) utility. These files must first be unpacked using uncompress(C). Files ending in .ltr are the cover letters and installation instructions for the corresponding Supplements. The cover letters assume you have received the Supplements on diskette. To install a Supplement, you must first transfer it to a diskette using this procedure: 1. Request UUCP to transfer to your system the SLS file and cover letter file for the desired supplement. When issuing the UUCP command, do not use wildcards or the ~ (tilde) character, as they will result in a "PERMISSION DENIED" error message. Also, be sure that the user "uucp" has write permission on the destination file and directory, and UUCP is allowed access to the destination directory by your local /usr/lib/uucp/Permissions file. 2. Expand the files if necessary using uncompress(C), or compress -u. 3. Format a diskette that is large enough to contain the supplement file. 4. Use the dd(C) command to transfer the supplement file to the diskette. For example, if the supplement file is "xnx102" and is in the /usr/spool/uucppublic directory on your system, and the diskette is a 5.25-inch, 360K, the command would be: dd if=/usr/spool/uucppublic/xnx102 of=/dev/fd048ds9 Substitute the appropriate device name for "/dev/fd048ds9" if transferring to a diskette of another capacity. However, always use the block device. The diskette must be formatted using the format(C) command before the data can be transferred. 5. Follow the installation instructions given in the cover letter file. -- Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- If MS-DOS didn't exist, who would UNIX programmers have to make fun of?
ronald@robobar.co.uk (Ronald S H Khoo) (05/07/91)
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > >Why not use pipes instead? > Because how do you make a pipe between unrelated processes? With the mknod command or system call, and the open system call. Named pipes have been in UNIX since System III at least. SCO Xenix documentation has a section on in in the "writing and using pipes" section of the Programmer's Guide. The pipe appears in the filesystem so anyone can open it. > Also I've found that the message passing system calls are very fast (I don't > have experience with streams but BSD sockets were always a bit slow). There is *zero* difference in speed between using pipes and using message queues. The reason is that the IPC overhead is completely swamped by the cost of the context switch. If you write a program that forks two processes, which does this: Process 1 Process 2 Send message Receive message Send message Receive message in a loop, you will find that the number of transactions that you can do in any given time frame is about the same no matter which IPC mechanism you use. Context switching in 386 Unixes is *AWFUL*. BAD BAD BAD. Terrible. You could do the IPC by carrier pigeon and and the transaction rate would *still* be the same. Ugh. <Shudder> This is probably a good reason to switch to Mach. Anyone want to volunteer some figures for this on Mach 386? > I seem to remember that there's supposed to be a SCO uucp site. Are these > fixes there, and if so, how do I contact the site? Machine name: sosco Phone numbers: (408) 425-3502 (2 lines, 300-9600 baud V.32 standard) (408) 429-1786 (9600 baud Telebit) Login name: uusls (fourth character is the letter "l" rather than numeral "1") No password Get the file /usr/spool/uucppublic/SLS/info. This information is posted here from time to time by SCO people. What they *don't* post is the fact that the file /usr/spool/uucppublic/SLS/descriptions is also a useful file to grab. The info file doesn't say so either. It might do in the future, I told the Nice Man[TM] from SCO about it last week when he came to visit. -- [TM] Nice Man may well be a trademark of the Automobile Association -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (05/12/91)
In article <1991May7.080724.3904@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: >> >Why not use pipes instead? >> Because how do you make a pipe between unrelated processes? >With the mknod command or system call, and the open system call. >Named pipes have been in UNIX since System III at least. >SCO Xenix documentation has a section on in in the "writing and using pipes" >section of the Programmer's Guide. The pipe appears in the filesystem >so anyone can open it. ! Oops, you're right. This leads to two questions: Why did they add message passing (which is very very ugly) when they already had an elegent IPC system? Why didn't I notice them? (the answer to the second question is that I'm used to BSD's sockets (which can be filesystem named) and since xenix didn't have sockets...) >> Also I've found that the message passing system calls are very fast (I don't >> have experience with streams but BSD sockets were always a bit slow). >There is *zero* difference in speed between using pipes and using >message queues. The reason is that the IPC overhead is completely >swamped by the cost of the context switch. If you write a program > Process 1 Process 2 > Send message > Receive message > Send message > Receive message >in a loop, you will find that the number of transactions that you can do in >any given time frame is about the same no matter which IPC mechanism you >use. Context switching in 386 Unixes is *AWFUL*. BAD BAD BAD. Terrible. >You could do the IPC by carrier pigeon and and the transaction rate would >*still* be the same. Ugh. <Shudder> Anyway, it's good that pipes at least arn't any _slower_ than message passing Mostly I solve this problem by: Process 1 --------- Send message 1 Send message 2 or Send big message 1 Send message 3 (task switch and) Receive message >This is probably a good reason to switch to Mach. Anyone want to >volunteer some figures for this on Mach 386? Here's the most important figure: Mach for 386 costs about $3000 And second most important figure: AMR's Unterminal doesn't work on it And third most important figure: it doesn't run Lotus 123 (er.. um.. SCO Professional) or Wordperfect -- /* jallen@ic.sunysb.edu */ /* Amazing */ /* Joe Allen 129.49.12.74 */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}