SysV + BSD + Pyramid.

[Carl S. Gutekunst]

In article <308 at dynasys.UUCP> jessea at dynasys.UUCP (Jesse W. Asher) writes:
>I'm going to be working with Pyramids sometime in the near future and I
>was curious about something.  Someone mentioned that you are able to
>run both SysV and BSD software, but it would switch modes or some such.

Pyramid's OSx Operating System implements what is commonly called a "dual
port." The system includes two complete environments (Pyramid calls them
"universes"), one 4.[23] BSD, and the other SVR3.2. This means the kernel
implements two complete sets of system calls, and the filesystem has to hold
two complete sets of utilities and header files. For each process, a runtime
flag indicates the "universe" in which it is running, and in the filesystem a
"conditional symbolic link" is used to select which directories and files are
to be used. 

Similar implementations are used by Apollo, Harris, and Gould (now Encore).
Sequent's Dynix is in between: internally, it is organized more like a merged
port (see below), but externally it looks like dual port. 

The alternative is a "merged port," in which the vendor provides the desired
features of both Berkeley and System V within the same unified environment.
The most common varient of this is "System V with Berkeley extensions," done
by everyone from Microsoft to Unisoft. Sun has been doing a more sophisticated
merge with SunOS for some time, and more recently AT&T with SVR4. 

I don't think there is any disagreement today that a dual port is a kludge
(Dennis Ritchie's exact word was "appalling"), and that a merged port is far
more desirable. (Pyramid is providing two reference ports for SVR4.) But the
dual port has been very popular for many reasons. The biggest is that it's a
lot easier than a merge; it requires very little design and much less coding
effort. In addition, crafting a merge involves many compromises and deviations
from the "base" Berkeley and System V semantics. Any vendor's merge is likely
to not be source-compatible with any other vendor's merge. (Indeed, Gould
tried this early on, and it was a complete flop.) Also, given the large number
of pure Berkeley and System V ports, the dual port made sense for developers
who needed to maintain source "purity." An old adage was that OSx was not
particularly easy to port *to*, but it is very easy to port *from.* The
nuisance is that if you really want a particular System V feature in your
Berkeley code, it's either very difficult or impossible. 

<csg>