sinclair@chaos.cs.brandeis.edu (Chester Sinclair) (04/20/91)
Hello. I am looking for a UNIX (tm) environment for my 80386-based PC. I am considering buying IBM Xenix version 2.0 (because I can get a good price on it!), and am looking for any users' input on this Xenix. Some questions: Will this Xenix take advantage of the power of a 386 cpu? Does it include graphics drivers for pc video (SVGA) (I am hoping to run X) Does it include a c compiler (I assume it MUST! :-) Any general comments/observations/criticisms will be a *great* help! Thanks much for any input (please reply by email)! cheers, -- ----------------------------------------------------------------- David A. Sinclair - "Chester" | Bobby Fischer doesn't *want* sinclair@chaos.cs.brandeis.edu | you to know where he is. -----------------------------------------------------------------
bill@bilver.uucp (Bill Vermillion) (04/24/91)
In article <1991Apr20.003949.585@news.cs.brandeis.edu> sinclair@chaos.cs.brandeis.edu (Chester Sinclair) writes: >Hello. I am looking for a UNIX (tm) environment for my 80386-based >PC. I am considering buying IBM Xenix version 2.0 (because I can get >a good price on it!), and am looking for any users' input on this >Xenix. >Some questions: >Any general comments/observations/criticisms will be a *great* help! I had to use this at a site about 4 or 5 years ago. Many things were broken in it. I specifically remember that in the ioctl area you could not 'and' values with existing values, you had to set them explicity. Also the creat call wouldn't use it's arguments properly. Code that worked on other systems would break on this one. I wouldn't recommend this unless you want a lot of frustration. On the other hand, their manuals were some of the nicest I have seen. :-) / 2 bill -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
peter@ficc.ferranti.com (Peter da Silva) (04/25/91)
In article <1991Apr24.051935.17997@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: > I specifically remember that in the ioctl area you could not 'and' > values with existing values, you had to set them explicity. I can't parse this. Could you explain? > Also the creat call wouldn't use it's arguments properly. Details? I believe IBM Xenix 2.0 is based on System III, so you might just be seeing older behaviour and interpreting it as being broken. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
bill@bilver.uucp (Bill Vermillion) (04/26/91)
In article <FEZAY05@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Apr24.051935.17997@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >> I specifically remember that in the ioctl area you could not 'and' >> values with existing values, you had to set them explicity. >I can't parse this. Could you explain? Hm. I must be talking in shorthand again. Now this is from memory, and it was about 4 years ago. I wrote the code on uPort's SysV.2 and ported it to the IBM Xenix box. (the code also ran on SCO Xenix). I was saving the state of a tty and then setting new values. In fact I was using the Bach book as a guideline, as I was trying to talk to a radio modem. I just looked for the sources and can't find them handy. Probably stored on some disk somewhere. This was a couple of machines ago. In the ioctl area I was taking the state of the tty and anding with something like. newtty.c_(someflag) &= (somevalue). This worked on both the uPort and SCO but failed on IBM. After setting two machine up side by side, running the code and then doing a stty <that_terminal we found that the new values were being anded with the original values on uPort and SCO, but the new values were replacing the old values on the IBM version. It did not work as documented. Took some hairpulling to find that one. >> Also the creat call wouldn't use it's arguments properly. > >Details? > Later on, same machine and same program, we were taking the values that were coming in continually from the radio modem, and writing them to files. These modems were battery power, and perhaps had solar recharge. They were used to send transmissions from oil pipeline transmission stations out in the boonies back to civilization. Using the creat call like this fd = creat("file",0666) The file wasn't being created with those permissions. This time we found that the creat call was being anded with the permissions of the user running the progam. So to get around this one we save umask, set umask to 000, ran the program, and restored umask. This code ran fine on the two other machines. I just couldn't figure out what I was going wrong, because it would work away from the site and not at the site. The "desperation attempt" of bringing in the other machine was what pointed out the problem. The only other thing that ever go me as bad was working on an old Z8000 based machine with Unix III, whose compiler would NOT strip the high bits on incoming serial from serial device metering delivery on a propane truck. Believe the machine was an Onyx if memory serves. This one would sign extend all the odd (or perhaps it was even) characters from a 7bit to 16 bits with the high bit set. So every other character in the set was a negative number >I believe IBM Xenix 2.0 is based on System III, so you might just be >seeing older behaviour and interpreting it as being broken. Okay - now that I have described it, was it broken or older behaviour. I suspet the former. I remember being at one of the introduction of Xenix 2, and IBM was proud of the fact that is was "supported". Xenix 1.0 was issued as is, no support. No nothing. As I mentioned in the preivious post however, their manuals were among the nicest. Multi color printing and the order and action of all the switches was diagramed. Very nice. The AIX manuals I have seen are similar in concept but much more poorly executed. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
peter@ficc.ferranti.com (Peter da Silva) (04/30/91)
In article <1991Apr26.001231.4238@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: > In the ioctl area I was taking the state of the tty and anding > with something like. > newtty.c_(someflag) &= (somevalue). > This worked on both the uPort and SCO but failed on IBM. After setting two > machine up side by side, running the code and then doing a stty > <that_terminal we found that the new values were being anded with the > original values on uPort and SCO, but the new values were replacing the old > values on the IBM version. It did not work as documented. Took some > hairpulling to find that one. I'd have to see the code, but from your description it sounds like you had a problem with the code, or a bug in the compiler. > fd = creat("file",0666) > The file wasn't being created with those permissions. This time we > found that the creat call was being anded with the permissions of the > user running the progam. So to get around this one we save umask, set > umask to 000, ran the program, and restored umask. But that's what it's supposed to do! I suspect your other machines were just configured so that umask wasn't getting in your way. On creat, umask is always complemented and anded with the mode. > The only other thing that ever go me as bad was working on an old Z8000 > based machine with Unix III, whose compiler would NOT strip the high bits > on incoming serial from serial device metering delivery on a propane truck. > Believe the machine was an Onyx if memory serves. > > This one would sign extend all the odd (or perhaps it was even) characters > from a 7bit to 16 bits with the high bit set. So every other character in > the set was a negative number But that's what it was supposed to do. If you're working with signed characters (default on many machines, including the Z8000 and 80x86!) and converting them to integers then it's suposed to sign extend. Program the following sequence in your wetware: i = (((int) c) & 0xFF); It's a lot of work to write portable (as opposed to ported) code, but it's worth it. For one thing all sorts of "bugs" in the O/S tend to vanish. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
scott@clmqt.marquette.Mi.US (Scott Reynolds) (04/30/91)
In article <FZ+AP5@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Apr26.001231.4238@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >> In the ioctl area I was taking the state of the tty and anding >> with something like. >> newtty.c_(someflag) &= (somevalue). >> This worked on both the uPort and SCO but failed on IBM. >I'd have to see the code, but from your description it sounds like you had >a problem with the code, or a bug in the compiler. I'd have to see that code, also. The system I am using to post this article from is running IBM XENIX 2.0 and it doesn't have any problem with code of the sort you're talking about here; perhaps that was a bug in the 1.0 release, but not this one. The area that I _have_ had a lot of problems with is the curses library, but certainly not the standard library. The compiler also has a few minor problems, some of which were addressed in the maintenance releases; perhaps the (somevalue) expression wasn't very portable, but I can't be sure. IBM used the Microsoft 3.0 release, which is a System V.something derivative. I can always get stuff written for Vr2 to work, and most Vr3 stuff to work, provided I don't have any massive memory requirements to work around. -- scott@clmqt.marquette.MI.US | Scott Reynolds - + - Enterprise Information System | Revive us, oh Lord! |
bill@bilver.uucp (Bill Vermillion) (05/04/91)
In article <FZ+AP5@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Apr26.001231.4238@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >> The only other thing that ever go me as bad was working on an old Z8000 ..... >> Believe the machine was an Onyx if memory serves. >> This one would sign extend all the odd (or perhaps it was even) characters >> from a 7bit to 16 bits with the high bit set. So every other character in >> the set was a negative number >But that's what it was supposed to do. If you're working with signed characters >(default on many machines, including the Z8000 and 80x86!) and converting >them to integers then it's suposed to sign extend. On that one the code that worked on the 80386 did NOT work on the Z8000. I also had the c_iflag set with ISTRIP to stip all incoming chars to 7 bits. The compiler on the Z8000 wouldn't, but the one on the 80386 would. I had other people look at it too, and it was only when we started monitoring the bit stream we found it. > >Program the following sequence in your wetware: > > i = (((int) c) & 0xFF); > >It's a lot of work to write portable (as opposed to ported) code, but it's >worth it. For one thing all sorts of "bugs" in the O/S tend to vanish. True. I will remember that. That line is about what I ended up with. The problem arose when the "serial device" program was being written on the 80386 machine, and then the code wouldn't run when ported to the other. The way I read the manual, ISTRIP should have returned a 7bit that should not have 8th bit set. But when 8th bit was set, so would bits 9 thru 16. If c_iflag has ISTRIP set, and it passed the 8th bit wouldn't you consider that a compiler bug.? -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
peter@ficc.ferranti.com (Peter da Silva) (05/07/91)
In article <1991May4.001619.13489@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: > The way I read the manual, ISTRIP should have returned a 7bit that should > not have 8th bit set. But when 8th bit was set, so would bits 9 thru 16. > If c_iflag has ISTRIP set, and it passed the 8th bit wouldn't you consider > that a compiler bug.? No, I would consider that a device driver bug. The compiler has nothing to do with ISTRIP. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"