gary@sci34hub.UUCP (Gary Heston) (06/26/90)
In article <5637@seac.UUCP> wain@seac.UUCP (Wain Dobson) writes: >As it goes, after utilizing the ODT (server and client systems) in-house, >we can't wait to get rid of our remaining XENIX systems. Applications When you start upgrading, feel free to send one of your old Xenix packages (discs, docs, notes and all) my way. I've got a 386SX machine at home I'd be glad to load it onto.... -- Gary Heston { uunet!sci34hub!gary } System Mismanager SCI Technology, Inc. OEM Products Department (i.e., computers) "The esteemed gentleman says I called him a liar. That's true, and I regret it." Retief, a character created by Keith Laumer.
campbell@Thalatta.COM (Bill Campbell) (06/27/90)
This month's issue of Computer Language has a comparison of 386 Un*x including SCO Xenix and UNIX and Interactive. Apart from some gaffes (Interactive also produces Xenix) the article was pretty good. They do make the points: 1. Xenix is smaller 2. Xenix is faster 3. Xenix is cheaper. I totally agree with this, and for my major use (on-line transaction processing and accounting applications) I don't want or need GUIs or the other ``creeping featurism'' of ODT... The Computer Language article also complained that Xenix was not totally UNIX compatible. I have been using Xenix since 1982, starting on the Tandy Model 16. I have never found any significant portability problems going from Xenix to UNIX System III or V that weren't caused by System V changing things for the better such as: grep -y being replaced by grep -i (ignore case) Every time I get on a ``pure'' UNIX box I miss Xenix commands like ``copy -romv'' and 'l'. I would like to see Xenix maintained (Bug fixes) and marketed for those of us who don't really need the bells and whistles being added to UNIX. -- ....microsoft--\ Bill Campbell; Celestial Software ...uw-entropy----!thebes!camco!bill 6641 East Mercer Way ....fluke------/ Mercer Island, Wa 98040 ....hplsla----/ (206) 232-4164
cpcahil@virtech.uucp (Conor P. Cahill) (06/28/90)
In article <4716@thebes.Thalatta.COM> campbell@Thalatta.COM (Bill Campbell) writes: >The Computer Language article also complained that Xenix was not >totally UNIX compatible. I have been using Xenix since 1982, >starting on the Tandy Model 16. I have never found any significant >portability problems going from Xenix to UNIX System III or V >that weren't caused by System V changing things for the better >such as: > grep -y being replaced by grep -i (ignore case) > One of the big problems xenix has is in porting stuff from other UNIX systems to it. The xenix compiler has alot of problems with large source files, complicated #define macros, etc. I am speaking from experience when I tried to port an office automation package to Xenix 2.2.? and ran into several brick walls, while the port to System V.3 (Bell Tech) of the same product just took around 4 days (it was 29MB of source). Going the other way should be much easier (which is obvious from your posting). SCO UNIX (with its inclusion of the standard AT&T compiler) should alleviate many of these problems. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
floydf@iphase.UUCP (Floyd Ferguson ENG) (06/29/90)
Article 6254 of comp.unix.i386: Path: iphase!uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Newsgroups: comp.unix.i386,comp.unix.xenix Subject: Re: Xenix vs. UNIX Message-ID: <1990Jun27.232700.3046@virtech.uucp> Date: 27 Jun 90 23:27:00 GMT References: <3304@crash.cts.com> <4716@thebes.Thalatta.COM> Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill) Organization: Virtual Technologies Inc., Sterling VA Lines: 27 Xref: iphase comp.unix.i386:6254 comp.unix.xenix:8544 In article <1990Jun27.232700.3046@virtech.uucp>cpcahil@virtech.uucp (Conor P. Cahill) writes: > SCO UNIX (with its inclusion of the standard AT&T compiler) should alleviate > many of these problems. In my opinion the C compiler situation in SCO is THE most unsatisfactory part of the package. Including rcc (Real C) barely makes up for the inadequacies of the default Microsoft compiler, and SCO has not taken any pains whatsoever to ensure that rcc is actually usable. While I've successfully compiled gcc and xemacs with rcc, gdb would not go, and a couple of the guys here have had a _terrible_ time getting some application code to port. I've not been able to get the MickeySoft compiler that SCO packages as cc to come even close to handling xemacs. There are three problems that either I've run into myself, or have been encountered by a couple of the guys here who've done a whole lot more at the application level than I have: 1. SCO has butchered a lot of the header files, which must be unbutchered before rcc will eat them. rcc knows nothing of void, which is liberally sprinkled through the header files. I also seem to remember running into some function prototypes that caused rcc to barf. 2. Structure assignment does not work, but does this silently (at least until you blow the stack frame assigning a structure to something with auto storage. 3. memcpy does not work. Actually, it fails to set the direction flag, so sometimes memcpy's backwards! Actually, there are three compilers: rcc, cc (Microsoft), and some stripped down version they use to build the space.o modules in the kernel. All three have a different idea of structure alignment! which has caused some very entertaining bugs when allocating storage for drivers in the space.c module. Overall, if I had to any serious application development the first thing I would do would be to get gcc running. floyd ferguson -- uunet!iphase!floydf
rogerk@sco.COM (Roger Knopf 5502) (06/29/90)
In article <2680CBDB.282C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >Yes, SCO will be supporting SCO Unix. And SCO will, I expect, be >dropping Xenix fairly soon. ARRGGHHH! No! No! We are *not* dropping Xenix soon. We have *no* plans to drop Xenix. We still make bug fixes for Xenix. If enough customers ask for it, we may even add a feature or two. Sorry for the aggravated tone. I thought we had said this enough times. As long as customers still want to buy Xenix, SCO will still sell and support it. This is driven _totally_ by demand from the marketplace. -- Roger Knopf <standard disclaimer applies> SCO Consulting Services uunet!sco!rogerk or rogerk@sco.com "...and he's got bare feet, too." 408-425-7222 (voice) 408-458-4227 (fax) --Charley Watkins
gary@cdthq (gary) (06/29/90)
campbell@Thalatta.COM (Bill Campbell) writes: > > Every time I get on a ``pure'' UNIX box I miss Xenix commands > like ``copy -romv'' and 'l'. If you're on a SysV.[23] system, write yourself a bunch of shell macros to emulate the commands you miss. I use a bunch, since I do admin work, that save me from typing. I also create them on the fly while doing debugging work. For example: ll () { ls -al $* ; } is a shell macro in my /etc/profile. It executes the ls -al with parameter substitution, and stays within the current environment. pe () { ps -ef | sort ; } is another I use on my mail hub (at work). On the other systems, I have a grep -v in there to get rid of anything with "root" in it, so I see only users' processes. Shell macros can be multi-line, have multiple commands per line separated with semicolons, and are memory resident so they don't have to be searched for along a path (cuts down on system load, too, especially if you use explicit paths to the commands). Macros can be passed positional parameters just like a shell, can include loops, and basically do about anything a short script will do, faster. The only disadvantage is that I haven't found a way to edit them in the environment. They can be redefined, though, so you can maintain them in a small file and use . to reload them after editing. Short ones (two or three commands) I'll usually retype, longer ones I'll debug as scripts and then change to a macro. I think more recent versions of Xenix support this, too.... Gary Heston, at home...
ron@rdk386.uucp (Ron Kuris) (06/29/90)
In article <1990Jun27.232700.3046@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > >One of the big problems xenix has is in porting stuff from other UNIX systems >to it. The xenix compiler has alot of problems with large source files, >complicated #define macros, etc. I am speaking from experience when I >tried to port an office automation package to Xenix 2.2.? and ran into >several brick walls, while the port to System V.3 (Bell Tech) of the same >product just took around 4 days (it was 29MB of source). > >Going the other way should be much easier (which is obvious from your >posting). > >SCO UNIX (with its inclusion of the standard AT&T compiler) should alleviate >many of these problems. Why not just use gcc and not worry about the abnormalities of the "standard" compiler provided with Xenix? I agree its broken, but the compiler doesn't make the entire system unusable, especially when there are alternatives... -- ...!pyramid!unify!rdk386!ron -or- ...!ames!pacbell!sactoh0!siva!rdk386!ron It's not how many mistakes you make, its how quickly you recover from them.
tneff@bfmny0.BFM.COM (Tom Neff) (06/29/90)
In article <223@iphase.UUCP> floydf@iphase.UUCP (Floyd Ferguson ENG) writes: ... >While I've successfully compiled gcc and xemacs with [SCO] rcc, gdb would >not go... Uh, if you've compiled gcc, why do you still need rcc to make gdb? Surely gcc is the tool for that job. -- A doubled signature is the devil's work. ** Tom Neff <tneff@bfmny0.BFM.COM> -- A doubled signature is the devil's work. ** Tom Neff <tneff@bfmny0.BFM.COM>
fred@cdin-1.UUCP (Fred Rump) (06/29/90)
rogerk@sco.COM (Roger Knopf 5502) writes: >We still make bug fixes for Xenix. If enough >customers ask for it, we may even add a feature or two. >This is driven _totally_ by demand from the marketplace. OK, then why don't we start by giving us support for a monochrome VGA monitor? These are less expensive than color but the resolution is much better then ordinary mono screens. It would certainly help to keep Xenix alive a little longer. You see we get this weird impression that you WANT us to move to Unix. Only SCO can change that. fred -- Fred Rump | UUCP: {uunet dsinc}!cdin-1!fred CompuData, Inc. | "Beware of cats for they are subtle and will .... on 10501 Drummond Rd. | your computer." Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/30/90)
In article <3304@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: | > My own feeling is that many users want NFS, TCP, and X, along with a | >solid UNIX, and almost any reasonable window manager. They also want it | >at low cost (<$1k). I believe that there will be a version of V.4 out | >which meets these objectives in the *very* near future. | | ESIX meets the price a helluva lot better than SCO. Okay, tell me what to order, since Everex can't. 2 user ESIX + NFS from ISC comes to more than ODT, either list or street price. Something like 20% as I recall. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
kevinc@sequent.UUCP (Kevin Closson) (06/30/90)
In article <5P7HL3w161w@cdthq> gary@cdthq (gary) writes: >campbell@Thalatta.COM (Bill Campbell) writes: >> >> Every time I get on a ``pure'' UNIX box I miss Xenix commands >> like ``copy -romv'' and 'l'. > >If you're on a SysV.[23] system, write yourself a bunch of shell >macros to emulate the commands you miss. I use a bunch, since I Uhmmmm... good info Gary, except.... they're "shell functions". Now my motive here isn't to be picky...especially since you replied to my post in misc.invest ......but the distinction needs to be made because the term macros, or even "shell functions" might not be explanatory enough to keep the novice,of the C Shell persuasion,from following your suggestion. And we know that /etc/profile is greek to good ol' csh .... But, Bill... take heart ... the man page for csh will tell you about alias'ing. Alias'ing a command in your .login will do the job here.... your "macro" will even go with you into child processes! Something we Bourne dudes grumble about... All of the purist stuff aside..... Bill's comment was that he feels this loss of command usage any time he gets on a REAL UNIX box. Watch out. What is REAL UNIX .... those using the BSD 4.? flavor of "REAL UNIX" might not like this posting at all... there's a bourne shell that will instantaneously barf at the sight of a shell function....there are a couple of built-ins missing too ...sounds an awful lot like Sys III..... KORN to the rescue .... Gary did put out the SysV.[23] disclaimer ... One last thought .... Shell functions are memory resident.... if your system administrator sees that all 400+ REAL UNIX users have "a bunch" of shell functions in their log in shell process come monday, he might get hot ... just type in 'set' and see how much over-head your functions are taking .... >I think more recent versions of Xenix support this, too.... That's right, Gary ..... Shell functions are SVS V Bourne Shell PERIOD ! SCO XENIX V.2.2 ......etc ...... So Bill, if you're stepping on to an unfamiliar ***NIX machine.... just type in: type type If it doesn't come back with "type is a shell built-in"..... you might as well just type in csh .... and alias away ......oooops ...or ksh ... ENOUGH kevinc DISCLAIM-IT .... THIS IS ME ... ALONE.... NO ONE ELSE ...I AM NOT PARANOID...........NO I DIDN'T....WHEN.....HOW ?????? ....
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/01/90)
In article <223@iphase.UUCP> floydf@iphase.UUCP (Floyd Ferguson ENG) writes: In article <1990Jun27.232700.3046@virtech.uucp>cpcahil@virtech.uucp (Conor P. Cahill) writes: > SCO UNIX (with its inclusion of the standard AT&T compiler) should alleviate > many of these problems. In my opinion the C compiler situation in SCO is THE most unsatisfactory part of the package. Including rcc (Real C) barely makes up for the I understand that rcc stands for Register C Compiler, the successor to pcc, the Portable C Compiler. On other versions of SystemV/386 it is called cc. While I've successfully compiled gcc and xemacs with rcc, gdb would not go, Well, with GNU software that uses alloca(), it is *vital* to turn off the default inline procedure expansion doen by the optimizer, using option '-W2,-y0' along with the '-O' one. I cannot imagine why ever AT&T put in a very sophisticated optimizer that does tricky things without documenting its zillion options. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/01/90)
In article <1216@sixhub.UUCP> davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes:
2 user ESIX + NFS from ISC comes to more than ODT, either list or
street price. Something like 20% as I recall.
Sanity check: do you mean that now ODT includes all the necessary
development system tools, like ESIX?
Or was it me hallucinating when I understood that ODT is strictly
runtime systems only, and you have to pay several thousand dollars to
get the ODT development system?
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukshwake@raysnec.UUCP (Ray Shwake) (07/10/90)
In article <1990Jun29..185@rdk386.uucp> ron@rdk386.UUCP (Ron Kuris) writes: > >Why not just use gcc and not worry about the abnormalities of the "standard" >compiler provided with Xenix? I agree its broken, but the compiler doesn't >make the entire system unusable, especially when there are alternatives... This response is just a tad facile for my taste. GCC doesn't always make life easier. I had my first encounter with GCC last week after a colleague installed it on his Sequent Balance. Well, here was an opportunity to see what all the fuss was about. Moved some of my source over, checked flags and file locations, typed "make". Given my System V biases, tried compiling in the ATT environment. Had to modify a few macro contructs to make them "ansi conformant", but things got REAL interesting in the link/load phase. It just couldn't find the c runtime module! Found the module in /.lib (that damn universe again!). OK, back to BSD. Argh! Can't find _regex, _strchr, ... Morale: GNU CC... It *might* work for you.
bakken@cs.arizona.edu (Dave Bakken) (07/13/90)
In article <99@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >In article <1990Jun29..185@rdk386.uucp> ron@rdk386.UUCP (Ron Kuris) writes: >> >>Why not just use gcc and not worry about the abnormalities of the "standard" >>compiler provided with Xenix? I agree its broken, but the compiler doesn't >>make the entire system unusable, especially when there are alternatives... > > This response is just a tad facile for my taste. GCC doesn't always > make life easier. I had my first encounter with GCC last week after > a colleague installed it on his Sequent Balance. Well, here was an > opportunity to see what all the fuss was about. Moved some of my > source over, checked flags and file locations, typed "make". > > Given my System V biases, tried compiling in the ATT environment. > Had to modify a few macro contructs to make them "ansi conformant", > but things got REAL interesting in the link/load phase. It just > couldn't find the c runtime module! Found the module in /.lib > (that damn universe again!). OK, back to BSD. Argh! Can't find > _regex, _strchr, ... > > Morale: GNU CC... It *might* work for you. Your problem here is not GCC but rather is DYNIX's retarded dual universes, which IMO is just a way of avoiding the task of integrating the two worlds, like virtually every other Unix vendor has done. Vendors have been providing this for many years, so much so that a lot of sources in comp.sources assume routines from both universes. These things compile with no problems, in general, on most systems, but it is a pain on DYNIX. This has been a pain for us when doing development work for our distributed programming language, SR, on a Sequent Symmetry running DYNIX. -- Dave Bakken Internet: bakken@cs.arizona.edu Dept. of Comp. Sci.; U.of Ariz. UUCP: uunet!arizona!bakken Tucson, AZ 85721; USA Bitnet: bakken%cs.arizona.edu@Arizrvax AT&T: +1 602 621 4098 FAX: +1 602 621 4246
nerd@percy.uucp (Michael Galassi) (07/17/90)
In article <1258@cdin-1.UUCP> fred@cdin-1.UUCP (Fred Rump) writes: >rogerk@sco.COM (Roger Knopf 5502) writes: >>We still make bug fixes for Xenix. If enough >>customers ask for it, we may even add a feature or two. >>This is driven _totally_ by demand from the marketplace. >OK, then why don't we start by giving us support for a monochrome VGA monitor? >These are less expensive than color but the resolution is much better then >ordinary mono screens. On one machine I have instaled an NEG multisync GS, almost as cheap ($200/ea in bulk) and similar in quality to a monochrome CRT, responsive as SCO is this is probably A LOT faster (CGI works with it). Of course if they do add support for VGA-mono in CGI I would LOVE to see EGA-mono added at the same time (hint?). >It would certainly help to keep Xenix alive a little longer. You see we get >this weird impression that you WANT us to move to Unix. Only SCO can change >that. I called in to ask about SCO's developer program, the person I talked to gave me the impresion that the most valuable thing I would get by paying whatever it was to get into the program would be a cheaper upgrade from Xenix 2.3.x to Unix 3.2.x. Based on that and the derived feeling that SVR3 will go the same way when SCO figures out if they will go SVR4 or OSF/1 we are holding off on any development work and are considering the alternatives (Intel SVR4, and Interactive both seem more stable). -michael -- Michael Galassi | If my opinions happen to be the same as ...!tektronix!percy!nerd | my employer's it is ONLY a coincidence, ...!sun!nosun!percy!nerd | of course coincidences OFTEN DO happen.