Re: Undocumented systems/standards PWB and 32V

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 7634 bytes --]

Hi Branden, Seth,

On Wed, Dec 31, 2025 at 11:46:32PM -0600, G. Branden Robinson wrote:
> Hi Seth,
> 
> At 2026-01-01T04:45:28+0000, Seth McDonald wrote:
> > Starting the year off strong, here's a classic bug report.  The man
> > page for alloca(3) lists two systems/standards in its HISTORY: PWB and
> > 32V.
> > 
> > $ man ./man3/alloca.3 | sed -n '/HISTORY/,/^$/p'
> > HISTORY
> >        PWB, 32V.
> > 
> > After some Googling, I assume these are referring to the PWB/UNIX and
> > UNIX/32V operating systems, respectively.
> 
> Yes.  Most likely.  I have some remarks on nomenclature, orthography,
> and history.
> 
> PWB stands for "Programmer's Workbench".  It was a flavor of Unix
> maintained and sustained outside of the Bell Labs Computing Science
> Research Center (CSRC) in Murray Hill, New Jersey.  The CSRC is where
> Unix was born and where famous names like Ken Thompson, Dennis Ritchie,
> and Brian Kernighan worked.  Eventually, the flavor of Unix produced by
> the CSRC came to be known as "Research Unix".  In the late 1980s the
> CSRC decided that the Unix system was an unrewarding vehicle for further
> _research_, and shifted its emphasis to Plan 9.  Over time, the Jack
> Welch-ification of AT&T[1] meant that research at Bell Labs became less
> ambitious and eventually halted.
> 
> PWB came in at least two revisions--the original, retro-branded PWB1,
> and a second, sometimes called "PWB/UNIX 2.0".

It would be good to check in which one alloca(3) was present.

> Back then, AT&T corporate demanded that full capitals be used to spell
> "Unix".  This however was contrary to the preferences of the people who
> actually invented and developed it.[2][3]
> 
> I'd say, if you want to side with the suits, say "UNIX".
> 
> If you want to side with the engineers, say "Unix".
> 
> Sources conflict on how to spell "32V".  I've seen it thus but also as
> "V32",[4] which may be an error by McIlroy in an otherwise authoritative
> source.  If it is an error, it's an understandable one arising from the
> naming conventions applied to editions of CSRC Unix, starting with
> (again, retrospectively) First Edition in 1971 up through Research Unix
> Tenth Edition in 1989.  These were, and still are, often keyed in as
> "V1" through "V10" for short, and the "V" spoken as "version".
> 
> > However, they aren't listed in the standards(7) man page nor anywhere
> > else in the docs.
> 
> The first few entries in this document aren't standards; they're more
> like convenient _milestones_ from which we can infer a loose
> specification.

What is a standard?

From WordNet (r) 3.0 (2006) [wn]:
      3: established or well-known or widely recognized as a model of
         authority or excellence; "a standard reference work"; "the
         classical argument between free trade and protectionism"
         [ant: {nonstandard}]

And <https://www.dictionary.com/browse/standard>:
	1  something considered by an authority or by general consent as
	   a basis of comparison; an approved model.

I'd certainly consider K&R C as a standard under that definition.  And
probably V7 Unix too.  None of them were developed as a standard, but
they have become standards after-the-fact.

> Plain "PWB" won't do as a standard because, as noted above, it saw at
> least two different releases.

PWB wouldn't be a standard, though.  That one is just a milestone.
However, I'd be willing to document it if it's useful, though.

> Two more remarks on PWB Unix: the system with the best claim to being a
> successor of PWB 2.0 is Unix System III (released internally within AT&T
> in 1980, but not commercially until--so some sources say--1982.[4]
> 
> The reason for the delay would, one supposes, involve the divestiture
> of AT&T, that is, its dissolution as a "legal" monopoly, a watershed
> event in U.S. commerce.[5]  It's one that was crucially important to
> Unix history, because prior to divestiture, AT&T was legally prohibited
> from operating commercially as a supplier of computer hardware or
> software, per a 1956 consent decree it entered into with the U.S.
> federal government.[6]  In practice, AT&T violated the consent decree
> with increasing overtness from the mid-1970s into the early 1980s,
> marketing Unix System III and then System V as commercial products[7]
> and charging ever higher license fees for Unix as software.[8]
> 
> "For example, John Lions, a faculty member in the Department of Computer
> Science at the University of New South Wales, in Australia, reported
> that his school was able to acquire a copy of research UNIX Edition 5
> for $150 ($110 Australian) in December, 1974, including tape and
> manuals. (See "An Interview with John Lions," in Unix Review, October,
> 1985, pg. 51)"[8]
> 
> (Aussies may be surprised to learn that that the AUD was once "stronger"
> than the USD.  As a former resident, I was!)
> 
> > As such, the two systems should likely either be added to standards(7)
> > so they can be referenced,
> 
> Yes, maybe under a different heading.  They weren't standards, but they
> _are_ worthwhile benchmarks.

In manual pages, I'd keep everything under STANDARDS.

In standards(7), we could have subsections for Standard C, POSIX, and
Unix systems.

> 
> > or be removed from the HISTORY of alloca(3) and replaced with another
> > system/standard.
> 
> There was no _standard_ for anything to do with Unix until the
> /usr/group user group (get it?) produced one in 1984.[10]
> 
> > I would think they should be added to standards(7), but perhaps
> > they're too old be notable enough.  Wikipedia says they were released
> > in 1977 & 1979, while the oldest standards listed in standards(7) are
> > K&R C (1978) and V7 (1979).
> 
> Again, K&R C wasn't standardized; it had a reference manual, which is
> not the same thing.
> 
> Maybe we should term such things "milestones".
> 
> I don't think age alone is a sufficient criterion to reject them, but
> when citing non-standards in "STANDARDS" sections of man pages, we might
> want to use English to clarify the matter.

I think formal standards don't deserve any special treating.  I'm
willing to keep both formal standards and de-facto standards documented
in the same STANDARDS section.

> To build on a point of Alex's, whether we can get at authoritative
> documentation for citation purposes (and to settle or avoid arguments
> over facts) is of more probative value than a standard or milestone's
> novelty or lack thereof.  Some things that are old are important, and
> others aren't--just as with new things.

And some formal standards are pure bullshit, such as the SVID
specification of realloc(3), and later the ANSI C / ISO C one.  :)
See also <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3752.txt>.


Have a lovely day!
Alex

> 
> [1]  https://www.nhbr.com/a-lesson-from-ge/
> [2]  https://lists.gnu.org/archive/html/groff/2015-01/msg00026.html
> [3]  https://lists.gnu.org/archive/html/groff/2015-01/msg00029.html
> [4]  https://www.cs.dartmouth.edu/~doug/reader.pdf
> [5]  https://en.wikipedia.org/wiki/Breakup_of_the_Bell_System
> [6]  https://law.justia.com/cases/federal/district-courts/FSupp/552/131/1525975/
> [7]  https://www.tuhs.org/pipermail/tuhs/2025-December/032907.html
> [8]  https://github.com/thaliaarchi/unix-history/tree/main/licenses
> [9]  https://www.tuhs.org/Mirror/Hauben/unix-Part_II.html
> [10] https://wiki.tuhs.org/doku.php?id=publications:standards



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]