- TUHS - www.tuhs.org

by Mychaela Falconia

Hello fellow lovers of old UNIX, After almost 20 y of intermittent development (started in the fall of 2004), I just made the first official release of my version of troff: https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.Z https://www.freecalypso.org/pub/UNIX/components/troff/qjtroff-r1.tar.gz (The .Z is the native format; the .gz is for greater accessibility.) The README file inside the tarball gives the full story, but basically it is my own derivative from classic V7 troff (not derived from ditroff, and certainly not groff) that runs under 4.3BSD and emits PostScript. Only PS output is supported, no non-PS targets of ditroff. I started it in 2004, but I still use it to this day (on a real MicroVAX running my "organically grown" 4.3BSD variant) to write various TPS reports and technical manuals etc, for my other projects that don't have much of anything to do with Ancient UNIX. For anyone who loves intricacies of troff and/or PostScript, you might find the source code quite interesting to study. :) Some Time Soon I am hoping to put out my PostScript reprint of the first 3 books of the 4.3BSD manual set (namely, URM, USD and PRM books) made with this troff. The actual book reformatting job is already done (for these 3 books, not for the other 3 yet), but I need to write new colophons to be appended (with pstmerge, a tool from my troff suite) at the end of each book. (The colophons I wrote for URM and PRM back in 2012 are in need of corrections and updates, and I didn't have the USD book done in 2012.) I will also be responding to BSW's detailed account of V7 PDF reprint in the other thread shortly - but I wanted to get this troff release out first, so I won't be in a position of saying "please look at my creation" when that creation is not publicly accessible. M~

1 year, 6 months

1
0
0 0

Re: Fred Grampp

by Brian Walden

This isn't directly UNIX related, and yes, the thread is 3 years old. But since it made national news last night, probably due to its proximity to Newark Airport. The enormous fire in Elizabeth, NJ, I recognized in the local news as the old Singer factory. That factory was the catalyst that linked me into finding out more on Fred Grampp, and his ancestry. Here's a non-paywalled link that also mentions it is indeed the old Singer factory: https://newjersey.news12.com/elizabeth-nj-fire-industrial-building On Tue, Mar 16, 2021 at 11:12 AM M Douglas McIlroy <m.douglas.mcilroy at dartmouth.edu> wrote: > > Serendipitous find! I hadn't realized that Fred had been the third > generation in the hardware store. > His father ("Pops") retired to Drayton Island in the St Johns River > about 60 miles south of Jacksonville. > Fred often visited him, driving the 19-hour trip in one stint. > > Doug > > On Mon, Mar 15, 2021 at 6:47 PM Brian Walden <tuhs at cuzuco.com> wrote: > > > > Amazing coincidences. A week prior I was researching Topper Toys > > looking for their old factory ("largest toy factory in the world") > > As there was litte on it's location and it lead me to find out > > in 1961 it took over the old Singer Factory in Elizabeth, NJ. > > So looking up the Singer factory led me to "Elizabeth, > > New Jersey, Then and Now" by Robert J. Baptista > > > > https://ia801304.us.archive.org/11/items/ElizabethNewJerseyThenAndNowSecond… > > > > Which had no information on Topper, but had had this paragraph in it's Singer > > section on page 28 -- > > > > Boys earned money "rushing the growler" at lunchtime at the Singer plant. > > German workers lowered their covered beer pails, called growlers, on ropes > > to the boys waiting below. They earned a nickel by filling them with beer > > at Grampp's saloon on Trumbull St. One of these boys was Thomas Dunn who > > later became a long term Mayor. In the early 1920s Frederick Grampp went > > into the hardware business at the corner of Elizabeth Ave. and Reid St. > > > > > > When I read it I thought funny, as I know the name Fred Grampp. But beleived > > just a coincidenental same name. After reading the biography post, I went back > > to the book as it turns out that Fred Grampp is your Fred Grampps's > > grandfather. You can find more his family and the hardware store and > > Grampp himself on pages 163-164, and 212. > > > > -Brian > > >

1 year, 6 months

2
1
0 0

Early supported UNIX manual

by Phil Budne

Rather than increase subject drift on a thread I started "UNIX on (not quite bare) System/370", here's a new thread. Since the TUHS archive seems to now include documentation, I decided to take a look and see if the earliest UNIX manual I have is in the archive: It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980) who had graduated, and worked for AT&T. It's hole punched for a four ring binder (I found an unused Bell System Project Telstar binder to put it in). The cover page has: Upper left corner: Bell Telephone Laboratories Incorperated PROGRAM APPLICATION INSTRUCTION Upper right corner: PA-1C300-01 Section 1 Issue 1, January 1976 AT&TCo SPCS Center: UNIX PROGRAMMER'S MANUAL Program Generic PG-1C300 Issue 2 Published by the UNIX Support Group January, 1976 The preface starts with: This document is published as part of the UNIX Operating System Program Generic, PG-1C300 Issue 2. The development of the Program Generic is the result of the efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift, G. C. Vogel and I. A. Winheim. and ends with For corrections and comments please contact C. D. Perez, MH 2C-423, Extension 6041. Not knowing who else I could ask, I brought it to a Boston Usenix (in the 90's or oughts), and asked DMR if he could identify it. He said it was an early supported UNIX, and he signed the preface page for me. The manual has sections I through VIII; all manual pages start with page -1- I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_ja… with cover page: UNIX PROGRAM DESCRIPTION Program Generic PG-1C300 Issue 2 Published by the UNIX Support Group January 1976 contents: NUMBER ISSUE TITLE PD-1C301-01 1 Operating System PD-1C302-01 1 Device Drivers Section 1 PD-1C303-01 1 Device Drivers Section 2 And consists of descriptions of kernel functions. So it seems likely that my manual is a companion to that. I have a Brother printer/scanner, but the paper is fragile, so unless it's of immediate and burning value to someone, it's unlikely to rise to the top of my ever-static list of documents to scan.... But if someone has specific questions I can look up, let me know....

1 year, 6 months

5
11
0 0

Re: Original print of V7 manual?

by Douglas McIlroy

>> What was the physical form of this book? Was it a "perfect bound" >> book? > The HRW copies I have are perfect bound. But I can't remember if they > were 3-hole punched as well. The Holt Rinehart edition was 3-hole punched. The original V7 (and its predecessors) were prepared for AT&T standard 4-hole binders, but distributed in Accopress binders that used only 2 of the 4. 4-hole paper was punched 2" and 3 3/8" from top and bottom of 11" paper. This reduced the stress concentration that makes the isolated end holes in 3-hole paper vulnerable to tearing out. It was a let-down when AT&T eventually acceded to a sort of loose-leaf Gresham's law and switched to 3 holes. Doug

1 year, 6 months

1
0
0 0

plan9 c / vax

by Steve Simon

1 year, 6 months

1
0
0 0

Lost Origins of the Plan 9 C Compiler

by Aram Hăvărneanu

The Plan 9 C compiler must predate Plan 9 and therefore it must have been created on Research Unix. The v10 manual doesn't mention them, fair enough, they document Unix and not Plan 9, but they do say that rc(1) is the Plan 9 shell... Research Unix of the time ran on VAX. A natural question arises, was VAX the original target of the Plan 9 compilers? Where is it? Why isn't it mentioned anywhere? If VAX was never a target, then what was the original purpose of these compilers and how were they tested on a target that Research Unix never ran on? One might think they might have been used for the Jerq/Blit/DMD-5620, but no, the Unix manual documents a different compiler used for these (which is distinct from the main C compiler). The Plan 9 compilers seems to have appeared out of thin air, but this certainly can't be the case. -- Aram Hăvărneanu

1 year, 6 months

4
4
0 0

3B2/400 and Documents on eBay

by segaloco

Wanted to share this in case anyone is in the market for one. Someone's posted a 3B2/400 to eBay along with many documents and some peripherals and such. Kicker is it's $2,000 altogether... https://www.ebay.com/itm/186237940947 Way outside what I'm wiling to sink into one, although a 3B2 would be very nice to have around. Anywho, figured I'd spread the word in case someone in the far flung UNIX-verse is seeking one and has the funds to spare. - Matt G.

1 year, 6 months

1
0
0 0

1998 UNIX RTR Reference Manual (And Other 5ESS-2000/3B20D Stuff)

by segaloco

Got some exciting stuff in the mail today, and for once it isn't going to amount to sitting in front of a scanner for hours: https://archive.org/details/5ess-switch-dk5e-cd-1999-05 After the link is the April/May 1999 issue of the 5ESS-Switch DK5E-CD, a collection of documents and schematics concerning the 5ESS-2000 variant of the 5ESS switch, as supported at the time by Lucent-Bell Labs. Of particular UNIX interest is the following: https://ia601200.us.archive.org/view_archive.php?archive=/12/items/5ess-swi… This is the November 1998 issue of the 5ESS-2000 Switch UNIX RTR Operating System Reference Manual (235-700-200, Issue 7.00). From the text it appears to be a descendant of the standard UNIX literature, although it only contains the intro, basic info, section 1, as well as a section on administration as well as an EMACS paper. It alludes to a more complete manual although I have not located that in this document collection (granted I'm busy on a work thing right now, just taking the time to upload and spread the word ATM.) There's probably plenty of other relevant stuff in there, plus plenty of content regarding the 5ESS and 3B20D generally. These CDs were included with a paper binder of installation and identification info. The binder appears to be largely for training programs and I have yet to verify whether its contents are included in these CDs or the two supplement each other. Either way, this should present plenty of leads on more potential sources of 5ESS, 3B20D, and maybe UNIX RTR stuff. Unfortunately the discs only seem to contain documents, there wasn't the holy grail of a snapshot of UNIX RTR in there that I was kinda hoping might be bumping around. Thus the hunt for 3B20 UNIX continues... - Matt G. P.S. This is a bit more modern than what I've been dealing with generally, hopefully given the current state of 5ESS and Nokia-Bell Labs seeming to be winding things down, that means this isn't a problem to have put up. I just urge caution on any use of this stuff that even remotely smells of commercial activities, but I probably don't have to tell anyone that. Just covering my bases.

1 year, 6 months

1
0
0 0

Re: [COFF] Intel ME, UEFI, User Control was Re: Question about BSD disklabel history

by segaloco

[TUHS bcc, moved to COFF] On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote: > For whatever reason, intel makes it difficult to impossible to remove > the ME in later generations. Part of me wonders if the general computing industry is starting to cheat off of the smartphone sector's homework, this phenomenon where whole critical components of a hardware device you literally own are still heavily controlled and provisioned by the vendor unless you do a whole bunch of tinkering to break through their stuff and "root" your device. That I can fully pay for and own a "computer" and I am not granted full root control over that device is one of the key things that keeps "smart" devices besides my work issued mobile at arms length. For me this smells of the same stuff, they've gotten outside of the lane of *essential to function* design decisions and instead have now put in a "feature" that you are only guaranteed to opt out of by purchasing an entirely different product. In other words, the only guaranteed recourse if a CPU has something like this going on is to not use that CPU, rather than as the device owner having leeway to do what you want. Depends on the vendor really, some give more control than others, but IMO there is only one level of control you give to someone who has bought and paid for a complete device: unlimited. Anything else suggests they do not own the device, it is a permanently leased product that just stops requiring payments after a while, but if I don't get the keys, I don't consider myself to own it, I'm just borrowing it, kinda like how the Bell System used to own your telephone no matter how many decades it had been sitting on your desk. My two cents, much of this can also be said of BIOS, UEFI, anything else that gets between you and the CPUs reset vector. Is it a nice option to have some vendor provided blob to do your DRAM training, possibly transition out of real mode, enumerate devices, whatever. Absolutely, but it's nice as an *option* that can be turned off should I want to study and commit to doing those things myself. I fear we are approaching an age where the only way you get reset vector is by breadboarding your own thing. I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for. For me the key point of contention is choice and consent. I'm fine having this as a selectable option. I'm not fine with it becoming an endemic "requirement." Are we there yet? Can't say, I don't run anything serious on x86-family stuff, not that ARM and RISC-V don't also have weird stuff like this going on. SBI and all that are their own wonderful kettle of fish. BTW sorry that's pretty rambly, the lack of intimate user control over especially smart devices these days is one of the pillars of my gripes with modern tech. Only time will tell how this plays out. Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this. People just want I push button I get Netflix, they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new... - Matt G.

1 year, 6 months

1
0
0 0

Question about BSD disklabel history

by Grant Taylor

Hi, I've found myself wondering about partitions inside of BSD disk labels. Specifically, when and where was the convention that "a" is root, "b" is swap, etc? I also understand the "c" partition to be the entire disk, unless it isn't, at which point it's the entire slice (BIOS / MBR partition) containing the BSD disklabel and "d" is the entire disk. I also found something last night that indicated that OpenBSD uses disk labels somewhat differently than FreeBSD. Aside: This is one of the dangers of wondering how something curious came to be and why it came to be when working on 10-15 year old FreeBSD systems. -- Grant. . . .

1 year, 6 months

16
42
0 0

Sad news: Niklaus Wirth

by Dan Cross

