TUHS February 2025

tuhs@tuhs.org

40 participants
17 discussions

by Warren Toomey

Hi all, I've just received a set of MP3 recordings from Bob Kridle. He says: These are recordings of Ken Thompson doing a read through of one of an early UNIX kernel code listing with a group of grad students at UC Berkeley while he was a visiting prof. there. The date is roughly 1975. I've put the recordings here along with his e-mails about the recordings: https://www.tuhs.org/Archive/Recordings/1975_Unix_Code_Walkthru/ I've only just listened to the first few minutes of each. The quality is fine, but I might spend some time reducing the noise, bringing up the quiet parts and removing a few clicks and pops. If anybody else has more details of these recording, please let us know! Cheers, Warren

2 weeks, 1 day

"Webster's Second on the Head of a Pin"?

by Royce Williams

Someone I know is seeking the original version of an internal Bell Labs memo from 1974 titled "Webster's Second on the Head of a Pin" by Morris and Thompson. The topic appears to be related to improving the speed of lookups or search. It's cited in a few papers as "Unpublished Technical Memo, Bell Laboratories, Murray Hill, NJ 1974." All I can find online is citations. Any leads appreciated! -- Royce

3 weeks

Having dickens of a time compiling gcc-4.4.7 on tru64 .

by babydr DBA James W. Laferriere

Hello Anyone interested in this silliness , I am just recently trying to reacquaint myself with this os . Which I had a decent passing knowledge of at one time . Not any real OS level or driver coding , But was least decently acquainted . Now on with the preliminaries ... Any good software items to update on this ol'thing that give me a better chance of completing this task , Greatly welcome . I have folowed , ths article which is a copy from (imo) several places , tho all of them are using a axp-Emulator . <https://gist.github.com/jamesy0ung/eeac82997ebeae92873d1f2844a14ac3> I am using (I'll admit) a REAL AlphaStation 200 (4/100) with 384MB main memory & three disks all are U160's 2x4G+1x72G , OS is installed on the 72G(now) & has a /home dir for users rather that the default location . See info & error during make of gcc . Those numbers for the allocation & total have been exactly the same accross many iterations of attempts in that exact file . # sizer -v HP Tru64 UNIX V5.1B (Rev. 2650); Sun Feb 23 19:43:32 AKST 2025 It is at patch level 008 . and had successfully compiled & installed all the prerequisites shown in the article mentioned above . It Seems the OS doesn't know how to access the swap properly . root@as200:/home/buildnfs/gcc-4.4.7# env PATH=/usr/local/bin:/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/dt/bin:~/bin:. make ... many lines snipped ... /home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/xgcc -B/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/ -B/usr/local/alpha-dec-osf5.1b/bin/ -c -g -$ cc1: out of memory allocating 135816 bytes after a total of 796519376 bytes make[3]: *** [fold-const.o] Error 1 make[3]: Leaving directory `/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/buildnfs/gcc-4.4.7' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/buildnfs/gcc-4.4.7' make: *** [all] Error 2 # swapon -s Swap partition /dev/disk/dsk2g: Allocated space: 249774 pages (1.91GB) In-use space: 1520 pages ( 0%) Free space: 248254 pages ( 99%) Swap partition /dev/disk/dsk1b: Allocated space: 49152 pages (384MB) In-use space: 1630 pages ( 3%) Free space: 47522 pages ( 96%) Swap partition /dev/disk/dsk0b: Allocated space: 49152 pages (384MB) In-use space: 1618 pages ( 3%) Free space: 47534 pages ( 96%) Total swap allocation: Allocated space: 348078 pages (2.66GB) In-use space: 4768 pages ( 1%) Available space: 343310 pages ( 98%) # hwmgr show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------------------------------------------------------------------------- 42: 0 as200 cdrom none 0 1 cdrom0 [0/4/0] 43: 1 as200 disk none 2 1 dsk0 [1/0/0] 44: 2 as200 disk none 2 1 dsk1 [1/1/0] 45: 3 as200 disk none 2 1 dsk2 [1/2/0] # hwmgr -view dev HWID: Device Name Mfg Model Location ------------------------------------------------------------------------------ 3: /dev/dmapi/dmapi 4: /dev/scp_scsi 5: /dev/kevm 29: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0 42: /dev/disk/cdrom0c TOSHIBA DVD-ROM SD-M1401 bus-0-targ-4-lun-0 43: /dev/disk/dsk0c IBM DDRS-34560D bus-1-targ-0-lun-0 44: /dev/disk/dsk1c COMPAQ BD07286224 bus-1-targ-1-lun-0 45: /dev/disk/dsk2c COMPAQ ST34371W bus-1-targ-2-lun-0 46: /dev/random 47: /dev/urandom Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+

