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.

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.

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....

[2] https://minnie.tuhs.org//pipermail/tuhs/2019-September/01868...

> 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.

So "print directory" or (print something about the) "parent directory" seem more likely to me.

But it sounds like the other commenters have figured out that it's "pack directory".

    open ..
    loop
        read a directory entry into tbuf
        if we read 0 bytes (eof presumably), break loop
        if tbuf[0] == '\0', go back to start of loop
        append tbuf to dir
    done
    close ..
    reopen .. with creat
    write the stuff we built up into dir to ..
    close ..
    exit

    int dst /*8*/, src /*9*/, c1, df, tbuf[8], dir[BIG];
    char dotdot[] = "..      ";

    df = open(dotdot, O_RDONLY);
    dst = dir - 1;
    while (read(df, tbuf, 8) != 0) {
      if (tbuf[0] != 0) {
        c1 = -8;
        src = tbuf - 1;
        do {
          *++dst = *++src;
        } while (++c1 != 0);
      }
    }
    close(df);

    df = creat(dotdot);
    write(df, dir, dst - dir + 1);
    close(df);
    exit();

According to https://wiki.tuhs.org/doku.php?id=systems:pdp7_unix ‘..’ was the name of the current directory (i.e. what is now ‘.’), so this operated on the current directory.

"Directory entries may be empty, indicated by an inode number of 0".

So if the pseudo-code is correct, this may be an utility to squeeze out those empty entries.

As for the sys write: my current hypothesis is that .. there is a placeholder for an argument which is written to by the preceding dac .+4. ('"If a program can't rewrite its own code", he asked, "what good is it?"'). But I can't make sense of what it's actually putting there - I'd guess length, but it looks like ~(dir - 2) + 8.

That took me a while. The ‘8’ in ‘tad 8' is the contents of memory location 8, i.e. the destination pointer in the memory copy, so it's ~(dir - 2) + dst. And since -x = ~x + 1 (there being no negation instruction), that works out to the length, dst - dir + 1.

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.

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

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

I think ‘dotdot’ is what is called ‘dd’ there (the corresponding symbol in ls is still named ‘dd'). I don't think the concept of a parent directory existed yet. Maybe ‘pd’ is something like ‘prepare directory’, constructing the dd/dotdot entry.

I think this is on the right track - it looks like the write call is to the newly created .., with df being used to hold the file descriptor.

I am leaning toward Pete_D's ‘pack directory’ idea.

¹ https://github.com/DoctorWkt/pdp7-unix/blob/e94417092a2980e7...

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.

...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-...

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.

That's assuming it's deemed a work-for-hire (which if it isn't makes it the property of Ken Thompson and the Ritchie estate) and that it wasn't somehow "published" before 1989 (which if it was without a copyright notice, makes it public domain - but works written before 1989 but not published until after are under copyright regardless). It's confusing stuff.

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

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.

At least it wasn't one of those people who write comments that don't align with what the code is doing.

>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

Likewise there were other high level systems programming languages being used since 1961.

The lost notable one being ESPOL, replaced a couple of years later by NEWP, both Algol derivatives for systems programming. The OS was called Burroughs B5000, used compiler intrisics with zero Assembly and is still being sold nowadays by Unisys, as ClearPath MCP.

There are other notable examples available to discover there was a decade old of other OSes and systems languages.