[TUHS as Bcc] I just saw sad news from Bertrand Meyer. Apparently, Niklaus Wirth passed away on the 1st. :-( I think it's fair to say that it is nearly impossible to overstate his influence on modern programming. - Dan C.

1 year, 6 months

1
0
0 0

Re: Question about BSD disklabel history

by norman＠oclsc.org

Disk sections (I don't think anyone in Research called them partitions--certainly the Research manuals didn't) were originally defined in the device driver, not by data on the disk. In those days, system management included recompiling stuff, including the OS kernel, and it was not unusual for sites to edit hp.c or whatnot to adjust things to local preference. There was nothing magic about the mapping between device names and minor device numbers either; the system came with certain conventions on the original tape, but it was not at all uncommon to change them. By the time I arrived at the first Unix site I ever helped run, in a physics group at Caltech, we already used a different naming convention: a BSD-like ddNs, where dd was a driver name, N the physical drive unit number, s a section letter. I don't know whether that was borrowed from BSD (it must have started during the 3BSD era, since I started there in mid-1980 and 4BSD appears to have been released late in that year). Looking at my archival copy of that much-locally-hacked source tree, I see that we later moved the definitions of all the disk-section tables to a single file compiled at system-configuration time (we used a USG-like scheme that compiled most of the system into libraries, rather than compiling every file separately for each target system a la V7 and BSD). That simplified handling our somewhat- complicated disk topology: all but system disks were connected through System Industries 9400 disk controllers, which were a neat design (each controller could interface to as many as four hosts and four disks) but in practice were not always reliable. On one hand, we arranged for one disk to be used in parts by our main time-sharing VAX and a subsidiary PDP-11/45, making the 11/45 cheaper to keep around; on the other, the main VAX had two paths to each of its disks, through different SI controllers, so when an SI controller conked out we could run without it until the service guys fixed it. (Each disk was dual-ported, as was common in the SMD world, hence connected to two controllers.) Reliability took rather more work in those days. A different data point: by the time I moved from California to New Jersey and joined 1127, Research was also using a different naming scheme for disk sections. By then the internal naming convention was e.g. ra17 for physical unit 1, section 7; by further convention 7 (the highest-numbered section). At some point a little later we added an ioctl to set the starting block and size of a particular section on a particular drive, but we never went to having the OS itself try to find a label and trust its contents (something that still makes the 1980s part of me feel a little creepy, though 21st century me has come to terms with it). Norman Wilson Certified old fart Toronto ON

1 year, 6 months

1
0
0 0

Early 70's WECo "Turnkey Systems"? Re: S.S. Pirzada UNIX Paper

by segaloco

In S.S. Pirzada's 1988 paper[1], page 35, section 3.3.2, he writes: "Some operating telephone companies and the switching control center system (SCCS) group in Holmdel, NJ decided to use UNIX to collect maintenance data from their switches and for administration purposes. Other departments also started building applications on top of UNIX, some part of turnkey systems licensed by Western Electric (WECo)." This is describing the situation before the establishment of USG in September 1973. I'm curious, does anyone recall what some of these pre-USG WECo "turnkey systems" were? The things that come to mind when I think of that phrase don't come about for several years, such as the 5ESS and other work surrounding Bellmac stuff. The SCCS UNIX connection describes what becomes CB-UNIX if I understand the situation correctly, but that stays a bit afield from the more conventional pool that is dipped into for WECo needs. Switching and UNIX all kinda come back together with DMERT on 1A/3B-API and 5ESS, but again that's late 70s R&D, early 80s deployment, not this time period, leaving me terribly curious what WECo would've been bundling UNIX with and shipping out to telcos. The famous early use of UNIX in the Bell System is typography, and WECo did have involvement with Teletype equipment, so perhaps something along those lines? If it helps set the scene, a binder I recently picked up from ~1972 describing Western Electric test sets distributed to telcos describes the following additional classes of such documents: Shop Services - Special non-standard products Public Telephones - System standard public telephone equipment Data Communications - Teletypewriter and Data Sets Subscriber Products - System standard PBX's, station equipment and special services Non-Subscriber Products - Microwave, cable, power equipment, etc. Non-Bell Equipment Index - Non-Bell System manufactured communication equipment Unfortunately haven't seen any of the other binders yet but I've been keeping an eye out, one or another might describe something WECo was shipping around that had some UNIX up in it. Nothing in this binder seems computer-y enough to run an operating system, just lots of gauges, dials, and probes. Luckily it is quite clear what data test sets are designed for 103-data set maintenance so I have fodder for seeking Dataphone tools... Anywho, happy soon to be new year folks, I'm excited to see what turns up next year! - Matt G. [1] - https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pi…

1 year, 6 months

3
2
0 0

Trying to compile cron

by KenUnix

Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 and am apparently missing required libraries. The reason is on the 3b2-400 after boot up it complains there is corruption in the crontab for every user lp, sysadm, root and so on. # make cron cc -O cron.c -o cron undefined first referenced symbol in file el_add cron.o el_delete cron.o el_empty cron.o el_first cron.o el_init cron.o xmalloc cron.o el_remove cron.o num cron.o days_in_mon cron.o days_btwn cron.o ld fatal: Symbol referencing errors. No output written to cron *** Error code 13 Stop. Does anyone have these libraries? Thanks. -- WWL 📚

1 year, 6 months

5
5
0 0

Re: Trying to compile cron

by Brian Walden

As I messed with making a custom cron in the late 80s, remembered the the el_ functions are for event list processing. But you didn't specify the source of your source, by the hardware it needs to be of System V heritage. And a lot of that source is hard to offically come by due to licensing. Good way to view old SVR4 is to look at OpenIndiana, Illumos, or OpenSolaris code bases that you can find. You're in luck, as TUHS has a copy, see -- https://www.tuhs.org/cgi-bin/utree.pl?file=OpenSolaris_b135/cmd/cron/elm.c Look at the Makefile for the other files you need to compile into it too. -Brian KenUnix wrote: > Hi. I am trying to compile cron for the 3b2-400 and 3b2-700 > and am apparently missing required libraries. The reason is > on the 3b2-400 after boot up it complains there is corruption > in the crontab for every user lp, sysadm, root and so on. > > # make cron > cc -O cron.c -o cron > undefined first referenced > symbol in file > el_add cron.o > el_delete cron.o > el_empty cron.o > el_first cron.o > el_init cron.o > xmalloc cron.o > el_remove cron.o > num cron.o > days_in_mon cron.o > days_btwn cron.o > ld fatal: Symbol referencing errors. No output written to cron > *** Error code 13 > > Stop.

1 year, 6 months

1
0
0 0

Historic "Communications Etiquette" Practices?

by segaloco

Good time of day folks, I often ponder on people's attachments to pixels on the screen that come about by clicking *this* icon and typing in a box surrounded by blue and with an icon in position <xyz> vs pixels on the screen that come about instead by opening that application that is a black border with a little paper airplane button in the bottom right vs....etc. To make it more clear, I find myself often confused at people treating email different from SMS different from social media DMs different from forum posts different from some other mechanism that like literally all the others is pixels arranged into glyphs on a screen conveying an approximation of human speech. This difference among these different ways to send said pixels to people has eluded me all my life despite working with technology since I was a tot. What this has me curious on is if in the early days of UNIX there were attempts at suggesting which provided communication mechanisms were appropriate for what. For instance something that smells of: It is appropriate to use mail(1) to send a review of a piece of work vs it is appropriate to use write(1) to ask Jim if he wants to take a lunch break before the big meeting. Did this matter to people back then like it seems to now? To me it's just pixels on a screen that are there when I look at them and aren't when I don't. Truth be told I am hoping to learn something from this because I only do a couple email lists and web forums, my social life generally does not involve SMS, phone calls, nor social media. Where it has become tedious is someone I meet who seems to want to communicate over pixels on screens is then put off when I provide them an email address, usually asking instead if I have a Facebook or whatever the kids are calling Twitters today. The few times I've tried to explain email will be me transmitting you communication as pixel glyphs on a screen just like anything else would be me transmitting you communication as pixel glyphs on the screen, this doesn't diffuse their concerns any, they then just think there is something wrong with me for comparing words as pixels on a screen to words as pixels on a screen. Granted, I've probably avoided plenty of vapid people this way, but it feels like it's becoming more and more expected that "these pixels on the screen in *this* program are only for this and those pixels on the screen in *that* program are only for that". Is this a recent phenomenon? Has communication over electronic means always had these arbitrary limitations hoisted on it by the humans that use it? Or did people not give a hoot what you sent over what program and actually cared more about the words you're saying than the word you typed at a terminal to then be able to transmit words? I doubt what I learn is going to royally change my approach to allowing technology in my irl social life, but it would be nice to at least have more mental ammo when someone asks to be friends online and then gives me mad sideeye when I go "sure here's my email address!" - Matt G.

1 year, 6 months

2
1
0 0

DMD 5620 mouse available

by arnold＠skeeve.com

... at a rather high price: https://www.ebay.com/itm/265518759380?hash=item3dd226bdd4:g:8gUAAOSwW21h8N7… :-) Arnold

1 year, 6 months

6
6
0 0

PDP-7 and Interdata 8/32 Bell System UNIX Installations?

by segaloco

Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point? My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX. Thanks for any info! - Matt G.

1 year, 6 months

4
3
0 0

Off topic: BSD timezone function vs. POSIX timezone variable

by Aharon Robbins

Hi All. This is a bit off-topic, but people here are likely to know the answer. V7 had a timzone function: char *timezone(int zone, int dst); that returned a timezone name. POSIX has a timezone variable which is the offset in seconds from UTC. The man pages for all of {Net,Free,Open}BSD seem to indicate that both are available on those systems. My question is, how? The declarations for both are given as being in <time.h>. But don't the symbols in libc.a conflict with each other? How does a programmer on *BSD choose which version of timezone they will get? Feel free to reply privately. Thanks, Arnold

1 year, 6 months

5
4
0 0

Loud machines (was Compatibility Question)

by Douglas McIlroy

> Paul -- you left out the other "feature" -- the noise, which was still deafening even with a model N1 and its cover. It was indeed loud, but GE out-roared them with a blindingly fast card reader. The machine had a supposedly gentle touch; it grabbed cards with vacuum rather than tongs. But the make-and-break pneumatic explosions sounded like a machine gun. A noise meter I borrowed from the Labs' tool crib read 90db 6 feet away. Doug

1 year, 6 months

3
2
0 0

Compatibility question

by KenUnix

I have been working with a VAX780 sim running Unix System V r2 VAX780 and am having strange issues. TERM is defined at vt100 When firing up vi at times the cursor is positioned in the wrong place or when inserting text it over writes areas on the screen. I have tried vt100, vt100-am, vt100-nam and none work as expected. Any ideas? Thanks -Ken Happy holidays -- WWL 📚

1 year, 6 months

20
30
0 0

Re: PDP-7 and Interdata 8/32 Bell System UNIX Installations?

by segaloco

Thanks Ken! I hadn't, even considered the PDP-15. Looks like SimH supports it, that could make for an interesting project... - Matt G. On Monday, December 18th, 2023 at 6:12 PM, Ken Thompson <kenbob(a)gmail.com> wrote: > the pdp-7 was run on the almost compatible > pdp-9 and pdp-15 computers. > i dont think that version of unix ever made > it out of the research department. > > On Mon, Dec 18, 2023 at 5:54 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote: > >> Are there any documented or remembered instances PDP-7 or Interdata 8/32 UNIX being installed on any such machines for use in the Bell System aside from their original hosts? Along similar lines, was the mention of PDP-7 UNIX also supporting the PDP-9 based solely on consistencies in the architecture or did this early version of UNIX actually get bootstrapped on a real PDP-9 at some point? >> >> My understanding of the pre-3B-and-VAX landscape of UNIX in the Bell System is predominantly PDP-11 systems, but there was also work in the late 70s regarding 8086 hosts as evidenced in some BSTJ and other publications, and there is the System/370 work (Holmdel?) which I don't know enough about to say whether it technically starts before or after UNIX touches the VAX. >> >> Thanks for any info! >> >> - Matt G.

1 year, 6 months

1
0
0 0

Re: Compatibility question

by David Arnold

> On 17 Dec 2023, at 13:02, KenUnix <ken.unix.guy(a)gmail.com> wrote: -8<— > I have tried vt100, vt100-am, vt100-nam and none > work as expected. I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine. Maybe worth a shot? d

1 year, 6 months

10
11
0 0

Sad news: Bell Labs leaving Murray Hill.

by Dan Cross

I'm sure this is already known, but Nokia is relocating Bell Labs to New Brunswick. Goodbye, Unix Room! https://www.roi-nj.com/2023/12/08/real_estate/nokia-bell-labs-is-moving-to-… - Dan C.

1 year, 6 months

10
11
0 0

Possible Moment of u_man/a_man Split

by segaloco

Somewhere between UNIX Release 3.0 and Release 4.1, a portion of the User's Manual was split off into a separate Administrator's Manual, leading to a reordering of the sections among other things. In the directories, these pieces would be placed in u_man and a_man respectively. There may be some evidence of the manual being intact as of 4.0 or at least not completely separated. I've found consistently that references to manpages in the Documents for UNIX Release 4.0 collection follow their pre-split numbering and all refer to the User's Manual. The catch is that all references are to the UNIX User's Manual Release 3.0, so this may not point conclusively to the state of /usr/man on disk at the time. The Release 4.1 Administrator's Manual hasn't turned up yet but the User's Manual reflects the renumbering and is less the a_man pages. To complete the circle, the various Release 5.0 revisions of the documents do refer to the Administrator's Manual where appropriate. Was the manual getting split up of any great shock or was it to be expected as the software grew? It would come to happen again between SysV and SVR2 with p_man. Out of curiosity I checked how my own manpage set is organized, it seems to be of the research order, with special files in section 4 rather than section 7 for instance. I've never studied how far reaching the different orders are. - Matt G.

1 year, 6 months

1
0
0 0

BSTJ DMERT "Programs From Other Processors" Comment

by segaloco

In a BSTJ article[1] it is said "The availability of a simulated UNIX operating system in DMERT allows UNIX programs from other processors to execute on the 3B20D Processor." Does this just mean C programs which are rebuilt or is there some implication DMERT's particular UNIX environment featured some sort of emulation facilities? I may be reading too much into it... - Matt G. [1] - https://archive.org/details/bstj62-1-303/page/n11/mode/2up P.S. I learned I may walk past DMERT and a 3B20D most days, there's a long-operational telephone CO on my usual walk that through referencing public records I've discovered has a WECo 5ESS up in it somewhere. That's all the listing said, dunno if WECo is given as meaning an early model or just a generic name. Either way...so close yet so far, makes me ever so curious what dusty old bookshelves in that building might hold.

1 year, 6 months

1
0
0 0

Re: Sad news: Bell Labs leaving Murray Hill.

by jnc＠mercury.lcs.mit.edu

> From: Ken Thompson > someone rewired someones desk lamp. i dont know how that worked out. Sometimes electrical 'jokes' don't pan out - in a big way. I was hacking the light switch in Jerry Saltzer's office (I don't recall exactly what I was planning; IIRC, something mundane and lame like flipping it upside down), and as I took it out of the box, the hot terminal touched the side of the box (which was, properly, well grounded). The entire 5th floor powered down. What had happened was that the breaker for Jerry's office probably hadn't been tripped in decades (maybe since it was put in), and it was apparently a little sticky. Also, the floor had originally been wired back when all that most people had in their offices, in the way of electrical load, was an incandescent desk lamp or so. Now, most offices had, not just a couple of terminals, most also had an Alto - greatly increased overall load. The total draw for the whole floor was now very close to the rating of the main breaker for the whole floor - and my slip of the hand had put it over. And that one _wasn't_ sticky. The worst part was that when we looked in the 5th floor electrical closet, we couldn't find anything wrong. An electrician was summoned (luckily, or unluckily, it was daytime; not having access to a 5th floor master, we'd gone in while everything was unlocked - daytime), and he finally located the breaker responsible - in an electrical closet on the 9th floor. I got carpeted by Jerry, when he got back; I escaped without major punishment,in part, IIRC, because I pointed out that I'd exposed a previously-unsuspected issue. (I have this vague memory that the wiring on the 5th floor was upgraded not long after.) That wasn't the only historic CS building that has been abandoned. 545 Technology Square, one-time home of the Multics project, the MIT AI Lab, and much else (including the above story) was exited by MIT some years ago. There, too, some history was abandoned - including the hack that allowed people to call the elevators to their floor from their terminals. (Some hackers had run some carefully disguised wires up into the elevator controller - ran them along the back of structural members, carefully hidden - and thence to the TV-11 that ran all the Knight TV bit-mapped displays attached to the AI ITS time-sharing machine. So from a Knight TV console, if you typed 'Escape E', it called the elevator to your floor - the code: https://github.com/PDP-10/its/blob/master/src/system/tv.147 even has a table - at ELETAB: - giving which floor each console was on, so it got called to the correct floor. I wonder what happened to that when the Knight TV system was ditched? Did it get moved to another machine? Actually, I have a dim memory that the elevator people found it, and it was removed.) Noel

1 year, 6 months

3
2
0 0

Re: Sad news: Bell Labs leaving Murray Hill.

by norman＠oclsc.org

ken.unix.guy(a)gmail.com: A company I used to work for was vacating a building. I asked, has anyone checked under the raised floor tiles? The answer was no. Well I did and found a lot of history down there. From component parts from long forgotten systems to water cooling lines for long gone IBM heavy metal and a ground window. === I bet you didn't find a bowling ball. Norman Wilson Toronto ON

1 year, 6 months

2
1
0 0

Some Wiki Documentation of...Documentation

by segaloco

After much saying I would and never getting around to it, I've finally started filling out a bit of documentation on the various UNIX manuals I've been tracking down, fleshing out history around, tracing bibliographic references though, etc etc. https://wiki.tuhs.org/doku.php?id=publications:manuals Thus far I've got the research and CB pages filled out from available information, and PWB/commercial up through about '85-'86, give or take some things. I apologize in advance if I've omitted your favorite piece of trivia or got something wrong, please suggest corrections in any areas needing them, or even better, a Wiki is a communal resource so with Warren's OK, I'm sure you can also make contributions. Most of the pictures are from my own library, although I've added a few others from thing around the net. There are links to various documents covered, TUHS content where most appropriate, a few archive.org and bitsavers links here and there. I don't intend to include links to any documents after System V's initial 1983 run, just pictures of covers for ease of identification. I've already mentioned a few times but I highly encourage contributions. I intend to do another round at this sometime soon and round out at least the BSD stuff and later System V. If anyone else has photographs or documents they think should be in these articles and you don't want to do the Wiki part yourself, feel free to send me stuff and I'll make sure it gets put up there. Finally, some reflection on the path here. "What was UNIX System IV" was one of those questions that plagued my mind for a long time, much before I knew much else about the history of UNIX. Not a crucial question by any means, but it was one of those little mysteries I always wanted to know more about, which is what then lead me to trying to find Release 4.0 documents and all that. Of course, that then lead to the rabbit hole of continuing to turn stuff up, I never imagined I'd actually be successful in trying to turn up more info on that version, let alone then continuing to find little pieces of history and slot in missing parts of stories. Along the way I've learned more about this darn operating system than I ever intended on learning and now feel net gain in several areas of my study. Plus, all this Bell System proximity is largely responsible for my interests in telephony as of late, and may come full circle in the gear I got for telephone experiments helping me resurrect this poor UNIX PC I've got sitting on the floor right now. I don't know what I would've been doing with so much of my free time the past few years otherwise, especially these colder months. Hope folks enjoy the commentary! - Matt G. P.S. Combing over things for this, I've found a few more pieces of the UNIX/TS puzzle. The details are in the Release 3.0 section of the PWB/Commerial page linked above. Short of it is there are some interesting "leaks" of the name "UNIX/TS" into Release 3.0 documentation, inconsistently between the sources on the UNIX tree and the physical document I recently obtained.

1 year, 6 months

2
1
0 0

Re: Sad news: Bell Labs leaving Murray Hill.

by Douglas McIlroy

Really sobering is the estimate that it will bring 1000 jobs to New Brunswick. That's a small fraction of the capacity of Murray Hill. On the upside is proximity to Rutgers. Contrary to what the article said, Murray Hill does not date from the Labs' foundation in 1925. The Labs was in the meat-packing district on West Street in New York in a building now called Westbeth, said to be the world's largest artist community. The High Line runs right through it. I worked there one summer in the penthouse with a fine view of ship traffic on the Hudson. Murray Hill opened in 1941 and West Street closed in about 1967. > Goodbye, Unix Room! The Unix Room was dismantled some time ago, but its quirky contents were grabbed by the Labs archivist, who had them on display at the Unix50 celebration--pink flamingo, G. R. Emlin, CCW clock and all. I wonder whether these relics will make the move. Doug

1 year, 7 months

2
1
0 0

Interesting 3B2 Manual on eBay

by segaloco

Spotted this this morning: [https://www.ebay.com/itm/186172178090](https://www.ebay.com/itm/18617217809… After the link is a "Western Electric 3B2 Model 300 C Programming Language Manual". The manual is from Februrary of 1984 and is of the same visual motif as the System V manuals for the 3B5 as well as DWB documentation released at the time, this motif being a small grey binder with a large orange square in the middle (as opposed to small grey binders with the AT&T death star motif that were contemporary to this time as well.) After these two cover styles, which follow the grid patterns System V original documentation, ATTIS then switches to the red covers that are seen throughout the rest of the 80s until the blue SVR4 books and the kinda criss-crossy grid pattern found on their late 80s stuff (not just UNIX, I've seen a similar motif on documentation shipped with AT&T telephones of the period, but in grey) Interestingly, despite the date, it is still labeled Western Electric, which is strange because the 3B5 manual I have is from 1983 I'm fairly certain but doesn't have "Western Electric" on the cover. Maybe there were mixed stocks of the professionally printed binder covers from the 1982-1984 timeframe with and without WECo branding at the same time. In any case, this one is still in the plastic and even has the 5 1/2 floppies with the SGS and other C support bits (and AT&T death star logos.) I don't plan on getting this as it's just a pinch later than where my focus is right now, but figured I'd mention it on list in case someone is looking for something like this. I got everything I needed from the pictures. - Matt G.

1 year, 7 months

1
0
0 0

Apologies, I Owe Someone On List a V7 Manual Binder Set

by segaloco

Something seems to have slipped through my recordkeeping, someone on list had spoken up with an interest in a free set of vintage V7 manual binders I got in a set of stuff from MIT Lincoln Labs. If you originally spoke up I'm sorry I've misplaced the email in which you sent me your shipping address. I've still got the binders and am finally in a place I can focus on putting my next post-office trip together. I'm a non-vehiculite so I tend to hold until I've got a few things to mail before packing a bag to carry down to the post-office. I do intend to make good on sending this to the first person that had spoken up last time (and I think you're the only person that bit) but if it gets to be several weeks out and I haven't heard from you (but have heard from anyone else) it may find a different destination. I'll give a few weeks though, not trying to rescind this and hand it to someone else instead. By the by just a reminder that this isn't a completely stock V7 manual, the Volume 1 manpages have a few additions such as the RAND editor and some other odds and ends. IIRC the only base page that has been replaced (as opposed to added pages) should be od(1). - Matt G. P.S. Just to raise the awareness for the more collector-y types, it looks like there is a relatively thorough SVR4 (blue books) manual set bumping around on eBay right now. The catch, it's going for $1,500, which as an owner of a comparable subset and some they're missing, I feel that is overkill and then some...but I don't understand nor want to understand the collector market. Anywho, if this is something your library is burning to include and you're looking to make a donation to that person's retirement fund...then they're up and ripe for the taking. In any case, this set is not complete, not that they're implying that, but I could only really see selling a truly, verifiably complete collection for that sort of asking price. These are a mismash of 3B and 386 versions and the set is missing some odds and ends like the master index, SVID, and any ABI documents. https://www.ebay.com/itm/204564417674

1 year, 7 months

1
0
0 0

ULTRIX-11 Network Revamp

by Jacob Ritorto

The network code in ULTRIX-11 v3.1 dies on me a lot and the scripts to set it up assume classed subnets still. Would anyone want to work with me to revamp it? I kind of need a mentor in such things but "used to be" a decent c programmer. Large ask, I know. I think the first thing would be to troubleshoot it enough to understand what's breaking (which I dont know know enough ULTRIX to do myself, but would probably pick it up quick with the company of an expert), then to replace the ailing pieces of code. Should be a reasonable scope for someone here, I bet. Over my head. But I'm happy to do all the housekeeping / gruntwork / announcing, documenting, etc. and I'm eager to learn your techniques! thanks! jake P.S. If this belongs not on this list but somewhere like cctalk, please say so and I'll take it there instead.

1 year, 7 months

1
0
0 0

Some New Scans

by segaloco

I'm finally back to my scan pile and have a few to share: https://archive.org/details/unix-system-document-processing-guide First is the UNIX System Document Processing Guide. This is the version of the TROFF et. al. documentation distributed for Release 5.0 as well as the initial release of System V. This contains the expected papers on NROFF/TROFF, MM, Eqn, Tbl, and other bits and pieces like viewgraph macros. These documents appear to be revisions of the various technical memoranda distributed as UNIX papers over time. I think this just leaves the Support Tools Guide as far as unscanned initial System V documents. I have this so just need to get it on my scanner and then the initial System V documentation run should be completely preserved out there on the net. https://archive.org/details/we-november-december-1981 Second is a copy of WE Magazine from November-December 1981. Distributed to Western Electric employees, this issue of the magazine has a cover story on the installation of the very first central office 5ESS in Seneca, Illinois on July 1st, 1981. The piece goes into some local reactions to installation day, some technical details of 5ESS, and has some nice pictures of the unit being unloaded and moved into place. There are additional articles concerning Nassau Metals, ISSMs, and some goings on around the company. https://archive.org/details/attached-processor-interface-3b-1a Finally is the "Attached Processor Interface", a small Western Electric pamphlet detailing an interface for incorporating 3B processors into existing 1A offices such as 4ESS and 1AESS. As with other applications of the 3B to telephony, DMERT features as the operating system, although the pamphlet is mostly concerned with the installation and diagnostic aspects of working with the interface. By the way, the original text is all green, but I scanned all but the covers in B/W. The last one is interesting in that it's an integration of the 3B into a telephone central office that isn't a 5ESS, rather, you wind up with something more like a 4.5ESS, a 4ESS with a 3B up in it somewhere. However, given the date of November 1981, this postdates the installation of that first 5ESS, making it less likely that this was some embryonic step before the 5ESS and more likely a retrofit designed to get more 3Bs into service in older offices. That this was 1A general was interesting too, that is why a 1AESS could absorb it, meaning there very well could've been frankenstein central offices out there with a 1ESS that got retrofitted with a 1A and then got retrofitted further with an API and a 3B, making one of the monstrosities this pamphlet suggests installing. It's too bad there's a snowball's chance in hell of one of these "API" units popping up out there, much less still mated to its 1A and 3B...but a guy can dream. Anywho, going to start a slow trickle of scans again now that I've got my office all settled. I'm foraying further and further into telephones so my document hunting these days lands closer to ESS and 1A2 KTS than UNIX, but I'm still keeping an eye out for whatever I can manage to preserve. That all said, that also means my "accepted for scan" circle has gotten larger, as I'm now seeking other 70s-early 80s Bell System stuff generally, not strictly UNIX things, so if you've got some obscure Dimension PBX manual collecting dust I'll happily scan it for ya! - Matt G.

1 year, 7 months

1
0
0 0

OT: Updates to One True Awk

by arnold＠skeeve.com

Hi. If anyone is interested (*BSD committers, I'm looking at you :-), there have recently been some updates in the One True Awk (BWK's) which you should pick up. In particular, regular expression matching performance against Unicode text should now be tolerable. Feel free to ping me off list if you need more info; let's not spam the list. Thanks, Arnold

1 year, 7 months

1
0
0 0

Re: Test, test

by norman＠oclsc.org

Damien Wildie: It is Friday in Australia now ==== Yes, I know that. I was at Caltech, it was one of the first things they taught us. I just don't understand why, if Australia had a Thanksgiving Day, they would choose to have it on the same day as the US. Does any other country? On the other hand, if Thanksgiving Day actually mattered to anyone important, the original ctime(3) would have had a special table to compute its date, including all the different a dates it had in the US before 1942. Norman Wilson Toronto ON, thankfully

1 year, 7 months

6
6
0 0

Re: Test, test

by norman＠oclsc.org

Stuff Received: > In the U.S., certainly. Do Auzzies celebrate thanksgiving? Grog: Not really, but if we did, it would have been yesterday. But we do get exposed to Black Friday (today). === Why yesterday? In Canada we had ours a month and a half ago! Norman Wilson Toronto ON

1 year, 7 months

9
9
0 0

UNIX Release 3.0 vs System III Published Materials?

by segaloco

Hello everyone, I've just recently secured an item that has drawn some questions to mind. The item is a "UNIX System III Programmer's Manual Volume 2A" (image from auction listing: https://i.imgur.com/6blnqz3.jpeg) The cover is of a typical 70's Bell System motif, branded Western Electric, with blue and yellow lines and a Bell logo. The cover itself appears to be a typical report cover with a window for the title page of the document. First, I've only seen System III stuff still labeled "Release 3.0." Indeed the manual I have says Release 3.0 on the title page. Also, said manual is Bell Laboratories branded and has the blue and yellow lines near the top, above the cover text but below the Bell Laboratories logotype, an arrangement that can be seen on plenty of Bell Laboratories stuff even into the AT&T period (with the lines being replaced with the blue, red, and black, and death star instead of bell.) With this set, however, it is specifically labeled "System III". I've heard, anecdotally, that there were User's Manuals that specifically had the text "System III" on the title page, but I've never seen this myself. Are there System III branded manuals or am I misremembering. Additionally, this is labeled specifically Western Electric rather than Bell Labs. Western Electric would continue to be the name on the cover of UNIX documentation (for the most part) after this until divestiture. If such formal "System III" manuals exist, which branding did they happen to get? Another curious matter is the document is titled "Programmer's Manual...Volume 2A". This nomenclature is more commonly associated with research than stuff descending more from the PWB line like the commercial lineage. For instance, even PWB 1.0 listed its two main documents as "User's Manual" and "Documents for Use With". Research has always called the document the "Programmer's Manual" as far as I know, and the "Documents for Use With" nomenclature was only used with V6, V7 introduced treating the two sets as "Volumes" of the same larger work. What's interesting is in the sources for System III on the archive, in /usr/src/man/docs, the road_map (Documentation Roadmap) specifically uses the text "User's Manual" and "Documents for UNIX", which is still the case by 4.x (albeit the a_man/u_man split seems to have happened right about this time). In any case, I would be curious if anyone knows what was going on with the naming of documentation at this time. Would this imply that there is some variation on the 3.0/SysIII manual out there named "Programmer's Manual" instead of "User's Manual", or perhaps that for some reason when the Sys III variants of these docs had started being published, they had for some reason tried to cut over to the V7 documentation structure only to back out back to "Documents for UNIX" and a "User's Manual" as distinct things by the time of 4.0? In any case, once this gets here, I'll look it over for anything compelling that might set it apart from the document sources in the UNIX tree. I'm a bit bummed it's only Volume 2A, not both, but it'll be nice to have a physical example of the distributed, published documentation of the time. Maybe a 2B will pop up one of these days. Thanks for any insights or recollections! - Matt G. P.S. Long shot, very long shot, but if anyone on this mailing list has any empty, unused Bell System report covers of the era, Bell Laboratories especially, I would happily buy them from you. I've got my V6 documents and some BSD stuff just in random report covers I fished out of the university recycling, they'd look much nicer in proper covers, but I also recognize the bulk of those covers probably also wound up in some recycling/waste stream decades ago and no longer exist. Once I get this I could use the cover to produce a reasonable facsimile but I feel a tad uneasy regarding "breaking the seal" on that prospect, I don't want to cross the line from improving the aesthetics of my bookshelf to counterfeiting something.

1 year, 7 months

1
0
0 0

trusting trust code

by Russ Cox

Hi all, Ken mailed me the code for the compiler backdoor. I have annotated it and posted it at https://research.swtch.com/nih. As part of the post, I wrote a new simulator that can run V6 binaries. The simulator is a halfway point between the designs of simh and apout. It is running a translation of the V6 kernel to Go (with no hardware) and running user binaries on a simulated PDP11 CPU. The result combines apout's "easy to run" with simh's "v6-specific system calls work". In particular, it is good enough to run the backdoored login command, which apout simply cannot due to host OS tty handling not being like V6, and without having to fuss with disk pack images like in simh. If you have Go installed locally, you can run the new simulator with go run rsc.io/unix/v6run@latest You can also run it in your browser at https://research.swtch.com/v6. Finally, it turns out that the backdoor code was published this summer in the TUHS archive, but no one noticed. It is in dmr_tapes.tgz [1] in the file dmr_tapes/ken-sky/tp/nih.a. It is also visible in the dmr_tapes/ken/bits tape image, although not in the extracted files. Enjoy! Best, Russ [1] https://www.tuhs.org/Archive/Applications/Dennis_Tapes/

1 year, 8 months

2
1
0 0

Re: Dave Cutler recollection about Xenix

by Paul Ruizendaal

An interesting set of videos indeed, although I wish they were not all chopped up in 5 minute segments. > I consistently hear from folks the same about Bill Gates pushing for volume over anything else with Xenix. That was his business model. His Basic for the 8080 was copied a lot (the famous 1976 open letter to hobbyists) and he shifted to selling bulk licenses to manufacturers. These could then make a bundled hw/sw sale and sidestep the copying. If I understood correctly, in the early days he sold the bulk licenses for a fixed amount, without per copy fees. I suppose this matched his cost structure, so it worked; the leverage and profit came from selling the same to all manufacturers in the market. He also used it in his deal with IBM, beating out Digital Research that wanted per copy fees. Retaining the rights to DOS also matched the business model that had been pioneered for his Basic. It would seem that the same thinking was at play in the deal for Xenix (which I think preceded the IBM deal). He would spend money once on porting Unix to each of the various next-gen microprocessors of the time (x86, Z8000, 68K, NS32K) and sell (sub-)licenses to hardware manufacturers, who in turn had a right to sub-license binaries to end-users. The deal that he had to negotiate with Bell had to match that business model. Beyond this, I’m sure that Bill Gates understood the strong network effects in software and the "winner takes all” dynamic that results from it -- hence his focus on volume and market share. However, I don’t think this drove the structure of his 1979 [?] Unix license deal with Bell. > Something this brings back to mind that I always wonder about with Microsoft and their OS choices: So they went with Windows NT for their kernel, scraped the Windows environment off the top of DOS and dolloped it on top. Has there been any explanation over the years why they also decided to keep the MSDOS CLI interface? The below site has a very nice summary of Xenix at Microsoft (I’ve linked it a couple of times before): http://seefigure1.com/2014/04/15/xenixtime.html About blending Xenix and DOS it says: "As late as the beginning of 1985, there was some debate inside of Microsoft whether Xenix should be the 16-bit “successor” to DOS; for a variety of reasons – mostly having to do with licensing, royalties, and ownership of the code, but also involving a certain amount of ego and politics – MS and IBM decided to pursue OS/2 instead. That marked the end of any further Xenix investment at Microsoft, and the group was left to slowly atrophy.” Probably that same dynamic was in play for the CLI of Windows NT. Moreover, as you already point out, by the time of NT there were tens of millions of users of DOS, and numerous books, magazines, etc. explaining it. Throwing away that familiarity for unclear benefits (in the eyes of those users) would serve no business purpose. In a way it is the same dynamic that kept C89 and Bash in place for so long: people know it, it is good enough and it works everywhere. === Seeing the Cutler interviews reminded me of the old joke that there are only two operating systems left: Unix and VMS (Linux being Unix-family and Windows being VMS-family). I wonder if we will see it narrow down to just one before the hardware changes so much that the concept of an OS changes beyond recognition. My hypothesis would be that an entirely new approach will come first.

1 year, 8 months

6
5
0 0

UNIX NEWS July 16, 1975 Special Issue

by Jonathan Gray

The scans of UNIX NEWS John Gilmore provided are appreciated but the July 16 1975 "special issue" is very difficult to read: tuhs/Documentation/Usenix/Early_Newsletters/19750716-unix-news-special-issue.pdf tuhs/Documentation/Usenix/Early_Newsletters/19750716-unix-news-special-issue-darker.pdf Hendrik Jan Thomassen shows the copy sent to Nijmegen in: From UNIX to Linux, a time lapse of 45 years T-Dose 2016 https://youtu.be/boahlBmc-NY?t=2434 A transcription from the video: * * * * ***** * * * * ***** * * **** * * ** * * * * ** * * * * * * * * * * * * * * * *** * * * *** * * * ** * * * * ** * ** ** * *** * * ***** * * * * ***** * * **** -------------------------------------------------------------------------------- Circulation 49 July 16, 1975 Special Issue -------------------------------------------------------------------------------- The contents of this "special issue" will be repeated in the normal July issue to be mailed the last week of July. NEW SYSTEM AVAILABLE The Sixth Edition - June 1975 of the UNIX system is now available for distribution to licensees. Commercial users should contact Western Electric for details. Academics can receive the new system for a service fee of $150.00. Normal distribution is on 800 bpi - 9 track tape. You need not send a tape. Just a check for $150.00 addressed to: C. W. Christ, Jr. Room 6A312 Murray Hill, NJ 07974 The tape contains a single file which extracts to 3 RK-packs or equivalent. These contain: pack0) The system except for /usr/source pack1) /usr/source pack2) Documentation in machine readable form Those who require distribution on RK-packs should send two or three packs along with their checks. The package also includes one hard-copy of each of the 19 documents. Among the new "goodies" are: 1) Separate I and D space for the resident monitor on 11/45s and 11/70s 2) Huge files (up to 16 megabytes) 3) A preprocessor for structured Fortran 4) TMG 5) A preprocessor for DC, with arbitrary precision 6) Many fixes and rewrites of system programs from "as" to "c" 7) Much improved comments embedded in system source 8) More graceful death on running out of resources and other crashes UNIX NEWS At the users' meeting in New York on June 18 it was decided that the UNIX NEWS will be irregular in format but regular in mailing. We will try to be in the mails by the last day of each odd month. Where, as in this case, a special issue is warranted we will mail it and include the contents also in the regular mailing. -------------------------------------------------------------------------------- Address Correspondence to Prof. M. Ferentz Physics Dept. Brooklyn College of CUNY Brooklyn, NY 11210 --------------------------------------------------------------------------------

1 year, 8 months

1
0
0 0

Dave Cutler recollection about Xenix

by Skip Tavakkolian

This might be interesting to some. It is a piece of a longer conversation between Dave Plummer and Dave Cutler (RSX11, VMS, WinNT) https://youtu.be/9K3eMzF6x28?feature=shared

1 year, 8 months

9
8
0 0

Found: 4.1BSD User's Manual Volume 2C Comb-Bound

by segaloco

Spotted this and ordered it on eBay https://www.ebay.com/itm/235246689392 After the link is a pretty nondescript comb-bound 4.1BSD User's Manual Volume 2C. I don't think I've seen comb-bound issues prior to the USENIX 4.2BSD set that introduced the Beastie cover. Does anyone know if there was a limited run produced by the Berkeley folks themselves or if this is more likely a one-off someone printed for themselves? Either way, this is an exciting find for the completeness of my library, this would leave 3BSD as the only VAX BSD version I don't have any Volume 2C papers in my bookshelf from. If this does prove to be issue from Berkeley or someone directly adjacent to them, the next thing I hope to figure out is if this has Volume 1 and Volume 2A/2B companions. I find myself curious because the 4BSD Volume 2C I have was following a plain Jane Version 7 Volume 2A/2B rather than also 4BSD 2A/2B, so whoever curated that set either got them that way or clobbered V7 and 4BSD docs together themselves. - Matt G. P.S. Would anyone be interested in some V7 binders? I'm not keen on acquiring too many duplicates so would happily ship them to anyone wanting an original set of the papers from back when. As a bonus, the binders have some nice numbered tabs separating the papers/sections. I actually have three such binders, two that seem to be stock V7 Volume 2A/2B and one that is V7 Volume 1 but slightly tweaked with some "local" pages (to my knowledge, local to MIT Lincoln Labs, they added stuff like the RAND editor). Just let me know, if I don't hear anyone speak for them in a month or so they're going to the CS department at the local uni, they've got a shelf with some 4.3BSD binders that could use some elder influence :)

1 year, 8 months

5
12
0 0

Re: Found: 4.1BSD User's Manual Volume 2C Comb-Bound

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Stakrting with V6, Ken/Dennis masters a tape in research, and the IBM > shop is imaging that for people licensing the IP -- *i.e.,* everyone is > getting the same bits on their tape. Although with V6, the famous > "patch tape" leaks independently Actually, TUHS contains two microscopically different V6 distros: Dennis_v6 --------- v6root.gz, v6src.gz and v6doc.gz are a set of three RK05 images of Sixth Edition with root, /usr and documentation, from Dennis Ritchie. Ken_Wellsch_v6 -------------- v6.tape.gz is a copy of the Sixth Edition distribution tape which was sent in by Ken Wellsch. It notes that there are differences between the two, but hadn't investigated what they are. Here are some details: the source files for the kernel are identical, except for sys/ken/main.c, which has the following added in the Wellsch version: printf("RESTRICTED RIGHTS\n\n"); printf("Use, duplication or disclosure is subject to\n"); printf("restrictions stated in Contract with Western\n"); printf("Electric Company, Inc.\n"); (What clearly happened is that after they'd done some distribution, the AT+T lawyers made them add that.) Anyway, as a result, the binary system images 'rkunix', etc are slightly different between the two. Everything else seems to be identical: everything in /bin, /etc, /lib, /usr/bin and /usr/lib are all identical. Noel

1 year, 8 months

1
0
0 0

Another Find: UNIX Release 5.0 BTL Administrators Manual

by segaloco

Just got this one today, UNIX Release 5.0 Administrator's Manual, BTL version: https://i.imgur.com/hZW1C01.jpg (the one on the right, companion to the one on the left I've documented a bit already). First, an amusing anecdote of how I happened across this one. I hate Amazon. Like despise Amazon. I could go on for hours on the why, but the point is, I do not like Amazon. As such, I rarely, if ever, find myself looking at anything for sale on their site. At some point the past few years I did happen across an auction for the WECo equivalent of this manual on Amazon and nearly broke my anti-Amazon-ness to register and purchase it, but I resisted. It stuck in my mind but wasn't enough to change my opinion. Well, fast-forward to a few weeks ago, I'm recanting this tale to a friend of mine as we're loitering in the lobby of our music space. He's on his laptop so decides to search up UNIX manuals on Amazon to be like see all this stuff you could be getting, you should just get an Amazon account. We look through auctions for a while and it's mostly a chorus of "I have that already" or "That's not relevant" or "I could buy that for pennies on the dollar elsewhere" but then he comes across an auction with no picture saying UNIX 5.0 Manual or something pretty generic like that. No pictures on the main posting, but there is a link saying two copies available. That was the first I learned that a pictureless Amazon posting can then lead to specific auctions or sales that do have pictures, that stuff just apparently doesn't always show up in the search results? In any case, he clicks down into them and this baby pops up. Luckily I was able to avoid registering as he offered to just buy it for me and I hand him the cash. So the result is this document is in my hands due to a deal with Amazon a brokered through a friend so I didn't have to join their site. I still feel like I've done a deal with the devil but hey, uncovered one more obscure thing in the process. Now for some analysis: Only difference on the cover page, like the BTL User's Manual, is additional text indicating "Including BTL Computer Center Standard and Local Commands". Like the User's Manual (and the Release 3.0 manual and other internal/pre-commercial manuals) there is an acknowledgements and preface page prior to the introduction. Added commands compared with a standard issue WECo 5.0 Administrator's Manual include: Section 1: Holmdel: archadmin - archlist, archsched, archque, archinit, archshut - archive administrative commands Indian Hill: bsnap - bsnap - snap baud rate usage findi - findi - find file names corresponding to inode numbers linesnap - linesnap - monitor activity on DH11 or DZ11 lines newids - newids - descend a directory changing owner and group id on files pisnap - pisnap - monitor performance of the operating system snap - snap - monitor activity within the operating system tabsnap - tabsnap - snap system tables vault - vault - save/restore a file system to/from tape Piscataway: archsys - archsys - archive system ds - ds - directory scanner filesave.py - filesave - perform daily filesave procedure fsea - fsea - file system entropy analyzer fss - fss - file system scanner fwall - fwall - write to all users by pathname lacctcms - lacctcms - command summary from per-process accounting records xchng - xchng - exchanges ownership of files Section 8: Div 452 STD: atd - atd - a batch monitor atf - atf - make a job file atr - atr - run a batch job att - att - parse time specification The TOC additionally lists a "trouble.div" page, presumably Div 452-specific trouble reporting stuff, but the manual contains no such page. Based on front-back pages available it doesn't look like the page would've been ripped out or anything, so probably just not actually in the print run. The trouble(8) page in this manual matches one from a standard 5.0 manual. So takeaways here, looks like Holmdel, Indian Hill, and PIscataway may have all had their own backup/archival systems between archadmin(1M)(HO), archsys(1M)(PY), and vault(1M)(IH). There were quite a few enhanced performance snapshot tools in Indian Hill while Piscataway appeared to have some particular filesystem analysis tools. The section 8 at administration tools are interesting in that at(1) itself is also Div 452 as of 5.0, is not in the System V manuals at all. While at(1) then pops up in standard SVR2 manuals, these administrative pieces do not (at least what I've got on hand, they're neither in the comb bound red covered AT&T UNIX User's Manual nor the 5 volume set with the metallic looking alphabet blocks on the cover.) I don't have any SVR3 manuals to check, and my blue wall of SVR4 books I already moved to my new place, so I can't look in those right this second. I can't seem to find either Administrators Manual volume on bitsavers either, so can't check to see if these exist in later versions yet. Anywho, as usual, reach out if there's something in particular you'd like to know about one of these pages, otherwise this is going on the pile I plan on starting work on again once this move is out of the way (and hopefully the last one for a few years at least...) - Matt G.

1 year, 9 months

1
0
0 0

Re: HCR FOOBAR

by norman＠oclsc.org

Ron Natalie: Really doesn't look like much, just a bar. THey had put `HCR FOOBAR' on the thing with letraset or something but that all flaked off over the years. ==== Pfui, or as some spell it, foo. Norman Wilson Toronto ON PS: Lunchtime. Time to visit the pfuid bar.

1 year, 9 months

1
0
0 0

HCR FOOBAR

by Ron Natalie

I was digging around my desk looking for something and I came across a quaint piece of UNIX history. Many years ago HCR gave away “foobars.” They had a gold one, which Rick “Seismo” Adams won and a silver one that I have in front of me now. The ounce of silver was never really worth enough for me to want to cash it in (I think Rick promptly did so with his ounce of gold).

1 year, 9 months

3
3
0 0

Known Specimens of Pre-5ESS UNIX Telephone Switching Software?

by segaloco

Hello, my studies lately bring me to the question: Are there any extant examples of telephone switching software, built on UNIX, from the various parts of the Bell System prior to the introduction of the 5ESS and 3B20D? My focus veers earlier as some 5ESS/3B20D/DMERT technology is still in active use, that sleeping dragon can lie. What's gotten me curious is reading about 1ESS in a BSTJ volume I picked up, noting the particulars on how previous concerns of manual and electro-mechanical systems were abstracted into software. Even without surviving examples, were previous systems such as the 1ESS central control ever ported to or considered for porting to UNIX, or was the hardware interface to the telco lines too specific to consider a future swap-out with, say, a PDP11 running arbitrary software? Columbus's SCCS (switching, not source code) also comes to mind, although all I know that survives of that is the CB-UNIX 2.3 manual descriptions of bits and pieces. By the way, it's funny, I have UNIX to thank for my current experiments with telephones and other signalling stuff, what with making me study the Bell System more generally. It's starting to come full circle in that I want to take a crack at reading dialing, at least pulse, into some sort of software abstraction on a SBC that can, among other things, provide a switching service on top of a UNIX-like kernel. I don't know what I'd do with such a thing other than assign work conference call rooms their own phone numbers to dial with a telephone on a serial line...but if I can even get that far I'd call it a success. One less dependency on the mobile... - Matt G.

1 year, 9 months

10
13
0 0

etymology of yacc

by Douglas McIlroy

Steve, Was Yacc an original coinage, or was it inspired by a similar acronym for yet another whatever? The question is inspired by Yamoo, yet another map of Orion, which is mentioned in today's NYT: https://www.nytimes.com/2023/10/02/science/orion-nebula-webb-planets.html. Do the two acronyms share a common ancestor? Doug

1 year, 9 months

4
3
0 0

SVR3 or SVR4 kernel sources for 3B2/700

by Seth Morabito

It's been a while since I asked, and I would be extraordinarily surprised if the situation had changed, but I thought I might try my luck one more time... The 3B2 is a dreadful computer, but nevertheless I find myself compelled to try to make the SIMH 3B2 emulation more accurate. The emulation for the 3B2/400 is probably as accurate as it's ever going to be, but the 3B2/700 has very clear and known bugs. One of the things holding back fixing those bugs is documentation in the form of source code. I have the leaked kernel source code for the 3B2/400 ("Version 2") architecture, but I have never seen any kernel source code that targets the 3B2/700 or /1000 ("Version 3") architecture. All I have are the system header files from /usr/include/sys, nothing more. If by some chance you have a /usr/src/uts tree for the 3B2/600, /700, or /1000, I would love to see it. It would refer to the system board using the code name "FALCON", probably with a lot of #ifdef's (at least the system headers do) -Seth -- Seth Morabito * Poulsbo, WA * https://loomcom.com/

1 year, 9 months

3
3
0 0

lyons commentry

by Steve Simon

hi all, maybe of interest, in the early 1990s i worked at UNSW and met several people in the computer science dept who knew John Lions. i *was* the character on the cover of the reprint, i have a photocopy of the original pamphlet, complete with hand written annotations by someone who attended Lyons course. perhaps everyone on tuhs has their own photocopy, but if anyone wants this one, give me a shout. -Steve

1 year, 9 months

1
0
0 0

Lions' commentary updated

by Greg 'groggy' Lehey

No, sorry, there hasn't been a new edition, just corrections. The original version contained a number of scan errors, and thanks to Conway Yee I have now applied a number of corrections. You can find the document in various forms at http://www.lemis.com/grog/Documentation/Lions/. I've scanned through the output, and it seems correct. If you find any further errors, please let me know. Also thanks to Brian Foley, who sent me similar corrections 10 years ago, but which I never got round to incorporating. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php

1 year, 9 months

4
4
0 0

Re: 7th ed local man pages

by jnc＠mercury.lcs.mit.edu

> From: Douglas McIlroy > The union table of man pages in "A Research Unix Reader', CSTR 139, > marks with "L" local man pages that were not distributed outside of > research. Does anyone have a copy of those pages? ... would love to get > them all The CB-UNIX manual has a bunch of xL "Local" pages, e.g. the Section 3 ones here: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man3/ I know this is CB-UNIX, but perhaps they are the same? Noel

1 year, 9 months

1
0
0 0

7th ed local man pages

by Douglas McIlroy

The union table of man pages in "A Research Unix Reader', CSTR 139, marks with "L" local man pages that were not distributed outside of research. Does anyone have a copy of those pages? I'm particularly interested in galloc(3), but would love to get them all, which I unwittingly trashed when I retired. Doug

1 year, 9 months

2
1
0 0

Re: custom NS and NE man(7) macros

by Douglas McIlroy

> You didn't say, but I reckon this is a survey of man(7) macros that > might be considered extensions? My presentation was too cute for my own good. I pointed out the consistency of xS/xE for various x. I apologized for EX/EE, which varied from that form (as UR/UE did more recently), and I questioned OQ/CQ, which utterly breaks it. The intended point was that one should have a strong rationale for deviating from established custom, and thereby fostering mental overload. Doug

1 year, 9 months

2
1
0 0

Re: UNIX Influence on Teletype and Vice Versa

by Douglas McIlroy

I omitted one crucial fact from my post about Joe Ossanna's influence on the TTY 37. That happened not in connection with Unix, but with Multics. When Unix came on the scene, model 37 was already in production. Doug

1 year, 9 months

3
2
0 0

Project Idea: The UNIX Programmer's Manual: Heritage Edition

by segaloco

I haven't known when or how to bring up this project idea, but figure I might as well start putting feelers out since my Dragon Quest project is starting to slow down and I might focus back on UNIX manual stuff. So something painfully missing from my and I'm sure plenty of other folks' libraries is a nice, modern paper UNIX manual that takes the past few decades into consideration. The GNU project, BSDs, etc. ship manpages of course, and there's the POSIX manpages, but I'm a sucker for a good print manual. Something I'm thinking of producing as a "deliverable" of sorts from my documentation research is a new-age UNIX manual, derived as closely as possible from the formal UNIX documentation lineages (so Research, SysV, and BSD pages), but: 1. Including subsequent POSIX requirements 2. Including an informational section in each page with a little history and some notes about current implementations, if applicable. This would include notes about "dead on the vine" stuff like things plucked from the CB-UNIX, MERT/PG, and PWB lines. The history part could even be a separate book, that way the manual itself could stay tight and focused. This would also be a good place for luminaries to provide reflections on their involvement in given pieces. One of the main questions that I have in mind is what the legal landscape of producing such a thing would entail. At the very least, to actually call it a UNIX Programmer's Manual, it would probably need to pass some sort of compliance with the materials The Open Group publishes. That said, the ownership of the IP as opposed to the trademarks is a little less certain, so I would be a bit curious who all would be involved in specifically getting copyright approval to publish anything that happened the commercial line after the early 80s, so like new text produced after 1982. I presume anything covered by the Caldera license at least could be published at-cost, but not for a profit (which I'm not looking for anyway.) Additionally, if possible, I'd love to run down some authorship information and make sure folks who wrote stuff up over time are properly credited, if not on each page ala OWNER at least in a Acknowledgements section in the front. As far as production, I personally would want to do a run with a couple of different cover styles, comb bound, maybe one echoing the original Bell Laboratories UNIX User's Manual-style cover complete with Bell logo, another using the original USENIX Beastie cover, etc. but that also then calls into question more copyrights to coordinate, especially with the way the Bell logo is currently owned, that could get complicated. Anywho, anyone know of any such efforts like this? If I actually got such a project going in earnest, would folks find themselves interested in such a publication? In any case I do intend to start on a typesetter sources version of this project sometime in the next year or so, but ideally I would want it to blossom into something that could result in some physical media. This idea isn't even half-baked yet by the way, so just know I don't have a roadmap in place, it's just something I see being a cool potential project over the coming years. - Matt G.

