From: Clem Cole <clemc@ccc.com>
To: segaloco <segaloco@protonmail.com>,
The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Other POSIX Candidates?
Date: Tue, 6 Aug 2024 14:23:13 -0400 [thread overview]
Message-ID: <CAC20D2OdMcin8QqsBtHZWNLjn5KJs+yCWpzJff=OugC7z9RwNg@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2OyTpgGzRKbQFqogSL6UF65P0+pH9yT-C0F65XP+jyMmA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8157 bytes --]
typo: Jim Isaak
ᐧ
On Tue, Aug 6, 2024 at 2:19 PM Clem Cole <clemc@ccc.com> wrote:
>
>
> 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:
>
>
> 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.
>
>
>
>
> ᐧ
>
[-- Attachment #2: Type: text/html, Size: 15026 bytes --]
next prev parent reply other threads:[~2024-08-06 18:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 3:26 [TUHS] " segaloco via TUHS
2024-08-06 3:38 ` [TUHS] " George Michaelson
2024-08-06 6:39 ` arnold
2024-08-06 13:29 ` Peter Weinberger (温博格) via TUHS
2024-08-06 17:31 ` Rik Farrow
2024-08-06 18:04 ` Marc Rochkind
2024-08-06 18:09 ` arnold
2024-08-06 18:36 ` Heinz Lycklama
2024-08-06 18:45 ` segaloco via TUHS
2024-08-06 19:31 ` Clem Cole
2024-08-08 1:25 ` Kevin Bowling
2024-08-08 3:56 ` Theodore Ts'o
2024-08-08 8:46 ` Marc Donner
2024-08-08 16:09 ` Charles H Sauer (he/him)
2024-08-06 19:07 ` Paul Winalski
2024-08-06 18:18 ` Rik Farrow
2024-08-07 4:06 ` Theodore Ts'o
2024-08-07 20:56 ` Steffen Nurpmeso
2024-08-07 23:47 ` Theodore Ts'o
2024-08-09 0:53 ` Steffen Nurpmeso
2024-08-06 18:19 ` Clem Cole
2024-08-06 18:23 ` Clem Cole [this message]
2024-08-06 18:49 ` G. Branden Robinson
2024-08-06 18:55 ` Clem Cole
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC20D2OdMcin8QqsBtHZWNLjn5KJs+yCWpzJff=OugC7z9RwNg@mail.gmail.com' \
--to=clemc@ccc.com \
--cc=segaloco@protonmail.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).