Live data from Hacker News

Unix Edition Zero (1971)

doc.cat-v.org

11–20 of 61 posts

Re: Unix Edition Zero (1971)

#11
seems extremely similar to modern unixes, though of course it's only a small subset

main differences seem to be

- filenames were only 8 bytes instead of 14 or 255

- devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory)

- there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x, and u+s)

- creat is spelled with an e (and evidently you couldn't open() nonexistent files)

- instead of lseek you only have seek, with a different argument order and presumably only able to handle offsets of up to 64KiB (less of a problem on a "256K word disk", which is presumably 524288 bytes, according to the note on p. 12 that a 64-word block was 128 bytes), which explains the name of lseek

- correspondingly, there were no doubly indirect blocks and so the maximum file size actually was 64 KiB

- the tty really was a tty, no video terminals!

- "i-number" and "i-node" had hyphens, and the "i" stood for "identification"

- the shell prompt was "@", and there was no control flow or pipes in the shell; it's not mentioned but I think that around this time there was a `goto` command which would seek standard input until it found the specified label before returning control to the shell. i/o redirection did exist, and so did argument quoting

- `cd` was spelled `chdir` even in the shell, and was the only shell builtin

- correspondingly, no standard error yet; the famous phototypesetter error printout had not yet happened because there were no pipes

- no shell wildcards

- no PATH, because no /usr/bin yet (they hadn't bought the /usr disk yet)

- no -o flag; `as` always wrote its output to `a.out` and you had to `mv` it if that wasn't what you wanted

- `fork()` returned to a different location in the child process, instead of returning a status value and making you test the return value. this would have saved me great embarrassment at my first sysadmin intern position when i accidentally wrote a fork bomb (by getting the test backwards) and ran it on the departmental nfs server

- no `execve`, just `execle` (called `execute`)

- no `waitpid()`, `wait3()`, etc., just `wait()`

- no `select()` or sockets of course, nor any of the other bsd niceties

- traps weren't handleable, so there was no SIGINT yet, just SIGQUIT, with the same ^\ keystroke it has today (but no way to attach a signal handler to it); no concept of tty process group (or indeed process groups at all) so ^\ could kill a random background job. but there was an `intr` system call to disable these breaks (presumably so you didn't kill the shell)

- no C yet, just B, but evidently the B compiler was already generating native code instead of stack bytecode as it had a few months before. consequently the system calls are documented in terms of machine registers and assembly instructions

- no `rename()` system call; `mv` linked and then unlinked the file

- no environment variables

- `time()` was still provided in sixtieths of a second since "the start of the current year" (so at the time the Unix epoch was the beginning of 01971, not the beginning of 01970) and was 32 bits (the AC and MQ registers)

- symbol tables were written to a separate `n.out` file

- no `ptrace()` and so no live debugging support (except for the kernel!), just inspecting core files

- `tar` is called `tap` and cannot put its archives in files other than actual physical magtapes

sadly page a7 is missing from the scan

Re: Unix Edition Zero (1971)

#14
post #11

seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…

Oddly enough, it looks both more and less featured than MS-DOS, and the PDP-11 it ran on was somewhat close to the first IBM PC in memory and CPU speed.

Some comparison points with MS-DOS 1.0:

- 8.3 filenames

- no subdirectories

- single user

- 32-bit file sizes and offsets (64k file size limit was definitely not enough by then)

- FCB-based API (not file handles), FAT12 filesystem with 32MB limit

- Hardcoded device names special-cased

- No pipes nor redirection either

- No multitasking nor TSRs

- No networking at all

- Environment variables present

- Supports dates up to 2099

- Kernel, shell, and utilities written in 100% Asm

- Live debugger (DEBUG.COM)

Re: Unix Edition Zero (1971)

#15

Earlier quoted context omitted.

and ken in the go source tree in 2009: > spell it with an "e" https://go.googlesource.com/go/+/c90d392ce3d3203e0c32b3f98d1...

Tangent: I've yet to find what I'd deem a "definitive" answer on why the 'e' was dropped. Sure, Ken said it was his biggest mistake, but every answer on why it's missing just point to the quote from him. I've seen suggestions related to a possible six-character limit (from Radix50 - "50" being octal for 64), but "creat" is only five. And being a mistake, why was it never fixed early on?

And being a mistake, why was it never fixed early on?

Maybe because it became part of the jargon and served a useful purpose --- if you mention creat, it's certain you're talking about the system call and not creation in general.

Personally, I like names which are close enough to an existing concept to be evocative of the meaning, but also distinct enough that, just like "byte" vs "bite" and "nybble" vs "nibble", a (non-stupid) search engine can give relevant results.

Re: Unix Edition Zero (1971)

#16

Earlier quoted context omitted.

and ken in the go source tree in 2009: > spell it with an "e" https://go.googlesource.com/go/+/c90d392ce3d3203e0c32b3f98d1...

Tangent: I've yet to find what I'd deem a "definitive" answer on why the 'e' was dropped. Sure, Ken said it was his biggest mistake, but every answer on why it's missing just point to the quote from him. I've seen suggestions related to a possible six-character limit (from Radix50 - "50" being octal for 64), but "creat" is only five. And being a mistake, why was it never fixed early on?

> 50 being octal for 64

Looks like 40 to me... 64 would be 100.

Re: Unix Edition Zero (1971)

#18
post #11

seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…

Oddly enough, it looks both more and less featured than MS-DOS, and the PDP-11 it ran on was somewhat close to the first IBM PC in memory and CPU speed. Some comparison points with MS-DOS 1.0: - 8.3 filenames - no subdirectories - single user - 32-bit file sizes and offsets (64k file size limit was definitely not enough by then) - FCB-based API (not file handles), FAT12 filesystem with 32MB limit - Hardcoded device n…

yeah, i think some of that was cp/m compatibility crap; too bad about 8.3

the other thing is that the pdp-11 had working segmentation, the 8086 didn't, so trapping faults in user processes so they couldn't break the kernel would have required some kind of interpretation or something

did you know microsoft was shipping xenix in 01981 (the same year they started shipping qdos/ms-dos/pc-dos) and shipping xenix for the 8086 in 01982, and that seattle computer products was selling 8086 xenix boxes in 01983

Re: Unix Edition Zero (1971)

#19
post #18

Earlier quoted context omitted.

Oddly enough, it looks both more and less featured than MS-DOS, and the PDP-11 it ran on was somewhat close to the first IBM PC in memory and CPU speed. Some comparison points with MS-DOS 1.0: - 8.3 filenames - no subdirectories - single user - 32-bit file sizes and offsets (64k file size limit was definitely not enough by then) - FCB-based API (not file handles), FAT12 filesystem with 32MB limit - Hardcoded device n…

yeah, i think some of that was cp/m compatibility crap; too bad about 8.3 the other thing is that the pdp-11 had working segmentation, the 8086 didn't, so trapping faults in user processes so they couldn't break the kernel would have required some kind of interpretation or something did you know microsoft was shipping xenix in 01981 (the same year they started shipping qdos/ms-dos/pc-dos) and shipping xenix for the 8…

The first time you zero-padded a year to five digits, I thought it was an accident, but there's two more instances of it. Why do you write 1983 as 01983?

Re: Unix Edition Zero (1971)

#20
post #11

seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…

> `tar` is called `tap` and cannot put its archives in files other than actual physical magtapes

Insofar as "everything is a file" applied at this point, could you just mv /tap0 out of the way and put a file there? If not, which of the few syscalls that had been invented so far was tap(1) using against /tap0, that couldn't be used against files?

Post reply on HN