1 year, 9 months

20
27
0 0

shell escapes in utilities

by ron minnich

I got to wondering, based on the sendmail discussions, how many shell escapes have appeared over the years? uucp sendmail xdvi : "The "allowShell" option enables the shell escape in PostScript specials" There must be a lot of them, however.

1 year, 9 months

14
24
0 0

CRC calculation in the 1980s

by Paul Ruizendaal

When looking at old xmodem code I noticed that it calculated its CRC bit-by-bit, switching to byte-wise using a table in the late 80’s. It never seems to have used the byte-wise, “on-the-fly” algorithm. This seems to match a pattern: I often come across bit-wise and table implementations, but rarely on-the-fly implementations if any. The on-the-fly algorithm was known at least since 1983, following a paper by Perez: http://www.bitsavers.org/components/fairchild/_appNotes/Byte-wise_CRC_Jun83… The paper was noted, for example it is on the citation list of RFC1134, describing the PPP protocol. Today, a wikipedia page gives implementations for various polynomials: https://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks#Paral… Now, it would seem to me that on memory constrained personal computers and PDP-11’s the “on-the-fly” algorithm would have been a good choice, being just a few lines of code and maybe 30-50% slower than table lookup. The tables aren’t big, but a kilobyte is a lot when you only have 64. Any suggestions as to why the on-the-fly algorithm did not catch on more in the 1980’s? Maybe it was simply less well known than I think?

1 year, 9 months

5
5
0 0

Re: CRC calculation in the 1980s

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > Any suggestions as to why the on-the-fly algorithm did not catch on > more in the 1980's? Maybe it was simply less well known than I think? I can't answer that directly, but I will point you at IEN-56, "CRC Checksum Calculation", by Dave Reed (11-Sep-78): https://www.rfc-editor.org/ien/ien56.pdf Dave wanted the INWG to use a more powerful (in terms of detecting errors) CRC, instead of the simple summation eventually adopted, in TCP and IP. So he produced code to implement a particular CRC, to show people that it would not be particularly expensive (whether in time, or space, I don't alas recall definitively; speed would have been an important consideration, when competing with the summation, though). This would have been close to the leading edge of our knowledge at the time; Dave liked playing around with math, and at about that time he did a very fast DES implementation. Noel

1 year, 9 months

3
2
0 0

UNIX 4.0 Typesetter Docs on eBay

by segaloco

Howdy all, just passing along this auction I spotted on eBay: https://www.ebay.com/itm/256216372208 This is a subset of papers from the Documents for UNIX 4.0 set compiled as a handy volume (and likely a forerunner to the packaged volumes released with System V.) Missing is the Typing Documents with MM pamphlet which is listed in the TOC of these issues. I've already got one of these or I'd scoop it up myself. Enjoy! - Matt G. P.S. I have seen this and its companion document (Programming Starter Package) with the AT&T deathstar in the upper right rather than Bell Labs and the Bell logo. What I don't know is if it's an exact repackaging just with a change in logo or if those versions have revisions to any of the papers. Most notably as far as version association, the Programming Starter Package includes the Documentation Roadmap, which in my Bell Labs-branded copy, indicates it is for use with UNIX 4.0. I'd be curious if the AT&T variant retains the UNIX 4.0 reference. I'll continue to keep my eye out for an AT&T-branded set, it might reveal some differences.

1 year, 9 months

1
0
0 0

CRC calculation in the 1980s

by Paul Ruizendaal

>> Any suggestions as to why the on-the-fly algorithm did not catch on more in the 1980’s? Maybe it was simply less well known than I think? > > Could it have been the per-cpu-second billing that was (fairly?) common at the time. I was only getting in to Unix in the early 90s but saw the tail end of that. Good point, but wasn’t per-cpu-second billing mostly used for big iron? For machines without memory constraint the table method makes the most sense, also if billing was not a factor. >> Any suggestions as to why the on-the-fly algorithm did not catch on more in the 1980’s? Maybe it was simply less well known than I think? > > The CRC algorithm I'm familiar with shows up in Dragon Quest for the Famicom in 1986[1], written in 6502 assembly. Admittedly though I only recognized it due to the EOR with 0x1021 on lines 318-323. That I then only know from a quick and dirty CRC I threw in an XMODEM-CRC client [2] I did to accommodate for a bug in the JH7100 RISC-V board's recovery ROM implementation. Not sure if this is along the lines of the approach you're talking about ... > > [1] - https://gitlab.com/segaloco/dq1disasm/-/blob/master/src/chr3/start_pw.s > [2] - https://gitlab.com/segaloco/riscv-bits/-/blob/master/util/sxj.c Both of these are what I call the bit-wise method: a loop iterating over bytes, with an inner loop iterating over bits. An example of the table method is here: https://github.com/u-boot/u-boot/blob/master/lib/crc16-ccitt.c and an example of the on-the-fly method is here: https://github.com/tio/tio/blob/master/src/xymodem.c#L44-L54 Note how the latter also only has one loop iterating over the bytes, but effectively calculates the table entry ‘on the fly’ for each byte. That is only a handful of instructions more than doing the table lookup. Maybe it is a “stuck in the middle” solution that was quickly forgotten.

1 year, 9 months

1
0
0 0

x/y/zmodem on Unix

by Paul Ruizendaal

Last december Matt brought up xmodem and recently I needed it for an almost identical use case. Studied it a bit and in the context of Unix, it is an interesting piece of software history. Although xmodem originated on CP/M in 1977, it seems to have arrived on Unix soon thereafter. The first Unix implementation seems to have gone by the name of “rbsb” and must have originated when V7 was prevalent: it uses alarm() to simulate non-blocking I/O. Over the course of the 80’s ymodem and zmodem were added and the package became lrzsz; the source continued to have a very V7-ish feel to it at least to the early 90’s. In the mid-90’s it was converted to ansi-C and had some other modernization, but it looks like it would still have run on SysIII (apart from the ansi).The last update to the upstream source package appears to be from 1998, i.e. 25 years ago. It is still packaged today for FreeBSD and major Linux distros. On Unix it must be one the oldest code bases still in regular use, with the 1980 source still recognizable in its current incarnation. Any other contenders come to mind? I had always associated x/y/zmodem with CP/M and MSDOS, not so much with Unix. Last December Clem already pointed out that it was popular for file exchange in the Unix scene as well, along with several other similar tools. Also, the ymodem approach to file metadata is very unix oriented, suggesting it originated on Unix or at least that Unix users were an important user demographic. Yet, I could find little trace of x/y/zmodem in the TUHS Unix Tree. The search tool finds it in 2.11BSD, in Minix 1.5 and 2.0 and in V10. Kermit is in those as well, and in 4.3BSD and 4.4BSD on top. Maybe these programs were commonly pulled from a bulletin board and hence not on distribution media. Not sure how that would be bootstrapped, although the 2.11BSD files for x/y/zmodem include “minirb.c”, a 175 line implementation to receive files using the ymodem protocol. It is possible that this was transferred as plain text as a first step, or even retyped. Any recollections?

1 year, 9 months

8
8
0 0

Re: UNIX Influence on Teletype and Vice Versa

by Douglas McIlroy

Joe Ossanna worked diligently to see that WECo's ASCII teletype really would come to market and would meet the needs of Unix. He famously estimated that Bell Labs alone was a sizable market: 777 machines. He also leaned on WECo to make the return key issue a single newline. And he specified what non-ascii characters would fill out the 128 positions on the Bell Labs type boxes. This requires encoding 7-bit ASCII in 8 bits. I don't know whether WECo had been planning to do so anyway. Doug

1 year, 9 months

1
0
0 0

UNIX Influence on Teletype and Vice Versa

by segaloco

Good morning folks, something I've been pondering on this morning is the potential close connection between UNIX development and Teletype interfacing designs as the 70s and 80s marched on. Seeing as Teletype was a part of the Bell System (albeit a little less obviously in marketing than it's kin), was there any sort of official rapport between folks working on UNIX and those designing subsequent Teletypes, Dataspeed terminals, etc? For instance, would there have been any influence an up-and-coming Teletype design would've had on developments in the UNIX tty drivers, or would particulars of UNIX tty drivers "rub off" on specifics of terminals being developed? Or were those units so distant from one another that there would've been little cross-talk between teams? Granted, an argument could be made for specifically avoiding any significant knowledge of internals, that way UNIX tty driver folks don't potentially paint into a Teletype corner and vice versa. Still, with the tightly integrated nature of Bell System R&D, manufacturing, supply, etc. it would be very "Bell System" for there to be some sort of interplay between Teletype and UNIX. Anyone got the scoop on whether Teletype hardware enjoyed a special place in UNIX tty-interfacing considerations or vice versa, or if they were just two relatively insular developments from one another in the same general field from the same big umbrella organization? - Matt G.

1 year, 9 months

3
2
0 0

Re: TUHS

by Will Senn

All, My apologies to you for sending a note to the entire list that was meant to be sent only to Warren. I definitely had not intended to send it to the entire list (reply list... ugh.). If I were to get a mulligan, I would make it clear that I do not take issue with anyone's signature, including Mary Ann's. Signatures, in my view, are a matter of free speech. I would simply state my preference that we keep the discussion to a more technical level and consider moving cultural topics to another list altogether. Thanks, Will

1 year, 9 months

1
0
0 0

Re: The AWK Programming Language, 2nd Ed.: What's new?

by arnold＠skeeve.com

Hello All. For whoever's interested, the csv code has been merged into the master branch of the Git repo. Have fun! Arnold > From: arnold at skeeve.com (arnold at skeeve.com) > Date: Sun, 10 Sep 2023 13:41:34 -0600 > Subject: [TUHS] The AWK Programming Language, 2nd Ed.: What's new? > > Hi. > > markus schnalke <meillo at marmaro.de> wrote: > > > Hoi, > > > > I just discovered that one of my favorite computer books about my > > best liked programming language (besides C) releases in a second > > edition. Does anyone know what the differences of 1st and 2nd > > edition are? > > > > As the original book is almost perfect, the only rework and > > extension direction I can think of is towards different > > implementations like gawk, mawk, portability and such things. > > > > Does anyone know more about it? Maybe some inside information? ;-) > > > > meillo > > Inside information? As it happens, yes, I do have some. :-) > (I was a reviewer.) > > [In the below, "awk" means Brian Kernighan's awk.] > > In the 36 (!) years since the first edition was published, awk > has undergone, shall we say, a large number of small changes. These > are listed in the FIXES file currently in the master branch of > https://github.com/onetrueawk/awk. > > In addition, Brian Kernighan decided to add support for UTF-8 input, > which is what awk now expects, and support for CSV input files when > invoked with the --csv option. Furthermore, there is a new \u escape > sequence which must be followed by 1-8 hexadecimal digits for specifying > Unicode code points. > > The book itself has been carefully revised. The large second chapter > which was a reference to the full language was moved to an appendix. > Many of the example programs from the first edition were retained > and updated, but there is also quite of lot of pleasing new material. > > There is mention of, and occasional comparison with, gawk, mawk and > Ben Hoyt's GoAwk, but by and large the focus is on the authors' version. > > The new code is currently in the "csv" branch of the above Github > repo. The maintainer is in the process of tidying up the repo (dealing > with issues and pull requests) and will merge the csv branch into > master sometime in the very near future. > > I'm told that the printed books with get to the publisher's warehouse > towards the end of September. The book is available now on O'Reilly's > Safari learning site (safari.oreilly.com) for anyone who has a > subscription. > > Matching code (--csv and \u) are in gawk's master branch now. I will > make a release this fall, after the new code has moved into master > in BWK's awk. > > I heartily recommend the book; it is totally up to Brian Kernighan's > usual very high standard. > > Enjoy, > > Arnold >

1 year, 9 months

9
12
0 0

Re: The AWK Programming Language, 2nd Ed.: What's new?

by norman＠oclsc.org

To the Attention of Warren Toomey (and all who stay in his hotel): I don't care enough to weigh in on any issues that don't interest me, but I am the most important person in the world, and whatever I say goes, so you better listen or you'll be sorry. It is my very important opinion that only things I want to hear about should be discussed on this mailing list. I want to hear about Unix and awk, but not about perl. No one must talk about any shell except Ken's original. The sun scares me, forcing me to hack all night and sleep all day (never mind the malicious stories that I press wild flowers); therefore there must never be any mention of Sun Microsystems or Solaris. I am also worried that a comet will fall on my house and damage my Twinkie stockpile, so no discussion of the VAX-11/750 is allowed, nor of work done by the Bell Labs Computing Science Research Center during the 1980s when much of their work was done on systems of that model, which were even named (ewwwww!!!) after comets. Any mention of non-nerd-approved(TM) subjects is also forbidden, including Agricola, ferrets, mimes (which are even scarier than comets!), Lions (and Tigers and Bears), lurgi, csv files, and gannets (they wet their nests). Not to mention Bazonka. I hereby direct the moderators of this list, who must obey my every command, to terminate with extreme prejudice anyone who dares even to think of violating these rules. Viva la revolution! Yeliz Gardinovich Bimmler (Mrs) Port Morton, Alabama, CUS

1 year, 9 months

1
0
0 0

TUHS

by Will Senn

Hi Warren, I don't care to weigh in on the transgender flag issue, but I also don't want to hear about it. Please remove me from the list. All due respect to you and Mary Ann. Monica Helms is not a Unix hero. Thanks, Will

1 year, 9 months

1
0
0 0

Some BSP Numbers Related to 3B/1A "Attached Processor Interface"

by segaloco

Hello, today I've received a 3B/1A "Attached Processor Interface" or "API" (as I will refer to it in this email, note API will not mean Application Programming Interface in my contributions to this discussion) pamphlet, published by WECo in November 1981, concerning installation and maintenance of the API. From the introductory page: > This lesson is a self-paced package that can be administered individually or in a classroom environment. There is a helpful glossary in the back of this booklet that you may use while going through the material. > > At the conclusion of this lesson, the installer will be able to: > > - State the purpose of the API as it applies to the 3B Processor. > > - Identify the different types of circuit packs used in the API. > > - List the number of API diagnostic phases. > > - Name the API circuit pack that interfaces the Dual Serial Channel in the 3B Processor. Among the many pages (which I'll be doing a formal scan on in the future) are some references to BSPs and schematic drawings relevant to this information, I wanted to get that information out in the email archive now so the bibliographic references are preserved somewhere: 3B Processor: 254-001-031 - Test Equipment List 254-301-000 - System Documentation 254-301-005 - General Description 254-301-115 - TTY System 254-301-010 - Central Control 254-301-020 - Power Systems 254-301-100 - Input Output Interfaces 254-301-105 - Input Output Processor 254-301-110 - Input Output Processor Peripheral Controller 254-301-200 - Main Store 254-301-210 - Moving Head Disk Drive 254-301-215 - Disk File Controller 254-301-220 - Magnetic Tape System 254-301-800 - Emergency Action Procedures 254-301-809 - Acceptance Test Plan 254-301-811 - Task Oriented Practice-Routine 254-301-812 - Task Oriented Practice-Trouble Clearing 254-341-000 - DMERT 254-341-220 - MTCE Management and Diagnostics API: 234-100-020 - APS Description and Theory 254-201-003 - API Frame Theory 254-280-114 - APS Software Description 254-281-030 - API Growth Misc: 234-153-055 - File Store Relocation 3B Schematics: SD-4C050-01 - 3B Control Frame, DMA Unit, CC Unit, MASM 0, MASM 1, Power Unit, Cooling Unit, Filter Unit SD-4C059-02 - 3B Peripheral Control Frame SD-4C052-01 - IOP Basic SD-4C049-01 - IOP Growth SD-4C051-01 - DFC Unit SD-4C056-01 - Disk Inverter Frame SD-4C058-01 - Tape Transport Frame SD-4C057-01 - Inverter Unit SD-4C070-02 - Inverter Control Unit SD-4C054-01 - Duct & Cabling SD-4C053-01 - Power Distributing, AC Requirements SD-4C069-01 - Micro Level Test Set SD-4C065-01 - Port Switch API Schematics: SD-5A056-01 - API Frame SD-5A055-01 - API Unit There are then references to a few "Handbooks": HB 309 - 3B Proc HB 263(A) - API ITS (Mainly mentions tests and diagnostic stuff) HB 264(A) - API Generic (Not sure what ITS and Generic distinguish here) Finally, a bit of fun. Towards the back of the pamphlet is a small crossword puzzle concerning the API: https://i.imgur.com/0pLcK9p.jpg Answers to come when I do a scan of this. If anyone has any particular information they want me to try and find in it sooner rather than later just let me know, it's 88 pages but small form. - Matt G.

1 year, 9 months

2
1
0 0

Unix install & "standalone" package

by norman＠oclsc.org

I don't remember any special many-programs-in-one binary like busybox in any Unix from the days when Unix was simple enough for me to understand. That covers the entire lifetime of the Research systems, but also System V and the BSDs and their sundry offspring up into at least the 1990s. I'm pretty sure OpenBSD at least still has nothing like busybox. The nearest thing was to make sure certain programs were linked statically (or existed in alternate statically- linked versions) so they would work before shared libraries were available. (It seems to be common wisdom that `sbin' means `system bin' these days, but I remember once, long ago, being told it stood for `static bin'.) Perhaps the question to ask is why such a magic program is needed at all. Is it just because programs like the shell have become so large and unwieldy that they won't fit in a small environment suitable for loading into an initramfs? Older UNIXes, even on the VAX, didn't use an initramfs. the boot code had just enough understanding of devices and file systems to load the kernel and to point it at the real root file system. The VAX hardware designers had a clever scheme on many (but, strangely, not all) VAX variants by which the hardware had several little boot ROMs, each containing a bare-bones read-only device driver for a particular device along with a few instructions to read the first sector into memory and start it, with pointers to the boot-rom driver and device ID in specified registers. That was enough to support a device-independent Unix boot block that could read unix (or another file name typed on the console) from the root of the file system at the start of the disk. I know it was because I wrote such a boot block, though I don't know whether anyone else did. (Other systems, I think, just used it to load /boot, a larger and more-capable program.) Maybe it was just that the boot environment was simpler in older systems, without the need to load kernel modules or support multiple locations and means of access for the root? Norman Wilson Toronto ON

1 year, 9 months

9
20
0 0

Re: nassau smelting was Re: Current Ownership of 3B/WECo Computer IPs

by Douglas McIlroy

> i’m having trouble identifying “Agricola”. See WIkipedia on "De re metallica", or for the real thing https://www.gutenberg.org/files/38015/38015-h/38015-h.htm On Mon, Sep 11, 2023 at 4:29 PM Mark Seiden <mis(a)seiden.com> wrote: > > i’m so happy you replied. > > have you considered a memoir? > > your writing is very vivid (and literate). > > but i’m having trouble identifying “Agricola”. > > the strategy board game? the roman emperor? the farm to table restaurant in princeton? > > > > > > > > On Sep 11, 2023, at 3:58 PM, Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote: > > > > Way off topic, but too nostalgic to pass up. I was involved in > > after-hours training courses and persuaded Bob Morris to organize the > > first one ever to be held off campus, "Bell System with field trips". > > The highlight of the series was Nassau Smelting and Refining. They > > proudly told us about their new environmental consciousness: aqua > > regia (used to reclaim gold) was now being adjusted to pH 7 before > > being dumped into the Kill van Kull, and stack emissions of lead had > > been reduced from hundreds of pounds per year to eight. > > > > The scene was almost straight out of Agricola. An enormous steel > > jousting pole mounted on a backhoe was used to shove scrap copper and > > live-cut tree trunks into a ferocious green-flaming furnace. Men in > > moon suits and respirators puddled slag floating on open vats of > > molten lead. A Dickensian crone snipped gold tips off the old relays > > cradled in her lap. Clothes, including shoes, exchanged at the door of > > the gloomy gold room, were collected periodically and thrown into the > > aqua regia pots to extract every last milligram. > > > > The only process that really deviated from Agricola was pyrolysis, for > > reclaiming modern cable cladding. But he surely would have been > > impressed by the mechanism for casting continuous copper bar and > > collecting it on a giant spool. They delighted in telling about the > > time the spool stopped turning while the copper feed continued, > > filling the hall with an enormous tangle of 1" copper stock. > > > > Doug > > > > > > On Mon, Sep 11, 2023 at 1:47 PM Mark Seiden <mis(a)seiden.com> wrote: > >> > >> hi, old friends (and i mean that both figuratively and literally) > >> > >> the recent/continuing brouhaha involving lead sheathed cables made me wonder about > >> nassau smelting and refining in staten island (a sub of WEco which ended up with Lucent) > >> (and apparently another location at W. 29th st which was a superfund site for a while.) > >> > >> wonderful chaplainesque photo: > >> > >> https://www.facebook.com/classicstatenisland/photos/a.286586221935407/51668… > >> > >> also regarding the Staten Island location, quoting from > >> > >> https://www.silive.com/news/2020/02/former-nassau-smelting-site-sells-for-3… > >> > >> "The cleanup was to entail covering 450,000 cubic yards of contaminated soil with a thick, unbreakable plastic liner, as well as layers of clean soil.” > >> > >> (hah, what could go wrong with that?) > >> > >> On Sep 11, 2023, at 11:34 AM, Paul Winalski <paul.winalski(a)gmail.com> wrote: > >> > >> Regarding the possible Western Electric -> Lucent -> Nokia IP path, > >> has anyone tried contacting Nokia's legal department and asking > >> whether they think they own the rights to the 3B/WECo computer IP, and > >> if not, do they know who does (or might) own it? > >> > >> -Paul W. > >> > >> >

1 year, 9 months

1
0
0 0

Current Ownership of 3B/WECo Computer IPs

by segaloco

Hello folks, I'm here today with a question that sprung off of some 3B20 research. When 1984 happened and ATTIS rose from the ashes of former Bell System computing efforts, presumably ATTIS received all IP rights from Western Electric for 3B processors, WE32000, and so on, and continued to sell related products through to the 3B2 line. Is this the case, is ATTIS the formal recipient of both computing software *and* hardware IPs after the breakup? Given that, plus subsequent market flow, "old AT&T" scooped up and paraded around in effigy by SBC, other old Bell stuff cannibalized by other RBOCs, spinoffs of stuff to Novell, then Caldera/SCO on the other side...who all wound up with the hardware IPs? The story as it "concludes" concerning UNIX is of course tied up in all the subsequent lawsuits, what with Novell and Caldera conflicts on ownership, transfer to the Open Group, so on and so forth, and SCO and progeny wind up with the Sys V "trunk." Is there a clear, current owner of these WECo hardware IPs, or have those waters grown even murkier than those of UNIX in the times after AT&T proper? Thanks everyone! - Matt G. P.S. As an aside (even though it's the more directly UNIX thing...) is anything after SVR4 developments that would've involved the same folks as were working up to that point in the USL group? Or did the transfer of System V to Novell also involve their own in house folks starting to take it over, then over to SCO, is there anything post SVR4 (4.2, 5, UnixWare stuff) that would even remotely be considered the logical next step by the same folks that engineered SVR4, or was it basically just another face in the crowd of "UNIX <xyz>" when USL wasn't involved anymore? Probably not the first time this has been asked either so to a finer point I'm basically fishing for whether anything post the initial SVR4 releases in the early 90s is generally considered "pure" in any way or if the Bell streams pretty much terminate with Research V10 and SVR4, (and IX) at the turn of the 90s.

1 year, 9 months

7
9
0 0

The AWK Programming Language, 2nd Ed.: What's new?

by markus schnalke

Hoi, I just discovered that one of my favorite computer books about my best liked programming language (besides C) releases in a second edition. Does anyone know what the differences of 1st and 2nd edition are? As the original book is almost perfect, the only rework and extension direction I can think of is towards different implementations like gawk, mawk, portability and such things. Does anyone know more about it? Maybe some inside information? ;-) meillo

1 year, 9 months

5
5
0 0

Unix install & "standalone" package

by Paul Ruizendaal

Recently, I was looking into the “Das U-Boot” boot loader package. Summarised with great simplification, u-boot bundles device drivers, file systems, commands and a Bourne-like shell into a standalone package. Normally it auto-runs a script that brings up a system, but when used in interactive mode it allows a great deal of poking around. It made me think of the “standalone” set of programs for installing early Unix. On 16-bit understandably each basic command has to be a separate standalone program, but after the shift to 32-bit bundling more functionality in a single binary would have become possible. How did the Unix “standalone” package evolve in the 80’s, both in the research and BSD lineages? Is there any retrospective paper about that? Or is it a case of “Use the source, Luke”?

1 year, 10 months

5
6
0 0

Source code for Research Unix Version 7 checkers game

by Marcus Clark

Research Unix Version 7 has a checkers game ( /usr/games/checkers). I can't find the source code for the game, does anyone know where I can find it?

1 year, 10 months

1
0
0 0

Were any of the commercial unixes source-available?

by Joseph Holsten

I’ve been playing around trying to link the OpenSolaris launch commit to various pieces in the Unix History Repository, and it’s making me wonder if we’ll ever have a chance to see the history of the systems. I’m less concerned about HPUX, AIX and SCO’s offerings since I presume someone has copy inside these companies. But what about A/UX, Irix, Tru64? Did these ever get sold with licenses to source tapes? Are there copies we need to preserve in-camera so something can exist 120 years after creation or whenever copyright expires? -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234

1 year, 10 months

6
6
0 0

3bsd tape image

by Will Senn

Hi All, Is this the only bootable 3bsd distribution tape we have? http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.ta… I don't like the idea that sourceforge is the only source, the provenance is unclear and I'm just not a big fan of how sourceforge handles downloads generally. I've found tarballs, but not tapes on TUHS. Thanks, Will

1 year, 10 months

7
12
0 0

Update CSTR tarball

by arnold＠skeeve.com

Hello All. Nelson Beebe has added PDF files for all the .ps files that didn't have them, and I did a little bit more cleaning up of the CSTRs I made available late last week. The new file is at https://www.skeeve.com/combined-cstr-2.tar.gz Warren will eventually add them to the archive, at which point I will probably take down my copies. Nelson and I request of the CSTR authors who are on the TUHS list if they are willing to make source code for their CSTRs available? That would certainly help in the preservation effort. Thanks, Arnold

1 year, 10 months

4
4
0 0

Re: Bell Labs CSTRs

by Nelson H. F. Beebe

