steven@lakesys.UUCP (Steven Goodman) (07/01/87)
In article <137@hobbes.UUCP> plocher@uwspan.UUCP (...!uwvax!geowhiz!uwspan!plocher) writes: >This started as a followup to a Microport question in the Xenix discussion >group, but evolved into this. There has been an even distribution of messages >in the comp.unix.xenix group between MicroPort System5 and Xenix. So far, the >content has been informative for both sets of users considering how Xenix is >leaning closer to System5 with every release, but in the interests of proper >classification there should really be a comp.unix.sys5. > I beg to differ on this. Xenix passes the SVID standards, thus making it a System V OS with another name. As far as I can see Xenix is a full implimentation of System V with some extras (SCO development contains dos/cross stuff etc...). To be abit more accurate on the naming of Xenix one might call it: Xenix System V Release 2. -- Steven Goodman Lake Systems Milwaukee, Wisconsin UUCP: {ihnp4,uwvax}!uwmcsd1!lakesys!steven -- Steven Goodman Lake Systems Milwaukee, Wisconsin UUCP: {ihnp4,uwvax}!uwmcsd1!lakesys!steven
root@hobbes.UUCP (John Plocher) (07/02/87)
+---- Steven Goodman writes the following in article <143@lakesys.UUCP> ---- | | Xenix passes the SVID standards, thus making it a | System V OS with another name. As far as I can see Xenix is a full | implimentation of System V with some extras ... | To be abit more accurate on the naming of Xenix one might call | it: Xenix System V Release 2. | -- | Steven Goodman +---- Does SVID address libraries? Xenix (By IBM for the AT) has no terminfo (termcap instead), incompatable header files, and a non-System 5 compiling environment (ie, it is a mix of what someone thought was the best of BSD and the best of Sys5. I could never be sure which system I was on. Makefiles which assumed either Sys5 or BSD didn't work correctly. I used it for 6 months before giving up on it. EVERY program I tried to compile needed modification - It wasn't quite System 5 and it wasn't quite BSD. I de-installed Xenix and brought up Microport System5. ALL the programs I had problems with under Xenix now compiled cleanly! (This was using the SAME base source code) What programs, you ask? News 2.10.x & 2.11, Larn, Hack, RCS... Hell, even uucp was broken. It only would allow full connections to other Xenix systems. Only after I changed to Sys5 did IBM inform us that there were problems with uucp... The cron system was all screwed up: The manuals were from BSD cron, the /etc/cron program was for Sys5 (indiv. crontabs) and the example crontabs on disk were BSD. Please tell me that this is just in IBM's port of Xenix - then I won't have this bad taste in my mouth forever! These problems have probibly been fixed by now, or at least worked around. I don't mean to flame (too much :-), but from my experiance with IBM's Xenix for the AT, I can't agree that it "is System 5". Sorry. John It did have a good point: It came with refer, diction, and style. I sure wish S5r2 did! -- * * * * Note email address change as of 7/1/87 * * * * John Plocher UUCP: <backbone>!uwvax!geowhiz!uwspan!plocher ============== Internet: plocher%uwspan.UUCP@uwvax.cs.Wisc.EDU FidoNet: 121/0 BITNET: uwvax!geowhiz!uwspan!plocher@psuvax1
karl@ddsw1.UUCP (Karl Denninger) (07/05/87)
In article <141@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes: > +---- Steven Goodman writes the following in article <143@lakesys.UUCP> ---- > | To be abit more accurate on the naming of Xenix one might call > | it: Xenix System V Release 2. > > Does SVID address libraries? Xenix (By IBM for the AT) has no terminfo > (termcap instead), incompatable header files, and a non-System 5 compiling > environment (ie, it is a mix of what someone thought was the best of BSD > and the best of Sys5. I could never be sure which system I was on. > Makefiles which assumed either Sys5 or BSD didn't work correctly. I used > it for 6 months before giving up on it. EVERY program I tried to compile > needed modification - It wasn't quite System 5 and it wasn't quite BSD. I > de-installed Xenix and brought up Microport System5. ALL the programs I ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > had problems with under Xenix now compiled cleanly! (This was using the SAME ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > base source code) > Please tell me that this is just in IBM's port of Xenix - then I won't > have this bad taste in my mouth forever! I have been seeing these postings for several months -- and until we got heavily into development work with Microport, I would have agreed with you. However, our latest projects as well as our (finally successful) attempt to establish a Usenet site on Microport have given me a better overall view of the situation. You've been misled by IBMs version. Let me tell you of some of the problems we currently have with Microport SYSV (2.2.2, the latest): 1) Panics in the serial driver -- routine 'rmsd'. Looks a heck of a lot like recursion at the interrupt level, but without source, who knows? Microport told us for 4 months that it wasn't a bug in the code. Now they admit it's broken, but it's not on the top of their list. (Also dropped characters, which are a real pain especially with #3 below) 2) Brain-damage: Specifically, 'varargs' things don't always work the way they should, or dump core. Also, what is this about not being able to use indirection in large model to get around segmentation problems? (As in 'array of pointers cannot point to >64k of data' -- known bug, #329, V1.3, verified). 1.3 was here in December -- and it's still not fixed! Also, the memory allocation routines have problems, if used often enough in a program you can get a nice core dump from them as well (free list corruption perhaps??) 3) UUCP -- sorry again. It's not reliable over packet-switched networks. In particular, Telenet barfs it quite often --- and it seems to lose an inordinate number of packets (which requires re-sync and retransmit). This could be related to the serial problems, but somehow I doubt it, as nothing ELSE has problems on the serial lines to this extent (we're talking about dropping packets consistantly and in large numbers -- failed transmissions, etc..) If you're thinking about feeding Usenet through this system you better hang on real tight! The deaths seem to be related to the length of time you are connected (it gets worse on long transmissions). Debug '-x[1-9]' to uucico will dump core if you are in the "MASTER" role and have nothing to send. Finally, 'dialinfo' was kludged when it was integrated with uucico, so a Pc-Persuit dialer was out of the question (unless you are willing to dedicate a speed class to it -- like 1200. Full details on this to anyone who asks - it's long). 4) Panics in the floating point -- first a divide by zero exception w/80287 would crash the system. Then a floating point emulator bug was found (for those without 80287) that would kill it as well (but the circumstances were never documented by Microport). 6 months after I first saw the 80287 divide-by-zero problem, it is not fixed. The emulator bug wasn't fixed until 2.2.2. 5) Standard I/O (open for 'r+') is broken. This is documented, and in fact, from the news software it appears that AT&T broke it in SysV, but nonetheless it could be fixed. 6) They want to charge me to fix BUGS that panic my system! I don't mind paying for enhancements. Bug fixes are another matter, especially when I am told 'there is no problem' during my 90 day so-called warranty (as we were on the serial problems). Now we get hit everytime they ship an update, and the last time was a waste of my time and money to install. It fixed nothing, and may have broken some things (we're not sure about the breaking yet, but are in the middle of running some checks). You may have been able to COMPILE things cleanly, but how many of them ran? news 2.11, smail, and many others have run here -- but not out of the wrapper. Things like 'pathalias' still don't run -- and although I have a working version for Xenix V, I *cannot* make that same version run on Microport (bug #2 above). It's usually stupid stuff, but once in a while you really hit a wall -- like when the 'varargs' problem bites you. The pointer problem makes things fun too. How often does your system hang or panic under Microport? We crash here about once every 2-3 days in the SIO code. I simply *cannot* sell a system to a client that has such a reproducable, documented problem. (Hook 2 Microport boxes together sometime at 9600 baud and see 1) how many characters you lose and 2) how long it takes to panic the system. Uucp transfers work real well for this). The only solution? A $1k smart serial board (with a driver to REPLACE the junk currently in the kernel) It's true that Xenix is not Unix SYSV -- but heck, with the problems I have with SYSV, sometimes I am happy it's not the same. Do others have problems with SCO Xenix these days? I'd love to hear from people using either Microport or SCO that have opinions, bug reports, etc... Of course, I will summarize responses to the net if it appears there is sufficient interest. -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)
wrp@krebs.UUCP (07/06/87)
In article <133@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes: >In article <141@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes: >> +---- Steven Goodman writes the following in article <143@lakesys.UUCP> ---- >> | To be abit more accurate on the naming of Xenix one might call >> | it: Xenix System V Release 2. >> >> Does SVID address libraries? Xenix (By IBM for the AT) has no terminfo >> (termcap instead), incompatable header files, and a non-System 5 compiling I think that the current release of Xenix (SCO 2.2) is much closer to SysV than you might think. Terminfo is available. However I would like to speak about the reliablity of the sytem. My machine is up 24 hrs a day, 7 days a week, making a uucp connection at 9600 baud to a nearby machine twice an hour, with no reliability problems (knock on wood). I am frequently talking to two or three machines simultaneously at 9600 baud over direct and LAN lines, with no lost characters. With one exception in the compiler, Xenix does fine with large models (there is a compiler bug incrementing array indices in structures that is easily written around) and mixed model programming. Xenix has been out for a long time, and is still an evolving product. The current version is very good. (Although I too wish I had source code for mail and uucp). Bill Pearson ...!seismo!virginia!wrp wrp@virginia.BITNET
brezak@apollo.uucp (John Brezak) (07/06/87)
Is Xenix real System V R2 ???? I don't think so. I had a problem once using the ( SVR2 ) shared memory calls, once. Upon disassembling I discovered, to my horror, that all Microsoft did was to write a front end to their own shared memory management system for Xenix, that did not follow the documented SVID behaviour. Also for BSD Unix users, Try to compare the Xenix Csh to the "real" Csh. Also look at curses. Just another point, I tried Microport Unix once, I found the same brain-damaged Csh, that was the end of using Microport. I already knew Xenix's incompatibilities, I didn't want to find out Microport's. If anyone has any more recent experience, I would like to hear from you. This isn't a flame on Xenix or Microport. I'd use them both is I have to use an 80286 over the other alternatives. But I prefer Virtual Memeory and not having to figure out the correct memory model. =============================================================================================== John Brezak Apollo Computer
greg@gryphon.CTS.COM (Greg Laskin) (07/08/87)
In article <35e5f0fe.8a06@apollo.uucp> brezak@apollo.UUCP (John Brezak) writes: >Is Xenix real System V R2 ???? > >I don't think so. I had a problem once using the ( SVR2 ) shared memory calls, once. >Upon disassembling I discovered, to my horror, that all Microsoft did was to write >a front end to their own shared memory management system for Xenix, that did not >follow the documented SVID behaviour. Yep. You caught them. Of course, the release notes do note the shared memory differences from SVID (Xenix uses "far" pointers - "far" is a Microsoft C dependent keyword). They also note on difference in ptrace (it doesn't fail in one case where it's supposed to) and a few differences in the termio implementation (QUIT, ERASE and KILL are different, etc.). > [ csh is braindamaged, he says, because it doesn't work the same as the csh he uses ] OK. >This isn't a flame on Xenix or Microport. I'd use them both is I have >to use an 80286 over the other alternatives. But I prefer Virtual Memeory and >not having to figure out the correct memory model. It's amazing we can do anything useful at all with such terribly brain damaged hardware and software but, still, we perservere. Xenix, BSD, real SV, SIII, UTS, HP/UX, V7, etc., are all slightly different. Everything has bugs. Brain damage is where you find it. Memory models and virtual memory, as noted, have little to do with Xenix. What difference does it make, really. -- Greg Laskin "When everybody's talking and nobody's listening, how can we decide?" INTERNET: greg@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg UUCP: {philabs, scgvaxd}!cadovax!gryphon!gregL
barber@rabbit1.UUCP (Steve Barber) (07/17/87)
A framework that I find very useful for comparing and understanding the difference between UNIXes in general, and Microport and Xenix in particular, is to keep in mind the geneology and histories of their evolution. Microport is an honest-to-God port of AT&T System V Release 2. Xenix started as a port of V7, was heavily hacked and extended with local (Microsoft) and BSD extensions, then brought into conformance with SVID while retaining more or less the same kernel. Xenix is fairly mature and high-priced. Microport is new and relatively inexpensive. It is not surprising then that it is not yet stable, though with time I believe it will be. There is a world of difference between conforming to the SVID (as it applies to V.2), and actually being System V. In particular, the SVID specifies a programming interface (system call, library calls and shell commands by now I guess), but doesn't cover the sysadmin stuff or certain utility subsystems like uucp, cron, etc. So the answer to the question "Is Xenix a System V?" is "It depends on what you mean by 'System V'." (P.S. to SVID folks: I'm basing my info off an old SVID spec, so I may be out of date on some details. Feel free to flame me *by mail*.) -- Steve Barber Rabbit Software Corp. ..!seismo!cbmvax!hutch!barber ...!ihnp4!cuuxb!hutch!barber (215) 647-0440 7 Great Valley Parkway East Malvern PA 19355