
The Earliest Unix Code: An Anniversary Source Code Release - matt_d
https://computerhistory.org/blog/the-earliest-unix-code-an-anniversary-source-code-release/
======
bbanyc
I've been reading up lately on the earlier OS's that influenced Unix - the
Compatible Time-Sharing System, the Berkeley Time-Sharing System (Project
Genie), and Multics. Bitsavers.org and Multicians.org both have a lot of
information on that early era (and Bitsavers has a whole lot more).

Lots of the ideas in Unix came from those earlier systems. What Thompson and
Ritchie contributed was synthesizing these ideas into a more coherent whole,
and demonstrating that they could be made a whole lot smaller. (Both in terms
of the PDP-7 and 11/20 being smaller computers than the mainframes previous
systems were written for, and in that descriptive command names were reduced
to cryptic abbreviations. CTSS's LISTF was shortened to ls, ARCHIV to ar,
RUNOFF to roff and then nroff/troff...) And of course Unix ran on the most
popular computer of the 1970s and got rewritten in a portable language to let
it run on every popular computer since then, while just about every other OS
was tied to its specific hardware platform and died off as the hardware did.

All really fascinating stuff.

~~~
msla
Having used Multics and a farrago of other OSes (not CTSS or the Berkeley
timesharing system) as part of my retrocomputing hobby, I think the single
biggest thing Unix brought to the day-to-day experience of using an OS was the
pipe, and the concomitant transformation of the command line from just being a
way to enter program names with command line options (on OSes which even have
command line options as we know them, of course) to being a programming
language in its own right suitable for rapid prototyping and the creation of
glue code.

Glue code isn't glamorous. It isn't something which seems to get a lot of
research put into it. It is, however, important to get right, and part of
getting it right is foregrounding the right thing: The stuff you're gluing
together, as opposed to the glue itself. This is something the "replace shell
with a Real Programming Language" projects get wrong, in that the Unix shell
defaults to treating unknown barewords as external programs as opposed to
syntax errors. This plays Hell with any kind of automated analysis, but it's
essential for a language primarily intended to glue those external programs
together. Typing isn't just about the type system, after all.

TL;DR: OSes prior to Unix had surprisingly weak scripting facilities, and
attempts to "improve" scripting tend to miss the point.