Yesterday, Arnold Robbins kindly posted to this list a link to a bundle of Bell Labs Computing Science Technical Reports that he had, luckily for us, and for Unix, IX, and Plan 9 history, preserved in his personal library. There are 67 distinct report numbers in the bundle, and 79 different files. Today, I completed a merger of data from all of those reports into the BibTeX entries in the extensive bibliography at https://www.math.utah.edu/pub/tex/bib/unix.bib https://www.math.utah.edu/pub/tex/bib/unix.html Arnold's bundle has mostly PostScript files, but some also have PDF companions. I expect to make PDF versions available for all of them in the TUHS archives, but for now, the new BibTeX entries do not yet have suitable URLs for their retrieval. URLs will be retrofitted once the files are widely available in TUHS mirrors. Some of the reports had already been recorded in unix.bib; those that had not carry a value "Fri Aug 25" in the bibdate string, making them easy to find with a text editor, or with an SQL search in the companion SQLite3 database at https://www.math.utah.edu/pub/tex/bib/unix.db For example, % sqlite3 unix.db sqlite> .mode table sqlite> select label, title from bibtab where bibtimestamp like '2023.08.25%' order by number; For TUHS member convenience, here is a summary from unix.bib of the thus-far-recorded Bell Labs report numbers, their year (several are undated, and thus assigned 19xx), their page counts, and their titles, ordered by increasing report numbers, with column widths chosen to limit lines to 80 characters: sqlite> .mode table sqlite> .width -4 4 -8 51 sqlite> select number, year, pages, title from bibtab where (filename = 'unix.bib') and (type = 'Computing Science Technical Report') order by 0 + number; +------+------+----------+-----------------------------------------------------+ | numb | year | pages | title | +------+------+----------+-----------------------------------------------------+ | 2 | 1972 | ii + 13 | The M6 Macro Processor | +------+------+----------+-----------------------------------------------------+ | 33 | 1975 | ii + 18 | A User's Guide to DODES, a Double Precision Ordinar | | | | | y Differential Equation Solver | +------+------+----------+-----------------------------------------------------+ | 52 | 1976 | ii + 36 | A Tutorial on Galerkin's Method, using on B-splines | | | | | , for Solving Differential Equations | +------+------+----------+-----------------------------------------------------+ | 53 | 1976 | ii + 44 | Numerical Solution of Time-Varying Partial Differen | | | | | tial Equations in One Space Variable | +------+------+----------+-----------------------------------------------------+ | 54 | 1992 | ii + 35 | Troff User's Manual | +------+------+----------+-----------------------------------------------------+ | 89 | 1981 | ii + 64 | A Test of a Computer's Floating-Point Arithmetic Un | | | | | it | +------+------+----------+-----------------------------------------------------+ | 97 | 1982 | ii + 13 | A Typesetter-independent TROFF | +------+------+----------+-----------------------------------------------------+ | 100 | 1981 | ii + 14 | Why Pascal is Not My Favorite Programming Language | +------+------+----------+-----------------------------------------------------+ | 102 | 1981 | 12 | The C Language Calling Sequence | +------+------+----------+-----------------------------------------------------+ | 103 | 1981 | ii + 25 | IDEAL User's Manual | +------+------+----------+-----------------------------------------------------+ | 106e | 1979 | 34 | BPSS | +------+------+----------+-----------------------------------------------------+ | 106d | 1993 | 34 | BASS | +------+------+----------+-----------------------------------------------------+ | 106f | 1993 | 13 | CSWAP with X and Y declared complex | +------+------+----------+-----------------------------------------------------+ | 106b | 1993 | 36 | GESS | +------+------+----------+-----------------------------------------------------+ | 106a | 1993 | i + 10 | Programs for Solving Linear Equations in the PORT L | | | | | ibrary | +------+------+----------+-----------------------------------------------------+ | 106c | 1993 | 30 | SYSS | +------+------+----------+-----------------------------------------------------+ | 114 | 1991 | ii + 37 | Grap --- A Language for Typesetting Graphs Tutorial | | | | | and User Manual | +------+------+----------+-----------------------------------------------------+ | 115 | 1991 | ii + 25 | PIC --- A Graphics Language for Typesetting User Ma | | | | | nual | +------+------+----------+-----------------------------------------------------+ | 117 | 1985 | ii + 2 | A Weakness in the 4.2BSD Unix TCP/IP Software | +------+------+----------+-----------------------------------------------------+ | 118 | 1985 | ii ++ 38 | Awk --- A Pattern Scanning and Processing Language | | | | | Programmer's Manual | +------+------+----------+-----------------------------------------------------+ | 120 | 1985 | ii + 19 | Twig Reference Manual | +------+------+----------+-----------------------------------------------------+ | 122 | 1992 | ii + 31 | CHEM --- a Program for Typesetting Chemical Diagram | | | | | s: User Manual | +------+------+----------+-----------------------------------------------------+ | 123 | 1989 | 29 | C Traps and Pitfalls | +------+------+----------+-----------------------------------------------------+ | 127 | 1991 | 10 | Maintaining Cross References in Manuscripts | +------+------+----------+-----------------------------------------------------+ | 128 | 1986 | ii + 13 | Tools for Printing Indexes | +------+------+----------+-----------------------------------------------------+ | 132 | 1991 | ii + 24 | A System for Algorithm Animation Tutorial and User | | | | | Manual | +------+------+----------+-----------------------------------------------------+ | 133 | 1989 | ii + 63 | AMPL: A Mathematical Programming Language | +------+------+----------+-----------------------------------------------------+ | 135 | 1985 | i + 73 | tt TTGR --- A Package for Solving Partial Different | | | | | ial Equations in Two Space Variables | +------+------+----------+-----------------------------------------------------+ | 136 | 1987 | i + 46 | Pictures of Karmarkar s Linear Programming Algorith | | | | | m | +------+------+----------+-----------------------------------------------------+ | 142 | 1988 | i + 13 | DFORMAT --- a Program for Typesetting Data Formats | +------+------+----------+-----------------------------------------------------+ | 143 | 1993 | ii + 13 | Newsqueak: A Language for Communicating with Mice | +------+------+----------+-----------------------------------------------------+ | 145 | 1992 | ii + 111 | A Permuted Index for TeX and LaTeX | +------+------+----------+-----------------------------------------------------+ | 148 | 1991 | i + 42 | Generating Automatically-Tuned Bitmaps from Outline | | | | | s | +------+------+----------+-----------------------------------------------------+ | 149 | 1995 | i + 25 | A Fortran-to-C Converter | +------+------+----------+-----------------------------------------------------+ | 150 | 1990 | 10 | Terminal Call Processing in Esterel | +------+------+----------+-----------------------------------------------------+ | 153 | 1990 | i + 21 | Usage Summary for Selected Optimization Routines | +------+------+----------+-----------------------------------------------------+ | 154 | 1990 | i + 52 | tt TTGU --- A Package for Solving Time Varying Part | | | | | ial Differential Equations on a Union of Rectangles | +------+------+----------+-----------------------------------------------------+ | 155 | 19xx | 29 | There Is No Royal Road to Programs: A Trilogy on Ra | | | | | ster Ellipses and Programming Methodology | +------+------+----------+-----------------------------------------------------+ | 157 | 1991 | ii + 39 | Tutorial: Design and Validation of Protocols | +------+------+----------+-----------------------------------------------------+ | 158g | 19xx | 14 | Rc --- A Shell for Plan 9 and UNIX Systems | +------+------+----------+-----------------------------------------------------+ | 158b | 19xx | 9 | Plan 9 from Bell Labs | +------+------+----------+-----------------------------------------------------+ | 158a | 19xx | 1 | Plan 9: The Early Papers | +------+------+----------+-----------------------------------------------------+ | 158f | 19xx | 6 | Process Sleep and Wakeup on a Shared-memory Multipr | | | | | ocessor | +------+------+----------+-----------------------------------------------------+ | 158d | 19xx | 9 | $ 8 1 over 2 $, the Plan 9 Window System | +------+------+----------+-----------------------------------------------------+ | 158e | 19xx | 10 | Multiprocessor Streams for Plan 9 | +------+------+----------+-----------------------------------------------------+ | 158c | 19xx | 7 | Plan 9, A Distributed System | +------+------+----------+-----------------------------------------------------+ | 158h | 19xx | 12 | A New C Compiler | +------+------+----------+-----------------------------------------------------+ | 159 | 19xx | 15 | Efficient Algorithms for Constructing Testing Sets, | | | | | Covering Paths, and Minimum Flows | +------+------+----------+-----------------------------------------------------+ | 160 | 1991 | 21 | What is ``Object-Oriented Programming''? | +------+------+----------+-----------------------------------------------------+ | 161 | 19xx | 19 | Sixteen Ways to Stack a Cat | +------+------+----------+-----------------------------------------------------+ | 162 | 19xx | 91 | A User's Manual for MetaPost | +------+------+----------+-----------------------------------------------------+ | 163i | 1992 | 50 | GETLAB | +------+------+----------+-----------------------------------------------------+ | 163 | 1992 | 1 | The IX Multilevel-Secure UNIX System | +------+------+----------+-----------------------------------------------------+ | 163h | 19xx | 2 | Glossary | +------+------+----------+-----------------------------------------------------+ | 163d | 19xx | 12 | The Design of IX | +------+------+----------+-----------------------------------------------------+ | 163c | 19xx | 19 | Multilevel Security in the UNIX Tradition | +------+------+----------+-----------------------------------------------------+ | 163f | 19xx | 3 | Multilevel Windows on a Single-level Terminal | +------+------+----------+-----------------------------------------------------+ | 163e | 19xx | 11 | A Tour of IX | +------+------+----------+-----------------------------------------------------+ | 163b | 19xx | 1 | The IX Multilevel-Secure UNIX System | +------+------+----------+-----------------------------------------------------+ | 163g | 19xx | 8 | Secure IX Network | +------+------+----------+-----------------------------------------------------+ | 164 | 19xx | i + 20 | Drawing Graphs with MetaPost | +------+------+----------+-----------------------------------------------------+ Here is a table of authors: sqlite> .width -4 4 62 sqlite> .output foo.out.6 sqlite> select number, year, author from bibtab where (filename = 'unix.bib') and (type = 'Computing Science Technical Report') order by 0 + number; +------+------+----------------------------------------------------------------+ | numb | year | author | +------+------+----------------------------------------------------------------+ | 2 | 1972 | Andrew D. Hall | +------+------+----------------------------------------------------------------+ | 33 | 1975 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 52 | 1976 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 53 | 1976 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 54 | 1992 | Joseph F. Ossanna and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 89 | 1981 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 97 | 1982 | Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 100 | 1981 | Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 102 | 1981 | Steven C. Johnson and Dennis M. Ritchie | +------+------+----------------------------------------------------------------+ | 103 | 1981 | Christopher J. Van Wyk | +------+------+----------------------------------------------------------------+ | 106e | 1979 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106d | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106f | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106b | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106a | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106c | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 114 | 1991 | Jon L. Bentley and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 115 | 1991 | Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 117 | 1985 | Robert T. Morris | +------+------+----------------------------------------------------------------+ | 118 | 1985 | Alfred V. Aho and Brian W. Kernighan and Peter 3. Weinberger | +------+------+----------------------------------------------------------------+ | 120 | 1985 | Steven W. K. Tjiang | +------+------+----------------------------------------------------------------+ | 122 | 1992 | Jon L. Bentley and Lynn W. Jelinski and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 123 | 1989 | Andrew Koenig | +------+------+----------------------------------------------------------------+ | 127 | 1991 | Alfred V. Aho and Ravi Sethi | +------+------+----------------------------------------------------------------+ | 128 | 1986 | Jon L. Bentley and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 132 | 1991 | Jon L. Bentley and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 133 | 1989 | Robert Fourer and David M. Gay and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 135 | 1985 | Linda Kaufman and Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 136 | 1987 | David M. Gay | +------+------+----------------------------------------------------------------+ | 142 | 1988 | J. L. Bentley | +------+------+----------------------------------------------------------------+ | 143 | 1993 | Rob Pike | +------+------+----------------------------------------------------------------+ | 145 | 1992 | Bill Cheswick | +------+------+----------------------------------------------------------------+ | 148 | 1991 | John D. Hobby | +------+------+----------------------------------------------------------------+ | 149 | 1995 | S. I. Feldman and David M. Gay and Mark W. Maimone and N. L. S | | | | chryer | +------+------+----------------------------------------------------------------+ | 150 | 1990 | Gary J. Murakami and Ravi Sethi | +------+------+----------------------------------------------------------------+ | 153 | 1990 | David M. Gay | +------+------+----------------------------------------------------------------+ | 154 | 1990 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 155 | 19xx | M. Douglas McIlroy | +------+------+----------------------------------------------------------------+ | 157 | 1991 | Gerard J. Holzmann | +------+------+----------------------------------------------------------------+ | 158g | 19xx | Tom Duff | +------+------+----------------------------------------------------------------+ | 158b | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Howard Trickey | +------+------+----------------------------------------------------------------+ | 158a | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Howard Trickey | | | | and Tom Duff and Gerard Holzmann | +------+------+----------------------------------------------------------------+ | 158f | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Gerard Holzman | | | | n | +------+------+----------------------------------------------------------------+ | 158d | 19xx | Rob Pike | +------+------+----------------------------------------------------------------+ | 158e | 19xx | David Leo Presotto | +------+------+----------------------------------------------------------------+ | 158c | 19xx | Dave Presotto and Rob Pike and Ken Thompson and Howard Trickey | +------+------+----------------------------------------------------------------+ | 158h | 19xx | Ken Thompson | +------+------+----------------------------------------------------------------+ | 159 | 19xx | Alfred V. Aho and David Lee | +------+------+----------------------------------------------------------------+ | 160 | 1991 | Bjarne Stroustrup | +------+------+----------------------------------------------------------------+ | 161 | 19xx | Bjarne Stroustrup | +------+------+----------------------------------------------------------------+ | 162 | 19xx | John D. Hobby | +------+------+----------------------------------------------------------------+ | 163i | 1992 | Anonymous | +------+------+----------------------------------------------------------------+ | 163 | 1992 | James A. Reeds and M. Douglas McIlroy | +------+------+----------------------------------------------------------------+ | 163h | 19xx | Anonymous | +------+------+----------------------------------------------------------------+ | 163d | 19xx | M. D. McIlroy and J. A. Reeds | +------+------+----------------------------------------------------------------+ | 163c | 19xx | M. D. McIlroy and J. A. Reeds | +------+------+----------------------------------------------------------------+ | 163f | 19xx | M. D. McIlroy and J. A. Reeds | +------+------+----------------------------------------------------------------+ | 163e | 19xx | Doug McIlroy and Jim Reeds | +------+------+----------------------------------------------------------------+ | 163b | 19xx | James A. Reeds and M. Douglas McIlroy | +------+------+----------------------------------------------------------------+ | 163g | 19xx | Jim Reeds | +------+------+----------------------------------------------------------------+ | 164 | 19xx | John D. Hobby | +------+------+----------------------------------------------------------------+ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

1 year, 10 months

2
1
0 0

UNIX Disassemblers and other RE Tools

by segaloco

Hello, I've been doing some research on the history of disassembly lately, tools available historically, today, and what sorts of developments have been made regarding utilities and systems for taking a machine-code binary and working it back to some semblance of source code. So in the early days UNIX had das(I), a PDP-11 disassembler I believe written by Ken (he's OWNER in the manual) with very little information other than "it exists". Fast forward to the UNIX 4.1 manual in 1981 for the 3B20S and there is dis(1), a 3B20 disassembler. Other such manuals feature dis(1) versions for other 3B targets. Was a disassembler ever considered part of the standard binary objects toolkit with the assembler, linker, etc. or was that the sort of thing that was more niche and therefore just kinda cropped up when/if someone decided to write one? Were there legal concerns to be grappled with when producing a disassembler? Were such tools ever shipped or did they only appear in the manuals as they were technically up in the code base, just not commonly distributed or used? Also, was there any thought given during the development of C to producing "decompilers" as has been becoming more common lately? Or was it a foregone conclusion that C to assembly is a "lossy" conversion and going the other direction couldn't be fully automated. Thank you for any insights! - Matt G.

1 year, 10 months

3
2
0 0

off topic: old linux drivers?

by arnold＠skeeve.com

Does anyone collect old Linux drivers? I just found one for the "Backpack CD" which was a CD-ROM reader that would attach to a PC via the parallel port. This is from April and May 1997. Before I nuke the code, I thought I'd ask if there is anyone who collects such things. Feel free to reply privately. Thanks, Arnold

1 year, 10 months

2
1
0 0

Bell Labs CSTRs

by arnold＠skeeve.com

Hello Folks, A while back I made avaiable a tarball of two directories I had of Bell Labs CSTRs (Computing Science Technical Reports). There was some overlap between them, and at the time I didn't have the free time to go through and weed through the duplicates. I have now done that. There is a new tar file available at https://www.skeeve.com/combined-cstr.tar.gz Warren, please add this to the TUHS archives. Enjoy, Arnold

1 year, 10 months

1
0
0 0

Fwd: [SDF] Computer Museum

by Dan Cross

I thought folks on COFF and TUHS (Bcc'ed) might find this interesting. Given the overlap between SDF and LCM+L, I wonder what this may mean for the latter. - Dan C. ---------- Forwarded message --------- From: SDF Membership <membership(a)sdf.org> Date: Thu, Aug 24, 2023 at 9:10 PM Subject: [SDF] Computer Museum To: We're in the process of opening a computer museum in the Seattle area and are holding our first public event on September 30th - October 1st. The museum features interactive exhibits of various vintage computers with a number of systems remotely accessible via telnet/ssh for those who are unable to visit in person. If this interests you, please consider replying with comments and take the ascii survey below. You can mark an X for what interests you. I would like to know more about: [ ] visiting the museum [ ] how to access the remote systems [ ] becoming a regular volunteer or docent [ ] restoring and maintaining various vintage systems [ ] curation and exhibit design [ ] supporting the museum with an annual membership [ ] supporting the museum with an annual sponsorship [ ] funding the museum endowment [ ] day to day administration and operations [ ] hosting an event or meet up at museum [ ] teaching at the museum [ ] donating an artifact Info on our first public event can be found at https://sdf.org/icf

1 year, 10 months

1
0
0 0

Emacs on v7

by Adam Thornton

I finally got an Emacs running on v7--it's on misspiggy at LCML now as "ue". It's Microemacs 3.6; what I did was to clone https://github.com/troglobit/MicroEMACS and check out the first commit. Some experimentation later, it had the usual problem with v7 and DEC linkers that not all the function names (er, more generally exported symbols, but in this case, function names) were unique in the first 7 characters (which is 6 if you're working with DEC OSes). So a bit of sed later and I had something that built, linked, and appears to run with TERM=vt100 set. Arrow keys, naturally, don't work, but C-b, C-f, C-p, C-n do. I think I'm going to just make a GH repo of it, but I'm happy to send the tarball, or tar.uue, upon request. I find UUCP kinda fragile on my simh installation, and I don't know how to get to Miss Piggy's (although the uucp commands are there), so, well, uuencoding, a pasteboard buffer, iTerm2's "Paste Slowly", and cat will work as a file transfer mechanism. Adam

1 year, 10 months

3
3
0 0

John Warnock [1940--2023]

by Nelson H. F. Beebe

[This posting was sent earlier today to some local lists, but may also be of interest to TUHS members.] The UofUtah lost one its significant alumni, John Warnock, on Saturday. John received Bachelor's and Master's degrees from the Department of Mathematics, and his doctoral degree from the Department of Electrical Engineering. After jobs at Evans & Sutherland in Salt Lake City, and Xerox PARC labs in Palo Alto, CA, he later went on to co-found Adobe Systems with Chuck Geschke (1939--2021), and the PostScript, PDF, and font technologies, and many others, that came from their company changed the publishing model of the entire world. See https://www.cs.utah.edu/adobe-co-founder-and-kahlert-school-of-computing-al… https://www.ksl.com/article/50713319/adobe-co-founder-utah-native-john-warn… https://www.adobe.com/ https://en.wikipedia.org/wiki/Charles_Geschke https://en.wikipedia.org/wiki/John_Warnock John's doctoral thesis is available at: https://www.proquest.com/pqdtglobal/docview/302478116/2F149E6F459946B7PQ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

1 year, 10 months

2
1
0 0

Re: when did v8 or later get networking?

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal <pnr(a)planet.nl> > a token ring driver (written by Noel Chiappa, if I remember well). No (unless they took one I wrote for the V6 machine and adapted it); I never did anything on any Unix after V6 (I think there's nothing of any significant interest in any later Unix). Anyway, writing a driver for that board would be about as much work as writing a driver for an RK11 controller - i.e. a day or so for someone competent. Noel

1 year, 10 months

2
1
0 0

Re: when did v8 or later get networking?

by Paul Ruizendaal

> Date: Thu, 10 Aug 2023 03:17:25 +0000 > From: segaloco > >>>> TCP/IP, not datakit > > > All of the files that have timestamps at the top list 83/07/29, except ip_input.c which has 83/08/16 instead. The V8 version has _device (device driver) and _ld (line discipline) components that the 4.1cBSD code does not have. Many other files have analogs between the two. The byte ordering subroutines have been copied into a file, goo.s, from their home in 4.1cBSD in the C library (/usr/src/lib/libc/net/misc). When this work originated someone else would need to answer, [...] As far as I can tell the history of this code line goes back to 1977, when Jack Haverty at BBN wrote a TCP/IP library (porting earlier work written in PDP-11 assembler) for a slightly modified 6th Edition Unix. Fighting with 64KB core limits, throughput was horrific and he concluded that a bigger PDP-11 was needed. Mike Wingfield then did a re-implementation in C for a PDP-11/70. This worked in early 1979 and is arguably the first Unix TCP/IP stack that can still interoperate with current IPv4. However, it was still mostly a proof of concept user mode design (it was funded as a test vehicle for the later abandoned Autodin-II fork of TCP). BBN then got a contract to write a kernel mode TCP/IP stack for 4BSD (“VAX TCP” in the old BBN doc’s). This work was performed by Rob Gurwitz under supervision of Jack Haverty. This stack - although all new code - still showed its heritage: it was designed as a loosely bound kernel process providing the NCP-Unix API. Some sources seem to imply that it was developed first as a user mode process and once working in that context changed into a kernel process / thread. Beta releases were available in 1981. It worked (and interoperates with modern IPv4), but in my experiments a few years back it turned out that it is difficult to get the scheduling for this kernel process right at higher system loads. Bill Joy of CSRG concluded that the BBN stack did not perform according to his expectations. Note that CSRG was focused on usage over (thick) ethernet links, and BBN was focused on usage over Arpanet and other wide-area networks (with much lower bandwidth, and higher latency and error rates). He then in 1982 rewrote the stack to match the CSRG environment, changing the design to use software interrupts instead of a kernel thread and optimising the code (e.g. checksumming and fast code paths). It was a matter of debate how new the code was, with the extremes being that it was written from scratch using the spec versus it being mostly copied. Looking at it with a nearly 50 year distance, it seems in between: small bits of surviving SCCS suggest CSRG starting with parts of BBN code followed by rapid, massive modification; the end result is quite different but retained the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP segments). The shift from the NCP-Unix API to sockets is separate from this and was planned. CSRG had the contract to develop a new API for facilitating distributed systems with Unix and this gelled into the sockets interface. The first prototypes for this were done in 1981. Nearly all of the above source is available in the TUHS online Unix Tree (Wingfield, VAX-TCP and two early versions from CSRG - one in 2.9BSD and one in 4.1cBSD).

1 year, 10 months

4
7
0 0

Hundreds of HP-UX Manuals (Auction Links)

by segaloco

Good morning folks, just sharing some eBay sales I spotted that are just not in the cards for me, both in terms of expense and I just don't have the bandwidth to focus on other UNIX lines right now. That said, someone is selling a very, very large collection of HP-UX documents: https://www.ebay.com/itm/285425883705 https://www.ebay.com/itm/285425882004 As mentioned, quite pricy, and bulky too. However, if anyone knows anyone with a particular eye for HP-UX history, this may interest them. No idea what is and isn't preserved there, non-Bell-and-UCB stuff hasn't been on my radar hardly at all other than acknowledging it exists. Tangential but I do appreciate the consistency in their documentation appearance. I see HP-UX stuff pop up time to time and the cover motif is identical to the documents they published with analytical equipment like gas chromatographs before spinning that unit off into Agilent. - Matt G.

1 year, 10 months

1
0
0 0

V8 Streams // was Re: when did v8 or later get networking?

by Paul Ruizendaal

> Warner Losh imp at bsdimp.com > Thu Aug 10 12:45:54 AEST 2023 > wrote: > > Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead of > Socket interface... Please see this old TUHS post for some more background in DMR’s own words: https://www.tuhs.org/pipermail/tuhs/2019-August/018325.html On the topic of DMR Streams, I’m increasingly intrigued by its design: recently I’ve been deep diving into classic USB to better understand this class of devices and how to drive them (https://gitlab.com/pnru/usb_host) It would seem to me that Streams would have been a neat way to organise the USB driver stack in a v8 context. Note that an USB analog did exist in 1982: https://en.wikipedia.org/wiki/Hex-Bus Sometimes I wonder what combining v8 streams with v8 virtual directories (i.e. like Killian’s /proc) could have looked like. Having the streams network stack (or usb stack) exposed as virtual directories would have been quite powerful.

1 year, 11 months

1
0
0 0

when did v8 or later get networking?

by lm＠mcvoy.com

TCP/IP, not datakit.

1 year, 11 months

7
7
0 0

Re: v8 /etc/motd

by Steve Simon

probably local, but i do remember: “Error 17. press control + backslash + underscore + exclamation mark to continue; or any other key to reboot.”

1 year, 11 months

1
0
0 0

v8 /etc/motd

by ron minnich

Sorry if this has been asked before, but: "Welcome to Eighth Edition Unix. You may be sure that it is suitably protected by ironclad licences, contractual agreements, living wills, and trade secret laws of every sort. A trolley car is certain to grow in your stomach if you violate the conditions under which you got this tape. Consult your lawyer in case of any doubt. If doubt persists, consult our lawyers. Please commit this message to memory. If this is a hardcopy terminal, tear off the paper and affix it to your machine. Otherwise take a photo of your screen. Then delete /etc/motd. Thank you for choosing Eighth Edition Unix. Have a nice day." was this one person or a group effort. It's wonderful.

1 year, 11 months

5
5
0 0

March 17, 1988 Bill Joy @ IBM Yorktown VHS discovered thanks to 512 byte C compiler

by Charles H Sauer (he/him)

At 1:46:50, Bill says "AIX is a good thing" https://www.youtube.com/watch?v=EmC5yoE_7PY backstory on how https://xorvoid.com/sectorc.html led to this rediscovery at https://notes.technologists.com/notes/2023/08/07/koko-keeping-warm/ Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer

1 year, 11 months

1
0
0 0

Re: Help with a Unix-ish project?

by steve jenkin

six years later… A note for the list: Warren (in. IMHO, a stroke of genius) changed the Repo from xv6-minix to xv6-freebsd. <https://github.com/DoctorWkt/xv6-freebsd> -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

1 year, 11 months

2
1
0 0

Re: python

by norman＠oclsc.org

At the risk of releasing more heat than light (so if you feel compelled to flame by this message, please reply just to me or to COFF, not to TUHS): The fussing here over Python reminds me very much of Unix in the 1980s. Specifically wars over editors, and over BSD vs System V vs Research systems, and over classic vs ISO C, and over embracing vendor-specific features (CSRG and USG counting as vendors as well as Digital, SGI, Sun, et al) vs sticking to the common core. And more generally whether any of the fussing is worth it, and whether adding stuff to Unix is progress or just pointless complication. Speaking as an old fart who no longer gets excited about this stuff except where it directly intersects something I want to do, I have concluded that nobody is entirely right and nobody is entirely wrong. Fancy new features that are there just to be fancy are usually a bad idea, especially when they just copy something from one system to a completely different one, but sometimes they actually add something. Sometimes something brand new is a useful addition, especially when its supplier takes the time and thought to fit cleanly into the existing ecosystem, but sometimes it turns out to be a dead end. Personal taste counts, but never as much as those of us brandishing it like to think. To take Python as an example: I started using it about fifteen years ago, mostly out of curiousity. It grew on me, and these days I use it a lot. It's the nearest thing to an object- oriented language that I have ever found to be usable (but I never used the original Smalltalk and suspect I'd have liked that too). It's not what I'd use to write an OS, nor to do any sort of performance-limited program, but computers and storage are so fast these days that that rarely matters to me. Using white space to denote blocks took a little getting used to, but only a little; no more than getting used to typing if ...: instead of if (...). The lack of a C-style for loop occasionally bothers me, but iterating over lists and sets handles most of the cases that matter, and is far less cumbersome. It's a higher-level language than C, which means it gets in the way of some things but makes a lot of other things easier. It turns out the latter is more significant than the former for the things I do with it. The claim that Python doesn't have printf (at least since ca. 2.5, when I started using it) is just wrong: print 'pick %d pecks of %s' % (n, fruit) is just a different spelling of printf("pick %d pecks of %s\n", n, fruit) except that sprintf is no longer a special case (and snprintf becomes completely needless). I like the modern print(f'pick {n} pecks of {fruit}') even better; f strings are what pushed me from Python 2 to Python 3. I really like the way modules work in Python, except the dumbass ways you're expected to distribute a program that is broken into modules of its own. As a low-level hacker I came up with my own way to do that (assembling them all into a single Python source file in which each module is placed as a string, evaled and inserted into the module table, and then the starting point called at the end; all using documented, stable interfaces, though they changed from 2 to 3; program actually written as a collection of individual source files, with a tool of my own--written in Python, of course--to create the single file which I can then install where I need it). I have for some years had my own hand-crafted idiosyncratic program for reading mail. (As someone I know once said, everybody writes a mailer; it's simple and easy and makes them feel important. But in this case I was doing it just for myself and for the fun of it.) The first edition was written 20 years ago in C. I rewrote it about a decade ago in Python. It works fine; can now easily deal with on-disk or IMAP4 or POP3 mailboxes, thanks both to modules as a concept and to convenient library modules to do the hard work; and updating in the several different work and home environments where I use it no longer requires recompiling (and the source code need no longer worry about the quirks of different compilers and libraries); I just copy the single executable source-code file to the different places it needs to run. For me, Python fits into the space between shell scripts and awk on one hand, and C on the other, overlapping some of the space of each. But personal taste is relevant too. I didn't know whether I'd like Python until I'd tried it for a few real programs (and even then it took a couple of years before I felt like I'd really figured out out to use it). Just as I recall, about 45 years ago, moving from TECO (in which I had been quite expert) to ed and later the U of T qed and quickly feeling that ed was better in nearly every way; a year or so later, trying vi for a week and giving up in disgust because it just didn't fit my idea of how screen editors should work; falling in love with jim and later sam (though not exclusively, I still use ed/qed daily) because they got the screen part just right even if their command languages weren't quite such a good match for me. And I have never cottoned on to Perl for, I suspect, the same reason I'd be really unhappy to go back to TECO. Tastes evolve. I bet there's a lot of stuff I did in the 1980s that I'd do differently could I have another go at it. The important thing is to try new stuff. I haven't tried Go or Rust yet, and I should. If you haven't given Python or Perl a good look, you should. Sometimes new tools are useless or cumbersome, sometimes they are no better than what you've got now, but sometimes they make things easier. You won't know until you try. Here endeth today's sermon from the messy office, which I ought to be cleaning up, but preaching is more fun. Norman Wilson Toronto ON

1 year, 11 months

2
1
0 0

Early Unix and Keyboard Skills

by steve jenkin

I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’) and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades. Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis. But as well, they wrote papers and man pages, probably more. I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know? There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills, which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially. Underlying this is something I once caught as a random comment: The commonality of skills between Writing & Coding. Does anyone has any good refs for this crossover? Is it a real effect or a biased view. That great programmers are also “good writers”: takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door. Ken is famous for his brevity and succinct statements. Not sure if that’s a personal preference, a mastered skill or “economy in everything”. steve j ========= A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986 M.D. McIlroy <https://www.cs.dartmouth.edu/~doug/reader.pdf> <https://archive.org/details/a_research_unix_reader/page/n13/mode/2up> pg 10 3.4. Languages CC (v2 page 52) V2 saw a burst of languages: a new TMG, a B that worked in both core-resident and software-paged versions, the completion of Fortran IV (Thompson and Ritchie), and Ritchie's first C, conceived as B with data types. In that furiously productive year Thompson and Ritchie together wrote and debugged about 100,000 lines of production code. ========= Programming's Dirtiest Little Secret Wednesday, September 10, 2008 <http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret…> It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else. But when it comes to programming, there are only so many things you can sacrifice! You can cut down on your documentation. You can cut down on commenting your code. You can cut down on email conversations and participation in online discussions, preferring group discussions and hallway conversations. And... well, that's about it. So guess what non-touch-typists sacrifice? All of it, man. They sacrifice all of it. Touch typists can spot an illtyperate programmer from a mile away. They don't even have to be in the same room. For starters, non-typists are almost invisible. They don't leave a footprint in our online community. ========= -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

1 year, 11 months

22
30
0 0

Early multiprocessor Unix

by Paul Ruizendaal

The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate? My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code. Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s. Any other notable work in this area prior to 1985? How was the SMP implementation in SVr3 judged back in its day? Paul

1 year, 11 months

13
20
0 0

Fwd: Message from the family of Bram Moolenaar

by Steffen Nurpmeso

I do not know whether it is right, and i am surely not the right person to mourn in public, but i wanted to forward this. I only spoke to him once, he mailed me in private, but i could not help him supporting Uganda, even though i admired what he was doing, and often looked. Local capacity building, and (mutual) respect for local culture and practice, despite all sharp spikes and edges the storm causes over time, that is surely the way to do it right. --- Forwarded from Bram Moolenaar <Bram(a)Moolenaar.net> --- Sender: vim_announce(a)googlegroups.com To: vim_announce(a)googlegroups.com Subject: Message from the family of Bram Moolenaar Message-Id: <20230805121930.4AA8F1C0A68(a)moolenaar.net> Date: Sat, 5 Aug 2023 13:19:30 +0100 (WEST) From: Bram Moolenaar <Bram(a)Moolenaar.net> Reply-To: vim_announce(a)googlegroups.com List-ID: <vim_announce.googlegroups.com> Dear all, It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023. Bram was suffering from a medical condition that progressed quickly over the last few weeks. Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of. We as family are now arranging the funeral service of Bram which will take place in The Netherlands and will be held in the Dutch lanuage. The extact date, time and place are still to be determined. Should you wish to attend his funeral then please send a message to funeralbram(a)gmail.com. This email address can also be used to get in contact with the family regarding other matters, bearing in the mind the situation we are in right now as family. With kind regards, The family of Bram Moolenaar -- -- You received this message from the "vim_announce" maillist. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_announce+unsubscribe(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_announce/20230805121930.4AA8F1C0A68%4…. -- End forward <20230805121930.4AA8F1C0A68(a)moolenaar.net> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 year, 11 months

5
5
0 0

Re: Cool talk on Unix and Sendmail history, by Eric Allman

by norman＠oclsc.org

Doug McIlroy: This reminds me of how I agonized over Mike Lesk's refusal to remove remote execution from uucp. ==== Uux, the remote-execution mechanism I remember from uucp, had rather better utility than the famous Sendmail back-door: it was how uucp carried mail, by sending a file to be handed to mailer on the remote system. It was clearly dangerous if the remote site accepted any command, but as shipped in V7 only a short list of remote commands was allowed: mail rmail lpr opr fsend fget. (As uucp was used to carry other things like netnews, the list was later extended by individual sites, and eventually moved to a file so reconfiguration needn't recapitulate compilation). Not the safest of mechanisms, but at least in V7 it had a use other than Mike fixing your system for you. Is there some additional history here? e.g. was the list of permitted commands added after arguments about safety, or some magic command that let Mike in removed? Or was there a different remote-execution back door I don't remember and don't see in a quick look at uuxqt.c? Norman Wilson Toronto ON

1 year, 11 months

31
77
0 0

Re: emacs

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > when did emacs arrive in unix and was it a full fledged text editor > when it came or was it sitting on top of some other subssystem Montgomery Emacs was the first I knew of; it started on PDP-11 UNIX. According to: https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Montgomery… Montgomery Emacs started in 1980 or so; here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/emacs/emacs.doc is a manual from May, 1981. It had pretty full EMACS functionality, but the editor was not written in an implementation language of any kind (like the original, and like much later GNU Emacs); it was written in C. It did have macros for extensions, but they were written in Emacs commands, so, like the TECO that the original was written in, their source looks kind of like line noise. (Does anyone young even know what line noise looks like any more? I feel so old - and I'm a youngster compared to McIlroy!) > Was TECO ever on unix? I don't think it was widespread, but there was a TECO on the PDP-11 UNIXes at MIT; until Montgomery Emacs arrived, it was the primary editor used on those machines. Not that most people used TECO commands for editing; early on, they added '^R mode' to the UNIX TECO, similar to the one on ITS TECO, and a macro package was written for it (in TECO - so again, the source looks like line noise); the command set was like a stripped down EMACS - about a dozen command characters total; see the table about a page down here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/help All the source, and documentation, such as it is, it available, here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/ but don't even think about running it. It's written in MACRO-11, and it used a version of that hacked at MIT to run on UNIX. To build new versions of that, you need a special linker - written in BCPL. So you also need the UNIX BCPL compiler. Noel

1 year, 11 months

2
2
0 0

Re: emacs

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > There was a guy in production at Google using Unix TECO as his main > editor when I joined in 2002. Do you happen to know which version it was, or what it was written in? It must have been _somebody_'s re-implementation, but I wonder who or where (or why :-). Noel

1 year, 11 months

4
3
0 0

Re: [COFF] Re: What Happened to Interdata?

by segaloco

Steve thank you for the recollections, that is precisely the sort of story I was hoping to hear regarding your Interdata work. I had found myself quite curious why it would have wound up on a shelf after the work involved, and that makes total sense. That's a shame too, it sounds like the 8/32 could've picked up quite some steam, especially beating the VAX to the punch as a UNIX platform. But hey, it's a good thing so much else precipitated from your work! Also, those sorts of microarchitectural bugs keep me up at night. For all the good in RISC-V there are also now maaaaany fabs with more license than ever to pump out questionable ICs. Combine that with questionable boards with strange bus architectures, and gee our present time sure does present ripe opportunities to experiment with tackling those sorts of problems in software. Can't say I've had the pleasure but it would be nice to still be able to fix stuff with a wire wrap in the field... - Matt G. P.S. TUHS cc as promised, certainly relevant information re: Interdata 8/32 UNIX. ------- Original Message ------- On Friday, August 4th, 2023 at 6:17 PM, scj(a)yaccman.com <scj(a)yaccman.com> wrote: > Sorry for the year's delay in responding... I wrote the compiler for the Interdata, and Dennis and I did much of the debugging. The Interdata had much easier addressing for storage: the IBM machine made you load a register, and then you had a limited offset from that register that you could use. I think IBM was 10 bits, maybe 12. But all of it way too small to run megabyte-sized programs. The Interdata allowed a larger memory offset and pretty well eliminated the offsets as a problem. I seem to recall some muttering from Dennis and Ken about the I/O structure, which was apparently somewhat strange but much less weird than the IBM. > > Also, IBM and Interdata were big-endian, and the PDP was little-endian. This gave Dennis and Ken some problems since it was easy to get the wrong endian, which blew gaskets when executed or copied into the file system. Eventually, we got the machine running, and it was quite nice: true 32-bit computing, it was reasonably fast, and once we got the low-level quirks out (including a famous run-in with the "you are not expected to understand this" code in the kernel, which, it turned out, was a prophecy that came true. On the whole, the project was so successful that we set up a high-level meeting with Interdata to demo and discuss cooperation. And then "the bug" hit. The machine would be running fine, and then Blam! it has lept into low memory and aborted with no hint as to what or where the fault was. > > We finally tracked down the problem. The Interdata was a microcode machine. And older Unix system calls would return -1 if they failed. In V7, we fixed this to return 0, but there was still a lot of user code that used the old convention. When the Interdata saw a request to load -1 it first noticed that the integer load was not on an address divisible by 4, and jumped to a location in the microcode and executed a couple of microinstructions. But then it also noticed that the address was out of range and entered the microcode again, overwriting the original address that caused the problem and freezing the machine with no indication of where the problem was. It took us only a day or two to see what the problem was, and it was hardware, and they would need to fix it. We had our meeting with Interdata, gave a pretty good sales pitch on Unix, and then said that the bug we had found was fatal and needed to be fixed or the deal was off. The bottom line, they didn't want to fix the bug in the hardware. They did come out with a Unix port several years later, but I was out of the loop for that one, and the Vax (with the UCB paging code) had become the machine of choice... > > --- > > On 2023-07-25 16:23, segaloco via COFF wrote: > >> So I've been studying the Interdata 32-bit machines a bit more closely lately and I'm wondering if someone who was there at the time has the scoop on what happened to them. The Wikipedia article gives some good info on their history but not really anything about, say, failed follow-ons that tanked their market, significant reasons for avoidance, or anything like that. I also find myself wondering why Bell didn't do anything with the Interdata work after springboarding further portability efforts while several other little streams, even those unreleased like the S/370 and 8086 ports seemed to stick around internally for longer. Were Interdata machines problematic in some sort of way, or was it merely fate, with more popular minis from DEC simply spacing them out of the market? Part of my interest too comes from what influence the legacy of Interdata may have had on Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several times in the chemistry-side of my career and am curious if I was ever operating some vague descendent of Interdata designs in the embedded controllers in say one of my mass specs back when. >> >> - Matt G. >> >> P.S. Looking for more general history hence COFF, but towards a more UNIXy end, if there's any sort of missing scoop on the life and times of the Bell Interdata 8/32 port, for instance, whether it ever saw literally any production use in the System or was only ever on the machines being used for the portability work, I'm sure that could benefit from a CC to TUHS if that history winds up in this thread.

1 year, 11 months

2
1
0 0

Re: python

by Douglas McIlroy

> Most of the time I'd rather not have to care whether the thing > I'm printing is a string, or a pointer, or an integer, or whatever: > I just want to see its value. > Go has %v for exactly this. It's very nice for debugging. Why so verbose? In Basic, PRINT required no formatting directives at all. Doug

1 year, 11 months

3
2
0 0

Re: Split addressing (I/D) space (inspired by the death of the python... thread)

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > first two subsystems for the 11 that ran out of text space were indeed > vi and Pascal subsystems Those were at Berkeley. We've established that S-I&D were in V6 when it was released in May, 1975 - so my question is 'what was Bell doing in 1975 that needed more than 64KB?' The kernel, yeah, it could definitely use S-I&D on a larger system (especially when you remember that stock V6 didn't play any tricks with overlays, and also dedicated one segment - the correct term, used in the 1972 -11/45 processor manual - to the user structure, and one to the I/O page, limiting the non-S-I&D kernel to 48KB). But what user commands? It happens that I have a complete dump of one of the MIT systems, so I had a look to see what _we_ were running S-I&D on. Here's the list from /bin (for some reason that machine doesn't have a /usr/bin): a68 a86 c86 emacs lisp ndd send teco The lisp wasn't a serious use; I think the only thing we ever used it for was 'doctor'. So, two editors, a couple of language tools, an email tool (not sure why that one got it - maybe for creating large outgoing messages). (The ndd is probably to allow the biggest possible buffers.) Nothing in /etc, and in /lib, just lint1 and lint2 (lint, AFAICT, post-dates V6). Not a lot. So now I'm really curious what Bell was using S-I&D for. (If I weren't lazy, I'd pull the V6 distro - which is only available as RK images, and individual files, alas - and look in /bin and everywhere and see if I can find anything. I suspect not, though.) Anyone have any guesses/suggestions? Maybe some custom applications? Noel

