Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!ames!lll-winken!tekbspa!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.sys.sequent
Subject: Re: Xenix vs. UNIX
Message-ID: <3665@auspex.auspex.com>
Date: 15 Jul 90 02:39:42 GMT
References: <99@raysnec.UUCP> <23002@megaron.cs.arizona.edu> <7523h7s@Unify.Com>
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 51

>>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
>
>As little as three years ago, no major Unix vendors (that I'm aware of) 
>provided a truly merged SYSV/BSD environment. Dynix was one of several
>implementations designed to bridge the gap by offering the "best of both
>worlds" (others which come to mind are Pyramid, Harris, Siemens, Apollo).
>
>For its time, dual universality offered a way to develop portable
>software for a Unix community which consisted of everything from hard-core
>SYSV-forget-the-csh machines to pure BSD environments. 
>
>Now that Sun, UI and OSF have done their thing, the trend toward
>integrated Unix has made (IMO) the dual-universe concept *obsolete*
>(s;dual universe;exception directories named 5bin, etc..;).

The "dual universe" scheme and the "exception directories" scheme are
generally *not* equivalent.

"Dual universe" systems seem to by inclined towards building "brick
walls" between the S5 and BSD environments, while the "exception
directories" systems tend not to disallow access to "xargs" or "shmat()"
from the BSD environment, or to "more" or "socket()" from the S5 one.

There are those who prefer the former, perhaps because it means they
don't get tempted to use stuff from the "wrong" environment.  There are
definitely those who prefer the latter; the original poster seems to be
one of those, and that was the point he was trying to make by referring
to "integrating the two worlds".

Given that there are routines that behave differently, you can't merge
them 100%, obviously.  The fact that "signal()" behaves differently in
the two environments doesn't mean you can't put "socket()" in the S5
environment or "shmat()" in the BSD environment, though (although, for
whatever reason, you may decide not to).

And as for what "Sun, UI and OSF" have done: well, SunOS isn't "truly
merged" if you mean that it has one environment, but then neither is
System V Release 4; it's similar to SunOS - or, probably, more like
recent (or upcoming?) versions of IRIX, in that the "default"
environment is the S5 one and any stuff in the BSD environment that's
incompatibly different gets stuck in "/usr/ucbinclude" or some place
like that; however, the *compatible* stuff generally ends up in *both*
environments.

Dunno what OSF plans to do, but I doubt they've figured out how to make
"signal()", for instance, read the programmer's mind, or the "tr"
command, so I suspect OSF/1 will probably be another of the "exception
directories" systems.