Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!uwvax!uwmacc!uwmcsd1!lakesys!gryphon!ddsw1!karl From: karl@ddsw1.UUCP (Karl Denninger) Newsgroups: comp.unix.xenix Subject: Re: Huh? Message-ID: <133@ddsw1.UUCP> Date: Sun, 5-Jul-87 01:35:55 EDT Article-I.D.: ddsw1.133 Posted: Sun Jul 5 01:35:55 1987 Date-Received: Sun, 5-Jul-87 19:37:18 EDT References: <143@lakesys.UUCP> <141@hobbes.UUCP> Distribution: na Organization: Macro Computer Solutions Inc., Mundelein IL Lines: 107 Summary: But neither is Microport 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)