On Mon, Aug 5, 2024 at 11:27 PM segaloco via TUHS <
tuhs@tuhs.org> wrote:
I'm paraphrasing here but I've read in a few places something to the effect that UNIX was "selected" as the basis on which to build a portable operating system standard, which of course we all know as POSIX.
I hate history rewrites and marketing spin. No other OS API or ABI was ever considered!!!
However, I got thinking on the implications of that phrasing, and have to ask, was there actually a "selection" made picking UNIX over some other candidate, or was it pretty much established from the outset of pursuing a standard that UNIX was going to get standardized?
Yes -- see below.
Another way to put it would be as a chicken and egg, which came first, desire for a portable base system definition that UNIX happened to fit nicely, or the ongoing need for UNIX standardization finding sponsorship by the working groups, IEEE, etc.?
UNIX needed IEEE -- see below.
Did any other OS contend for this coveted honor?
No.
Ok, the history. The commercial ISVs, particularly in the Minicomputer and Mainframe works, were tired of customizing applications for VMS, AOS, NOS, VM, or the like, and UNIX, as a "portable" operating system, offered them a potential solution, but the problem was that the HW vendors had an instilled concept of "value add" (embrace and extend) that would take UNIX and customize it. Note there were two primary schools of thought in those days, the idea of an ABI (application binary interface) definition, which was popular for systems that were being cloned (i.e., the IBM Mainframes and the new PCs with CP/M and DOS), and the API (application programming interface) folks that wanted to use something more like what was proving to be successful in the programming language world - which was that the minicomputer vendors favored.
So, the "Open Systems" community of the early 1980s had a problem. People already knew that the availability of application SW that solves people's problems drove HW sales, so the question was: How to make more applications available for UNIX and do it in a manner that the ISVs would support.
There were two organizations at the time, USENIX and /usr/group (later renamed "uniform"), that were the primary place where that could be solved. USENIX was the Academic Research Community, and everyone had sources, so helping commercial ISVs was not really on their plate. But /usr/group were the folks that were trying to build a new commercial market for UNIX. They sponsored a group led by TUHS's Heinz Lycklama to try to create an API standard that the ISVs could accept.
The members of that committee were: J. Bass, R. Bott, J. Boykin, B. Boyle, J. Brodie, E. Brunner, D. Buck, H. Burgess, P. Caruthers, F. Christiansen, D. Clark, C. Cole, A. Cornish, W. Corwin, B. Cox, D. Cragun, I. Darwin, L. Ford, C. Forney, M. Gien, S. Glaser, A. Godino, J. Goldberg, T. Green, J. Guist, M. Hakam, R. Hammons, G. Harris, S. Head, T. Hoffman, T. Houghton, J. Isaak, B. Joy, M. Katz, D. Kretsch, D. Ladermann, G. Laney, M. Laschkewitsch, B. Laws, Jr., H. Lycklama, J. McGinness, R. Michael, J. Moskow, M. O’Dell, D. Peachey, E. Petersen, P. Plauger, T. Plum, C. Prosser, R. Ptak, J. Schriebman, S. Sherman, H. Stenn, R. Swartz, T. Tabloski, M. Teller, J. Thomas, M. Tilson, D. Weisman, M. Wilens, R. Wirt, D. Wollner.
In November 1984, the original /usr/group standard was published. BTW: a residual effect of this work can be seen today, as this is the document where the <unistd.h> was defined.
As a side note, this document is "perfect bound" and I have been reluctant to break the back on my copy of it. At some point, I may have to do that so it can be properly scanned.
As soon as it was published, it was known to be incomplete and, of course, lacked the user (command) level standard and an ABI standard. It also has had one huge issue, in that /usr/group was not recognized by any of the American Standards or ISO to create a document that could be brought forward for International standardization. Furthermore, without a formal proposal from an American Standard a Federal Information Processing Standard (FIPS) couldn't be proposed, so a document needed to created from one of the blessed organizations that could be.
Maurice Graubie had recently been the chair of IEEE 802. Jim Issak, then of Charles RIver Data System with Maurice's sponsorship was able to get IEEE to open a committee under their guidance to create a portable OS. The scope and purpose are cut/pasted from the charge:
This effort entails three major components:
1. Definitions - Terminology and objects referred to in the document.
In the case of objects, the structure, operations that modify these,
and the effects of these operations need to be documented as well.
(Sample Term: Pipe, Sample Object: File Descriptor)
2. Systems Interface and Subroutines (C-Language Binding)
This area includes:
A. The range of interface & subroutines in the /usr/group document
B. IOCTL/TermIO
C. IFDEF Specifications
D. Real Time (Contiguous files, synchronization, shared data, priority
scheduling, etc.)
E. Device interface, including Termcaps/TermIO
F. Job Control, Windowing
G. Network Interface (but not Protocol)
H. Distributed Systems
I. Device Drivers
J. Error Handling & Recovery
3. User interface issues, including:
A. Shell, Command Set, Syntax
B. Portability - Media/Formats
C. Error Handling & Recovery
In all of these areas, consideration will be given to defining the impact on
security, international usage (language and character sets, etc.), and
application needs such as transaction processing.
The following areas may require review and commentary, perhaps even revisions
and updates, but are outside of the scope of the current effort: Network
Protocols, Graphics, DBMS, Record I/O.
Two areas are explicitly outside of the scope of the group: Binary compati-
bility/exchange of software in executable form, and the end-user interface
(where ease-of-use is a critical issue).
Target "consumers" of the documents are: Systems implementations (including
AT&T Licensees, those developing compatible systems, and those implementing
"hosted" systems), and application implementors - for areas 1 and 2. With
Area 3, multivendor systems integrators and shell users are also identified
as document consumers.
All of these efforts will not occur at once. The initial document for
balloting will be based on Section 1 and 2-A and B above. As this goes
through the balloting process, additional areas in 2 and 3 will be readied
for balloting. At this point, it is not clear if this will represent separate
revisions of a common document, separate "chapters" or "modules" of a common
document, or separate standards documents.
At the first meeting of the /usr/group committee in 1985, Jim presented this document from IEEE. We voted to disband and reconvene the meeting under IEEE's rules, with Heinz graciously stepping back and Jim becoming the new chair of the new committee.
The first IEEE version was published in 1988, and the first ISO version in 1990. Somewhere in between FIPS-151 was published.