From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 642BC272A5 for ; Tue, 6 Aug 2024 20:20:06 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id EFCE6427A8; Wed, 7 Aug 2024 04:20:02 +1000 (AEST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by minnie.tuhs.org (Postfix) with ESMTPS id EF100427A4 for ; Wed, 7 Aug 2024 04:19:56 +1000 (AEST) Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-e05e4c3228bso867953276.0 for ; Tue, 06 Aug 2024 11:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1722968396; x=1723573196; darn=tuhs.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=H/yQ3200Jr1H1D/uvKgKlATGAVQmUVXd0GaZkC2G14Y=; b=Gd94nmVQtrS0FVTAvGGlJy+g0zDFuIiB3UYyHgC0I0GjFgqVnpniLDMV1eL99cEx+z T+KQohgIJd6Uwy71gOcuhwYenKQsElDrMvajFwGC9bkzsE1DHyIFcDQ0Sa6xLqeWNLLr Soyh7LV8gnnpLpzJ+O73wDjRgk7zkrEdhm0+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722968396; x=1723573196; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=H/yQ3200Jr1H1D/uvKgKlATGAVQmUVXd0GaZkC2G14Y=; b=DI/LSghtzoFE4N6JC3SmUF9aQ2eLSuAT4UXTb5/4gJQbckiPGhkTT2lJUMdF78H75K 7r7Jfth2Av6WG7sy0QDfIP46A5rmou96w9N37ml75KV52wN57O3pBOug3DKeWma9MWyU 7nZn14W0NpvKO5qytJI41DKgG9gLBKcYe4GXNh6SHZNe8kA2nCQOxaVKKpG1SGBvytL3 2jIFNNvfwqJcI5CkcwAZLak/uOYaHC2GrjJub26+ALYZXtvZeVqXOALhkRMBjqspYe3m +CvtK+KhKYe1qxQsAc/GxAoriDs+RRuj+Y/aB4p6fPaGwr9OSad2xRGi8ptGKpYkxFHB OOcA== X-Forwarded-Encrypted: i=1; AJvYcCV4IhUsjl0OkhuJecHS0UzhWT7WbNuvecMhTAnMAX6POjUSDYVTOOWUp+eyc6eqRirqE56BgYOHW3Gp696Q X-Gm-Message-State: AOJu0Yz0MRCvmn5tfOBzqwuJkgYWl0i00chNVHrrPnLycagye9PVpz4r Nn/94YScGwY0K7vvR/ptvQlZCerVr+aaCxLK+r6H7rzrVBLhW773K82qLSj/lkYcJzuQsDsGmN5 SC1XCIH0bo2wSPTpxSge8Hc4f9eLSiVjMUxMZSo/1HnjrmyE= X-Google-Smtp-Source: AGHT+IHy20kwFWcucFu1FAUGIIEff2Iu7F6TjjXzHJyjmxIYsfRD7uOPEZED6yg9iZATrUU8rWqlJs4wsTmtH03HB2A= X-Received: by 2002:a05:6902:3c4:b0:e03:61d4:ab35 with SMTP id 3f1490d57ef6-e0bde465b5fmr15871997276.53.1722968395791; Tue, 06 Aug 2024 11:19:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clem Cole Date: Tue, 6 Aug 2024 14:19:19 -0400 Message-ID: To: segaloco , The Eunuchs Hysterical Society Content-Type: multipart/alternative; boundary="00000000000030dbbc061f07d73a" Message-ID-Hash: VZD23EORW6YDYH7U4354LAFEYZRF6NOD X-Message-ID-Hash: VZD23EORW6YDYH7U4354LAFEYZRF6NOD X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Other POSIX Candidates? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000030dbbc061f07d73a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 5, 2024 at 11:27=E2=80=AFPM segaloco via TUHS w= rote: > 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=E2=80=99Dell, 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 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 o= n 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 (includin= g 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. =E1=90=A7 --00000000000030dbbc061f07d73a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 5, 2024 at 11:27= =E2=80=AFPM segaloco via TUHS <tuhs@tuhs.org> wrote:
I'm paraphrasing here but I've read in a f= ew places something to the effect that UNIX was "selected" as the= basis on which to build a portable operating system standard, which of cou= rse we all know as POSIX.=C2=A0
I hate history rewrites and marketing=C2=A0 spin.=C2=A0=C2=A0<= /span>No other OS API or ABI was ever con= sidered!!!
<= br>
Yes -- see below.

Another way to put it would be as a chicken and egg, which came first, desi= re for a portable base system definition that UNIX happened to fit nicely, = or the ongoing need for UNIX standardization finding sponsorship by the wor= king groups, IEEE, etc.?=C2=A0
= UNIX needed IEEE -- see below.

=C2=A0
Did any other OS contend for = this coveted honor?
No.=C2=A0

<= font color=3D"#0000ff">Ok, the history.=C2=A0 The commercial ISVs, part= icularly in the Minicomputer and Mainframe works, were tired of customizing= applications for VMS, AOS, NOS, VM, or the like, and UNIX, as a "port= able" operating system, offered them a potential solution, but the pro= blem was that the HW vendors had an instilled concept of "value add&qu= ot; (embrace and extend) that would take UNIX and customize it.=C2=A0 =C2= =A0Note there were two primary=C2=A0schools of thought=C2=A0in those days,= =C2=A0 the idea of an ABI (application binary interface) definition, which = was popular for systems that were being cloned (i.e., the IBM Mainfr= ames and the new PCs with CP/M and DOS), and the API (application programmi= ng interface) folks that wanted to use something more like what was proving= to be successful in the programming language world - which was that the mi= nicomputer vendors favored.

So, the "= ;Open Systems" community of the early 1980s had a problem. People alre= ady knew that the availability of application SW that solves people's p= roblems 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.=C2=A0 USENIX was the Academi= c Research Community, and everyone had sources, so helping commercial ISVs = was not really on their plate.=C2=A0 But /usr/group were the folks that wer= e trying to build a new commercial market for UNIX.=C2=A0 =C2=A0They sponso= red a group led by TUHS's Heinz Lycklama to try to create an API = standard that the ISVs could accept.=C2=A0
=
The members of that committee were:=C2=A0J. Bass, R. Bott, J. Boykin, B. Boyle, J. Brodi= e, 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. Law= s, Jr., H. Lycklama, J. McGinness, R. Michael, J. Moskow, M. O=E2=80=99Dell= , D. Peachey, E. Petersen, P. Plauger, T. Plum, C. Prosser, R. Ptak, J. Sch= riebman, 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.=C2=A0 BTW: a residual effect of this wor= k can be seen today, as this is the document where the <unistd.h> was defined.

As a side note, this document is "perfect bo= und" and I have been reluctant to break the back on my copy of it.=C2= =A0 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.=C2=A0 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 docu= ment that could be brought forward for International standardization.=C2=A0= =C2=A0Furthermore, without a formal proposal from an American Standard a F= ederal Information Processing=C2=A0Standard (FIPS) couldn't be proposed= , so a document needed to created from one of the blessed organizations tha= t could be.

=
Maurice Graubie had recently b= een the chair of IEEE 802.=C2=A0 Jim Issak, then of Charles RIver Data Syst= em with Maurice's sponsorship was able to get IEEE to open a committee = under their guidance to create a portable OS.=C2=A0 =C2=A0The scope and pur= pose are cut/pasted from the charge:


=
A.003.2
15JAN85<= br>

=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Scope and Purpose of the IEEE P1003 Working Group

"To define a standard operating sy= stem interface and environment based
on the =C2=A0= UNIX Operating System documentation to support application
portability at the source lev= el. (UNIX is a trademark of Bell Labs)"

This effort entails three= major components:

1.=C2=A0 Definitions - Terminology and objects re= ferred to in the document.
=C2=A0 =C2=A0 In the case of objects, the str= ucture, operations that modify these,
=C2=A0 =C2=A0 and the effects of t= hese operations need to be documented as well.
=C2=A0 =C2=A0 (Sample Ter= m: =C2=A0Pipe, Sample Object: =C2=A0File Descriptor)

2.=C2=A0 System= s Interface and Subroutines (C-Language Binding)
This area includes:
=C2=A0 =C2=A0 A.=C2=A0 The range of interface & subroutines in the= /usr/group document
=C2=A0 =C2=A0 B.=C2=A0 IOCTL/TermIO
=C2=A0 =C2= =A0 C.=C2=A0 IFDEF Specifications
=C2=A0 =C2=A0 D.=C2=A0 Real Time (Cont= iguous files, synchronization, shared data, priority
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 scheduling, etc.)
=C2=A0 =C2=A0 E.=C2=A0 Device interface, in= cluding Termcaps/TermIO
=C2=A0 =C2=A0 F.=C2=A0 Job Control, Windowing=C2=A0 =C2=A0 G.=C2=A0 Network Interface (but not Protocol)
=C2=A0 =C2= =A0 H.=C2=A0 Distributed Systems
=C2=A0 =C2=A0 I.=C2=A0 Device Drivers=C2=A0 =C2=A0 J.=C2=A0 Error Handling & Recovery

3.=C2=A0 User= interface issues, including:

=C2=A0 =C2=A0 A.=C2=A0 Shell, Command = Set, Syntax
=C2=A0 =C2=A0 B.=C2=A0 Portability - Media/Formats
=C2=A0= =C2=A0 C.=C2=A0 Error Handling & Recovery

In all of these areas= , consideration will be given to defining the impact on
security, intern= ational usage (language and character sets, etc.), and
application need= s such as transaction processing.

The following areas may require re= view and commentary, perhaps even revisions
and updates, but are outside= of the scope of the current effort: =C2=A0Network
Protocols, Graphics, = DBMS, Record I/O.

Two areas are explicitly outside of the scope of t= he group: =C2=A0Binary compati-
bility/exchange of software in executabl= e form, and the end-user interface
(where ease-of-use is a critical issu= e).

Target "consumers" of the documents are: =C2=A0Systems= implementations (including
AT&T Licensees, those developing compati= ble systems, and those implementing
"hosted" systems), and ap= plication implementors - for areas 1 and 2.=C2=A0 With
Area 3, multivend= or systems integrators and shell users are also identified
as document = consumers.

All of these efforts will not occur at once.=C2=A0 The in= itial document for
balloting will be based on Section 1 and 2-A and B a= bove.=C2=A0 As this goes
through the balloting process, additional area= s in 2 and 3 will be readied
for balloting.=C2=A0 At this point, it is = not clear if this will represent separate
revisions of a common document= , separate "chapters" or "modules" of a common
docu= ment, or separate standards documents.

A= t the first meeting of the /usr/group committee in 1985, Jim presented this= document from IEEE.=C2=A0 We voted to disband and reconvene the meeting un= der IEEE's rules, with Heinz graciously stepping back and Jim becoming = the new chair of the new committee.

The first IEEE version was p= ublished in 1988, and the first ISO version in 1990.=C2=A0 Somewhere in bet= ween FIPS-151 was published.




3D""=E1=90=A7
--00000000000030dbbc061f07d73a--