I can assure you that Lorinda Cherry wrote most of the important
code in WWB, including style and diction. The idea for them
came from Bill Vesterman at Rutgers. Lorinda already had parts,
a real tour de force, which assigned parts of speech to words
in a text. Style was the killer app for parts and was running
within days of his approach to the labs wondering whether
such a thing could be built. Lorinda also wrote deroff, which
these tools of course needed. WWB per se was packaged by
USDL; I am sorry I can't remember the name of the guiding
spirit. So Lorinda's code detoured through there on its
way into research Unix.
Chris van Wyk was cvw. He was at Bell Labs, not BSD.
Chuck Haley is indeed Charles B. Haley.
Andy Koenig was ark.
A few scattered answers, some redundant with those of others:
-- Lorinda Cherry (llc) worked at Bell Labs. She wrote diction (and
the rest of the Writer's Workbench tools) there, in the early
1980s; if some people saw it first in BSD releases that is just
an accident of timing (too late for V7) and exposure (I'm pretty
sure it was available in the USG systems, which weren't generally
accessible until a year or two later).
Lorinda is one of the less-known members of the original Computer
Science Research Center who nevertheless wrote or co-wrote a lot
of things we now take for granted, like dc and bc and eqn and
libplot.
Checking some of this on the web, I came across an interesting
tidbit apparently derived from an interview with Lorinda:
http://www.princeton.edu/~hos/frs122/precis/cherry2.htm
I wholly endorse what she says about UNIX and the group it came from.
One fumble in the text: `Bob Ross' who liked to break programs is
surely really Bob Morris.
-- So far as I know, Tom Duff (td) was never at Berkeley. He's
originally from Toronto; attended U of T; was at Lucasfilm for a
while (he has a particular interest in graphics, though he is a
very sharp and subtle programmer in general); started at Bell Labs
in 1984, not long before I did. He left sometime in the 1990s,
lives in Berkeley CA, but works neither at UCB nor at Google but
at Pixar.
-- T. J. Kowalski (frodo) was at Bell Labs; when I was there he
worked in the research group down the hall (Acoustics, I think), with
whom Computer Science shared a lot of UNIX-releasted stuff. Ted is
well-known for his work on fsck, but did a lot of other stuff, including
being the first to get Research UNIX to work on the MicroVAX II. He
also had a high-quality mustache.
-- Andrew Koenig (ark) was part of the Computer Science group when
I was there in the latter 1980s. He was a early adopter of C++.
asd, the automatic-software distributor we used to keep the software
in sync on the 20-or-so systems that ran Research UNIX, was his work.
-- Mike Tilson was, I think, one of the founders of HCR (Human Computing
Resources), a UNIX-oriented software company based in Toronto in the
early 1980s. The company was later acquired by SCO, in the days when
SCO was still a technical company rather than a den of lawyers.
-- Peter Honeyman (honey) was never, I think, at Berkeley, though
he is certainly of the right character. In the 1980s he was variously
(sometimes concurrently?) working for some part of AT&T and at Princeton.
For many years now he has been in Ann Arbor MI at the University of
Michigan, where his still-crusty manner appears not to interfere with
his being a respected researcher and much-liked teacher.
Norman Wilson
Toronto ON
(Bell Labs Computing Science Research, 1984-1990)
I found out that the book "Life with Unix" by Don Libes and Sandy
Ressler has a seven page listing of Unix notables, and I'm using that to
fill gaps in the contributors of the Unix history repository [1,2].
Working through the list, the following questions came up.
- Lorinda Cherry is credited with diction. But diction.c first appears
in 4BSD and 2.10BSD. Did Lorinda Cherry implement it at Berkeley?
- Is Chuck Haley listed in the book as the author of tar the same as
Charles B. Haley who co-authored V7 usr/doc/{regen,security,setup}? He
appears to have worked both at Bell labs (tar, usr/doc/*) and at
Berkeley (ex, Pascal). Is this correct?
- Andrew Koenig is credited with varargs. This is a four-line header
file in V7. Did he actually write it?
- Ted Dolotta is credited with the mm macros, but the document "Typing
Documents with MM is written by by D. W. Smith and E. M. Piskorik. Did
its authors only write the documentation? Did Ted Dolotta also write
mmcheck?
Also, I'm missing the login identifiers for the following people. If
anyone remembers them, please send me a note.
Bell Labs, PWB, USG, USDL:
Andrew Koenig
Charles B. Haley
Dick Haight
Greg Chesson
Herb Gellis
Mark Rochkind
Ted Dolotta
BSD:
Bill Reeves
Charles B. Haley
Colin L. Mc Master
Chris Van Wyk
Douglas Lanam
David Willcox
Eric Schienbrood
Earl T. Cohen
Herb Gellis
Ivan Maltz
Juan Porcar
Len Edmondson
Mark Rochkind
Mike Tilson
Olivier Roubine
Peter Honeyman
R. Dowell
Ross Harvey
Robert Toxen
Tom Duff
Ted Dolotta
T. J. Kowalski
Finally, I've summarized all contributions allocated through file path
regular expressions [3] into two tables ordered by author [4]. (The
summary is auto-generated by taking the last significant part of each
path regex.) If you want, please have a look at them and point out
omissions and mistakes.
I will try to commit all responses I receive with appropriate credit to
the repository. (You can also submit a GitHub pull-request, if you prefer.)
[1] https://github.com/dspinellis/unix-history-repo
[2]
http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.pdf
[3]
https://github.com/dspinellis/unix-history-make/tree/master/src/author-path
[4] http://istlab.dmst.aueb.gr/~dds/contributions.pdf
Diomidis
> From: Clem Cole
> Eric Schienbrood
> .. Noel might remember his MIT moniker
No, alas; and I tried 'finger Schienbrood(a)lcs.mit.edu' and got no result.
Maybe he was in some other part of MIT, not Tech Sq?
> From: Arnold Skeeve
> Here too I think stuff written at ATT got out through Berkeley. (SCCS)
That happened at MIT, too - we had SCCS quite early (my MIT V6 manual has
it), plus all sorts of other stuff (e.g. TROFF).
I think some of it may have come through Jon Sieber, who, while he was in high
school, had been part of (IIRC) a Scout troop which had some association with
Bell Labs, and continued to have contacts there after he became an MIT
undergrad.
Noel
> From: Peter Jeremy <peter(a)rulingia.com>
> Why were the original read(2) and write(2) system calls written to
> offer synchronous I/O only?
A very interesting question (to me, particularly, see below). I don't think
any of the Unix papers answer this question?
> It's relatively easy to create synchronous I/O functions given
> asynchronous I/O primitives but it's impossible to do the opposite.
Indeed, and I've seen operating systems (e.g. a real-time PDP-11 OS I worked
with a lot called MOS) that did that.
I actually did add asynchronous I/O to V6 UNIX, for use with very early
Internet networking software being done at MIT (in a user process). Actually,
it wasn't just asynchronous, it was _raw_ asynchronous I/O! (The networking
device was DMA, and the s/w did DMA directly into the user process' memory.)
The code also allowed more than one outstanding I/O request, too. (So the
input could be re-enabled on the device ASAP, without having to wake up a
process, have it run, do a new read call, etc.)
We didn't redo the whole Unix I/O system, to support/use asyn I/O throughout,
though; I just kind of warted it onto the side. (IIRC, it notified the user
process via a signal that the I/O had completed; the user software then had
to do an sgtty() call to get the transfer status, size, etc.)
Anyway, back to the original topic: I don't want to speculate (although I
could :-); perhaps someone who was around 'back then' can offer some insight?
If not, time for speculation! :-)
Noel
Why were the original read(2) and write(2) system calls written to offer
synchronous I/O only? It's relatively easy to create synchronous I/O
functions given asynchronous I/O primitives but it's impossible to do the
opposite.
Multics (at least) supported asynchronous I/O so the concept wasn't novel.
And any multi-tasking kernel has to support asynchronous I/O internally so
suitable code exists in the kernel.
--
Peter Jeremy
As I was dropping off to sleep last night, I wondered why the superuser
account on Unix is called root.
There's a hierarchy of directories and files beginning at the tree root /.
There's a hierarchy of processes rooted with init. But there's no hierarchy
of users, so why the moniker "root"?
Any ideas?
Cheers, Warren
> Did any Unix or Unix like OS ever zero fill on realloc?
> On zero fill, I doubt many did that. Many really early on when memory
> was small.
This sparks rminiscence. When I wrote an allocation strategy somewhat
more sophisticated than the original alloc(), I introduced realloc() and
changed the error return from -1 to the honest pointer value 0. The
latter change compelled a new name; "malloc" has been with us ever since.
To keep the per-byte cost of allocation low, malloc stuck with alloc's
nonzeroing policy. The minimal extra code to handle calls that triggered
sbrk had the startling property that five passes through the arena might
be required in some cases--not exactly scalable to giant virtual address
spaces!
It's odd that the later introduction of calloc() as a zeroing malloc()
has never been complemented by a similar variant of realloc().
> Am I the only one that remembers realloc() being buggy on some systems?
I've never met a particular realloc() bug, but realloc does inherit the
portability bug that Posix baked into malloc(). Rob Pike and I
requested that malloc(0) be required to return a pointer distinct from
any live pointer. Posix instead allowed an undefined choice between
that behavior and an error return, confounding it with the out-of-memory
indication. Maybe it's time to right the wrong and retire "malloc".
The name "alloc" might be recycled for it. It could also clear memory
and obsolete calloc().
Doug
Dave Horsfall:
Today is The Day of the Programmer, being the 0x100'th day of the year.
===
Are you sure you want to use that radix as your standard?
You risk putting a hex on our profession.
Norman Wilson
Toronto ON
> Today is The Day of the Programmer, being the 0x100'th day of the year.
Still further off topic, but it reminds me of a Y2K incident circa 1960.
Our IBM 7090 had been fitted with a homegrown time-of-day clock (no, big
blue did not build such into their machines back then). The most significant
bits of the clock registered the day of the year. On day 0x100 the clock
went negative and the system went wild.
Doug
