|
|
|
|
|
|
by Zach_the_Lizard
702 days ago
|
|
|
It's a bunch of small things: command line flags, whether a command line tool is even present at all, compiler built-ins / differences in behavior, headers possibly being in different places, compiler support for various language standards and more. Even to this day, it's not uncommon to find libraries that won't compile with one of GCC, clang, etc. or even the same compiler but Linux vs MacOS. It was even worse in ye olde times before package managers, I'm assuming. EDIT: I forgot to mention that System V and BSD are two of the major families. Both influenced Unix-like OSes far and wide, such as SysV style init scripts in certain Linux distros, MacOS being derived partly from BSD, Solaris being a continuation of SysV IIRC, and more. There was a rough standardization in where certain things could be found, command line flags, etc. |
|
|
"In order to provide maximum portability of software from Domain/ as to other Berkeley or System V UNIX systems, Apollo provides two complete and separate UNIX environments, rather than a hybrid of the two. Any workstation can have one or both UNIX environments installed, and users can select which environment to use on a per-process basis.
Two key mechanisms support this facility. First, every program can have a stamp applied that says what UNIX environment it should run in. The default value for this stamp is the environment in which it was compiled. When the program is loaded, the system sets an internal run-time switch to either berkeley or att, depending on the value of the stamp. Some of the UNIX system calls use this run-time switch to resolve conflicts when the same system call has different semantics in the two environments.
The other mechanism is a modification of the pathname resolution process, such that pathname text contains environment variable ex- pansions.
[...]
When UNIX software is installed on a node, the standard trees (/bin, /usr) are installed under directories called bsd4.3 and sysS.3. The names /bin and /usr are actually symbolic links dependent on the value of an environment variable named SYSTYPE. That is, /bin is a symbolic link to /$(SYSTYPE)/bin. When the program loader loads a stamped program, it sets the value of SYSTYPE to either bsd4.3 or sys3.3, according to the value of the program stamp. Therefore, a program that refers to a name in one of the standard directories will access the correct version for its environment."
[0] https://bitsavers.org/pdf/apollo/014962-A00_Domain_OS_Design...