------
beefhash
People are working on transcribing it:
[https://minnie.tuhs.org/pipermail/pdp7-unix/2019-October/000...](https://minnie.tuhs.org/pipermail/pdp7-unix/2019-October/000480.html)

Incidentally, wkt confirmed that's one of the two artifacts[1] which he
[teased a while ago[2].

[1]
[https://minnie.tuhs.org//pipermail/tuhs/2019-October/019106....](https://minnie.tuhs.org//pipermail/tuhs/2019-October/019106.html)

[2]
[https://minnie.tuhs.org//pipermail/tuhs/2019-September/01868...](https://minnie.tuhs.org//pipermail/tuhs/2019-September/018685.html)

------
saagarjha
> PDP-7 assembly listing for “pd”

> Unidentified program.

> Might “pd” stand for “previous directory”?

I know approximately zero PDP-7 assembly, but this looks like it might be
“print directory”, equivalent to pwd today? It seems to open its parent
“dotdot” directory and write it out.

~~~
kps
It only opens dotdot once at the start, though, and calls creat(dotdot) later.

~~~
kazinator
If dotdot can't be opened it fails. So I don't think creat was the same as
what we now know.

It looks like the code opens dotdot, and then scans through it for something
(match for dir?).

The creat call might mean "open for writing", and possibly the flags mean
append. It appears dir is appended to the dotdot directory file.

So maybe, add this "dir" entry to dotdot if it isn't there already?

I can't guess what initializes dir; maybe it somehow comes as an argument from
the command line or whatever.

~~~
Pete_D
dir appears to be copied into from tbuf at some point. It puts dir-1 into
memory location 8 at the start, and then the code around the 2: section I'm
pretty sure is a memcpy-ish loop like:

    
    
        c1 = -8;
        *9 = tbuf - 1;
        do {
            *(++(*8)) = *(++(*9));
        } while(++c1 != 0);
        goto 1b; // b for backwards?
    

It seems that memory locations 8-15 are auto-indexing[0], so the lac/dac i
increments the pointed-at location before use, and isz is "increment and skip
next instruction if zero".

[0] PDP7 manual, big PDF: [http://bitsavers.trailing-
edge.com/pdf/dec/pdp7/F-75P_PDP7pr...](http://bitsavers.trailing-
edge.com/pdf/dec/pdp7/F-75P_PDP7prelimUM_Dec64.pdf)

------
auvi
Who owns the copyright? Novell?

~~~
bsdimp
Nobody! There were no copyright notices, and this is a work made before the US
adopted the BERN convention. Prior copyright law required copyright notices.

We learned from the ATT vs Regents case that a judge ruled there was a large
likelihood that AT&T couldn't establish it had a valid copyright on V32
because they never marked it properly.

~~~
beefhash
> Nobody! There were no copyright notices, and this is a work made before the
> US adopted the BERN convention. Prior copyright law required copyright
> notices.

...in the U.S.

This does _not_ apply to other countries, especially continental European
ones. They'll happily retroactively apply copyright for software, even when it
wasn't explicitly protected by means of their jurisdiction claiming that
software has is categorized as a work even before the convention. No license,
no luck over there.

cf. [https://virtuallyfun.com/wordpress/2018/11/26/why-bsd-os-
is-...](https://virtuallyfun.com/wordpress/2018/11/26/why-bsd-os-is-the-best-
candidate-for-being-the-only-tested-legally-open-unix/)

If it's not deemed a work for hire (and given UNIX was a rogue operation at
the time, that's not entirely unreasonable to question), then the copyright
probably remains with Thompson and Ritchie themselves, or rather Thompson and
Ritchie's family (or whichever way the inheritance process went). If it is,
then probably Micro Focus via Attachmate via Novell via USL. Special
considerations may also apply because it wasn't "published" in any sense of
the world until past Ritchie's death.

------
fernly
45 pages in before I saw the first comment. whoever wrote section 8, "what may
be a simulation or game for billiards or pool", put actual one-line
descriptions before each section. Later on he gets real chatty, e.g.

    
    
        fsin: 0203 " sine of the fine rotation angle
        mfsin: -0203 " negative of fsin
    

Seriously, I bet there is a lot to be learned figuring out how he was
approximating trigonometry using 12-bit int constants.

~~~
boomlinde
It looks like there are symbols named "sin" and "cos" not declared in the
program. These are possibly system provided tables.

Accesses to "sin" and "cos" are preceded by what looks like a self modifying
store ("dac .+3", interpreted to mean "deposit accumulator at current program
counter + 3"), possibly to modify the "lac sin" and "lac cos" instructions to
index the tables, but I'm not familiar with the instruction encoding.

If so, this is a relatively straight forward, non-magic way of implementing
trigonometric functions.

------
bbanyc
>pp. 145−169 >PDP-7 assembly listings for “t1,” “t2,” “t3,” “t4,” “t5,” “t6,”
“t7,” and “t8”

>Unidentified program.

>Perhaps an interpreter for a programming language? B?

Could be TMG, the language that B was originally written in. See
[https://www.bell-labs.com/usr/dmr/www/chist.html](https://www.bell-
labs.com/usr/dmr/www/chist.html)

------
bsdimp
SIMH now has a reason to upgrade to support Graphics2: Looks like the spacewar
source uses it!

~~~
larsbrinkhoff
I'm doing this.

------
Ididntdothis
Is this written in assembly? I thought Unix was written in C and you had to
only write a C compiler to port it to other platforms. I remember that was the
story I was told.

~~~
beefhash
UNIX was written in assembly at first. By the Fourth Edition, the kernel was
rewritten to be in a version of C (that won't go through a modern C compiler
anymore), both 1973. The C compiler itself was introduced in the Third
Edition. Parts of userland would still be in assembly even until the 7th
Edition (1979), such as roff(1) (nroff/troff were in C), parts of as(1) or
chess(6).

