[TUHS] Other POSIX Candidates?

[Clem Cole]

typo:  Jim Isaak
ᐧ

On Tue, Aug 6, 2024 at 2:19 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Aug 5, 2024 at 11:27 PM segaloco via TUHS <tuhs at 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:
>
>
> A.003.2
> 15JAN85
>
>
>            Scope and Purpose of the IEEE P1003 Working Group
>
> "To define a standard operating system interface and environment based
> on the  UNIX Operating System documentation to support application
> portability at the source level. (UNIX is a trademark of Bell Labs)"
>
> 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.
>
>
>
>
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240806/ff3d12fa/attachment.htm>