1 year, 11 months

1
0
0 0

Re: python

by jnc＠mercury.lcs.mit.edu

How is discussing Python's output options related to the history of Unix? Noel

1 year, 11 months

3
2
0 0

SVR2 on the PDP-11? SVR3?

by segaloco

Does anyone know if there are any surviving examples of SVR2 for the PDP-11? Various SVR2 manuals still make mention of the assembler, linker, etc. and the pdp11 variable is present in machid(1)*. And on the note of the later years of the PDP-11, was there any hope for SVR3 on the PDP? I presume the introduction of demand paging was the end of things but I would be curious for anyone's recollections on the final years of System V on the PDP-11. - Matt G. P.S. *interesting little 3B5 side note, found as I was checking references that machid(1) in the "System V" branded manual from the initial System V commercial release mentions the pdp11, vax, and u3b machines, the latter being the 3B20S. However, the "Release 5.0" branded manuals also make mention of the u3b5 machine, the 3B5. The System V manuals are from January 1983 and the Release 5.0 manuals are June 1982. There isn't an earlier reference to cite as machid(1) was introduced in Release 5.0, at least from the literature I have available. The 4.x series ran on at least the PDP-11, VAX, and 3B20S computers at least, matching those listed in the System V manual. From what I have available initial 3B5 literature was distributed in the form of small binders a little different from the grey-on-black 1984 DEC Processor SVR2 binders, possibly right on the cusp of the split of p_man from u_man as this 3B5 User's Manual that I have contains sections 1-6 rather than just 1 and 6. They're dark grey with a large orange square in the middle (I believe I've sent a photograph of the manual before).

1 year, 11 months

2
1
0 0

emacs

by Will Senn

As a longtime user and lover of ed/ex/vi, I don't know much about emacs, but lately I've been using it more (as it seems like any self-respecting lisper, has to at least have a passing acquaintance with it). I recently went off and got MACLISP running in ITS. As part of that exploration, I used EMACS, but not just any old emacs, emacs in it's first incarnation as a set of TECO macros. To me, it just seemed like EMACS. I won't bore you with the details - imagine lots of control and escape sequences, many of which are the same today as then. This was late 70's stuff. My question for the group is - when did emacs arrive in unix and was it a full fledged text editor when it came or was it sitting on top of some other subssystem in unix? Was TECO ever on unix? Will

1 year, 11 months

14
16
0 0

Re: Split addressing (I/D) space (inspired by the death of the python... thread)

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill > Strecker that he could implement an 11 on a single"hex high" CPU board > if he got rid of the lights and switches. He ran out of room to > implement seperate I/D, so it became an 11/40 class [and it has an > 8008-1 that runs the front panel]. I don't know about the Strecker story, but the first PDP-11 CPU on a single card (a hex card) was the KD11-D: https://gunkies.org/wiki/KD11-D_CPU of the -11/04. It didn't have _any_ memory management, though (or a front panel; to get that, you had to use the KY"11-LB: https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console which added another quad card). The first -11 CPU i) on a single card and ii) with memory management was the FDF11-A: https://gunkies.org/wiki/KDF11-A_CPU The first -11 CPU i) on a single card and ii) with split I+D memory management was the KDJ11-A. > It was not until 11/44 that DEC was able to make a hex height > implementation of the 11 that managed to cram a full 11/70 into that > system. I'm not sure what your point is here? The KD11-Z CPU of the -11/44: https://gunkies.org/wiki/KD11-Z_CPU was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex cards). Floating point was an extra card; CIS was 2 more. > if you look at the link line of sys/run the 45 does not have -i Split I+D for the kernel was not supported by the linker in V6; a combination of 'sysfix' (a special post-processor, which took as input a relocatable linked image) and code in m45.s was needed. https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition https://gunkies.org/wiki/UNIX_V6_memory_layout The code in m45.s to handle split I+D in the kernel: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s starts at 'start:' and is adequately commented to tell you what it's doing when it plays around with kernel memory. > From: Will Senn > with I/D, you can use 64k for I and 64k for D. Was that it, or were > there other tricks to get even more allocated I have this vague memory that someone (Berkeley, I think?) added support for automatic code overlays in user processes. The programmer had to decide which modules went in which overlays, but after that it was all automagic. There was a 4xx code allocated to them. I think the support for that (in e.g. the linker) was somehow involved with the use of overlays in the kernel, but I don't know the details (nothing after V6 is at all interesting to me). > didn't the 11 max out at 256k)? You need to distinguish between i) the amount of memory the machine could handle, and ii) the amount of memory that running code could 'see' at any instant. The latter was always either 64KB, or 64KB+64KB (with split I+D turned on, on CPUs which supported it). The former, it's complicated. Mostly, on UNIBUS only machines, it was 256KB. (Although there was the Able ENABLE: https://gunkies.org/wiki/Able_ENABLE which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70, as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44 had an Extended UNIBUS, and could also handle up to 4MB (but only after the MS11-P became available; there were only 4 main memory slots in the backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the KB11-A (Revision A), which only suppported 256 KB, all later revisions and CPUs could also handle up to 4MB. Noel

1 year, 11 months

2
1
0 0

Re: Split addressing (I/D) space (inspired by the death of the python... thread)

by Steve Simon

not quite split i and d but i do have a memory of some code which could run in three parts as overlays. this could have been through exec’ing the next overlay with an appropriate argv and a pipe or file of data, or, perhaps there was some kernel support for overlays in early unix. anyone seen evidence of this? sadly i cannot remember where i saw it, i want to say it was a versatex printer driver but i am pretty sure that is rubbish. -Steve

1 year, 11 months

1
0
0 0

Re: Split addressing (I/D) space (inspired by the death of the python... thread)

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > Does unix (v7) know about the PDP-11 45's split I/D space through > configuration or is it convention and programmer's responsibility to > know and manage what's actually available? There are two different cases: i) support of split I+D in the kernel, and ii) support of split I+D in user processes. Both arrived with V6; the V5 source: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/main.c (former for kernel; later for users) shows no sign of it. > From: Kenneth Goodwin <kennethgoodwin56(a)gmail.com> > 1. I don't think the 11/45 had split I & d. > But I could be wrong. > That did not appear until the 11/70 You are wrong. The chief differences between the KB11-A&-D of the -11/45 and the -B&-C of the -11/70 were i) the latter had a cache, and ii) the latter used the 32-bit wide Main Memory Bus, which also allowed up to 4 Mbytes of main memory. Detail here: https://gunkies.org/wiki/PDP-11/70 along with a couple of lesser differences. > From: "Ronald Natalie" > with only 8 segment registers combined for code, data, and stack I think you meant for code, data, and user block. > The 55 (just a tweaked 45) The /50 and /55 had the identical KB11-A&-D of the /45; the difference was that they came pre-configured with Fastbus memory. > In addition the 23/24/J-11 and those derived processors did. No; the F-11 processors did not support I&D, the J-11 did. Noel

1 year, 11 months

1
0
0 0

Re: Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman)

by segaloco

> And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary. > > Warner Losh You're right, I just tried it out. Been avoiding that pattern for years because I swear some make implementation I used at one point was very unhappy with that, but if V7 does it, then whatever implementation that was is probably not what I want to be using anyway. Also shows how little I've used specifics of BSD, I've never made a Makefile using bsd.prog.mk, although I have this desire for a write-once-build-everywhere Makefile that the preponderance of build systems that generate them imply is an exercise in futility... On that note, one quirk I've found with the implicit .c.o rule on older UNIX, just tested on V7 and System III, is that they render: cc -c $< rather than cc -c -o $@ $< If you have an object list with objects in several different directories, it spits them all out in the CWD, causing problems if you have similarly named files in multiple directories, and then outright failing on the final compilation if it's something like $(CC) -o $(BIN) $(OBJS) because $(OBJS) is a string of object pathnames with the full nested path, not just the resulting *.o files. Granted, I could be anti-patterning here for all I know, I haven't worked closely with a whole lot of Make-based projects that aren't my own. Maybe I just haven't read these darn papers I'm always hunting down enough. - Matt G.

1 year, 11 months

2
1
0 0

Re: Cool talk on Unix and Sendmail history, by Eric Allman

by Douglas McIlroy

"Lessons learned" overlooked the Morris worm, which exploited not only the unpardonable gets interface, but also the unpardonable back door that Allman built into sendmail. This reminds me of how I agonized over Mike Lesk's refusal to remove remote execution from uucp. (Like Eric, Mike created the feature to help fix the myriad trouble reports these communication facilities stimulated.) It seemed irresponsible to distribute v7 with the feature present, yet the rest of uucp provided an almost indispensable service. The fig leaf for allowing uucp in the distribution was that remote execution was described in the manual. If you didn't like it you could delete or fix uucp. (Sendmail's Trojan horse was undocumented, though visible in the code.) Doug

1 year, 11 months

1
0
0 0

Posted a video on installing and running v7

by Will Senn

Hi All, I got some questions recently about getting v7 working, so I fired up OBS to create a video walkthrough of the install process and first steps (it's basically following my v7 note, but hey some folks dig video). The video is totally amateur hour, but it was fun. I never get tired of logging in as dmr, writing hello.c, running cc, running hello and watch the magic of hello, world appear on "screen". As a reminder - the note (and thus, the video) walks the user through installing OpenSIMH (including pdp11), building a tape image, installing to disk from tape, booting off the disk, building and using a DZ-11 as a telnet listener on 16 lines, adding a user, running learn, and piddly stuff like setting baud, delays, and such. Not a lot of hand-holding, but some. When I get around to it, I'll probably update the note to add additional test environments (I'm pretty sure it works anywhere OpenSIMH does, but some folks like to see there system or one kinda like it in the list of tested systems). I'm running LMDE5 and Debian 12 Bookworm these days, so I know they work there in addition to pretty much any Linux Mint, MX Linux, FreeBSD, Mac OS, etc. I'm still in awe of Hayle and Ritchie's Setting Up Unix - Seventh Edition as the basis of my note - 44 y.o. and counting... for holding up so well. The blog: https://decuser.github.io The blog post: https://decuser.github.io/unix/research-unix/v7/videos/2023/07/14/installin… The note blog post: https://decuser.github.io/unix/research-unix/v7/2022/10/28/installing-and-u… Later, Will

1 year, 11 months

2
2
0 0

Cool talk on Unix and Sendmail history, by Eric Allman

by Rich Morin

Lessons Learned from Sendmail https://www.youtube.com/watch?v=Re1MAO6jOLE -r

1 year, 11 months

12
13
0 0

Offering Free Unbound System V Document Processing Guide (1983)

by segaloco

Good day all, I'm emailing to offer a duplicate UNIX document I picked up free of charge to whoever speaks for it first, I'll even cover the shipping. What I've got is a second copy of the Document Processing Guide shipped with the initial System V version, code 341-920, from 1983. Now for the caveat: I ordered this second copy as it was in much rougher shape than the one I currently have. I intend to chop the spine off so I can get quality scans of the pages rather than having to deal with creasing the hell out of the binding on my other copy (unlike the manuals and some of the other guides, this one is a typical paperback glue binding.) Once I'm done with the scans I'm just going to put all of the pages in a binder (as they're already Bell-style 7-hole punched.) That to say, I'm not ready to ship it right now, just got it today, still need to do the scans. As for contents, this contains the System V-era versions of the following papers (titles paraphrased): - Advanced Editing on UNIX - Sed - NROFF/TROFF User's Manual - TROFF Tutorial - Tbl - Eqn - MM Macros Manual - View Graphs and Slide Macros Anywho, figured I'd see if anyone was interested in this after I'm done with it. Otherwise I'll just see if a library around here is interested. - Matt G.

1 year, 11 months

1
1
0 0

AT&T UNIX Support Activities Post-1983

by segaloco

Hello, I received in the mail today a USOC listing from the NY Bell division listing various standardized service codes in 1982. I wasn't particularly expecting to see anything relevant to UNIX in there, but flipping through the pages, it did have me curious on one point. Prior to divestiture, one of the conditions placed on Bell was that they could not support UNIX. Sure, tapes could find their way to individuals for service costs or under particular agreements, but this provision of "service" seemed to be right out and not allowed under their then-terms. This is presumably why there is nothing resembling UNIX in this manual, nor can I find anything implying 3B20(D/S) services. So after 1983 when the cat is out of the bag and AT&T begins aggressive marketing, what sorts of "services" were they then providing to UNIX customers that they couldn't before? One item I've got that further complicates my understanding, a class listing from Western Electric Corporate Education from July, 1983[1]. Did offering classes like this not constitute "support", or was there a little window between 1982 and 1984 where AT&T could start their true marketing and support in earnest while still not being absolutely complete with the divestiture of the Western Electric business? In any case, if WECo was out the door as part of the legal settlement, it does strike me as a bit odd they'd put any work into spinning up the WECo Corporate Education machine on this for the space of just part of a year in 1983, only to then rebrand it all for ATTIS when Jan 1st passes. An additional time-frame indicator is while this foldout does list WECo, it is devoid of Bell system logos, consistent with the date as that was one of the conditions that started to take effect that summer. Anywho, I'm sure some of the general information what services they provided in addition to licensing and distributing for UNIX license holders lives in documentation out there, so I'll be reading up too, but figured it'd be good to ask if nothing else to figure out what was going on in the early 80s, because that WECo training document certainly has me a bit curious on the timeframe vs what they could and couldn't do throughout the Bell System breakup years. - Matt G. [1] -https://imgur.com/a/xbEOGZn Note, I intend to do a proper scan on glass with this after I get through some IBM stuff I'm working on, so don't worry, I don't intend these photos to be historical record.

1 year, 11 months

1
0
0 0

"UNIX/370: A Feasibility Study" by W.A. Felton (Bell TM)

by Tom Lyon

A friend found this doc which as far as I can tell is not online anywhere yet. Preliminary sketch for the UNIX/370 effort at Bell based on TSS/370. Apparently started at Holmdel, I had always thought Indian Hill. https://drive.google.com/file/d/1zrnKJ7fT1yrt_9r8QJHtZm7cI9EQEw76/view?usp=… Please archive!

1 year, 11 months

4
5
0 0

(Amdahl UNIX) "Notes on Au Performance - or How to get the Pb out of Au"

by Tom Lyon

This is perhaps the first significant document I wrote at Amdahl. Although undated, I believe this was written in August 1979, after I had attended a 2 week class at IBM Chicago about VM//370(CP) internals and performance. The paper makes reference to V7 UNIX being "on order", so this is when the V6 UNIX system was in use. IIRC, V7 UNIX was released in Nov. of 1979. https://drive.google.com/file/d/1cB2eqTwmicj1AQOiULDZjED5Rq-_V4N4/view?usp=… Huge thanks to my friend Karl D. for hanging on to this for 44 years.

1 year, 11 months

2
2
0 0

Re: Research UNIX PDP 11/45

by jnc＠mercury.lcs.mit.edu

> From: Henry Bent > there will be a lengthy addendum shortly. The most useful thing is probably this: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/low.s which lists exactly what was there; not only the types, but how many of each there are. This is from 'nsys', which is slightly before the actual V4, so it's quite early. 'low.s' is inherently machine-specific; i.e. different machines would share most kernel files identically, but _not_ this one - unless they had _absolutely identical_ device sets. So this one is _probably_ the one from the /45 in picture. It shows: RK11 RF11 PC11 TC11 TM11 1xKL11 12xDC11 1xDP11 (synchronous serial) 1xDN11 (dial-out asynch control) 1xDR11C (parallel port to -11/20) 2xDC11 (Screw Works voice synthesizer) 1xDR11A (voice response unit) 1xDR11C (C/A/T typesetter) (Line printer, card reader and RP11 are commented out; more about the RP11 in a later message. There's also this: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/11-45 which is a bit hard to interpret, but I think might list what's in each rack: the TC11, RK11 (early ones), RF11 and TM11 (early ones) were large custom wire-wrapped backplanes which bolted into the front or back of a 19 inch rack; this: https://gunkies.org/wiki/RK11-C_disk_controller has an image of such an RK11. The "MOS 16-24" is probably a reference to an MS11: https://gunkies.org/wiki/MS11_Semiconductor_Memory_System which had to mount in the CPU backplane. The "MM" entries are likely core memory units; probably MM11-K's: https://gunkies.org/wiki/MM11-K_core_memory since they seem to be 4KW each. (Maybe MM11-E's or 'F's, though; those are also 4KW each.) I'm not sure what they "PL"s are - probably Plessey core? Anyway,it looks like the machine had 104KB total. This file: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/conf.c lists all the types of devices on the machine. One oddity is that it lists two RK11's; but if you look at the RK11 driver: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/rk.c it's only set up to handle one physical controller. But there is this: #define JRK 1 /* temp */ if (bp->b_dev.d_major==JRK) d = bp->b_dev.d_minor; else d = bp->b_blkno%3; so the two different major device entries appear to handle the same disks in different ways ("d = bp->b_blkno%3" will spread a virtual drive across three physical drives). Memory, it would have been hard to say (UNIX even then sized memory at start up) but then I found that '11-45' file. I also found a copy of the CACM version of the UNIX paper: https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf which says the machine had 144KB (so they had added 40KB more at that point). (I seem to recall someone had scanned the SOSP version; I didn't save the pointer, but if someone knows where it is, it would be interesting to look, and see what it says - they seemed to update this paper on a regular basis - the copy included with V6 talks about the -11/70.) The system at that point had "a 1M byte fixed-head disk .. four moving-head disk drives which each provide 2.5M bytes on removable disk cartridges, and a single moving-head disk drive which uses removable 40M byte disk packs" The RS11 disks for the RF11 were 512KB, so either they'd added a second one, or switched to an RS04 (but that's a MASSBUS device). The big disk was an RP03 so they had added an RP11, which wasn't present earlier. Noel

1 year, 11 months

3
2
0 0

Research UNIX PDP 11/45

by Henry Bent

Hello all, I asked this question in a different thread but it may have been bogged down in other discussion so I figured it was worth asking again. What was the hardware configuration of the 11/45 that Research used to implement early UNIX? This would be circa late 1972/earlty 1973. I have found numerous references to it being an early production 11/45, and I assume that it had an RK05, but I cannot find any details about things like memory size and other peripherals. Since the only extant sources are for V1, which was as I understand only run on a singular 11/20, and V5 by which time UNIX had spread it doesn't seem possible to infer a hardware configuration from existing code. -Henry

1 year, 11 months

3
2
0 0

Re: Research UNIX PDP 11/45

by jnc＠mercury.lcs.mit.edu

> From: Henry Bent > What was the hardware configuration of the 11/45 that Research used to > implement early UNIX? .. I have found numerous references to it being > an early production 11/45, and I assume that it had an RK05, but I > cannot find any details about things like memory size and other > peripherals. A good source is the Ken+Dennis picture: https://www.bell-labs.com/usr/dmr/www/picture.html and the caption which Dennis wrote for it. The image is not quite definitive, because there are two machines in that bank of racks: a PDP-11/20, and a PDP-11/45 (mostly hidden behind the right-hand Teletype), and it's not possible to say which of the two machines the various peripherals are attached to. But it seems to have had two RK03's (and an RK11 somewhere to drive them) and an RF11 (no idea how many RS11 drives it had at that point),; a TU56 (and a TC11 somewhere to drive that), and a PC05 (with PC11 controller boards). (There are pages for all these things here: https://gunkies.org/wiki/Category:UNIBUS_Peripherals which include links to the DEC documentation on them.) I'm doing more searching, through documents I recall having additional crumbs; let me go ahead and send this, and there will be a lengthy addendum shortly. Noel

1 year, 11 months

4
3
0 0

Some old DECtapes from Dennis Ritchie

by Warren Toomey

All, way back when, Dennis sent me some DECtape images to look after. I've put some of them in the Unix Archive (the s1 and s2 tapes) as they contained Unix source code or binaries. The others I kept aside as they didn't contain Unix code, or they were potentially sensitive. Anyway, Angelo Papenhoff asked for any old tapes from the Labs that might contain fragments of B source code or B binaries. I passed the extra tapes on to him, and he has found some very interesting nuggets from the time period when B -> NB -> C. So, to help provide the context around Angelo's work, I've decided to put all the tapes that Dennis gave me here: https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ Cheers, Warren

1 year, 11 months

9
14
0 0

Re: Bell COBOL Environment?

by Paul Ruizendaal

> Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product. Ryan-McFarland comes to mind: in my recollection they were the leading Cobol on small machines in the early 80’s. Ryan-McFarland’s predecessor company Digitek was contracted to do the PL/I compiler for Multics, but failed. It seems they later did Bell Labs PL/I (says https://en.wikipedia.org/wiki/Digitek) I think they did a Unix version of their Cobol in the mid/late 80’s as well. A few years ago I tried to find out more about RM-Cobol as it existed in the late 70’s and early 80’s, but with little success. As a product it survived till the present day under the ownership of Micro-Focus and most web mentions are for more recent versions. It would seem to me that compilers on machines with small memories and word sizes in the 60’s, 70’s and even 80’s tended to compile to a virtual machine / intermediate code -- sometimes with the option to compile to native from there. Think BCPL and o-code, Pascal and p-code, the Amsterdam Compiler Kit and m-code, the Microsoft “revenue bomb” p-code C compiler, etc. According to the above Wikipedia article RM-Cobol used the same approach. I did once see the source for another 80’s Cobol compiler and it compiled to a virtual machine with 60-bit words. By the way, I loved the recent posts on B and NB. THUS at its best!

1 year, 11 months

1
0
0 0

Bell COBOL Environment?

by segaloco

Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.) There's also the LPI-COBOL which appears to be a Language Processor Inc. product. Are these the earliest AT&T endorsed COBOL solutions for UNIX or were there other efforts either promoted by Bell or even perhaps developed locally that were in any use before this version? Or otherwise is there any other family of ubiquitous UNIX COBOL tools that was in use in the 70s and early 80s, before the timeframe of this document? Additionally is anyone aware of any surviving code or binaries of either of these or other, earlier efforts at COBOL on UNIX? I have no goal for this information in mind yet, but just gathering details at this point. Thanks all! - Matt G. [1] - http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf

1 year, 11 months

11
13
0 0

B compiler restored

by Angelo Papenhoff

So there's been quite a bit of talk about B recently (mostly from my side) and right now I feel that I've reach an interesting enough milestone to warrant a separate thread for this here. First of all, I want to stress that this is still WIP, but everything can be found here now: https://github.com/aap/b/tree/master/unix1_bdir In this repo you will find the following: - bc and ba that can build themselves (I've included .s files so everything can be bootstrapped easily). - libb and bilib in source form from object/library and binary files of the s2 tape - brt1 and brt2 restored from binary files of the s2 tape - olibb, obilib and obrt1, older versions of the above - a version of ba that does not generate threaded code but an interpreted code more like the pdp-7 code. ken told me such a thing existed at one point and indeed it is the only way to fit the compiler into 8kb/4kw - an implementation of this interpreted code. With this bc and ba fit into 8kb Note I have only tested this under apout so far. The version I used [1] needed two tweaks, but see my README. With this I was able to build the recently reversed B programs [2] and produce exact matches to the originals (modulo assembler differences). In that process I found a few mistakes I made, now the programs are exact. I want to thank everyone who was of help in this endeavour in one way or another: Ken Thompson, Phil Budne, Robert Swierczek, Steve Johnson, Warren Toomey What's left to do now is to actually run this under UNIX v1 proper, preferably even on a real machine. I've been too lazy for that so far. Also there are inaccuracies and unknowns in the compiler and assembler. Right now the intermediate code is a binary code that's easy to generate and to parse, but if I understood ken correctly the intermediate code was more like something the PDP-7 assembler could deal with. I'm also rather unsure how to handle the conditional ?: operator. The printf.o file shows that it produces labels that are in line with all the other labels. Now the C compiler uses labels starting at L10000 for the ones generated in the second pass. So it *feels* like the conditional should be generated by bc directly and not by ba but this leads to other problems, which I won't go into detail now. Finally the code should probably be a bit closer to the C compiler than it currently is. Cheers, Angelo [1] https://github.com/philbudne/pdp11-B/tree/pb/tools/apout [2] http://squoze.net/B/programs/

1 year, 12 months

1
0
0 0

OSDI/ATC?

by Dan Cross

Is anyone else at OSDI/ATC this year? Any interest in a BoF? - Dan C.

1 year, 12 months

2
1
0 0

Re: Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases

by jnc＠mercury.lcs.mit.edu

> From: Diomidis Spinellis <dds(a)aueb.gr> > I seem to recall reading that the power of Unix stems from the wise > choice of a few design principles rather than the endless accumulation > of special cases. However, I cannot find where this is stated. I think you're thinking of something in the CACM paper: https://www.bell-labs.com/usr/dmr/www/cacm.html "The success of Unix lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas" Noel

1 year, 12 months

1
0
0 0

Who stated that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases

by Diomidis Spinellis

I seem to recall reading that the power of Unix stems from the wise choice of a few design principles rather than the endless accumulation of special cases. However, I cannot find where this is stated. I tried a Google web and a Google Scholar search using the terms "unix endless accumulation special cases", and I also asked ChatGPT for a publication associated with this phrase. I also searched for "special" in D.M.Ritchie's "The Evolution of the Unix Time-sharing System" and "The UNIX Time-sharing System A Retrospective". (Amazingly, both have several parts that still highly relevant.) Can anyone help? Am I misremembering something?

1 year, 12 months

2
1
0 0

PSA: Several 1983 SysV Documents on eBay

by segaloco

Howdy folks, I just wanted to pass on word that there is currently a stack of 1983 System V documents on eBay, here's a link to the User's Manual: https://www.ebay.com/itm/225659365754 The same seller has these documents available in their shop (as well as a bunch of other old computing documents and magazines): - User's Manual - Administrator's Manual - Error Message Manual - Operator's Guide - Graphics Guide - Transition Aids - Release Description So not the whole lot, but a nice spread nonetheless. I've already got all of these and they're already all scanned in some fashion or another, or I'd have scooped em up already. Anywho, figured that might pique folks' curiosity. The pricing is very agreeable might I add, sometimes I see single volumes from this set going for over $100. - Matt G.

2 years

1
0
0 0

Lions commentary

by Rich Salz

I have a copy of Lions's "A Commentary on the UNIX Operating System" It is an n-th generation photocopy that I've had for some number of decades. It also has the source code, as I guess all of those copies did back in the day. I could just recycle the paper -- it's yellowed with age -- but I'd rather pay it forward and ship it to someone who promises to make copies for others who want it. This is also on bitsavers, so you're only doing this to preserve the sense of history in passing photocopies around. I'll take bids on how many copies you'll provide. I'll post the winning bid (without their address), so that the community can pressureXXXXXX ensure they meet their commitment. I'll send it out by the end of the week. I will give preference to US/Canada domestic addresses since that is easier for me. How much preference is left to my discretion. :) I hope this doesn't make me sound like a jerk; it's intended to be lighthearted community service.

2 years

3
2
0 0

Re: symbols in eqnchar

by Douglas McIlroy

> What is the name of the mathematic symbols Here are some readings, not exactly names incl (used with partial orderings) is included in, or is less than |> is not greater than |< is not less than <wig >wig wig is approximately, or asymptotically approaches ~wig is approximately Doug

2 years

1
0
0 0

Re: Jerq menuhit/mhit

by norman＠oclsc.org

I had an experience similar to Tom London's: To: alice!rob Subject: you've spoiled me I can't believe it. I'm sitting here at home in front of my 2621, and I can't work. Damn it. I've got to get a blit at home. When I left Bell Labs, I had an X11 workstation at work, but only a simple terminal at home. Having used a Jerqblit5620 for years at both work and home, I found it incredibly limiting. After a year or so I came across a reseller who had a lot of off-lease 5620s for sale cheap (like USD 150 or so each). I asked around the university I now worked at, found a handful of other people who wanted in, and then a local small company who did System V system-administration consulting who wanted some for themselves, and were willing to handle all the paperwork. All that allowed us to negotiate the price down even more. In the end I bought six, of which I think four are still working, though I haven't turned any of them on for years. None of the Unixes I used at the time came with 5620 support, but the protocol for the basic window system built into the ROM was well-documented and I managed to roll my own host support. I also managed to cobble up my own binary-loading tools sufficient to get sam working (I forget how I compiled the binary for the terminal); that was rather more work, but it was worth it to be able to have sam and multiple windows from home, even though it was the ROM OS and therefore mpx rather than mux. I remember porting my version of the host code to Ultrix, SunOS 4, and IRIX. My workplace at the time had a little bit of VAX/VMS around. I didn't use that much but wanted to try porting my host code to VMS as well. VMS had had a C compiler for some years and some sort of pseudo-terminal for a shorter time, so it ought to have been possible. I didn't get around to it before we finally left VMS behind in the dustbin of history. I wish I'd found time to do it, just to show that there really was nothing Unix-specific about the idea or the implementation. It's just a multiplexing protocol; it needs no kernel support except that needed to run a command-line session not attached to a physical terminal, and networking has long since made that available on any competent OS. Norman Wilson Toronto ON

2 years

1
0
0 0

Jerq menuhit/mhit

by Noel Hunt

The standard routine for drawing menus on the jerq was 'menuhit'. Items in the menu were centered, and the menu was scrollable when a certain threshold number of items was reached, and in addition, when the mouse pointer was in the top (bottom) item of the menu and it was possible to scroll in the appropriate direction, the menu was scrolled up or down 1 line. The structure associated with these menus is 'Menu'. There was however another menu-drawing routine, 'mhit', the menus drawn by this being hierarchical, the structure NMenu, which no longer contained text strings but an array of NItems. NMenus also had provision for 'help' text to be displayed, a simple string displayed on the screen, when button 1 was pressed while an entry in the menu was selected. The earliest version in the Eight Edition jerq code, also has one function in the NMenu structure which is called when the mouse pointer invokes a hierarchical menu. By Ninth Edition this has been expanded, with 3 functions, one as above, one invoked when an item is selected ('hit') and one when a hierarchical menu is exited. In the jerq code directories, under 'lib/jj', is a small 'ms' document, 'A Library of Goo for the 5620', which lists routines available in the library, and their authors. Andrew Hume is listed as the author of 'mhit'. Are there examples of code using these three menu functions ('dfn', 'hfn', 'bfn')? There seems to have been little interest in hierarchical menus at the labs, their use was quite limited. I found a program in the Tenth Edition archive, 'bubble' (which seems to be a program for displaying the three-dimensional structure of molecules) which uses them. 'samuel' made heavy use of them, including use of the 'hit' function, and Tom Cargill used basically the same code in 'pads' wherein the routine was called 'scripthit'. The plain 'menuhit' survived into Plan9, but as far as I know, it is only used by 'sam'.

2 years

6
6
0 0

Bell Labs CSTRs

by arnold＠skeeve.com

Available at https://www.skeeve.com/bell-labs-cstrs.tar.gz Warren and Brantley and anyone else, feel free to retrieve. I have two sets - both are in the tarball so there are undoubtedly duplications. If someone else can curate them into single canonical set that'd be helpful, I just don't have the time right now. Enjoy, Arnold

2 years

6
7
0 0

Bell Labs CSTRs

by Douglas McIlroy

> once you've got M3 and M4, you've got a naming convention; I'd > think it a safe bet that there was an M5 that was an internal > experiment, and that M6 was simply the next in line M6 came first, created by Andy Hall as a portability tool for Altran. I always assumed the name echoed Ken Knowlton's L6 (BelL Labs low level list language, with a superscript 6). I seem to recall that M6 was endowed with a very labored acronym. Doug

2 years

1
0
0 0

troff doc discovery

by Steve Simon

2 years

3
2
0 0

Trying to date "A Supplemental Document For Awk"

by Aharon Robbins

Hi All. Attached is "A Supplemental Document For Awk". This circulated on USENET in the 80s. My copy is dated January 18, 1989, but I'm sure it's older than that. One clue is the reference to the 4.2 BSD manual, and 4.3 came out already in 1986 or so. Does anyone else have a copy of this with perhaps an older date? As far as I can tell from a short search, the author is no longer living. If someone knows better and can provide contact info for him, that'd be great. In the meantime, Warren, do you want to add it to the archives? Thanks! Arnold

2 years

15
19
0 0

C Btrees

by Noel Hunt

There is a little known suite of programs, written by Peter Weinberger, found as 'btree', or 'cbt', in the archives for Eighth and Tenth Edition. The code in the Eighth Edition archive seems to be the earliest, and has fewer utilities than available in the Tenth Edition code. A search through files shows that it was used by 'road', 'weather' and 'apnews'. There is an ms file, 'memo', describing the programs, amongst the code, but an appendix seems to be missing. If anyone knows about this or where it might be I'd like to get my hands on it. 'Memo' itself is interesting because it's the only troff document I've seen amongst the reseach papers (excluding Christopher Van Wyk's own paper of course) that uses 'ideal', in this case, for drawing a picture depicting B-tree structure.

2 years

3
3
0 0

Late 70's UNIX Stream Differences from V6

by segaloco

Hello, I'd like to share some analysis from my recent Sixth Edition pass of my mandiff repository. For the V5-V6 diff, I opted for a branching approach, starting with a last universal common ancestor (which isn't quite right [1]). I compared each set of changes with the MERT0, PWB 1.0, CB-UNIX 2.3, 32V, and to a lesser extent V7 and System III manuals attempting to suss out the spiderweb of changes between them all. I created a series of branches representing last common changes between groups of branches as well. This has resulted in a littering of merge commits in the repository, but a banana's gonna have a peel. A few important points about document genealogy here: - The MERT0 manual, in the introduction, denotes descent from the USG Program Generic 3 manual. Furthermore, there is a listing of which pages would be replaced, which also serves as a key to which pages should be PG3 original text. However, the hs(IV) and ht(IV) pages make reference to specific MERT pages, so I question the veracity of this list. In any case, for the purposes of this analysis, much may extrapolate to USG PG3 as well. More study is needed. - The CB-UNIX manual currently available is Edition 2.3. In studying the numbering system for CB, I've found that this represents Release 2, Issue 3, as in the kernel there are references to releases, not editions. The clue is in one of the manpages somewhere, I don't recollect as of this typing where, but that'll come back around soon enough. The manual itself appears to be from a binder that was once a CB-UNIX 2.1 binder and had select pages replaced. There are some bits and pieces of 2.1 pages that were otherwise slated to be replaced, alluding to things like the /etc/lines file in common with PG3. In any case I've prioritized 2.1 changes over 2.3 changes where they can be determined, but like PG3, no complete picture can be determined of 2.1 from available documentation. For each of the branches, the following number of files in total reflect V5-V6 changes which aren't incorporated: - 32V: 7 - PWB: 15 - MERT0: 46 Of these MERT0 has the greatest number of items lacking research's upstream changes from late '74-early '75. Among them: - Has a V5-ish bas(I), no rc(I) (ratfor) at all - The group system is not present, newgrp(I), group(V), chgrp(VIII), etc. are nowhere to be found - nice(I) has no priority argument, simply sets a "low priority" - TTYs are still referred to as "teletypes" instead of "typewriters" in many places - there are 10 TTYs max so many commands don't reflect adjustments for two-digit IDs (ps(I) in particular is quite different, very V5) - retains the lpr print command (which shows up again in 32V and System III) - additionally, according to the replacement page list, PG3 retained the fed and form editing programs - Program Generic may not have had a man(I) page, as the one here is a MERT0 addition, hard to say CB tragically needs to be remerged, found as I was typing this up the system call section got an errant merge with V6 changes that shouldn't be there. Needless to say there is much in section II of the CB manual that leans more V5-ish than V6-ish. PWB differs in minor ways. The differences can be found in this list https://gitlab.com/segaloco/mandiff/-/merge_requests?scope=all&state=closed Each of the obviously labeled, closed merges represents a snapshot diff of the particular branch in question. As stated, the CB branch currently is in dire straits, I'm going to work that up again sometime in the future, but I should be able to use this to produce diff-able reproductions of the MERT0 and CB-UNIX 2.3 manual sources for this repository, as well as any other materials that may pop up. - Matt G. [1] - This pass I did not take good notes on such matters, but there are a few pages I'll anecdotally say reflect contents predating V5 sprinkled amongst the various manuals. I will consult with previous diffs when questions arise on in-depth analysis of the non-research changes in the branches. In any case the historical record already confirms CB-UNIX at the very least branched off quite early.