1 month

Re: Pre-Struct C Compiler with Funny Syntax Resurrected

by Douglas McIlroy

Yufeng, > I've recently brought the "prestruct-c" compiler back to "life" Great archeology! It seems you've unearthed a snapshot from the brief period when Dennis was struggling to reconcile byte addressing with BCPL pointers--the seminal innovation of C. In characteristic Unix fashion, he was trying out his ideas as they developed. I had forgotten that product types were under con-struct-ion at the same time. That really was a big bang. Doug

1 month, 1 week

Pre-Struct C Compiler with Funny Syntax Resurrected

by Yufeng Gao

Hi again, I've recently brought the "prestruct-c" compiler back to "life" (https://github.com/TheBrokenPipe/C-Compiler-Dec72) and thought it might be worth documenting here. One thing I have to say first - it's barely working and probably never worked to begin with. There were some efforts in the distant past to revive this compiler; however, the compiled compiler never worked. The reasons are as follows: - The compiled executable is too big (exceeds 32K, making pointers effectively negative). This triggers a bug in the liba I/O routines. - The compiler assumes an origin of 0 and writes temp data at the NULL pointer. Without an MMU, this kills the interrupt vectors and possibly the kernel on the 11/20. - The compiler is missing ALL code/tables written in assembly language. This is pretty fatal, and internal changes rendered files from the last1120c compiler incompatible. - Calling convention changes make the s2/last1120c libc library incompatible. I'm a big fan of the C programming language, and the reason I was so insistent on getting this compiler to work is that it has a funny struct syntax not seen in any other C compiler. Structs are defined like: struct name ( type field; ... ); ... with round brackets (parentheses) instead of curly braces. Another notable thing introduced in this compiler is that certain things are no longer lvalues. In the past (B and last1120c), functions, labels, and arrays were lvalues, meaning they could be assigned. For instance, this code: func1() { return (1); } func2() { return (2); } main() { printf("func1() = %d\n", func1()); printf("func2() = %d\n", func2()); printf("func1 = func2\n"); func1 = func2; printf("func1() = %d\n", func1()); } produces the output: func1() = 1 func2() = 2 func1 = func2 func1() = 2 This code: main() { second = first; goto second; first: printf("first\n"); second: printf("second\n"); } produces the output: first second And this code: main(argc, argv) { int arr1[10]; int arr2[10]; arr1[0] = 5; arr2[0] = 8; printf("arr1[0] = %d\n", arr1[0]); printf("arr2[0] = %d\n", arr2[0]); printf("arr1 = arr2\n"); arr1 = arr2; printf("arr1[0] = %d\n", arr1[0]); } produces the output: arr1[0] = 5 arr2[0] = 8 arr1 = arr2 arr1[0] = 8 Now, the rules of the game have changed with the prestruct-c compiler, and these are no longer lvalues. I don't know why this change was made, but if I had to guess, speed was probably the biggest driving factor, with security also playing a role. Anyhow, they're no longer lvalues, so there's now one less level of indirection involving functions and labels. This means the codegen tables from last1120c have to be modified to suit this compiler change. However, even with it generating the correct code, there is still one fatal problem - the libc. The libc from s2/last1120c was designed for the older compiler and therefore has one extra layer of indirection for functions. Luckily, the source code of the libc is available on the last1120c tape, and it wasn't too much work to remove the indirection manually. Okay, what else? Well, this compiler also seems to be the first to introduce the "modern" pointer syntax. Before this compiler, pointers were declared using the same syntax as arrays/vectors, like "char name[];". This compiler introduced the "modern" syntax of "char *name;". No big deal, right? Well, the compiler itself was written using the old syntax, meaning it cannot compile itself. I think this indicates that this compiler (or the new syntax) was so unstable that the production compiler still used the old syntax. With everything carefully put back into place, I managed to get this to work: struct foo ( char x; int y; char *z; ); main(argc, argv) char **argv; { struct foo bruh; bruh.x = 'C'; bruh.y = 123; bruh.z = "test"; printf("x = '%c', y = %d, z = \"%s\"\n", bruh.x, bruh.y, bruh.z); } However, if I rename the variable "bruh" to something like "bar", it throws the error "Unimplemented pointer conversion". I have no clue why. I've also never gotten struct pointers to work - it always complains about "Illegal structure ref" when I try to use "->". It also seems to accept "." on structure pointers (and does not actually dereference the pointer when accessing the members), so something is probably very wrong with referencing and dereferencing. Anyway, there are plenty of other issues with the compiler, like the code may not compile correctly with pointers and switch statements. I'm not sure if the issues are caused by my poor reconstruction of the assembly tables, or if the compiler itself never worked properly in the first place (or both). Either way, I've managed to get it to spit out a correct hello world, as well as the struct test above, so I think I've fulfilled my goal of seeing this compiler "work". The code, build instructions and pre-built binaries are here: https://github.com/TheBrokenPipe/C-Compiler-Dec72 Ideally, it runs under a PDP-11/45 environment with 0 as the origin and generates code for the PDP-11/45. However, I made it target the 11/20 since I couldn't get the 11/45 toolchain to work, and I haven't implemented 11/45 instructions in my simulator yet. If anyone wants to pick up the baton and get it working for the 11/45 or fix my bugs, be my guest! Sincerely, Yufeng

1 month, 1 week

Re: 1972 UNIX V2 "Beta" Resurrected

by jnc＠mercury.lcs.mit.edu

> From: Yufeng Gao > The s1 kernel is, to date, the earliest machine-readable UNIX kernel, > sitting between V1 and V2. It will be interesting to see what it reveals, as it's in the UNIX 'dark age' between V1 and V4. Working from hints and clues in the extant 'UNIX Programmer's Manual: Second Edition', I had tried to figure out how V2 differed from V1: https://gunkies.org/wiki/UNIX_Second_Edition but I was mostly interested in 'big picture' issues (like how a process'es address space was laid out), not details like 'the foo() call was added', or 'how exec() differs'. (If someone _does_ create lists of the calls in V1 and V2, and their details, and compares them, that _will_ be of value, don't get me wrong; I was mostly just trying to work out how the mysterious KS11 worked.) > It's somewhat picky about the environment. So far, aap's PDP-11/20 > emulator .. is the only one capable of booting the kernel. SIMH and > Ersatz-11 both hang before reaching the login prompt. It would be very interesting to know what fails. By 'hang', do you mean 'ceases making progress', or 'halts'? If the former, since I've almost always had good experiences with Ersatz-11, my _guess_ would be a problem with the RF11 emulation. (The RF11 was a very early, and smalll, disk, so I wouldn't be surprised if there hasn't been a lot of software run on those emulators that uses it, to flush out bugs. It's also kind of an odd duck; it's word-oriented, not block-orientd.) So, for instance, a 'lost' disk interrupt would produce this symptom. Are there any RF11 diagnostics online? That would be the thing I would start with. And I guess this system doesn't include the KS11; a pity, code that uses it would allow re-creation of the programming manual (the way the: https://gunkies.org/wiki/ANTS/ISI_IMP_Interface programming instructions were re-created). > From: Angelo Papenhoff > So the next step would be to restore the assembly source? :) Having only the binary to work from (to start with) is not optimal; those early versions of UNIX ran on a number of very different hardware configurations (e.g. with or without the KS11), with conditional assembly to handle different configurations. Having only the dis-assembled code for _this_ configuration would obviously leave the code for the others missing. Still, having _this_ source _would_ be useful; e.g. the 'hang-up' problem above; the easiest way to debug that would to put 'print' statements in the code, where a disk operation was started, and completes. If it's 'losing' a disk interrupt completion, that will show right up. (Been there, done that, on the RK11 hardware emulator Bridgham and I built, when UNIX wouldn't boot, just hung.) Although I suppose one could put break-points there. Trying to debug it any other way would be painfu beyond belief. Noel