2 years

1
0
0 0

Software written in B

by Sebastien F4GRX

Hello everyone, this is my first post on this list. After looking at the archives for this mailing list, I have seen that the B language has been discussed several times already. After viewing Ken Thompson's interview by Brian Kernighan at VCF East 2019, I became interested in the B language, as it seemed full-featured for system programming, close to C, and simple enough to write a parser for it without a code generation tool. So for fun and self-education, I am now writing a (or yet another) B compiler, in C, after reading Jack Crenshaw's "Let's build a compiler" documentation ( https://compilers.iecc.com/crenshaw/ ) Here it is: https://git.sr.ht/~f4grx/bpars It is now starting to generate code for the 68hc11 8-bit platform. It can also generate C code. I have written some test programs, found some B examples, but I thought it would be great to use my compiler with actual B software. Of course, B was a "transition" language, that did not have a continued use as soon as it evolved into C. so if any software remains, it will be quite hard to find. And here is my question, is any of you aware of original B source code archives? or are in touch with people that would know? In particular, I read on this document written by Dennis Ritchie: https://www.bell-labs.com/usr/dmr/www/chist.html > After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). I have also read that the YACC tool was initially written in B. There might be other historical B sources that I am not aware of. Do you know if any of this code has survived to this day? Where could I find more information about this? Thank you very much, Sebastien Lorquet (F4GRX)

2 years

10
37
0 0

1981 Bell System Brochure and Price List

by segaloco

Spent some time this afternoon scanning and included a couple of those 1981 marketing documents I relayed some prices from in a previous email: https://archive.org/details/bell-system-software-brochure-1981 https://archive.org/details/bell-system-commercial-software-fees-1981 The cover of the former came out a bit rough. The stock photo is very fine stippling and my scanner just couldn't cut it. In any case, the first is a series of one-page summaries of various software offerings by the Bell System and the second is a price sheet not unlike https://www.bell-labs.com/usr/dmr/www/licenses/pricelist84.pdf but earlier. The larger brochure also includes software offerings for Honeywell and IBM systems as well as some portable components. - Matt G.

2 years

1
0
0 0

4.3BSD User Contributed Software Volume?

by segaloco

Hello, I've come across something in a bookshelf up at the local university that I have thus far been unsuccessful at locating online. It's a binder amongst other 4.3BSD binders like the reference manuals and supplementary documents but this one is labeled "User Contributed Software (UCS)". I can't find any of these in the doc folder of the 4.3BSD copies in the archive nor can I find a scan of the originals. There is an overview at the start listing the following packages: B, X, ansi (VAX tape tools), apl, bib, courier, cpm, dipress, dsh, emacs, enet, help, hyper, icon, jove, kermit, mh, mkmf, mmdf, news, notes, npl00, patch, path alias, rcs, rn, spms, sumacc, sunrpc, tac, tools, umodem, and xns. There are a preponderance of man pages as well as some focused papers for B, SPMS, the Icon programming language, and MMDFII. I didn't scribble down more notes before heading home because I figured this was something I'd find on page one of an internet search, but thus far have had no luck. If I don't turn up a digital copy soon I might just have to make another trip up there soon with my flatbed scanner. In any case I left a note too hoping whoever the curator of that bookshelf is (it was in some club room) might have the scoop on those binders, if they're left over from some long gone 4.3BSD installation in the EE/CS department and if they might have some siblings in other bookshelves nearby. - Matt G.

2 years

3
4
0 0

Re: undiagnosed pic error

by Douglas McIlroy

There may be a simple generic way to correct pic's habit of accepting any set of object modifiers on any object, but obeying only a compatible subset. Pic already collects a bit vector of modifier types attached to the current object. If that were extended with a few more bits that designate the object types, the size, B, of the bit vector would be about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could record both modifier/modifier incompatibilities and object/modifier incompatibilities. The collected bit vector needs to be tested against the matrix once per object definition. It seems to be harder to catch duplication of modifiers, requiring extra code at all points where bits are set. Nevertheless, this kind of error also merits detection. Some questions Does anybody think the issue is not worth addressing? Is there a better scheme than that suggested above? Is the scheme adequate? It would not, for example, catch a three-way incompatibility that does not entail any pairwise incompatibility, should such an incompatibility exist. Any other thoughts? Doug

2 years

3
4
0 0

WECo UNIX 3B5 User's Manual Found

by segaloco

Good day, I've just received in the mail a UNIX System User Reference Manual for the 3B5 computer. It has a few differences with other documentation around it. As usual with an initial expository message, lots of info here, mostly so it'll get in the archive and on the record. So first off, I can't find a version reference in this thing. It is branded as "UNIX System" consistent with the branding nomenclature in the System V era, but I can't actually find the term "System V" anywhere thus far. However, a high level view implies relative parity with the initial release of System V. There are some areas where nomenclature is closer in character to the Release 5.0 manual, for instance, the "basinf" section in the intro refers to the user guide as "UNIX User Guide" rather than "UNIX System User's Guide" which is found in later System V stuff. In fact, this minor reference may point to some branching in the documentation between 4.x and SVR2 as I have the following in various manuals (prior to 4.1 i.e. 3.0/SysIII the reference is still directly to UNIX For Beginners, not a guide): - Release 4.1 - "UNIX User's Guide" - Release 5.0 - "UNIX User's Guide" - Release 5.0 BTL - "UNIX User's Guide" - System V - "UNIX System User's Guide" - System V 3B5 - "UNIX User Guide" - System V R2 BTL - "UNIX System User Guide" - System V DEC (1984) - "UNIX System User Guide" - System V R2 (1986 Manuals) - "UNIX System User's Guide" So SysV adds "System" to what was in Release 5.0, this carries through to conventional SVR2. The 3B5 version, however, drops the apostrophe and 's' that were in the pre-SysV nomenclature but doesn't add "System". Then even more confusing the SVR2 BTL copy appears to bear some lineage from this as it also has the dropped apostrophe and 's' but includes "System". Strange. Even stranger is I decided to take a peek at SVR2 docs from 1984, they lack the apostrophe and 's', but later SVR2 material from 1986 restores it. I wonder if this implies the 3B5 branch was started in the 5.0 days, diverged a bit, and then was only partially recombined with System V before release, although on the flip side, this manual *does* include the edit, ex, and vi manpages which were not printed in time for the System V manual run (as they are included with a separate documentation package instead.) This tracks with the BTL 5.0 having edit, ex, vi, and termcap present from Holmdel, the BTL manual got the pages early. All that to say, there are things in this manual that aren't yet in published System V manuals at the time, but there are things in this manual that have since been altered by the time of the formal System V documentation, pointing to an earlier branch point and then ongoing cross-talk after that. Included are references to a "3B Computer Network" and a few utilities associated. There are a few other pages too I didn't see in other contemporary public manuals, in total: - dcon(1) - Spawns a shell on a remote system via a DATAKIT circuit - logdir(1) - Returns the home directory field from /etc/passwd, this is in the BTL versions, I don't see it in public SysV though - ncp(1) - Copies files over the DATAKIT network - nisend(1) - Copies files over the "3B Computer Local Network" - nistat(1) - Query the status of said network - nitable(1) - Display the configuration table of said network - niupdate(1) - Update said configuration table - nkill(1) - Kill but using process names instead of IDs, but doesn't define process names, be it argv[0], the name of the image file, etc... - rexec(1) - Executes commands over a DATAKIT network - rl(1) - Login remotely over the 3B Computer Network (distinct from dcon being DATAKIT remote logins) This appears to be uucp-derived (specifically cu(1)) - dkdial(3) - Dials a DATAKIT connection - boothdr(4) - 3B5 only, provides the contents of <sys/boothdr.h> which supports storing parts of master(4), via mkboot(1M), in "a driver object file" to be used with "the self-config boot". Section 6 is mentioned in the intro but then omitted from the rest of the manual, so nothing to compare there. Also keeping with the documentation changes at the time, this does not include Sections 1M, 7, nor 8, as those are presumably in an accompanying Administrator's Reference Manual. That is another thing pegging this as System V rather than SVR2, by SVR2 they had further divided from two to three manuals, splitting the user manual into Sections 1 and 6 (User) and Sections 2, 3, 4, and 5 (Programmer) (although even this isn't entirely true, I've got a "UNIX User's Manual" published in 1986, red ATTIS-style cover, that contains what appear to be selections from Sections 1, 2, and 3...it seems more geared towards folks writing portable software between SVR1 and SVR2 than anything) Finally, here are the omissions I compared with the SVR2 BTL, SVR2 DEC, and 1986 manual mentioned above: Removed by SVR2 public, only in the BTL version: - nscstat(1) - nsctorje(1) - nusend(1) - stlogin(1) - ststat(1) Non-portable DEC stuff: - adb(1) - arcv(1) - kasb(1) - net(1) - vpr(1) - maus(2) - x25alnk(3) - This X.25 stuff never shows back up, probably dropped as of SVR2 BTL (1983) - x25clnk(3) - x25hlnk(3) - x25ipvc(3) Non-portable 3B20S stuff: - cprs(1) - hpio(1) Honeywell/GCOS Interop, gone by SVR2 BTL (1983): - dpd(1) - dpr(1) - fget(1) - fsend(1) - gcat(1) - gcosmail(1) Graphics Subsystem, remains in SVR2 so probably not 3B5 supported as of this printing: - gdev(1) - ged(1) - graphics(1) - gutil(1) - stat(1) - toc(1) So just to review, some matters this manual supports: - The initial 3B5 UNIX release seems closest in character to the initial System V version - Many DEC and 3B20-specific components are omitted - The Honeywell/GCOS interop was on the way out the door and likely never ported - The graphics subsystem was not supported on 3B5 as of this release - Synchronous terminals and NSC networking are taken internal likely by this release, certainly by SVR2 - The 3B5 version supported "DATAKIT" and "3B Computer Network" networks - Included a logdir(1) command used in BTL for getting a user's login directory from /etc/passwd - Included an nkill(1) command to kill a process by its (undefined) name - The boot process included a header object for "driver object files" used with a "self-config boot" process If there are any questions or any pages folks think I should peruse for details, just let me know. Otherwise this'll won't be hitting my detailed analysis for a while, I'm currently in the midst of figuring out a branching scheme in my mandiff repo that'll facilitate tracking the various forks, as I've found many changes between V5 and V6 that are *not* reflected in various ways throughout PWB, Program Generic, CB, and 32V (as an example, go look up where lpr(I) is and isn't available.) - Matt G. P.S. Kudos to the production quality of this manual. It's a small binder, the pages are the same size as the earlier comb-bound manuals. The binder rings themselves are fixed to the back cover and the right side of the rings is flat instead of rounded, so the pages sit very nicely whether opened or closed. This compares with the BTL SVR2 binder where the rings are perfectly round and affixed to the spine instead, so they sit differently depending on whether the binder is on a shelf or open on a desk, with pages risking getting all crumpled up getting bunched up at the edge of the rings. Certainly has nothing to do with software or technical history, but the physical nature of the various publications has also been factoring into my study. Here's a picture of the two covers by the way, since I haven't given any visuals on my work in a while: https://i.imgur.com/hhaaxfA.jpeg

2 years

1
0
0 0

Re: GNU eqn clarifications and reforms

by G. Branden Robinson

At 2023-06-17T05:19:46+1000, Damian McGuckin wrote: > Getting back to groff, that final/terminating sigma, is it still > pronounced as sigma. > > It certainly has no EQN equivalent name and its groff short symbol > name is > > \(ts > > (terminal sigma) which is not like other greek letters. Just > wondering whether it needs a sentence to mention its abscence from > EQN. There are a few others, but they postdate Ossanna troff. From groff_char(7) in 1.23.0.rc4: ϵ \[+e] u03F5 variant epsilon (lunate) ϑ \[+h] u03D1 variant theta (cursive form) ϖ \[+p] u03D6 variant pi (similar to omega) φ \[+f] u03C6 variant phi (curly shape) ς \[ts] u03C2 terminal lowercase sigma + I know of no reason to make these generally available by default in eqn, though, any more than they already are. You can type their special characters in eqn input and assign spacing and style types to them. (This typing system is a GNU eqn feature, not present in AT&T eqn). In fact I have a coupled pair of reforms in mind for GNU eqn: unfastening the definitions of the lowercase Greek special characters from the typeface used for letters (variables), and then defining the lowercase Greek letter eqn macro names ("alpha", "beta", ...) to explicitly use the "letter" style type. https://savannah.gnu.org/bugs/?64232 https://savannah.gnu.org/bugs/?64231 (For example: define alpha ! type "letter" \(*a ! ) This should result in no change for historical documents (except on terminals, where it will fix a bug), and give us some flexibility for users of modern fonts where Greek letters are properly supported in text fonts (i.e., in four styles). The Graphic Systems C/A/T had uppercase Greek available _only_ upright and lowercase Greek _only_ italic. Modern typesetting systems are not so limited. Regards, Branden

2 years

1
0
0 0

Re: GNU eqn clarifications and reforms

by G. Branden Robinson

At 2023-06-16T14:22:22+1000, Damian McGuckin wrote: > On Thu, 15 Jun 2023, G. Branden Robinson wrote: > > But I may suffer from an excessive familiarity with this material. > > Yes. Me too. Maybe that is a sad comment on the both of us. That is the price of trying to leave things better than one found them. > Why do Greeks have an alternate way of writing sigma! We English-speakers used to have an alternative way of writing it, if you regard the Latin alphabet's "S" as cognate (so to speak) with the Greek sigma (and I think doing so is defensible). It's even in Unicode with a low code point, U+017F. For inſtance, the United States uſed to employ a non-final lowercaſe S in the founding documents of its preſent government, where you can see exhibits of the "Congreſs of the United States". It can take the modern reader a "long S" time to not read that "s" as an "f". And if you think that's difficult enough, check out, IIRC, the Arabic and Devanagari scripts where you can have different initial, medial, and final forms for letters. Follow-ups ſhould probably be confined to groff@; I'll ſtop now leſt we get ſent to the COFF liſt for groſs tranſgreſſions of topicality. (Although if anyone wants to tell me whether non-final s was applied to the trailing ends of non-final morphemes _within_ words, I'm all ears.) Regards, Branden

2 years

7
6
0 0

Re: GNU eqn clarifications and reforms

by Douglas McIlroy

I am not convinced that using special characters rather than in-line eqn is a good thing. It means learning a whole new vocabulary. Quick, what's the special character for Greek psi? I have found that, for a sequence of displayed equations as in an algebraic derivation, a pile often looks more coherent than a sequence of EQ-EN pairs. The pile can even contain interleaved comments, as in Hoare-style proofs. Doug

2 years

2
1
0 0

Re: [COFF] Re: Re: crt0 -- what's in that name?

by Adam Thornton

On Tue, Jun 13, 2023 at 9:29 AM Paul Winalski <paul.winalski(a)gmail.com> wrote: > > VMS (officially OpenVMS; I hated that marketing name when it was first > proposed and I hate it now) is still alive and supported by a company > called VMS Software, Inc. (VSI). Here is a pointer to their document > OpenVMS Programming Concepts, Volume II, which describes the CLE in > detail: > > I think it's worth mentioning that the OpenVMS Hobbyist Program is still alive and well and recently began supplying x86_64 licenses to hobbyists, so if you have a reasonably modern amd64 system, you can run it under QEMU.

2 years

1
0
0 0

crt0 -- what's in that name?

by ron minnich

This came up lately in the riscv firmware universe. Someone named early boot bt0, I mentioned crt0, and ... when did that name first appear? I first saw it in v6 but I'm sure it was long before.

2 years

10
19
0 0

Re: crt0 -- what's in that name?

by Douglas McIlroy

> Not a citation, either, but I believe the original RUNCOM came from CTSS (https://multicians.org/shell.html) Yes, the CTSS command "runcom" arranged for commands stored in a file to be run in the background. Such a file (which could contain at most six commands) became known as "a runcom". The term "script" did not emerge until Unix. I vaguely recall that Lee McMahon coined the usage, but would welcome more reliable info about its origin. Doug

2 years

1
0
0 0

Re: crt0 -- what's in that name?

by Rudi Blom

Maybe not really 'defining' but useful https://en.wikipedia.org/wiki/Crt0 https://en.wikipedia.org/wiki/.bss -- The more I learn the better I understand I know nothing.

2 years

1
0
0 0

Re: crt0 -- what's in that name?

by norman＠oclsc.org

Clem Cole: > Apologies to TUHS - other than please don't think Fortran did not > impact UNIX and its peers. Fortran had an important (if indirect) influence in early Unix. From Dennis's memories of the early days of Unix on the PDP-7: Soon after TMG became available, Thompson decided that we could not pretend to offer a real computing service without Fortran, so he sat down to write a Fortran in TMG. As I recall, the intent to handle Fortran lasted about a week. What he produced instead was a definition of and a compiler for the new language B. (The Evolution of the Unix Time-Sharing System; see the 1984 UNIX System issue of the BLTJ for the whole thing, or just read https://www.bell-labs.com/usr/dmr/www/hist.html) Now let's move on to the name `rc'. Not the shell, but the usage as part of a file name. Those two characters appear at the end of the many annoying, and mostly pointless, configuration files that litter one's home directory these days, apparently copied from the old system-startup script /etc/rc as if the name means `startup commands' (or something beginning with r, I suppose, instead of startup). But I recall reading somewhere that it just stood for `runcom,' a Multics-derived term for what we now call a shell script. I can't find a citation to back up that claim, though. Anyone else remember where to look? Norman Wilson Toronto ON

2 years

3
2
0 0

Re: crt0 -- what's in that name?

by Douglas McIlroy

>I thought it was pretty well known that it [BSS] stands for, "Block Started (by) Symbol"? BSS was a "pseudo-operation" in SAP (SHARE assembly program) for the IBM 704. My recollection is that the assembler manual called it "block starting at symbol". There was also a BES (block ending at symbol) pseudo-op. Both reserved a block of memory, with the assembler assigning the appropriate value to the pseudo-op's label. The reason for BES was that index registers were subtractive. There was a loop-ending instruction ,TIX (transfer on index), that decreased the index by a specified amount and transferred to a specified location unless the index hit zero, in which case the instruction counter continued in sequence. BES was originally conceived for addressing an array stored by increasing subscript but indexed by a register that counted down. BES was also useful for FORTRAN object code, which stored arrays backward and kept the true, uncomplemented subscript in an index register. Doug

2 years

1
0
0 0

Re How should I define 'thing' before I start talking about it?

by Douglas McIlroy

Mea culpa. eqn does recognize groff escapes outside of quotes. Doug

2 years

1
0
0 0

Re: How should I define 'thing' before I start talking about it?

by Douglas McIlroy

> As far as I see it, EQN input is made of things where a thing is one of > mathematical or troff or eqn symbol > mathematical punctuation > delimiter, these being space, '~', '^', '{', '}', or newline > a character surrounded by punctuation or delimiters > - with/without users errors > a word surrounded by punctuation or delimiters > - with/without users errors > EQN keywords (which are special words???) > That is way too long winded!! I want something tight. Quotes take precedence over all other things. What is a "troff symbol"? I can only think of troff escapes, which can only appear in quotes , so are not eqn things in their own right. (In user errors they may be seen as punctuation, etc.) Ditto for "eqn symbol"? Perhaps the union of some or all of the things that follow in the list? Ditto again for "mathematical punctuation". Comma is one example I can think of. Apostrophe, read as "prime", may be another. Are there more? Is "surrounded by" inclusive or exclusive? Why is "character" distinguished from "word"? The ??? question bears on the issue of whether sintheta is one thing or two. The word "maximal" will probably figure in the answer Another (sticky) point is how punctuation sticks to an adjacent thing. For example, eqn inserts space in (a,b), but keeps the whole thing(?) together in 2 sup (a,b). Doug

2 years

1
0
0 0

Major update in unix.bib

by Nelson H. F. Beebe

Thanks to Unix document recovery work by some TUHS list members that has been recently added to the archives at minnie.tuhs.org, a large Bell Labs bibliography about Unix has been uncovered and is now available online. I have spent time this week converting the 59-page PDF file to a somewhat searchable OCR'ed PDF, and from a text conversion of that file, to relatively clean BibTeX entries in https://www.math.utah.edu/pub/tex/bib/unix.bib [change .bib to .html for similar view with hypertext links]. The bibliography recorded in entry Scheiderman:1980:UB, with a long remark field, has 457 entries, from the years 1972 to 1980, but due to splitting into subject-specific sections, there are some duplications: 448 remain after data merger. Much work remains to be done, including locating electronic copies of those reports, correcting truncated data, and getting suitable URLs retrofitted into their BibTeX entries. However, I prefer a release-early-and-often approach to bibliographic data distribution, whence this announcement to the TUHS list and others. For searching convenience, I have created an SQLite3 portable database file at https://www.math.utah.edu/pub/tex/bib/unix.db There is a tutorial on SQL searching of BibTeX data in a paper and talk slides at BibTeX meets relational databases https://www.math.utah.edu/~beebe/talks/#2009 and further documentation about BibTeX itself at BibTeX Information and Tutorial https://www.math.utah.edu/pub/bibnet/bibtex-info.html Below are some samples of searches to find the earliest mention of selected topics in the Bell Labs technical memoranda. Even if you have never used SQL queries, they should be fairly understandable, and the new entries all carry identical bibtimestamp values to make their identification and selection easy. % sqlite3 unix.db .headers on .mode table -- Find the earliest entries select label, year, author from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') order by year, label limit 10; +--------------------+------+-------------------------------------+ | label | year | author | +--------------------+------+-------------------------------------+ | McIlroy:1972:MTC | 1972 | M. Douglas McIlroy | | Ritchie:1972:UAR | 1972 | Dennis M. Ritchie | | McIlroy:1973:SES | 1973 | M. Douglas McIlroy | | Olsson:1973:GCC | 1973 | S. B. Olsson | | Remde:1973:CCS | 1973 | J. R. Remde | | Kernighan:1974:PCT | 1974 | Brian W. Kernighan | | Lycklama:1974:ILC | 1974 | Heinz Lycklama | | Morris:1974:CDT | 1974 | Robert Morris and Lorinda L. Cherry | | Morris:1974:WSH | 1974 | Robert Morris and Ken Thompson | | Swanson:1974:GFC | 1974 | G. K. Swanson | +--------------------+------+-------------------------------------+ -- Find earliest mentions of IBM mainframes select label, year, title from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and (title like '%ibm%') order by year, label; ------------------+------+--------------------------------------------------------------+ | label | year | title | +------------------+------+--------------------------------------------------------------+ | Roberts:1975:UIU | 1975 | UNIXLIST --- An IBM / 370 Utility Program to List a UNIX Fil | | | | e Stored on a 9-Track Magnetic Tape. | +------------------+------+--------------------------------------------------------------+ | Bach:1979:PAD | 1979 | Porting the ADAPT Data Translation System to the IBM 370 | +------------------+------+--------------------------------------------------------------+ | Grampp:1979:SCI | 1979 | Support for C on IBM Computers | +------------------+------+--------------------------------------------------------------+ | Huber:1979:ULD | 1979 | UNIX Line Discipline for IBM 2740-1 Protocol | +------------------+------+--------------------------------------------------------------+ -- Find earliest mention of porting work to Intel 808x family select label, year, title from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and ((title like '%intel %') or (title like '%z80%')) order by year, label limit 5; +--------------------+------+--------------------------------------------------------------+ | label | year | title | +--------------------+------+--------------------------------------------------------------+ | Molinelli:1977:UAI | 1977 | UNIX Assembler For The Intel 8080 Microprocessor | +--------------------+------+--------------------------------------------------------------+ | Bradley:1978:EMS | 1978 | Evaluation of Microprocessors Supporting the C Language: LSI | | | | -11, MAC-8, Z80 | +--------------------+------+--------------------------------------------------------------+ | Farrell:1978:UGS | 1978 | User's Guide to the SMAL2 Language for the Zilog Z80 Micropr | | | | ocessor | +--------------------+------+--------------------------------------------------------------+ | Vogel:1978:ZAR | 1978 | 8080 / Z80 Assembler Reference Manual | +--------------------+------+--------------------------------------------------------------+ | Blumer:1979:UUI | 1979 | UNIX / 86: UNIX on the Intel 8086 | +--------------------+------+--------------------------------------------------------------+ -- Find earliest mentions of port to Interdata machines [note the full -- text search of entry, rather than just of the title] select label, year, title from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and (entry like '%interdata%') order by year, label limit 5; +------------------+------+---------------------------------+ | label | year | title | +------------------+------+---------------------------------+ | Johnson:1977:CLC | 1977 | The C Language Calling Sequence | +------------------+------+---------------------------------+ -- Find earliest mentions of 36-bit Univac Unix select label, year, author from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and (title like '%univac%') order by year, label; +----------------+------+---------------------------------+ | label | year | author | +----------------+------+---------------------------------+ | Lyons:1976:GUR | 1976 | T. G. Lyons | | Graaf:1979:PPE | 1979 | D. A. De Graaf and Jerome Feder | +----------------+------+---------------------------------+ -- Find authors of earliest mentions of Programmer's Workbench (PWB) select label, year, author from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and ((title like '%PWB%') or (title like '%workbench%')) order by year, label limit 5; +------------------+------+-------------------------------+ | label | year | author | +------------------+------+-------------------------------+ | Dolotta:1975:PWP | 1975 | T. A. Dolotta and others | | Dolotta:1976:PWP | 1976 | T. A. Dolotta and others | | Lyons:1976:GUR | 1976 | T. G. Lyons | | Smith:1976:NTF | 1976 | D. W. Smith | | Dolotta:1977:PUV | 1977 | T. A. Dolotta and D. W. Smith | +------------------+------+-------------------------------+ -- Find titles of earliest mentions of Programmer's Workbench (PWB) select label, year, title from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and ((title like '%PWB%') or (title like '%workbench%')) order by year, label limit 5; +------------------+------+--------------------------------------------------------------+ | label | year | title | +------------------+------+--------------------------------------------------------------+ | Dolotta:1975:PWP | 1975 | Programmer's Workbench Papers From The Second International | | | | Conference On Software Engineering (G.4) | +------------------+------+--------------------------------------------------------------+ | Dolotta:1976:PWP | 1976 | Programmer's Workbench Papers From The Second International | | | | Conference on Software Engineering. (G.4) | +------------------+------+--------------------------------------------------------------+ | Lyons:1976:GUR | 1976 | Guide to UNIVAC Remote Job Entry for Programmer's Workbench | | | | Users | +------------------+------+--------------------------------------------------------------+ | Smith:1976:NTF | 1976 | NROFF / TROFF Formatting Codes For Departmental Organization | | | | Directories On PWB / UNIX | +------------------+------+--------------------------------------------------------------+ | Dolotta:1977:PUV | 1977 | PWB / UNIX View Graph and Slide Macros (T.9) | +------------------+------+--------------------------------------------------------------+ -- Find earliest mentions of nroff and troff select label, year, title from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and (title like '%roff%') order by year, label limit 5; +---------------------+------+--------------------------------------------------------------+ | label | year | title | +---------------------+------+--------------------------------------------------------------+ | Smith:1976:NTF | 1976 | NROFF / TROFF Formatting Codes For Departmental Organization | | | | Directories On PWB / UNIX | +---------------------+------+--------------------------------------------------------------+ | Cummingham:1977:NPG | 1977 | NROFF For Producing Generic Program Documentation | +---------------------+------+--------------------------------------------------------------+ | Kernighan:1978:TT | 1978 | A TROFF Tutorial | +---------------------+------+--------------------------------------------------------------+ | Lesk:1978:TDU | 1978 | Typing Documents on the UNIX System: Using the tt -ms Macros | | | | with Troff and Nroff | +---------------------+------+--------------------------------------------------------------+ | Ossanna:1979:NTU | 1979 | NROFF / TROFF User's Manual | +---------------------+------+--------------------------------------------------------------+ -- Find earliest mentions of typesetting select label, year, title from bibtab where (filename = 'unix.bib') and (bibtimestamp like '2023.06.06%') and (title like '%typeset%') order by year, label limit 5; +--------------------+------+-------------------------------------------------------+ | label | year | title | +--------------------+------+-------------------------------------------------------+ | Lesk:1976:CTTa | 1976 | Computer Typesetting of Technical Journals on UNIX | | Edelson:1977:TAA | 1977 | Typesetting ACS and APS Meeting Abstracts --- Issue 2 | | Vogel:1977:EPV | 1977 | Easy Phototypeset View Graphs on UNIX | | Kernighan:1978:TMU | 1978 | Typesetting Mathematics --- User's Guide | | Kernighan:1979:STM | 1979 | A System for Typesetting Mathematics | +--------------------+------+-------------------------------------------------------+ As always, comments on, corrections for, and addenda to, unix.bib are most welcome: just send me e-mail. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

2 years

2
1
0 0

Pixel 100/AP UNIX Computer

by segaloco

After talking with the folks I bought the recent documents from, they let me know they are also selling a piece of hardware: https://www.ebay.com/itm/125714380860 After the link is an auction for an Instrumentation Laboratory Pixel 100/AP. A small booklet included with the many documents I received indicates as of 1982 the Pixel 100/AP ran a System III derivative. The booklet goes on to present a summary of user commands and options. Despite the System III basis, included among these are the C shell and ex/vi. I have no room for hardware or honestly at that price point it'd be worth the preservation effort. Hopefully it finds a good home, it includes an almost complete documentation set save for the small booklet I've got (which could be separate promo material for all I know) In any case, there were a few letters amongst the documents suggesting the original owner was involved in the production of this system, particularly in the area of OS details. If I find any noteworthy information I'll pass it along. - Matt G. P.S. If anyone knows of a preservation effort accepting new machines I can pass this along.

2 years, 1 month

1
0
0 0

Some AT&T Promotional Material/Pricing from Early 80s

by segaloco

Hello, I've just today received another box from the person I got that set of UNIX manual binders from and hoo boy there's some cool stuff in here. It'll probably be a bit before I scan it all, but among the many bits is a folder bearing "Software by the Bell System" on the front cover with a photo of some tape reels lying around. The back is a simple black 70's Bell system logo. Flipping to the interior, the left panel of the folder bears facsimile AT&T letterhead with a "letter" from Otis L. Wilson, Technology Licensing Manager, denoting what promotional materials are enclosed. Among the various terms of the licenses mentioned is: 'all software comes "as is" -- with no maintenance agreements or technical support' Between this and the Bell logos all over this stuff, I presume it is prior to 1982. As for the contents themselves, there are pages for V6, V7, Mini-UNIX, PWB, 32V, and System III, the last of which is a photocopy whereas all the others are on some nice glossy cardstock, so I presume this was hot out the door on the heels of System III as a commercial release. Aside from pages describing each of these UNIX versions, there is a separate page describing "The Phototypesetter Package", in other words, pre-DWB distribution of TROFF and friends. Aside from the UNIX stuff, there are also various utilities amongst IBM 360/370 and Honeywell 600/6000 systems and some various scientific and mathematical systems. Also included is "Summary of UNIX System III" which looks to be a bit of an amalgamation of info from some of the "Documents for UNIX 3.0" set distributed with System III. Unfortunately, being for external release, the document is very of the mindset of "here's what changes from V7/32V to System III" rather than that sweet sweet "here's what changes from PWB 2.0 to 3.0" that I hope to find (or create) sometime. Anywho, finally amongst the promo material was an (undated) letter from M.B. Wicker (Technology Licensing, AT&T) to an unlisted recipient, obviously just copy they sent to everyone, essentially communicating the terms of UNIX System III in more detail. Between all of these materials, the following are UNIX-related prices I could find: UNIX Sixth Edition - Initial CPU - $20,000 - Additional CPUs - $6,700 - UNIX Programmer's Manual - $30 - Documents for Use with UNIX - $30 - System III upgrade - $26,000 - System III add CPU - $10,300 PWB/UNIX - Initial CPU - $30,000 - Additional CPUs - $10,000 - PWB/UNIX User's Manual - $40 - Documents for PWB/UNIX - $40 - System III upgrade - $16,000 - System III add CPU - $7,000 Mini-UNIX - Initial CPU - $12,000 - Additional CPUs - $4,000 - UNIX Programmer's Manual - $30 - Doucments for Use with Mini-UNIX - $30 UNIX/V7 - Initial CPU - $28,000 - Additional CPUs - $9,400 - UNIX Programmer's Manual, Vol. 1 - $40 - UNIX Programmer's Manual, Vols. 2A and 2B - $60 - System III upgrade - $18,000 - System III add CPU - $7,600 UNIX/32V - Initial CPU - $40,000 - Additional CPUs - $15,000 - UNIX/32V Programmer's Manual - $40 - UNIX/32V Programmer's Manual, Vols. 2A and 2B - $60 - System III upgrade - $6,000 - System III add CPU - $2,000 UNIX System III - Initial CPU - $43,000 - Additional CPUs - $16,000 - UNIX User's Manual - $40 - Programmer's Manual for UNIX System III, Volume 2A and 2B - $40 each - The separate page detailing System III further goes on to break down that a non-refundable payment of $25,000 to sublicense object code Phototypesetter (Version 7) - Initial CPU - $3,300 - Additional CPUs - $1,100 - Documents for Use with Phototypesetter - Version Seven - $20 Additionally there are options to upgrade a V6&V7 supporting license to System III for $14,000 and add additional CPUs to those terms for $6,300. The same for a group of V7 and PWB for $4,000 and $3,000 for first CPU and addtional CPUs respectively. Of note is that all documents listed above could be purchased from the Computing Information Service in Murray Hill *except* those issued for UNIX System III, which instead were to be ordered from the Western Electric Patent Licensing Organization. This reflects the shift to WECo distribution from Bell Labs themselves, as would continue to be the case for 3B20S shipments of 4.1 and the eventual 5.0 and System V releases. In addition to the promotional materials are also "Specimen Copy" blanks of the various licenses involved in at least System III, perhaps other versions (there are blanks where LICENSED SOFTWARE is supposed to be written/typed in). Finally, in the same folder is also a nice stack of UNIX summary documents spanning different versions. There are summaries for PWB, Mini-UNIX, V7, and 32V. Additionally, there is a document "Proposal to Provide VAX UNIX system support at Berkeley" by Bob Fabry. A quick internet search didn't turn up a PDF of this, so I have to wonder if it's preserved somewhere. If not, it will be. The other document here may prove even more interesting though: "The UNIX Time-Sharing System for UNIVAC 1100 Series Systems - 7th Edition Summary", dated October 19th, 1981. Can't say I've seen this anywhere, just mention of the UNIVAC version in the BSTJ article on UNIX porting experiences. A quick perusal yields a document very similar to the V7 and 32V summaries, but with UNIVAC-isms pointed out. Anywho, there's more material in this box than just this stuff, but this floated to the top as particularly significant. Among other contents are a "UNIX System and 'C' Language" "Training from the Source" foldout from WECo's Corporate Education group, listing 16 courses available at various training centers. There is a copy (nicely produced) of the 1984 draft /usr/group standard along with a stapled, standard printer document titled "Reviewer's Guide to the PROPOSED /usr/group Standard" dated March 14, 1984. I must say, the publication quality for this being a proposed standard is quite nice, I'd expect a draft to be lucky to have staples if not being just paper-clipped together, but it has a nice printed cover with a logo and all. There is one other thing but I'm making a separate thread for that one, might warrant quite different feedback than this stuff. - Matt G.

2 years, 1 month

2
1
0 0

DOD KSOS Secure UNIX Operating System Manual and Final Report

by segaloco

As promised in the other email, I had one other tidbit worth sharing some detail on but that is very different from WECo promo and informational material. What I've got here are two documents pertaining to the "Department of Defence Kernelized Secure Operating System" project as undertaken by Ford's Western Development Laboratories Division. The documents in question are https://apps.dtic.mil/sti/pdfs/ADA111577.pdf and https://apps.dtic.mil/sti/pdfs/ADA111566.pdf and represent the User's Manuals and Final Report respectively on this KSOS system. These appear to be from the same microfiche as the documents linked based on splotches on the last page's date frame, although the copies I have here have the full frame, the PDFs linked seem to have the last panel cropped to a small square in the middle. Not super significant, but sometimes it's the little details. Anywho, unfortunately I don't have much to report, I got a bit excited while looking for these at first because I was having a hard time turning up PDFs, thought I had stumbled upon something unseen for some time, but in the gulf between last email and this I found them. Silver lining is one less set of documents to scan, but nothing to really expose that isn't already a click away. - Matt G.

2 years, 1 month

2
2
0 0

Re: CB-UNIX dsw(1l) Page from PDP-7?

by norman＠oclsc.org

Rather an aside, but the alt.sysadmin.recovery message referenced in https://www.tuhs.org/pipermail/tuhs/1999-November/001203.html chimes interesting chords for me. If you care only about technical stuff, you should skip to your next e-mail message now. On one hand, the doubly-embedded net.unix-wizards message from Dennis, dated 1984-12-08, containing the original dsw.s: that was posted a few months after I joined Bell Labs, and may even have been partly my fault. 1984 was the nominal 15th anniversary of UNIX; as a member of the steering committee of the recently-formed UNIX* Special Interest Group in US DECUS, I convinced Dennis to attend the Fall 1984 Symposium, in Anaheim in early December, as part of a celebration. As another part, I made copies of the V1-V7 manuals in the UNIX Room and had them shipped out so people could leaf through the history. I think Dennis dug out the PDP-7 source-code books as a contribution to that effort; I am all but certain we brought copies of those too. Of course I had the copies returned not to the Labs but to my home address. I still have them, now on a shelf in my home office. A good friend offered to take care of shipping them back to New Jersey, of course making her own copies in return. I also recall that the conference hotel happened to give me room 127. I offered to swap with Dennis, since he deserved that number more than I did (the extra digit had already been prepended before I joined) but he cheerfully declined. On the other hand--not as historic except to me--the author of the singly-embedded 1999-11-23 alt.sysadmin.recovery message is now (and has for some years been) a co-worker and a good friend. So this single 1999 TUHS posting touches points near both the beginning and the end (so far) of my career, and two different groups of smart people who are fun to work with. Norman Wilson Toronto ON

2 years, 1 month

1
0
0 0

CB-UNIX dsw(1l) Page from PDP-7?

by segaloco

While performing my CB-UNIX 2.3 manual separation, among the many curious things I came across was this manual page: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man1/dsw.1l.pdf The dsw(I) pages I've seen in the various UNIX manuals are all for the interactive delete utility, but make brief mention of the history of the command being amusing. I've seen some communication on the matter of the years here, but had never come across a manual page for the former version of dsw. In the linked page up there is the actual "delete from switches" version of dsw. What I find particularly interesting is that the footer indicates this was printed 8/11/81, but likewise indicates the command is "PDP-7 local". This raises a couple of questions: - Did Columbus ever touch PDP-7 UNIX? - Did dsw(I) as "delete from switches" ever make it to PDP-11 UNIX? Even the V1 manual lists the "delete interactively" utility, not this. - If neither are true, that begs the question of where this page came from, if there was ever a formalized PDP-7 manual that it would've descended from or not, etc. Finally, this page plainly spells out the history of the command in the bugs section: "This command was written in 2 minutes to delete a particular file that managed to get an 0200 bit in its name. It should work by printing the name of each file in a specified directory and requestion a 'y' or 'n' answer. Better, it should be an option of rm(1). The name is mnemonic, but likely to cause trouble in the future." So the first bug is eventually mitigated by transforming this into the more familiar dsw. I can't say what the latter means, whether it's a concern of "dsw" colliding with some reserved word eventually or is more poking fun at the other folk etymology of "delete s__t work". In any case, I hadn't seen the etymology explained to this degree in the mailing list references I found while searching around, so figured I'd share this analysis. - Matt G. P.S. There is mention here that Dennis Ritchie shared the original dsw manpage at some point https://www.tuhs.org/pipermail/tuhs/1999-November/001203.html however the link in question appears to be dead. In any case, the source for the PDP-7 version is in that email if anyone wants to look at it, although looks to be the same as what is in the archive.

2 years, 1 month

4
3
0 0

Likely Late-73/Early-74 C Reference Manual (And NROFF Doc and Summary Changes)

by segaloco

Came across something interesting by chance in the Sixth Edition document set I recently received. I took the binder to the park for a little light reading and found myself perusing the C reference manual. As an aside, I will always appreciate the style of the manual, and I still pick up something new or see something differently every time I flip the pages. The introduction includes these paragraphs: > Most of the software for the UNIX time-sharing system is written in C, as is the operating system itself. C is also available on the HIS 6070 computer at Murray Hill, using a compiler written by A. Snyder and currently maintained by S. C. Johnson. A compiler for the IBM System/360/370 series is under construction. > > This is a manual only for the C language itself as implemented on the PDP-11. Hints are given occasionally in the text of implementation-dependent features, and an appendix summarizes the differences between the Honeywell and DEC implementations; it also contains some known bugs in each. I didn't think too much of this initially, but then I found myself looking through some other old documents yesterday evening and found myself reading the memorandum version of the manual that Dennis linked to on his Bell Labs usr page: https://www.bell-labs.com/usr/dmr/www/cman74.pdf In this version, the paragraphs have been altered and merged: > Most of the software for the UNIX time-sharing system is written in C, as is the operating system itself. C is also available on the HIS 6070 computer at Murray Hill and and on the IBM System/370 at Holmdel. This paper is a manual only for the C language itself as implemented on the PDP-11. However, hints are given occasionally in the text of implementation-dependent features. So between the two, the print document I have here indicates the compiler for IBM mainframes is still in the works, but by the January 15, 1974 document, it is noted as complete and in use in Holmdel. Additionally, this print document mentions an appendix detailing DEC vs. Honeywell differences and some other bug notes. Unfortunately this appendix doesn't actually appear to be in the binder, so either it wasn't done yet or was tossed by a previous owner some time ago. Luckily, this appendix, despite the reference being dropped, *is* on the cman74 version. In any case, upon discovering this, I then spot checked the rest of the contents of the two by seeing if any paragraphs had strange offsets from each other or there were noticeable changes in the visual flow. I didn't read each and every line, instead opting to see if paragraphs still had the same number of lines, the same "outline" (i.e. lines seem to start, end, and break pretty much the same), and that pages started and ended the same, and everything pretty much matched. There may be punctuation changes or other minor edits, but I didn't see anything indicating major changes in the language. The only other thing noticeably different is the references list, with Dennis's cman74 copy containing two extra references mine does not: "A User's Guide to the C Language on the IBM 370." by T.G. Peterson and M.E. Lesk, 1974, and "Programming in C- A Tutorial." by B.W. Kernighan, 1974. The latter is listed as unpublished in cman74. In my copy, aside from the two omitted references, the reference to the CACM paper does not have a date, instead just saying "To appear in C. ACM." and "The GCOS C Library" is listed as an unpublished memorandum with a speculative year of 1974. So all in all, this appears to be a C Reference Manual most likely from late 1973, or however unlikely, one that was very rapidly published in the first few weeks of 1974 before the mentioned changes on January 15th of that year. Are there any known copies of the manual that predate this which I can compare back with, or in any case is this particular revision known and captured somewhere? If not, it should be trivial to take the sources from V6 and produce a facsimile copy until it bubbles up in my scanning list (much ahead of it, got the ROFF manual scanned the other day, hoping to hit TMG and m6 in the next few.) There is also an NROFF manual here that I see referenced in the TOC of the V6 document set in the source, but don't actually see in files. It is dated 9/11/74 and is only labeled "NROFF Users' Manual", no TROFF in the title. It is also noted as the "Second Edition" in the header. This document makes reference to the "TROFF User's Manual", dated April 1974, also by Ossanna. Of note too is a "Quick NROFF Addendum" dated 5/19/75 that is included at the end. Finally, a slightly later version of the UNIX summary appears, dated August, 1975 instead of May, 1975, the date of the one in the V6 sources. It has minor chnages, most noticeably that the last few pages regarding NROFF and TROFF stuff have been split into two sections, one with more NROFF-y stuff and one with more more TROFF-y stuff. Anywho, nothing earth shattering here, but at the very least, a couple of document variants vs. what is currently on the archive. - Matt G.

2 years, 1 month

3
2
0 0

CB-UNIX 2.3 Manual Split

by segaloco

Hello, I'm just emailing to notify that I've managed to split up the CB-UNIX 2.3 manual in the archive[1] into individual items. I've moved the original contents of this directory into the "raw" directory, and now the split PDFs of the manual live under "man". I intend to do the same with the source code scans, breaking them up into individual files, which will eventually go in an accompanying "sys" folder. As for my process, decided to throw together a little something to facilitate splitting up PDFs from a simple table. I've created two scripts[2], pdfslice and pdfbutcher. The former is an interface on top of Ghostscript to take a particular page-bound slice out of a PDF on stdin and drop it on stdout. The latter then reads a tab-delimited list of slices out of a table, butchering the PDFs down into their various cuts. The format is dirt simple: the source PDF name, the start page, the end page, and the destination file prefix to which .pdf is appended on output. This isn't by any means a formal or robust solution, just something that came together easy and works for my application. I'm sure this could be made much more efficient; it just operates on one slice at a time, including all the opening and closing for each slice, but gets the job done. Feel free to use it for whatever just don't complain to me when it eats your favorite file or scribbles all over your disk. Also, an example input file for the curious is included[3]. As for the CB-UNIX pages, my hunch is that whoever owned this manual had a CB-UNIX 2.1 manual originally and "upgraded" it with supplied pages for 2.3, as was conventional with documentation updates. For this reason, there are a few random blank pages and several locally printed pages strewn throughout. In any case a blank page was encountered, it was retained in the document for the manpage it followed. In other words, if there is a blank page between a.1 and b.1, it is appended to a.1. The likely reason for blank pages on the back of 2.1 pages was that new copies of the same 2.1 pages were provided with the replacements to keep the page spacing correct with respect to the pages not being replaced. That's my hunch anyway. There are also pages here and there missing a page, or more likely that were supposed to be removed in the 2.1->2.3 update and simply weren't. Plus, there are a few instances of more than one copy of a non-local version of a page present (in other words, situations where the original 2.1 page wasn't removed but a 2.3 or other newer page was also added). In all these circumstances, the 2.1 page is the one with the normal name and the 2.3 page has been affixed .1l instead of .1, despite not being in the "local pages" PDFs. I'm open to suggestions but my reasoning was that if the 2.1 was the original page for that actual binder, and wasn't replaced by 2.3 but rather that was added, then the 2.3 page for all intents and purposes is a local addition. When in doubt, [4] should be a reasonably complete list of which non-l-suffixed pages aren't from 2.1. Anything else non-local should originate from the previous manual. Also, where there were duplicates on pages that otherwise couldn't be solved this way, the older of the two pages is marked with a .o in the path before the manual section, keeping with the CB-UNIX convention of doing this for old versions of pages. As usual, please let me know if anything seems amiss. I'll admit after a few spot checks I didn't check each and every page my script popped out for accuracy, but everything I've checked had the right pages. If you do find something off and want to try and slice it right, the scripts above include manpages that should give you a good idea on how to use them if simply reading the scripts isn't clear. - Matt G. [1] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/ [2] - https://gitlab.com/segaloco/misc/-/tree/master/scripts [3] - https://pastebin.com/9s2ene9g [4] - https://pastebin.com/jHw7JeDc P.S. Wholly unrelated but just out of curiosity, if anyone knows the 16650 UART well and has some time, can you please email me privately? It's tangential to a UNIX-y project but I'll spare the details here.

2 years, 1 month

1
0
0 0

Early UNIX Explor Support?

by segaloco

Good day, something I've come across in my documentation study that I finally got around to researching a bit is a reference to the language Explor in the V2 ld(I) page: 'There are libraries for Fortran (x="f"), C (x="c"), Explor (x="e") and B (x="b").' The manual has no corresponding mention of any Explor environment, not even a section VI page. The only other UNIX Explor reference I can easily find is on the mailing list here indicating that there is a version of Explor for UNIX on a 1977 tape here (in the 1/explor+dl directory): https://www.tuhs.org/Archive/Applications/Usenix_77/ug091377.tar.gz Does anyone know if there is continuity here or if the V2 reference and the code on the tape are only related in that they're both for Explor? - Matt G.

2 years, 1 month

2
2
0 0

Re: Documentation for Sys-V basic interpreter

by Tom Perrine

KSOS and related work was sponsored by several DoD activities, at least the part that I worked on - after 1983. We've wandered a bit afar for TUHS(?), but, the PWB and other software wasn't pirated, it was supplied as "government furnished equipment" as part of each contract. PWB and other software we got via the NSA's Tycho site, etc. NRL (and then others) funded later KSOS work, including the Advanced Command and Control Testbed (ACCAT) and various multi-level secure "Guard" systems, for the Navy, Air Force, USAFE, etc. All of which ran on PDP-11s, using the KSOS kernel and userspace, almost all built by using PWB as the build platform. On Sat, May 20, 2023 at 12:09 PM Clem Cole <clemc(a)ccc.com> wrote: > I don't think it was pirated. I'm think it was a special license Ford Aero > got due to the work with the USG. I sort of remember KSOS and if I'm > correct that was a DoD funded effort for the Orange Book. So it would make > absolute sense that Ford Aero might have used the USG connections to > convince AT&T to release it to them. As I said, Al was very skittish about > anything that might be misinterpreted by the Justice dept. But if DoD was > asking for it, Al could show the Jusitce -- "hey -- your people asked for > it -- we were not selling it." > ᐧ > > On Sat, May 20, 2023 at 3:03 PM Jon Forrest <nobozo(a)gmail.com> wrote: > >> >> >> On 5/20/2023 11:50 AM, Clem Cole wrote: >> > Taking this off list. >> > >> > I've always wondered about that. Thank you bad word choice -- but it >> > was not officially released outside the Bell System. Since Ford Aero >> > had it, it must have been a very special license. >> >> It was already there when I arrived so I don't know how it got there. >> I doubt it was pirated. >> >> > Was Ford Aero doing something on a Gvt bid when you were using it? >> >> Yes. It was creating KSOS which Tom Ferrine has also mentioned on the >> TUHS list. This was a "provably" secure version of Unix. >> >> You might want to ask John Nagle. His email is probably >> nagle(a)sitetruth.com, and his GitHub is https://github.com/John-Nagle. >> He was there when I arrived and he was a key developer of KSOS. >> If he doesn't know the answer then he might be able to refer you to >> someone who does. >> >> Jon >> >> >> >>

2 years, 1 month

1
0
0 0

Documentation for Sys-V basic interpreter

by KenUnix

Hi. Was any documentation ever done for the basic interpreter that was on System-V? Things like allowed keywords or special keywords. Thanks Ken -- WWL 📚 Okey Dokey OK Boss

2 years, 1 month

6
11
0 0

Re: A Census of /etc and /sys Prior to V4

by jnc＠mercury.lcs.mit.edu

> From: Matt G. > there is a "core" file included, I wonder if kernel text is swept up in > that. My _guess_ is perhaps not; the disks were really small (the UNIX people started with an RF11, which the first DEC machine I used - a RSTS system - also had; that was _really small - 512KB :-). Probably it did whatever V1 did. I was not up for going to look, since I wasn't familiar with the V1 code - but then I decided to break down and look at it, and also create a minimal index to say what's in each module. (Here: https://gunkies.org/wiki/UNIX_First_Edition#Source_index if anyone is interested. Made easier because the code is very well commented; it's very easy to read.) The code to take core dumps is in u1, at 'badsys:'. It dumps the user's entire possible memory space (i.e. not just up to the 'break'), and then (separately) the 'user' area. The system is not included. I doubt V2/V3 are different. > ac and mq EAE registers are still in use in s2-bits binaries Interesting. How did you work that out, BTW? Also, V1 seems to mandate use of a KE11-A (use is made of it throughout the kernel). > but have been replaced by s1-bits. Interesting; how did you work that out? V3's core (V): http://squoze.net/UNIX/v3man/man5/core doesn't give the format, just says "The actual format of the information is complicated because it depends on what hardware is present (EAE, floating-point option)". Do you have C3's db(I) source? Oh, wait, TUHS has what claims to be V2's db source: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/db1.s but it actually seems to be later; it's conditionalized for having the FPP. So it must be for a machine running the -11/45 - which we seem to have decided is V3? The header for TUHS' V2 says: "The files in cmd/ are recreated from the text fragments found on the file s1-bits.gz." Which agrees with your take: > All in all that pegs the s1-bits fragments as being closer in character > to V3 That's all for the moment... Noel

2 years, 1 month

2
1
0 0

Re: A Census of /etc and /sys Prior to V4

by jnc＠mercury.lcs.mit.edu

> From: Matt G. > Given the movement of UNIX to the 11/45 and then to C, does the Third > Edition represent a version of UNIX for the 11/45 with protection but > written in assembly, not C? I think so (evidence detailed below). The support may not have been _quite_ identical to that in V4 (e.g. there was no support for pure texts in V3 - below), though. > is there any other information such as documents, code, etc. concerning > the 11/45 assembly version? This is the real problem, of course; all we have for V3 is some man pages. (And in relying on them, we have to hope that they were updated to match the then-current system - which is not guaranteed, but in general at this point in time, man pages do seem to match whats's in the code.) > Was work completed on the 11/45 kernel changes in the context of this > version and then simply "ported" to the C version or were there > concepts that were cropping up in one or the other and varying amounts > of transportation back and forth as 11/45 and C aspects were > implemented? Without a lot more information, which is now almost certainly lost, we are unlikely to be able to tell. But let me start by laying out what we _do_ know. To start with, it's important to realize that support for protection (and relocation - i.e. memory that looks, to user code, like it's at 0, is actually at, say, 060000 in physical terms) in PDP-11 UNIX _pre-dates_ the -11/45. DEC had a rare, and now almost forgotten "Memory Protect & Relocate" option for the -11/20, the KS11: https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option What exactly it did, and how, is now uncertain (no documentation, or code that used it, appeats to have survived - all we have are a couple of vague recollections), but it is certain that that the UNIX group's -11/20 had it: https://www.bell-labs.com/usr/dmr/www/odd.html and Ken has said that he wrote the code to use it. It's also important to remember that not all the machines running UNIX would have had their hardware updated simultaneously: e.g. the patent group's -11/20 would not have needed the KS11 as much, since it was runnng mature applications. So UNIX was probably conditionalized to run with and without the KS11. As late as V3, there were apparently still UNIX machines without relocation hardware: "The purpose of this command is to simplify the preparation of object programs for systems which have no relocation hardware.": http://squoze.net/UNIX/v3man/man1/reloc When the support for the KS11 appeared is uncertain. It's not in the extant V1 code; but V2 seems to have had it: "the current system, which has relocation and protection hardware": http://squoze.net/UNIX/v2man/man5/core V2 also seems to have started looking forward to the -11/45 - "a trap is simulated by the floating point simulator" (ditto); "if they correspond to 11/45 floating point instructions": http://squoze.net/UNIX/v2man/man3/fptrap It is possible that they already had the -11/45 at this point, but I would tend to doubt it: "immediate mode ((pc)+) is not supported, since the PDP-11/45 handbook is not clear on what to do about it." (If they had it, a simple experiment would have produced the answer.) And "Double precision results are probably less correct than the hardware will be" (note tense). (All from v2man/man3/fptrap.) V3 seems to have the -11/45: "it depends on what hardware is present (EAE, floating-point option)": http://squoze.net/UNIX/v3man/man5/core The "floating-point option" would only have been on the -11/45. (And again we see that V3 still ran on -11/20's; the -11/45 would not have had an EAE: https://gunkies.org/wiki/KE11-A_Extended_Arithmetic_Element since all the EAE operations - except normalization, but that's only needed for floating-point - were in the basic -11/45.) Probably the protection and relocation provided to UNIX processes on the 11/45 was very similar to that provided with the KS11. Do note that thememory management was not exactly the same as V4's: "In the future the text segment will be write-protected and shared.": http://squoze.net/UNIX/v3man/man5/a.out However, it was keeping multiple processes in main memory at the same time: "only processes whose core images are on disk have visible names": http://squoze.net/UNIX/v3man/man8/ps So we can actually tell a fair amount about the evolution through V2 and V3 from the few scraps that are left to us. I do live in hope that a V2 or V3 listing will turn up one day; the system changed a lot in that period, and many questions aren't answered definitively by the man pages. (One big one is details of how the process' address space was laid out - ld(III) and exec(II) simply say nothing at all. I assume it started at 0 - but who knows? In V1, it must have started at a higher address - as on MINI-UNIX: https://gunkies.org/wiki/MINI-UNIX#Implementation_details which I am fairly familiar with - but again, neither V1's ld(III) or exec(II) mentions this detail. I suppose I could work it out from the V1 source, but I'm not _that_ interested... :-)) It is possible that the evolution started with just protection (if the KS11 could do that), and relocation was added later. It seems clear that the step from the KS11 to the -11/45 was probably not large. If anyone has a V2 or V3 listing, please sing up! That would be an _incredibly_ valuable thing to add to the historical record. Noel

2 years, 1 month

2
1
0 0

Berkeley Font Catalog

by segaloco

Hello, I've just today secured purchase of an original 4BSD manual and papers set and a copy of what I believe is the V6 papers set as well. Of note amongst the tabs I could read from the pictures of the Berkeley binder was a section of fonts that I don't think I've seen before named the Berkeley Font Catalog. I did a bit of searching around and didn't find anything matching that on first inspection re: scanned and source-available BSD doc collections. Anyone got the scoop on this? Either way, once these arrive in the mail in I'll try and see what the delta might be between these and the current sources in V6 and 4BSD stuff on the archive. They're from the collection of an emeritus professor on the east coast, and I'm not sure if they represent unmodified docs shipped from Bell and Berkeley or have local modifications. In any case, his son said they'll be going through more material soon and are liable to turn up more UNIX stuff, so I'll keep folks posted if I come into possession of anything else particularly spiffy. - Matt G.

2 years, 1 month

6
7
0 0

older book

by Andrew Hume

for some reason, i have a copy of “computer programming and autocodes” by burnett-hall, dresel and samet (1964). it covers pegasus-sirius autocode, elliot 803 autocode, mercury autocode and algol. it is a hardcover duplicate from the library of congress. anyone want this? otherwise, it gets recycled thru my local library.

2 years, 1 month

2
1
0 0

A Census of /etc and /sys Prior to V4

by segaloco

I've just completed the Fourth Edition pass of commits in my manual history repository here: https://gitlab.com/segaloco/mandiff Something I've kept a particular eye on is what the landscape looked like on the filesystems over the early years of development. Here are some of those observations with a few areas perhaps requiring further illumination: In the first two editions, there was a file, /etc/uids, which mapped simply a username to a uid. The reason was presumably due to the plaintext passwords in /etc/passwd at the time. The arrival of crypt(III) and related functionality rendered this moot by the time of V3. Additional GECOS information is first spotted in /etc/ident in V2 but by V3 has also found home in /etc/passwd in the GECOS field today used often for a user's full name. The s1-bits source codes refer to /etc/passwd where disassembled s2-bits binaries refer to /etc/uids still, dating both sets of code. References to /etc/motd first appear in the V2 manual from what I could find, so that may not have been around in V1. Additionally, after V1 many files are moved from /etc to locations under /usr such as ascii and kbd moving to /usr/pub and roff's suftab moving to /usr/lib. It seems in the First Edition, manual section VII mapped to /etc itself it seems, with etc and misc in the manual being synonymous. So all in all it seems, in terms of support files anyhow, /etc wound up smaller by the advent of the C system, at which point init beings using /etc/rc and the directory begins to expand again. Another directory of interest is /sys for a few reasons. First, this directory serves different purposes depending on your kernel these days, with BSD systems storing system source code here whereas Linux provides a kernel interface filesystem. I'm not sure what other contemporary systems may use this for, but from V3 and back, this was another RK disk mounted in addition to /usr. This /sys directory appeared to contain the manuals, source code to system components including the commands, kernel, bootloader, and languages, and a copy of the kernel image referenced down in the source tree. In total I've identified the following directories: c, fort, lang, man, mdec, source, sys. Most names should be obvious from later releases, with lang being a parent directory that contained bdir and mdir B and m6 languages respectively. My guess is that when RP support was made workable in V4, there was no longer a need to segregate data amongst RKs like this so /sys was merged into /usr, leading to the later structure we see in V4-V6. Of note, this structure is implied in CB-UNIX still in the path names of the source code available on the archive. The kernel is found at /tsys/sys/ much like the kernel in V1-V3 living at /sys/sys. One thing I haven't been able to glean in the process is precisely how the command and library source code was stored in these very early versions. The kernel in T.R. Bashkow's analysis is implied to be stored in files u[0-9x].s, and command source files at least exist somewhere as the command followed by .s. As of V5, the command, syscall wrapper, and library source codes are split up amongst a number of directories with names such as s1, s2, s3, etc. under source. By V7, this has taken on the cmd/lib/sys structure of later releases. Finally, just a general curiosity the version study involved has raised. Given the movement of UNIX to the 11/45 and then to C, does the Third Edition represent a version of UNIX for the 11/45 with protection but written in assembly, not C? I've seen one handwritten document that makes mention of some of this, but is there any other information such as documents, code, etc. concerning the 11/45 assembly version? Was work completed on the 11/45 kernel changes in the context of this version and then simply "ported" to the C version or were there concepts that were cropping up in one or the other and varying amounts of transportation back and forth as 11/45 and C aspects were implemented? As always, thanks for keeping up, hopefully I can get this repository up to V6 soon, then the real branching fun begins. The V3 to V4 changes are hopefully the last time the commit diffs have major noise, what with the conversion from roff to nroff. I suspect transitions to macro packages later won't be as bad. - Matt G.

2 years, 1 month

2
1
0 0

BSTJ 1978 UNIX Issue Price Appreciation

by segaloco

Howdy folks, I was perusing old copies of ;login: and came across a note about the BSTJ UNIX issue in the August 1978 newsletter: https://archive.org/details/login_august-1978 What I find particularly amusing is that all UNIX licensees at the time of that publication allegedly were provided a copy free of charge. The text goes on to indicate additional copies can be purchased for a measly $1.50. Fast forward to today and I typically don't see this copy pop up on auction for less than $100. Still, amazing how something was being just tossed out to anyone who wanted one and now here 45 years later, it's a mad scramble to find the same. Then there's this listing: https://www.ebay.com/itm/134212722284?hash=item1f3fb39e6c:g:9VEAAOSw8HtjCp2… $3000 dollars...quite shocking, although perhaps they're banking on the uniqueness of that little sleeve, I've never seen one of those with a BSTJ issue before. Was that some sort of packaging the issues were delivered in? It has the Bell Logo in the little window on either side, so I want to believe it's original and not something someone threw together after the fact. In any case, I suspect part of the low pricing is due to Bell anti-trust stuff, as they really moved on nickle and diming on documentation once they were legally able to. In any case, I'm always shocked to see how much I paid for something in my archival efforts and then I find a price sheet only to find out someone bought a book back in the day for the cost of a burger and fries. While I'm pursuing documents for research purposes...I may be inadvertently building myself quite the value store without even meaning to... - Matt G.

2 years, 1 month

10
11
0 0

OT: TUHS mails not going to Outlook & Hotmail. Help!

by Warren Toomey

All, e-mails from the TUHS server are not making it to Hotmail or Outlook. I've not changed anything. Is there anybody with some MTA/ISP experience who might be able to help diagnose the problem? Thanks, Warren

2 years, 1 month

11
12
0 0

The Gnome and Its "Secret Place"

by segaloco

In the midst of my documentation research, I've done a little analysis on the life and times of this whimsical little phrase which first appeared in the "HOW TO GET STARTED" or basinf section of the Third Edition manual (a derivative of the original login(VII) page): "When you type to UNIX, a gnome deep in the system is gathering your characters and saving them in a secret place." Aside from the wonderful imagery of the terminal interrupt driver as a little gnome, I've found that this line has some implications regarding UNIX documentation lineages. This exact verbiage survives in the research line through the Sixth Edition, and is slightly edited prior to the Seventh: "When you type characters, a gnome deep in the system gathers your characters and saves them in a secret place." The latter of the two changes holds with a trend over time of using progressive rather than continuous language. That aside, simple change of "to UNIX" to "characters". Seems simple enough, reduce redundancy and make it more clear what is happening. In this same breath, basinf was merged into intro. Checking the Tenth Edition manpage sources on the source tree, this version then seems to persist for the rest of the research lifetime. Peering across into BSD-land, I had to pull a paper copy for this one because I can't find the intro document in the tree, but it likewise has the same exact text, so this version also persisted through the remainder of the UCB development period. When you start to look into other Bell lineages, things get a little more interesting. Let's start with MERT Release 0. This manual was produced in October, 1977, and has a "gnome" message identical to that in the Sixth Edition manual, so presumably by this time, the old text could very well have still been up in research. Unfortunately we only have scans of this manual, so I can't say whether the merge from intro and basinf to just intro has happened yet. Additionally, this may not reflect the case with USG Program Generic 3 (or any of those) as the intro is one of the sections marked as modified from the USG manual. Next let's check the situation with PWB 1.0. To start, the intro and basinf documents have been merged into a document titled "introduction", which may very well indicate that this manual page at least was produced after the merge in the research line, and given this was July 1977, that's a case for the MERT 0 page likewise probably being a merged page. However, the text reads: "When you type to UNIX, a gnome deep in the system is gathering your characters and saving them." So a different modification of the Sixth Edition text, we still have "to UNIX" and the continuous "is gathering...and saving". What does change is we no longer know where the gnome is saving those characters. We've now lost the secret place, research and BSD carry on knowing the real story, and MERT 0 kept this intact as well. Taking a look further afield, in the System III manuals, originally produced in 1980, we see the same as PWB, a merged intro document (now just named intro again), and the same text, the Sixth Edition text minus the secret place commentary. So whatever merges of documentation took place between PWB 1.0 and 3.0, it seems the updated text from the Seventh Edition was never picked up, and the modified line persisted through to this point. Checking forward, this text persists into the release of PWB 5.0. The first release of System V only changes "UNIX" to "the UNIX System", consistent with nomenclature changes throughout documentation in the PWB 5.0->System V transition. Taking a little peek aside into yet another lineage, the CB-UNIX 2.3 manuals circa 1981 likewise carry this same text, with the "secret place" removed. Unfortunately we don't have any other versions of CB-UNIX manuals to compare with, but the specific page in question actually lists CB-UNIX 2.1 in the footer with a date of November 1979, so the PWB-ish text in that lineage dates to at least that point. There are a few different variations circa SVR2, with the 1983 BTL version and 1984 DEC processors versions of the manual changing the first bit to "When you type to UNIX system", whereas the 1986 HRW tradebook manuals state "When you type to the UNIX system." So the "the" is dropped, "system" is lower-cased, but then the "the" is added back between 1984 and 1986. Finally, there is one more variation on this line, the saddest one of all, that appears circa System V Release 3 material in 1987: "When you type to the UNIX system, your individual characters are being gathered and temporarily saved." "Pay no attention to the gnome behind the curtain," says AT&T, removing all whimsy from the equation. This persists into SVR4. Can't say what happens in SVR4.2, I don't have one of those user's manuals, but in any case, it's probably save to assume Novell didn't resurrect the gnome. So just to review the strange and wonderful journey our little gnome has been on: - Introduced in Third Edition - intro and basinf documents merged between Sixth and Seventh Edition - MERT 0 takes the old text - PWB line takes the old text and drops the reference to a "secret place" - Seventh Edition adjusts the text to drop UNIX redundancy and use progressive language - PWB line keeps rolling with their modified text, CB-UNIX takes it up (or vice versa? can't conclude anything there) - PWB to System V process converts most references of "UNIX" to "the UNIX System" - Along the way, the "System" is ultimately lowercased, the "the" gets lost for a while and comes back - AT&T finally removes the gnome reference in SVR3/1987 - Research and BSD keep the Seventh Edition text to the end Granted, this is a very trivial detail, but one that does demonstrate some flow of documentation revisions and what sorts of changes different groups were making to their documents, what with research making changes to the grammatical style while the PWB-then-commercial line grew more sterile in this presentation over time. This then shows at least one instance of a lack of merging of aspects of the Seventh Edition documentation back into the PWB line after the split of 1.0. Eventually I hope to illuminate many more such areas through the diffing and historical analysis I'm performing. By the way, I believe a few list members had indicated at some point or another being in possession of some USG Program Generic manuals. If you happen to catch this, and have the time, I'd be ever so curious which of the above, if any, variations on the text they contain. This particular line is immediately following the "How to communicate through your terminal" heading the "HOW TO GET STARTED" section. Anywho, I hope this was an entertaining diversion. While most of the analysis I'm performing concerns software details and version differences, it's also nice to take a closer look at some of the other sorts of changes that have happened in the lifetime of the system's growth and diversification. - Matt G.

2 years, 1 month

4
6
0 0

Re: Corbato dead

by Douglas McIlroy

Although it dates from four years ago, MIT's obituary for Corbató was still interesting to reread. It couldn't bring itself to mention Unix--only the latecomer Linux. It also peddled some mythology about Whirlwind from the decade before timesharing. "Whirlwind was ... a rather clunky machine. Researchers often had trouble getting much work done on it, since they had to take turns using it for half-hour chunks of time. (Corbató said that it had a habit of crashing every 20 minutes or so.)" "Clunky" perhaps refers to Whirlwind's physical size. It occupied two stories of the Barta Building, not counting the rotating AC/DC motor-generators in the basement. But it was not ponderous; its clean architecture prefigured "RISC" by two decades. Only a few favored people got "chunks" of (night) time on Whirlwind for interactive use. In normal business hours it was run by dedicated operators, who fed it user-submitted code on punched paper tape. Turnaround time was often as short as an hour--including the development of microfilm, the main output medium. Hardware crashes were rare--much rarer than experience with vacuum-tube radios would lead one to expect--thanks to "marginal testing", in which voltages were ramped up and down once a day to smoke out failing tubes before they could affect real computing. My recollection is that crashes happened on a time scale of days, not minutes. "Clunky" would better describe the interface of the IBM 704, which displaced Whirlwind in about 1956. How backward the 60-year-old uppercase-only Hollerith card technology seemed, after the humane full Flexowriter font we had enjoyed on Whirlwind. But the 704 had the enormous advantages of native floating-point (almost all computing was floating-point in those days) and FORTRAN. (Damn those capital letters!) Doug

2 years, 2 months

6
6
0 0

Corbato dead

by Rich Salz

https://www.csail.mit.edu/news/fernando-corby-corbato-1926-2019. He invented time-sharing, passwords, and ran Project MAC.

2 years, 2 months

1
1
0 0

Senior moment

by Douglas McIlroy

Apologies for once again posting an item for the groff list to tuhs, re: "Any reason the removal/renaming of read-only registers should be permitted?" Doug

2 years, 2 months

1
0
0 0

Any reason the removal/renaming of read-only registers should be permitted?

by Douglas McIlroy

I think Clark was justified in deviating from Ossanna. The prime rationale for allowing removal of read-only registers is uniformity--a powerful argument. It simplifies documentation and relieves a burden on users' understanding. It probably simplifies the code, too. This kind of special-casing is AI in the service of some perception that "no one would want to do that.". If "that" is the clear meaning of some specified action, then so be it. We are not dealing with physical hazards here. > even if they don't screw up the formatter internally, > they will become unrecoverably useless for documents > and macro packages, The same argument could be made about \applying .rm to any standard request, and I would disagree for the same reason as above. (A disappointing experimental discovery in this regard: .de seems to be immune to removal.) A change that I *would* welcome is warning about writing into a read-only register. (Also make .rm work on .de--a near reversal of the original proposal.) Doug

2 years, 2 months

2
1
0 0

BSD question: Kurt Shoens, or Kurt Schoens?

by Steffen Nurpmeso

Hello. Even in these rusty times (oh what complicated chemical processes there are!) a question that i hope someone can answer. In both Spinellis' UNIX history repo as well as the CSRG one (via robohack/ucb-csrg-bsd.git) one can find two ways of writing Kurt Shoen's name, and whereas i, who always refer to Mail and its "usr.bin/mail/def.h" (aac48ec10b56f59b321fb033a36bca2114ef061b): [ Author: Kurt Shoens <kas> AuthorDate: 1980-10-08 08:53:34 -0800] + * Author: Kurt Shoens (UCB) March 25, 1978 one can find the name "Kurt Schoens" as early as 4.2 BSD (curses, twinkle1), and then in a growing number of files, especially after 1993 when Keith Bostic and then Kirk McKusick did admin/admin/contrib/address.list and admin/admin/contrib/contrib and share/man/man0/title.cdrom But one can also see the commit Author: Kurt A. Schoens <kas(a)ucbvax.Berkeley.EDU> AuthorDate: 1980-10-09 02:48:47 -0800 and that is strange, as i presume all-automatic version control conversions here? Schoens .. is a bug? Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) |~~ |..and in spring, hear David Leonard sing.. | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure |~~ |Farewell, dear collar bear

2 years, 2 months

3
4
0 0

Revisiting 6th Edition: rxv64

by Dan Cross

I've mentioned tangentially this a few times, but over the weekend I finally got around to dusting off the code and getting it running: https://github.com/dancrossnyc/rxv64.git rxv64 is a rewrite of MIT's xv6, which in turn, reimagines 6th Edition as a purely pedagogical system, implemented in ISO C for 32-bit SMP x86 machines. Building on xv6, rxv64 is implemented in Rust and targets 64-bit x86_64. It works well enough to boot up, run a shell, and run commands, but it doesn't really have much of a userland at present. I started this as a pedagogical tool, being something that one could point working engineers at as an example of a "real" operating system implemented on real hardware in Rust. The code could surely be made safer and more comprehensible, but cycles are short at present, and it's better to just get it out there. Have fun. - Dan C.

2 years, 2 months

4
4
0 0

I have unsubscribed my original address from the list

by Gregg Levine

Hello! For some time now I've had both this address, and my original address which was on another service altogether subscribed to this list. And starting some time earlier, it would not show a full thread, it would show partial contents, the latest was the work by Dan Cross. In fact With that being last, ah, straw I decided to do that. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 years, 2 months

1
0
0 0

Re: UNIX "Machine Layer"

by Steve Simon

“soldering iron…” i do remember the fun of changing the baud rate of an async line on the Honeywell level 66 mainframe at college. This required shutting the whole machine down, removing one of the cards, and the (very careful) use of a wire wrap tool. -Steve

2 years, 2 months

2
1
0 0

UNIX Usage for Bell Telecom Typesetting

by segaloco

Good evening folks, I'm doing some research lately into the typesetting style apparent in the various UNIX System V guides I've scanned to archive.org. Their typesetting style is unlike that of the MM papers published with 3.0 and 4.0, but the contents seem to have continuity with the text in these collections. Well, in my searches sometimes telecom documents from the Bell System come up too and in materials from the 70s and 80s I started noticing that familiar typesetting in telecom stuff such as that hosted here https://www.telephonecollectors.info/index.php/browse/bsps-bell-system/bsp-… The earliest example I could find is 1969, so certainly at least a publication style that predates UNIX, but what I can't tell from my searches alone is if this style implies some non-UNIX typesetting system through and through or if there was a macro package dreamed up at some point between 1969 and 1982 that was in place by the time of the System V documentation. Just to detail specifics of the publication style, the commonalities I've found are the use of specifically bold numbers for page numbers, having the doc title and call number in the outer upper corner of pages, and just the fonts themselves look very similar. As an added note, the fonts used in the telecom documents and System V guidance documentation also resemble those in the copyright statement pasted on the cover of the extant PDF of the fifth edition UNIX manual. There is also some resemblance to the visual style observable in USG Program Generic and adjacent documentation (for instance the 1976 kernel description of PG 2 or the MERT 0 documents). This typesetting style is not seen in known research, CB, nor PWB until 5.0. Was there some separate typesetting system used in the broader System that, say, WECo may have taken up when they took over documentation between 3.0 and SVR2? - Matt G.

2 years, 2 months

1
0
0 0

S2-bits V2 Source Code Restoration

by segaloco

Hi folks, sharing another project that I've been tinkering on for a little bit since I like having a lot of irons in the fire: https://gitlab.com/segaloco/v2src After the link is a repository which over time will be accumulating the results of disassembly and analysis of files found in the s2-bits.tar.gz file in the archive. Details of my process are contained in the repository's readme. The short of it is I'm disassembling the binaries one by one, and where possible am comparing them with known sources to massage these into a pretty close restoration of the original sources. A few discoveries I've made in the process thus far: - These binaries appear to represent a version between the first and second editions. The binaries themselves are a mix of "naked" binaries as well as V1 and V2 a.out formats. Where it matters, things are much closer in character to V2 than V1. - All section 1 content that would be gone by V2 is removed here. Curiously, mount(1), type(1), and umount(1) which are in both V1 and V2 are absent from the s2-bits. - The sources marked "V2" in the UNIX source tree may be a bit closer in character to V3. Notable examples are that, while string references to /etc/uids remain, all data references have been updated to /etc/passwd, and several mathematical operations in the disassembled binaries map to KE-11 Extended Arithemtic Element registers where in the sources labeled "V2" in the tree have instead shifted to doing these calculations differently, presumably as these sources target the 11/45, not the 11/20. Additionally, the cat.s in "V2" on the tree contains the '-' stdin option, which was first documented in V3. The most likely story is that they're somewhere between, just like the s2-bits are between V1 and V2, but all of these observed differences thus far have aligned the sources with their descriptions in the third edition manual. Anywho, as usual, if anyone spots anything amiss or that could be done better, happy to accept contributions, or fork it and tinker away. Also, if anyone has already done this, speak up and tell me now so I don't double up on something so involved =P - Matt G.

2 years, 2 months

1
0
0 0

Re: UNIX "Machine Layer" Standards

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > something like a boot rom only became the norm in the late > 70's. Before that, one keyed in two dozen words with a tiny program to > load the first boot stage. A little wrong on that date. Even the PDP-11/20 (the first -11) had a boot ROM: https://gunkies.org/wiki/BM792_ROM which appreared in mid-1971 (about a year after the release of the /20). DEC sold them pre-programmed, but one could 'program' one onself, if one wanted - with a soldering iron! (Check out the image! I actually did that to one that I was given, that had been eviscerated by someone.) From then on (follow the category link), the rest used PROM chips. > From: Warner Losh > Oftentimes, the interrupt vector was in the lowest core addresses It's worth remembering that in the early period, that restriction to low addresses was built into the hardware (in an amusing way :-). Take the DL11: https://gunkies.org/wiki/DL11_asynchronous_serial_line_interface which was sort of mandatory as the 'console' serial interface on most early -11's (until the DL11-W appeared; more on its big improvement in a second). It set the interrupt vector with _jumpers_. (You want to change the interrupt vector? Dig out your soldering iron! :-) There were only 6 jumpers - one each for address bits 3 through 8. So the largest vector you could set was 0770. The DL11-W was a big step forward - it replaced the jumpers with a DIP switch! :-) Still only six bits, though. :-) Noel

2 years, 2 months

3
2
0 0

Re: UNIX "Machine Layer" Standards

by Paul Ruizendaal

Hi Matt, I’ve responded on list about the early unix development process as I understand it, but I want to avoid discussing things that are not directly related to the history of Unix. Hence this PM as well. > Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. I have a similar interest, working with early Unix and modern RiscV hardware for a compare and contrast experience. - My development targets are (i) an FPGA based RV32 SoC implementation, (ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V. - My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experiments around SysIII Linux is for me a secondary target, just for comparison and to see if ideas are “Linux capable”. I’m not overly interested in Arm at the moment. My ideas are still evolving, but currently more or less along the below lines: - Boot rom loads SPL, this is custom in each case and set by the SoC's designers. - SPL initialises DRAM system and loads next stage. Unfortunately, this too would seem to be quite system specific, but the BSP should provide the baseline for this. As BSP’s are often a mess, milage may vary. - The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to provide a standard abstraction layer that all of my software targets can work with. This idea is used for the FPGA target and allows booting a Linux kernel with just the generic Virtio device drivers (so far just disk and console). - The last layer is the classical OS layer. If I get it right, each OS can run on all h/w targets without customisation. At the moment I’m playing with USB, and how that might layer into the structure of V7, SysIII or 8th Edition -- and also the above.

2 years, 2 months

3
2
0 0

Re: UNIX "Machine Layer" Standards

by Paul Ruizendaal

> Date: Mon, 10 Apr 2023 18:27:51 +0000 > From: segaloco > ... or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle? I stumbled into the same question last year, when doing my SysIII to RV64 port. I managed to turn that into a somewhat chaotic discussion, mixing old and new, and history with ideas. From that chaotic discussion I got the impression that it was indeed mostly ad hoc. In context, hardware was much easier to boot and drive back then -- it probably was not seen as complex enough to warrant much research into layering and abstraction. Also bear in mind that something like a boot rom only became the norm in the late 70’s. Before that, one keyed in two dozen words with a tiny program to load the first boot stage. That said, there is an implicit layering in v7 and beyond: - “low.s" does hardware setup, incl. such stuff as setting up interrupt tables. As this is closely tied to the hardware, it would have been a custom job in each case. - “mch.s” (later also mch.c) has the basic routines that are hardware dependent (switching stacks, changing priority levels and modes, etc.). It also has emulation for ‘missing’ instructions, such as floating point ops where this is not available in hardware. Same as above, I think. Maybe h/w related memory protection operations should live here as well, but the hardware was still quite divergent in this area in the 70’s and early 80’s. - low-level device drivers live in the ‘dmr’ or (later) ‘io’ directory. Here there is some standardisation, as all device drivers must conform to the (char/block) device switch APIs. It seems to me that most of these drivers were written by taking one that was similar to what needed to be written and to start from there. Maybe this is still how it works in Linux today. - To the extent that there is such a thing as 'high-level device drivers’ in early Unix, the structure is less clearly visible. The file system (and there was only one at the time of v7) is placed between the block device switch and the mount table so to speak. This was structured enough that splicing in other file systems seems to have been fairly easy in the early 80’s (the splicing in, not the writing of the file system itself, of course). Starting with 8th edition, the ‘file system switch’ created a clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also a ‘high-level device driver’, but this one lives as custom code together with the serial port device drivers. Also in 8th Edition, ‘streams' were introduced. One could think of this as a structured approach to high-level device drivers for character mode devices, incl. the ’tty’ subsystem. - I don’t think there was ever anything in early Unix that merged ’streams’ and the 'file system switch' into a single abstraction (but maybe 9P did?). > Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. I have a similar interest, but to avoid the same chaos as I created before, I’ll respond to this with a pm.

2 years, 2 months

3
2
0 0

UNIX Manual Cover Art Origins?

by Douglas McIlroy

> Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? The Bell Labs publication department at Whippany did the physical design for the bound versions of the Research Unix manual--from v7 as a trade brook through v10, also a trade book.. They did the cover designs for v8-v10 in house. I am not sure whether they did the v7 cover, farmed it out, or left it up to Holt Rinehart. Whippany handled the printing of v8 and v9. Saunders College Publishing did it for v10. Unfortunately, I do not remember whom I dealt with in Whippany, and my records of the interactions are long gone. Doug

2 years, 2 months

3
2
0 0

UNIX SVR2 User's Manual BTL Edition Additions and References

by segaloco

Good evening, I'd like to share a listing I've taken of the various extra pages present in the BTL version of the SVR2 User's Manual I picked up a little while ago. https://pastebin.com/18uTzyfS Like the Release 5.0 BTL version before it, many of the added pages are DIV 452 standard pages for Writer's Workbench as well as the Basic-16/BELLMAC-4/BELLMAC-8 development environments. To quote the preface: "This manual was designed through a cooperative effort of the BTL Computer Centers in Division 452. It represents a collection of nearly all the commands that are running on any Computer Center UNIX machine. ... The header of each manual page identifies the classification of the command along with any machine or site dependencies. ... Any page marked LOCAL indicates the sites that are running that command. ... Pages marked DIV 452 STD are from the collection of Computer Center standard commands, and are available on machines administered by Division 452 Computer Centers. The pages that are designated as INTERIM or 5.0 are those commands which are scheduled to be included in a separate WECo software add-on package." This manual is just sections 1 and 6, presumably 1m, 7, and 8 are in a corresponding administrator's manual and 2, 3, 4, 5 are in a programmer's manual, making SVR2 the start of the user's manual being further subdivided. I seem to recall one or the other of this same issue of manuals show up on eBay at some point, I'm kicking myself for not springing for it at the time, but hopefully one or the other (or both) turn up again to be documented someday. Additionally included in the above listing is a list of references from various "SEE ALSO" sections throughout the manual, as well as some other odds and ends from the text. Finally, there is a short listing of teach(1) classes as provided by a couple variants of the application. If any particular page piques an interest, let me know and I can scan it for you, otherwise this one is a ways away on my scan backlog. - Matt G.

2 years, 2 months

1
0
0 0

UNIX Manual Cover Art Origins?

by segaloco

Good day everyone, I'm in search of a bit of esoteric information regarding published UNIX works. Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals? Some that come to mind: The alphabet blocks cover of the HRW V7 Manuals The simple 70's Bell-style cover of the UNIX System III manual The nice 3B-20 picture on the UNIX 4.1 manual The grid patterns design on the UNIX System V documentation The blue "big V" SVR4 manuals (given the time disparity, these could have totally different underpinnings) Where I'm particularly curious is how these covers were actually set, defined, the image data to print on them stored, formatted, etc. In other words, <???>:troff::covers:manpages where ??? may also represent more than just the specific tools/formats. Anyone have the scoop on the actual raw materials and technologies used for preparing the covers and/or if any of those original assets, in their raw form, would potentially still exist somewhere? To be honest, I am particularly interested in the original, highest fidelity possible image of the 3B-20 from the corresponding manual (https://commons.wikimedia.org/wiki/Category:Unix_Manuals#/media/File:UNIX4.…) but am happy with any info illuminates what went into the actual physical production. Thanks all! - Matt G. P.S. If it provides any leads, the closest thing I've found in actual document sources to material related to these aspects of physical publication are the files M.folio and M.tabs here: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/tools

2 years, 2 months

1
0
0 0

Free books

by Rich Salz

I figure it won't cost me much more than $5 to ship domestically, which I'll pay for. International is more hassle so let's discuss. BSTJJuly-August 1978 ("the" issue) Elements of Programming Style 2nd Ed, Kernighan and Plauger The UNIX Programming Environment, Kernighan and Pike The C Programming Language 2nd Ed, Kernighan and Ritchie (includes printout of errata posted by dmr(a)alice.JUCP "5 Jun 89")

2 years, 2 months

3
3
0 0

UNIX "Machine Layer" Standards

by segaloco

Good day everyone. I'm taking a bit of a break from my documentation stuff and veering back towards some embedded systems work and have the burning question on my mind this morning: Was there any coordination between different groups engaged in porting efforts at Bell regarding machine layer implementations? In other words, was there any sort of common design of "get a stack pointer, do <XYZ> on the protection hardware, move the binary to address <ABC>, clear bss, etc." that was followed as lore when working up new machine bootstraps, or was that sort of work a bit more siloed? For instance, when working on the VAX port, was the crew more likely stepping through mch replicating things based on what the PDP-11 was doing, was the startup more derived from DEC literature, or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle? Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. What I don't know is if I'm barking up the wrong tree and it was already settled in the 70s that machines are sufficiently different enough that you can't really just set forth one abstract "machine startup" design that actually includes all those CPU-level concerns such as protection, stack config, context switching, etc. I know even today peering into sources of stuff like Linux and seL4, the "ml" for each seems to have been built by a different person/group rather than someone setting out with a CPU bootstrap design and implementing the same on each chip. So boiled down to a one liner: Was there a guiding document/design/memoranda for the mch/ml components of UNIX in Bell, or was each one designed more "on-the-fly" as the particulars of the hardware were sorted out? - Matt G.

2 years, 2 months

1
0
0 0

Latest 2.9BSD and 2.11BSD

by Warner Losh

Greetings, What's the canonical source for patches to 2.9BSD and 2.11BSD? I see we have 2.11BSD patch 469 dated last month in the archive. Where does it come from? Has anybody climbed the hill to import all the patches into a git repo? I've found some mirrors, but moe.2bsd.org has been down for me for ages... How does Warren keep things up to date? I also have a (maybe faulty) memory of a similar series of patches to 2.9BSD because it was the last BSD to support non-split I&D space machines. yet a quick google search turns up nothing other than a set of patches dated August 1985 (also in our archive) and some changes for variants of hardware (pro, mscp). Is that it? Warner

2 years, 3 months

3
6
0 0

CWRU Univac artifacs

by Lars Brinkhoff

Hello, I received word from someone who went to Case Wester Reserve Univsersity, and is willing to send early 1970s ephemera to someone interested in going through it. The description is: "I've go stuff from my course work done on our Univac 1108/ChiOS system, program listing, cpu code cards, etc." Any takers? Best regards, Lars Brinkhoff

2 years, 3 months

2
2
0 0

Warren Toomey interviewed by Rik Farrow.

by Dan Cross

Enjoy this interview with our own wkt! https://www.usenix.org/publications/loginonline/interview-warren-toomey-fou…

2 years, 3 months

1
0
0 0

2.9BSD PUCC

by Henry Bent

Hello all, I am working on restoring the 2.9BSD PUCC distribution as provided on the CSRG CD/DVD set, hopefully as closely as possible to the original system. I am at a point where I have a setup that boots 95% of the way to multiuser but I have encountered some difficulties with the final few steps. I would appreciate it if anyone who is familiar with the login procedure could contact me off-list. -Henry

2 years, 3 months

1
0
0 0

administrivia: redirects from minnie?

by Royce Williams

I see that all the old minnie links: https://minnie.tuhs.org/pipermail/* ... break, and archived post are now at: https://www.tuhs.org/pipermail/* Could we get a courtesy redirect for pipermail/* ? -- Royce

2 years, 3 months

1
0
0 0

Warning: April Fools

by Ron Natalie

Once again, I must dredge up this post from 1991…. From spaf(a)cs.purdue.EDU Thu Apr 4 23:11:22 1991 Path: ai-lab!mintaka!mit-eddie!wuarchive!usc!apple!amdahl!walldrug!moscvax!perdue!spaf From: spaf(a)cs.purdue.EDU (Gene Spafford) Newsgroups: news.announce.important,news.admin Subject: Warning: April Fools Time again (forged messages on the loose!) Message-ID: < 4-1-1991(a)medusa.cs.purdue.edu> Date: 1 Apr 91 00:00:00 GMT Expires: 1 May 91 00:00:00 GMT Followup-To: news.admin Organization: Dept. of Computer Sciences, Purdue Univ. Lines: 25 Approved: spaf(a)cs.purdue.EDU Xref: ai-lab news.announce.important:19 news.admin:8235 Warning: April 1 is rapidly approaching, and with it comes a USENET tradition. On April Fools day comes a series of forged, tongue-in-cheek messages, either from non-existent sites or using the name of a Well Known USENET person. In general, these messages are harmless and meant as a joke, and people who respond to these messages without thinking, either by flaming or otherwise responding, generally end up looking rather silly when the forgery is exposed. So, for the few weeks, if you see a message that seems completely out of line or is otherwise unusual, think twice before posting a followup or responding to it; it's very likely a forgery. There are a few ways of checking to see if a message is a forgery. These aren't foolproof, but since most forgery posters want people to figure it out, they will allow you to track down the vast majority of forgeries: o Russian computers. For historic reasons most forged messages have as part of their Path: a non-existent (we think!) russian computer, either kremvax or moscvax. Other possibilities are nsacyber or wobegon. Please note, however, that walldrug is a real site and isn't a forgery. o Posted dates. Almost invariably, the date of the posting is forged to be April 1. o Funky Message-ID. Subtle hints are often lodged into the Message-Id, as that field is more or less an unparsed text string and can contain random information. Common values include pi, the phone number of the red phone in the white house, and the name of the forger's parrot. o subtle mispellings. Look for subtle misspellings of the host names in the Path: field when a message is forged in the name of a Big Name USENET person. This is done so that the person being forged actually gets a chance to see the message and wonder when he actually posted it. Forged messages, of course, are not to be condoned. But they happen, and it's important for people on the net not to over-react. They happen at this time every year, and the forger generally gets their kick from watching the novice users take the posting seriously and try to flame their tails off. If we can keep a level head and not react to these postings, they'll taper off rather quickly and we can return to the normal state of affairs: chaos. Thanks for your support. Gene Spafford, Net.God (and probably tired of seeing this message)

2 years, 3 months

8
7
0 0

Manpage Analysis Repository (And V1/V2 roff Restorations)

by segaloco

Good evening or whatever time of day you find yourself in. I've just finished the first tag in a git repository I've put together to track UNIX developments as documented in the manual. In preparation for this, I also created restorations of the V1 and V2 manuals in roff based on the available V3 sources. The repositories for all this can be found here: https://gitlab.com/segaloco/mandiff https://gitlab.com/segaloco/v1man https://gitlab.com/segaloco/v2man There are most certainly typos and minor discrepancies still to be found between sources and the PDF scans, but given all the cross-referencing involved I believe the manual restorations to be largely complete. As for the mandiff repository, the commit log (which might shake up in format...) should capture relatively complete transactions of either a particular feature or comparable additions, deletions, or modifications. That said, there may be little fixes in later commits of edits that really should've been in other ones, and the toc and index accuracy at any given commit is dubious at best. However, the content of the pages themselves should be pretty well broken up in to noteworthy transactions. If you find a problem or have a correction, feel free to send it my way or even better, open a pull request with an explanation for the change. This repository will accrete more UNIX releases as time goes on, with a first goal being getting to V6, after which the fragmentary pathways will be a little harder to reconcile to a single informative trunk. I might start branches at that point. By the way, in this process I found that the V2 manual scanned by Dennis Ritchie [1] contains references to nroff(I) in the TOC and permuted index, but the page may not have been in his copy. Given this, just to not hang up on it, I simply dropped in the V3 page with a note about this in the BUGS section. 1 - https://www.tuhs.org/Archive/Distributions/Research/Dennis_v2/v2man.pdf - Matt G.

2 years, 3 months

1
0
0 0

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