1 month, 1 week

Typesetting ROFF/NROFF Documents

by Yufeng Gao

Hi everyone, I've cobbed together a crude Teletype Model 37 emulator that generates PDF files (https://github.com/TheBrokenPipe/Teletype-37-PDF) It produces sane-looking PDFs for most (all?) of the early UNIX ROFF/NROFF documents. The biggest advantage of this over something like "roff $1 | enscript -c -f Courier12 -l -M Letter --margins=67:-9:0:-9 -p $1.ps -s -0.05" is it supports half (forward/reverse) line feeds which enscript does not. Early ROFF stuff like the UNIX manuals and memos made extensive use of subscripts (and superscripts), making them rather painful to typeset. As an experiment, I re-set Ken Thompson's "Users' Reference to B" memo from early 1972 (https://github.com/TheBrokenPipe/kbman-reset) I picked this one because it contains a BNF-alike description of the grammar as well as fractions in code comments, both of which make extensive use of sub/superscripts. I went to the extent of overlaying the re-set pages on top of the originals to make sure everything lined up. I'd really appreciate it if someone could review my work on the B manual. If everything looks good, I may tackle other documents, starting with low hanging fruits like the "V0" manual and potentially moving on to re-setting the V1 and V2 manuals in the future (building on aap's work). Sincerely, Yufeng

1 month, 1 week

1972 UNIX V2 "Beta" Resurrected

by Yufeng Gao

Hi everyone, First-time poster here. Near the end of last year, I did some forensic analysis on the DMR tapes (https://www.tuhs.org/Archive/Applications/Dennis_Tapes) and had some fun playing around with them. Warren forwarded a few of my emails to this list at the end of last year and the beginning of this year, but it was never my intention for him to be my messenger, so I'm posting here myself now. Here's an update on my work with the s1/s2 tapes - I've managed to get a working system out of them. The s1 tape is a UNIX INIT DECtape containing the kernel, while s2 includes most of the distribution files. The s1 kernel is, to date, the earliest machine-readable UNIX kernel, sitting between V1 and V2. It differs from the unix-jun72 kernel in the following ways: - It supports both V1 and V2 a.outs out of the box, whereas the unmodified unix-jun72 kernel supports only V1. - The core size has been increased to 16 KiB (8K words), while the unmodified unix-jun72 kernel has an 8 KiB (4K word) user core. On the other hand, its syscall table matches that of V1 and the unix-jun72 kernel, lacking all V2 syscalls. Since it aligns with V1 in terms of syscalls, has the V2 core size and can run V2 binaries, I consider it a "V2 beta". login: root root # ls -la total 42 41 sdrwrw 7 root 80 Jan 1 00:02:02 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 43 sdrwrw 2 root 620 Jan 1 00:01:30 bin 147 l-rwrw 1 root 16448 Jan 1 00:33:51 core 42 sdrwrw 2 root 250 Jan 1 00:01:51 dev 49 sdrwrw 2 root 110 Jan 1 00:01:55 etc 54 sdrwrw 2 root 50 Jan 1 00:00:52 tmp 55 sdrwrw 7 root 80 Jan 1 00:00:52 usr # ls -la usr total 8 55 sdrwrw 7 root 80 Jan 1 00:00:52 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 56 sdrwrw 2 28 60 Jan 1 00:02:22 fort 57 sdrwrw 2 jack 50 Jan 1 00:02:39 jack 58 sdrwrw 2 6 30 Jan 1 00:02:36 ken 59 sdrwrw 2 root 120 Jan 1 00:00:52 lib 60 sdrwrw 2 sys 50 Jan 1 00:02:45 sys 142 s-rwrw 1 jack 54 Jan 1 00:52:29 x # ed a main() printf("hello world!\n"); . w hello.c 33 q # cc hello.c I II # ls -l a.out total 3 153 sxrwrw 1 root 1328 Jan 1 00:02:12 a.out # a.out hello world! # It's somewhat picky about the environment. So far, aap's PDP-11/20 emulator (https://github.com/aap/pdp11) is the only one capable of booting the kernel. SIMH and Ersatz-11 both hang before reaching the login prompt. This makes installation from the s1/s2 tapes difficult, as aap's emulator does not support the TC11. The intended installation process involves booting from s1 and restoring files from s2. What I did was I extracted the files from the s1 tape and placed them on an empty RF disk, then installed the unix-jun72 kernel. After booting from the RF under SIMH, I extracted the remaining files from s2. Finally, I replaced the unix-jun72 kernel with the s1 kernel using a hex editor, resulting in an RF disk image containing only files from s1/s2. This RF image is bootable under aap's emulator but not SIMH. The RF disk image can be downloaded from here (https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta) Direct link - https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta/raw/refs/heads/main/… Interestingly, its init(7) program does not mount the RK to /usr, suggesting that /usr was stored on the RF. Sincerely, Yufeng

1 month, 1 week

Unix page at the Multicians web site.

by Dan Cross

Tom Van Vleck just posted to the multicians mailing list that he is doing an update to the Unix page at multicians.org and is soliciting feedback. I figure some folks here may have useful suggestions. His draft is here: https://multicians.org/unix2.html Comments directly to Tom, I suppose, but if interested parties would rather discuss here I'd be happy to summarize and send to him as well. - Dan C.

1 month, 2 weeks

Re: Unix V10 Volume 2 PDFs

by norman＠oclsc.org

For the non-TUHS folks who don't know me, I worked in Center 1127 (the Bell Labs Computing Science Research Center) 1984-1990, and had some hand in 9th and 10th Edition Manuals and what passed for the V8-V10 `distributions.' To answer Branden's points: A. I do know what version of troff was used to typeset the 8th through 10th Edition manuals. It was the version we were using in 1127 at the time, which was indeed Kernighan's. The macro packages probably matter more than the particular troff edition. For the 10th Edition (which files I have at hand), there was an individual mkfile (mk(1)) for each paper, so in principle there was no fixed formatting package, but in practice everything appears to have used troff -mpm, with various preprocessors according the paper: prefer, tbl, pic, ideal, and in some cases additional macros and even odds and ends of sed and awk. If you wanted to re-render things from scratch you'd want all the tools. But if you have the real troff sources you'll have all the mkfiles--things were stored one paper per directory. -mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible package with special expertise in page layout. B. There was no such thing as a `release' after V7. In fall 1984 we made a single V8 snapshot. Making that involved a lot of fiddly work, because we didn't normally try to build systems from scratch; when we brought in a new computer we cloned it from an existing one. So there was lots of fiddly work to make sure every program in /bin and /usr/bin on the tape compiled correctly from the source code that would be on the tape when the cc and as and ld and libraries on the tape were used. We sent V8 tapes to about a dozen external places, few of which did anything with it (many probably never even installed it). Which makes sense, by then we really weren't a central source for Unix even within AT&T, let alone to the world. Neither did we want the support burden that would have carried--the group's charter was research, after all, not software support. So the 9th and 10th editions existed as manuals, but not as releases. We did occasionally make one-off snapshots for other parts of AT&T, and maybe for a university or two. (I definitely remember taking a snapshot to help the official AT&T System N Unix people set up a Research system at one point, and have a vague memory that I may have carried a tape to a university under a special one-off license letter.) On the other hand, troff wasn't a rapid moving target, and unlike the stars of the modern software world, we tried not to break things unless there was a real reason to do so. So I suspect the troff from any system of that era would render the Volume 2 papers properly, and am all but certain the 10th-edition-era troff would do so even for older manuals. C. Just to be clear, the official 10th Edition manuals published by Saunders College Publishing were made from camera-ready copy prepared by us in 1127 (Doug McIlroy did all the final work, I think) and printed on our phototypesetter. We didn't ship them troff source, nor even Postscript. We did everything including the tables of contents and indexes and page numbering. D. troff is indeed not TeX, and some of us think of that as a feature, not a bug. I think the odds are fairly good (but not 100%) that groff would do a reasonable job of rendering the papers; as I said, the hard part is the macro packages. I'm not sure -mpm ever made it out of Research. And there are probably copyright issues not just with the software but with the papers themselves. The published manuals bear a copyright notice, after all. Norman Wilson Toronto ON (A much nicer place than suburban NJ, which is why I left the Labs when I did)

1 month, 2 weeks

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS February 2025