From lm at mcvoy.com Tue Mar 1 00:07:15 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 28 Feb 2022 06:07:15 -0800 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: <20220228140715.GQ21168@mcvoy.com> So I'm curious, did Plan 9 run on a similar number of architectures and support a similar number of graphics cards? If it did that, nicely, then you have a great point, the X11 people (and most of us) clearly missed a better way to do things. If this is the case, I'd like to understand how you did it because just including different definitions doesn't begin to scratch the surface of what the #ifdefs did in X11, there were tons in the actual code. Maybe the constant system interface made all the difference, that could be. If it supported a much smaller number of targets, well, sure, it's easier to be clean if you have a clean set of targets. I remain grateful for the #ifdefs, I could make enough sense of it all to bring up X11 on every platform I worked on. It wasn't pretty, there was a ton of "I don't recognize this $WHATEVER, what happens if I just #if 0 around the whole thing? Wow, it compiles, lets see if I get a window system. Yep, I do. Shrug." That limited what I had to understand to the much smaller subset of code I was actually going to run, yeah, that set of #ifdefs was a mess but not such a mess that I didn't get a working X11. I'm not arguing that #ifdef is good, I'm just acknowledging it had a lot of benefit to me, and _for me_, the cost was worth it in that instance. I could have X11 working in less than a day. I do get your point about abstracting the interface differences away, I actually hate #ifdefs in the code with a passion so in BitKeeper we had all that stuff buried under the abstractions. We made everything look like Unix, even on Windows, except for fork(). I haven't called fork() directly in close to 20 years, we picked up spawn() and made that work everywhere. The abstraction layer cuts down on the #ifdefs in the code a LOT. On Mon, Feb 28, 2022 at 06:22:28PM +1100, Rob Pike wrote: > Plan 9 had the distinct advantage of a constant system interface at the > source level. X11 did not, but it also made essentially no attempt to > abstract it away, so the lines starting #ifdef often outnumbered the actual > code. I couldn't make hide nor hair of it, and had no way to reliably test > any change. > > C with #ifdefs is not portable, it is a collection of 2^n overlaid > programs, where n is the number of distinct #if[n]def tags. It's too bad > the problems of that approach were not appreciated by the C standard > committee, who mandated the #ifndef guard approach that I'm sure could > count as a provable billion dollar mistake, probably much more. The cost of > building #ifdef'ed code, especially with C++, which decided to be more > fine-grained about it, is unfathomable. > > Google alone might well count for many millions of dollars in wasted > compilation equipment. I remember giving a Plan 9 demo to someone soon > after I got to Google. None of the features of the system were of interest. > The thing that astounded my audience was the ability to build the kernel on > a P90 in 20 seconds or so, and the window system in under 3. At that time, > a build of a Google server would require hours on a large distcc cluster. > > I still shudder to think of it. It's worse now, of course, far worse, but > Google has far larger clusters to handle it and some improvement in > tooling. However, the #ifdefs persist. > > > Tom Cargill warned Bjarne about this around 1984, but the plea fell on deaf > ears. > > -rob > > > On Mon, Feb 28, 2022 at 12:07 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > > > > The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have > > > an answer as to how you would reuse all that code on different hardware > > > in a better way. > > > > Plan 9 did it with #include. The name of the included file was the same for > > every architecture. Only the search path for include files changed. Done > > with > > care, this eliminates the typical upfront #ifdefs.that define constants > > and set > > flags. > > > > Other preprocessor conditionals can usually be replaced by a regular if, > > letting > > the compiler optimize away the unwanted alternative. This makes > > conditionals > > obey the scope rules of C. > > > > Doug > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Tue Mar 1 01:48:56 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Feb 2022 10:48:56 -0500 Subject: [TUHS] Memory on Lion's v6 In-Reply-To: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> References: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> Message-ID: On Mon, Feb 28, 2022 at 12:51 AM Will Senn wrote: > Does anybody know how much memory was configured on the PDP-11 that Lion's > used for the commentary system. Here's what the book says about the system: > > ; from lions, page 1 > ; The code selection presumes a "model" system consisting of: > ; PDP11/40 processor; > ; RK05 disk drives; > ; LP11 line printer; > ; PC11 paper tape reader/punch; > ; KL11 terminal interface. > > I usually add the mag tape, too > ; TM10 magnetic tape - not in lions, but super handy > > It seems like he must have had an MMU and 128k memory, but I don't know. > I'm hoping y'all remember, know, or can otherwise divine the correct value. > I've run with no MMU - crash on boot. I've also run with less memory, but > then cc won't build mkconf, when I have the TM10 enabled kernel loaded. As > a reminder, his book was published in 1977. > > Thanks, > > Will > Can't tell you definitively. You'd need to ask some one like Andrew. FWIW: the 11/40 has a MMU, but does not support split I/D like the 45. He has 256K bytes [128k words] as the Max memory. IIRC v6 will boot with 48K words [96K bytes] - maybe a little less. But the less physical memory, the slower the system (the more it swaps). DEC was just switching to semiconductor memory at the time and it was pretty expensive. The MS11-B was MOS based 18 bit x 4K word modules for the 11/45, which were dual ported Unibus and Fastbus. I have forgotten what the 11/40 used as we tended not to use DEC memory modules***. Lions and his team was likely to have been between 96K and 256K max, depending on budget. In my experience, we tended to build up to max memory on systems, but only as soon as we could afford it. In my experience, we often bought the machines in phases... just enough to boot it, with two or three RK05's to start. Then add more memory and more serial ports and more terminals. Then more (larger) disk and maybe a tape drive and printer, and then even more serial ports and some sort of modems and network connections. Clem *** At CMU during those days, we tended to use aftermarket memory or locally designed memory boards on the 11/40 and 11/34s as EE/CS had negociate and bought a few megabytes of memory chips from National Semi for C.mmp at a heavy discount - other groups could add to that order as needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Mar 1 04:18:30 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 28 Feb 2022 11:18:30 -0700 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: Message-ID: On Sun, Feb 27, 2022 at 6:07 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have > > an answer as to how you would reuse all that code on different hardware > > in a better way. > > Plan 9 did it with #include. The name of the included file was the same for > every architecture. Only the search path for include files changed. Done > with > care, this eliminates the typical upfront #ifdefs.that define constants > and set > flags. > The qemu project does this, for the most part. It makes things a lot easier, but does take some getting used to to find the proper file to be included. It helps a lot to keep the twisty maze of #ifdefs down to a dull roar. FreeBSD (and all the BSDs) has a similar philosophy. You define the page size, for example, of the target, and the rest of the system is written to that abstraction rather than having #ifdefs in a lot of places. NetBSD is much better about keeping the total number of #ifdefs out of MI code than FreeBSD. In both cases, most of the #ifdefs are basically #ifdef __HAS_FUNKY_THING #endif that are needed on a couple of architectures, though usually that idiom is expressed by a macro (that's empty for most platforms) or an inline function. > Other preprocessor conditionals can usually be replaced by a regular if, > letting > the compiler optimize away the unwanted alternative. This makes > conditionals > obey the scope rules of C. > As long as they are always defined... :) Though older gcc/clang compilers get cranky when they view the if expression as a tautology (warning about the idiom rather than encouraging it: stupid clang tricks). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Mar 1 04:47:43 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 28 Feb 2022 13:47:43 -0500 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: <20220228140715.GQ21168@mcvoy.com> References: <20220228140715.GQ21168@mcvoy.com> Message-ID: On Mon, Feb 28, 2022 at 9:10 AM Larry McVoy wrote: > So I'm curious, did Plan 9 run on a similar number of architectures and > support a similar number of graphics cards? > Yes, it did. If it did that, nicely, then you have a great point, the X11 people > (and most of us) clearly missed a better way to do things. If this is > the case, I'd like to understand how you did it because just including > different definitions doesn't begin to scratch the surface of what the > #ifdefs did in X11, there were tons in the actual code. > #ifdef has more or less always struck me as the solution to the wrong problem. "We have all this code and we want to shoehorn it into a new environment," instead of, "we have many environments, so we carefully structure the code to accommodate the differences." Of course, the latter is harder than the former, but it also pays larger dividends over time as compared to the former. Maybe the constant system interface made all the difference, that > could be. > > If it supported a much smaller number of targets, well, sure, it's > easier to be clean if you have a clean set of targets. > In fairness, a meaningful comparison is hard: plan9 ran on ~a dozen different architectures over its lifetime, but never supported near the variety of software or workloads of Unix, and didn't exactly "compete" in the market the way Unix did. The PC port in particular supported oodles of graphics cards at one point, but not as many as X did, mostly because there weren't all that many folks working with the unsupported cards, so there wasn't a lot of motivation to write tons of drivers. Could it have retained its elegantly clean structure over time had things evolved differently? That's impossible to answer, but I'm sad that we never got the chance to find out. I remain grateful for the #ifdefs, I could make enough sense of it > all to bring up X11 on every platform I worked on. It wasn't pretty, > there was a ton of "I don't recognize this $WHATEVER, what happens if > I just #if 0 around the whole thing? Wow, it compiles, lets see if > I get a window system. Yep, I do. Shrug." That limited what I had > to understand to the much smaller subset of code I was actually > going to run, yeah, that set of #ifdefs was a mess but not such > a mess that I didn't get a working X11. > I'm not arguing that #ifdef is good, I'm just acknowledging it had > a lot of benefit to me, and _for me_, the cost was worth it in that > instance. I could have X11 working in less than a day. > I do think that #ifdef, used extremely judiciously, can have some utility: for example, compiling out debug code by setting a constant. Consider: #ifdef NDEBUG const bool DEBUGGING = false; #else const bool DEBUGGING = true; #endif static inline void DBG(const char *fmt, ...) { if (DEBUGGING) { va_list ap; va_start(ap, fmt); vfprintf(stderr, fmt ap); va_end(ap); } } DBG(foo); if `NDEBUG` is defined, then the body of the static inline becomes, `if (0) { ... }` and one hopes our compilers are sufficiently smart to elide the entire thing. The biggest problem with #ifdef wasn't so much that it existed, but rather that it was used for too many things that it wasn't well-suited for. The second biggest problem was that it was semantically unaware of the language; it was purely textual. Bummer. I do get your point about abstracting the interface differences away, > I actually hate #ifdefs in the code with a passion so in BitKeeper we > had all that stuff buried under the abstractions. We made everything > look like Unix, even on Windows, except for fork(). I haven't called > fork() directly in close to 20 years, we picked up spawn() and made that > work everywhere. The abstraction layer cuts down on the #ifdefs in the > code a LOT. > Agreed. But getting those abstractions right requires experience and taste. #ifdef is a blunt took for a nuanced problem. - Dan C. On Mon, Feb 28, 2022 at 06:22:28PM +1100, Rob Pike wrote: > > Plan 9 had the distinct advantage of a constant system interface at the > > source level. X11 did not, but it also made essentially no attempt to > > abstract it away, so the lines starting #ifdef often outnumbered the > actual > > code. I couldn't make hide nor hair of it, and had no way to reliably > test > > any change. > > > > C with #ifdefs is not portable, it is a collection of 2^n overlaid > > programs, where n is the number of distinct #if[n]def tags. It's too bad > > the problems of that approach were not appreciated by the C standard > > committee, who mandated the #ifndef guard approach that I'm sure could > > count as a provable billion dollar mistake, probably much more. The cost > of > > building #ifdef'ed code, especially with C++, which decided to be more > > fine-grained about it, is unfathomable. > > > > Google alone might well count for many millions of dollars in wasted > > compilation equipment. I remember giving a Plan 9 demo to someone soon > > after I got to Google. None of the features of the system were of > interest. > > The thing that astounded my audience was the ability to build the kernel > on > > a P90 in 20 seconds or so, and the window system in under 3. At that > time, > > a build of a Google server would require hours on a large distcc cluster. > > > > I still shudder to think of it. It's worse now, of course, far worse, but > > Google has far larger clusters to handle it and some improvement in > > tooling. However, the #ifdefs persist. > > > > > > Tom Cargill warned Bjarne about this around 1984, but the plea fell on > deaf > > ears. > > > > -rob > > > > > > On Mon, Feb 28, 2022 at 12:07 PM Douglas McIlroy < > > douglas.mcilroy at dartmouth.edu> wrote: > > > > > > The X11 tree was a heavily ifdef-ed. And it needed to be, I don't > have > > > > an answer as to how you would reuse all that code on different > hardware > > > > in a better way. > > > > > > Plan 9 did it with #include. The name of the included file was the > same for > > > every architecture. Only the search path for include files changed. > Done > > > with > > > care, this eliminates the typical upfront #ifdefs.that define constants > > > and set > > > flags. > > > > > > Other preprocessor conditionals can usually be replaced by a regular > if, > > > letting > > > the compiler optimize away the unwanted alternative. This makes > > > conditionals > > > obey the scope rules of C. > > > > > > Doug > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Mar 1 05:25:39 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 28 Feb 2022 14:25:39 -0500 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: <20220228140715.GQ21168@mcvoy.com> Message-ID: On Mon, Feb 28, 2022 at 1:47 PM Dan Cross wrote: > [snip] Oops, I forgot to mention something. I imagine a lot of readers of this list are familiar with this paper, but for those that aren't, this resonates: https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer.pdf On a personal note, when I was learning to write C for Unix, I read a lot of open source code to see how to do it. So much of it was riddled with complex #ifdefs that I kind of got the impression that that was how things were _supposed_ to be written. Then I read the Spencer/Collyer paper, and modified some program that I'd written to use abstract interfaces; it was so much easier to reason about that I was kind of shocked that others didn't do the same. I suppose the point is that many programmers learn by copying what has come before. However, so much of what's out there is a poor example of how to do things; we're stuck with a feedback loop of poor design. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Mar 1 05:26:46 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 28 Feb 2022 14:26:46 -0500 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: <20220228140715.GQ21168@mcvoy.com> Message-ID: On Mon, Feb 28, 2022 at 1:49 PM Dan Cross wrote: > > #ifdef has more or less always struck me as the solution to the wrong > problem. "We have all this code and we want to shoehorn it into a new > environment," instead of, "we have many environments, so we carefully > structure the code to accommodate the differences." Of course, the latter > is harder than the former, but it also pays larger dividends over time as > compared to the former. > Absolutely - but the problem is the development process (more in a minute). > > The biggest problem with #ifdef wasn't so much that it existed, but rather > that it was used for too many things that it wasn't well-suited for. > Agreed. > The second biggest problem was that it was semantically unaware of the > language; it was purely textual. Bummer. > Dan - I'll argue with you on that one actually. One of the reasons why C was successful in a professional language is that it could be easily preprocessed, which other languages like Pascal and even Ada sucked when you tried. There are times when a preprocessor is just really handy as Larry said, particularly in a product programming house. And here is the issue ... Doug and Rob are 100% right about Plan 9 but .. it's not a fair comparison. Plan9 was a research system. X started out as that, but by the time of X11 it was a production system and very different types of programmers. When you are porting code, particularly when under type constraints, Larry described exactly how it's done ... #ifdef NOTDEF ... ok this works.... and off you go the next issue with the product. In my experience, the development process often (tends to) reinforce this behavior. Note I am not telling you that's a good idea ... but *it is a typical behavior* (*a.k.a. *whiskey to teenagers). You intend to go back and redo it, but it never gets done. The next person adds their hack and pretty soon you have the BSD kernel if #ifdef FASTVAXl or #ifdef BIG_ENDIAN scattered all over the code base. As Larry and others have pointed out, an abstraction layer, when you can enforce it, clearly is the best. But to be fair, one of the reasons why C was so popular, is that so much code could be moved. One of the things I hated about Pascal, was that so much code had been written that assumed 36 or 40 integers, or that string limits varied depending on byte or work size and how the len was encoded -- yeech. The problem, as Larry said, is that it is a powerful tool that was easy to and often was, abused by both neophytes and people that should have known better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Mar 1 06:03:22 2022 From: athornton at gmail.com (Adam Thornton) Date: Mon, 28 Feb 2022 13:03:22 -0700 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: <20220228140715.GQ21168@mcvoy.com> Message-ID: >From the Spencer paper: "In such cases,it is important to go back and fix the kludges. The time is not wasted; it is an investment in the future" Yeah, well, that's the problem, isn't it? Investment in the future is not incentivized. The manager needs a win *now* so he can collect his bonus and then leave for someplace that will pay him more. Even as a lowly engineer I've never seen a place where it made financial sense to stick around. You'd never get compensation, authority, and responsibility as fast by being internally promoted as by hopping to the competition across town. If the goal were building a sustainable and maintainable ecosystem, then, sure. But it isn't. Good software engineering doesn't pay. Barfing out a checklist of feature bullet points that marketing wants pays. That does suggest that there's some scope for doing this properly in big Open Source projects--except those, in reality, are almost always driven by a very few large funders, who have particular features they want and are willing to pay for. Shipping those features then becomes the priority, not keeping the codebase manageable. I guess it comes down to "hate the game, not the player" on my part and I'm having a grumpy day. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Tue Mar 1 07:25:25 2022 From: meillo at marmaro.de (markus schnalke) Date: Mon, 28 Feb 2022 22:25:25 +0100 Subject: [TUHS] run commands at login in v6 and stty In-Reply-To: References: <20220228140715.GQ21168@mcvoy.com> Message-ID: <1nOnWH-7qi-00@marmaro.de> Hoi. [2022-02-28 14:25] Dan Cross > > On a personal note, when I was learning to write C for Unix, I read a lot of > open source code to see how to do it. So much of it was riddled with complex # > ifdefs that I kind of got the impression that that was how things were > _supposed_ to be written. Then I read the Spencer/Collyer paper, and modified > some program that I'd written to use abstract interfaces; it was so much easier > to reason about that I was kind of shocked that others didn't do the same. > > I suppose the point is that many programmers learn by copying what has come > before. However, so much of what's out there is a poor example of how to do > things; we're stuck with a feedback loop of poor design. ... and I am very happy that I found my way into a different feedback loop, called Unix philosophy ... with sources meant to be read, great documentation, and books that actually feature real life code (already a thing by itself) but also that the production code is on the same ``acts as a good example'' level. If programmers have never experienced such wonderful worlds -- how poor their programming lifes must be! meillo From andrew at humeweb.com Tue Mar 1 09:27:04 2022 From: andrew at humeweb.com (Andrew Hume) Date: Mon, 28 Feb 2022 15:27:04 -0800 Subject: [TUHS] Memory on Lion's v6 In-Reply-To: References: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> Message-ID: the actual configuration of Lions’ PDP 11/40 was 128 Kbytes of core memory, a DJ11 terminal multiplexor and three RK05 disc units each, but note that because of the way the machines were bought, and because of addressing weirdness (the top 8KB were memory-mapped to I/O registers), Lions’ PDP actually had 112KB of main memory. the PDP 11/40 had 18bits of address space, so while processes were limited to 64KB, the system could have had 256KB. > On Feb 28, 2022, at 7:48 AM, Clem Cole wrote: > > > > On Mon, Feb 28, 2022 at 12:51 AM Will Senn > wrote: > Does anybody know how much memory was configured on the PDP-11 that Lion's used for the commentary system. Here's what the book says about the system: > > ; from lions, page 1 > ; The code selection presumes a "model" system consisting of: > ; PDP11/40 processor; > ; RK05 disk drives; > ; LP11 line printer; > ; PC11 paper tape reader/punch; > ; KL11 terminal interface. > > I usually add the mag tape, too > ; TM10 magnetic tape - not in lions, but super handy > > It seems like he must have had an MMU and 128k memory, but I don't know. I'm hoping y'all remember, know, or can otherwise divine the correct value. I've run with no MMU - crash on boot. I've also run with less memory, but then cc won't build mkconf, when I have the TM10 enabled kernel loaded. As a reminder, his book was published in 1977. > > Thanks, > > Will > > Can't tell you definitively. You'd need to ask some one like Andrew. > > FWIW: the 11/40 has a MMU, but does not support split I/D like the 45. He has 256K bytes [128k words] as the Max memory. IIRC v6 will boot with 48K words [96K bytes] - maybe a little less. But the less physical memory, the slower the system (the more it swaps). > > DEC was just switching to semiconductor memory at the time and it was pretty expensive. The MS11-B was MOS based 18 bit x 4K word modules for the 11/45, which were dual ported Unibus and Fastbus. I have forgotten what the 11/40 used as we tended not to use DEC memory modules***. > > Lions and his team was likely to have been between 96K and 256K max, depending on budget. In my experience, we tended to build up to max memory on systems, but only as soon as we could afford it. In my experience, we often bought the machines in phases... just enough to boot it, with two or three RK05's to start. Then add more memory and more serial ports and more terminals. Then more (larger) disk and maybe a tape drive and printer, and then even more serial ports and some sort of modems and network connections. > > > Clem > > > > *** At CMU during those days, we tended to use aftermarket memory or locally designed memory boards on the 11/40 and 11/34s as EE/CS had negociate and bought a few megabytes of memory chips from National Semi for C.mmp at a heavy discount - other groups could add to that order as needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Mar 1 10:44:22 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Feb 2022 19:44:22 -0500 (EST) Subject: [TUHS] Memory on Lion's v6 Message-ID: <20220301004422.EB7A118C07B@mercury.lcs.mit.edu> > From: Will Senn > Does anybody know how much memory was configured on the PDP-11 that > Lion's used for the commentary system. Here's what the book says about > the system: > .. > ; PDP11/40 processor; > ... > It seems like he must have had an MMU V6 absolutely requires an MMU; the need for it is all throughout basic attributes of the system - e.g. user processes start their address space at 0. (BTW, there are V6 descendants, MINI-UNIX: http://gunkies.org/wiki/MINI-UNIX and LSX, which don't use/need an MMU, and run on -11 models without memory managament, such as -11/05's, but I don't think they were in wide use outside Bell.) > and 128k memory The -11/40, as originally released, only supported the MM11-L, which came in multiples of 16KB (for a 3-board set). Use of the later MM11-U (32KB units) required a new main power harness, which only came in on higher-serial-numbered -11/40's. The -11/40 (as it was at first) that I had at LCS had, to start with, I'm pretty sure, 3 MM11-L units (i.e. one MM11-L backplane full) - i.e. 48KB. I know this sounds incredible, and I'm having a hard time believing it myself, wondering if my memory is failing with age; but it definitely had extraordinarily little. I just looked on my V6 (running in a simulator), and it appears that by trimming all parameters (e.g. number of disk buffers) to the absolute bone, the kernel could be trimmed to about 36KB. (I haven't actually tried it, since I don't feel like recompiling all the kernel modules, but one can estimate it - take the current system size [44KB], delete 10 buffers @ .5KB gives 39KB, etc, etc.) That would allow a maximum user process of 12KB on a 48KB machine - and MINI-UNIX, which runs basically stock V6 user code, can manage with user processes that small. I see Andrew's email which reports that the Lions machine had more main memory, 128KB (maybe 4 MM11-U's - two MM11-U backplanes full); that woould have made their life a lot easier. Noel From bakul at iitbombay.org Tue Mar 1 11:25:09 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 28 Feb 2022 17:25:09 -0800 Subject: [TUHS] Memory on Lion's v6 In-Reply-To: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> References: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> Message-ID: <85538B2F-7FDF-4D97-B7F0-F71977408D8F@iitbombay.org> On Feb 27, 2022, at 9:48 PM, Will Senn wrote: > > It seems like he must have had an MMU and 128k memory, This is covered in the Lions book. For instance On the PDP11/40 the memory management unit consists of two sets of registers for mapping virtual addresses to physical addresses. These are known as “active page registers” or “segmentation registers”. One set is used when the processor is in user mode and the other set, in kernel mode. Changing the contents of these registers changes the details of these mappings. The ability to make these changes is a privilege that the operating system keeps firmly to itself. Also see section 7 and in particular 7.9. And may be more! From andrew at humeweb.com Wed Mar 2 01:31:36 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 1 Mar 2022 07:31:36 -0800 Subject: [TUHS] Memory on Lion's v6 In-Reply-To: References: <4e3c05d2-2496-b917-f1f4-1c6cba9ef58a@gmail.com> Message-ID: <13902322-32C6-4591-9027-A50691146758@humeweb.com> i should also point out that lions would have had access to a PDP 11/70 running with 4MB of main memory at the Australian Graduate School of Management (where i worked for a while after graduating). but i don’t recall him doing anything on that machine. > On Feb 28, 2022, at 3:27 PM, Andrew Hume wrote: > > the actual configuration of Lions’ PDP 11/40 was > 128 Kbytes of core memory, > a DJ11 terminal multiplexor and > three RK05 disc units each, > > but note that because of the way the machines were bought, > and because of addressing weirdness (the top 8KB were memory-mapped to I/O registers), > Lions’ PDP actually had 112KB of main memory. > the PDP 11/40 had 18bits of address space, so while processes were limited > to 64KB, the system could have had 256KB. From paul.winalski at gmail.com Wed Mar 2 02:56:37 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Mar 2022 11:56:37 -0500 Subject: [TUHS] Pipes and PRISM Message-ID: Last week there was a bit of discussion about the different shells that would eventually lead to srb writing the shell that took his name and the command syntax and semantics that most modern shells use today. Some of you may remember, VMS had a command interpreter called DCL (Digital Command language), part of an attempt to make command syntax uniform across DEC's different operating systems (TOPS-20 also used DCL). As DEC started to recognize the value of the Unix marketplace, a project was born in DEC's Commercial Languages and Tools group to bring the Unix Bourne shell to VMS and to sell it as a product they called DEC Shell. I had been part of that effort and one of the issues we had to solve is providing formal UNIX pipe semantics. They of course needed to somehow implement UNIX style process pipelines. VMS from the beginning has had an interprocess communications pseudo-device called the mailbox that can be written to and read from via the usual I/O mechanism (the QIO system service). A large problem with them is that it is not possible to detect the "broken pipe" condition with a mailbox and that feature deficiency made them unsuitable for use with DEC Shell. So the team had me write a new device driver, based closely on the mailbox driver, but that could detect broken pipes lines UNIX-style. Shortly after I finished the VMS pipe driver, the team at DECwest had started work on the MICA project, which was Dave Culter's proposed OS unification. Dave's team had developed a machine architecture called PRISM (Proposed RISC Machine) to be the VAX follow-on. For forward compatibility purposes, PRISM would have to support both Ultrix and VMS. Dave and team had already written a microkernel-based, lightweight OS for VAX called VAXeln that was intended for real-time applications. His new idea was to have a MACH-like microkernel OS which he called MICA and then to put three user mode personality modules on top of that: P.VMS, implementing the VMS system services and ABI P.Ultrix, implementing the Unix system calls and ABI P.TBD, a new OS API and ABI intended to supersede VMS So I wrote the attached "why pipes" memo to explain to Cutler's team why it was important to implement pipes natively in P.TBD if they wanted that OS to be a viable follow-on to VMS and Ultrix. In the end, Dick Sites's 64-bit RISC machine architecture proposal, which was called Alpha, won out over PRISM. Cutler and a bunch of his DECwest engineering team went off to Microsoft. Dave's idea of a microkernel-based OS with multiple personalities of course saw the light of day originally as NT OS/2, but because of the idea of multiple personalities, when Microsoft and IBM divorced Dave was able to quickly pivot to the now infamous Win32 personality, as what would be called Windows NT. It was also easy for Softway Systems to later complete the NT POSIX layer for their Interix product, which now a few generations later is called WSL by Microsoft. -Paul W. -------------- next part -------------- The prime functional characteristics of pipes on Unix are: 1) they are a pseudo-device that can be created on demand by programs 2) communications is one-way, from one or more write channel to one or more read channels 3) if either all read channels or all write channels are deassigned, the other communicating partners are notified via an error condition (Unix calls this "broken pipe"). The last characteristic, detection of broken pipes, is the key. The restriction of pipes to one-way communication is required for broken pipe detection. If there were exactly one reader and one writer, then it would be easy to detect a broken pipe. If the channel count drops to 1, then the pipe is broken. This is how DECnet-VAX detects "network partner exited" conditions. However, because fork(2) can cause the cloning of open I/O channels, this isn't sufficient in the Unix pipe case. One can have multiple readers and multiple writers. It therefore is necessary to restrict each individual I/O channel to be either read-only or write-only. With that restriction in place, the I/O system can detect "broken pipe"--the condition exists when there are readers but no writers, or writers but no readers. VMS mailboxes have most of the characteristics required for pipes. There is a service to create the pseudo-devices from user-mode code. You can have multiple read and write channels. The only problem is that you cannot detect the broken pipe condition. One cannot do this because channels assigned to a mailbox can be used for both reading and writing. There is no way to tell which is which, so one cannot tell when all readers have gone away or when all writers have gone away. This is why I had to write a new driver to support pipes on VMS. The driver was written from scratch, but follows the design of the mailbox driver very closely. Here is a functional summary of the VMS pipe driver. - You create a pipe by assigning a channel to the template device PIPE0:. You get back a single I/O channel to a newly-cloned pipe pseudo-device. You can use $GETDVI to find out the name of the new device so that you can assign other channels to it. The device is created with the characteristics bits MBX, REC, SHR, IDV, ODV, device class DC$_MAILBOX, device type DC$_PIPE. RMS treats it as a mailbox. I opted for dynamic UCB cloning rather than building a $CREPIPE system service to do the cloning. Since I was not in the VMS group, I could not add a system service easily. Also, using dynamic cloning is more flexible. It makes it easy to create pipes from DCL level, for example, whereas it is nearly impossible to create and use mailboxes from DCL level because there is no way to get at $CREMBX from command level. This does mean, though, that one cannot control buffer quota, max. message size, device protection, or assignment of a logical name as part of the device creation call. Max. message size (the UCB device buffer size) and device protection can be set by IO$_SETMODE calls. The pipe driver does not allow for user control of buffer quota (more about that later, though). The device protection set upon cloning is (S,O:RWLP,G,W). This is what you want for communication among child processes in the same job tree, which is the usual application of pipes. - When one initially assigns a channel to a pipe, it is "untyped"--the driver does not know if it is a read or a write channel. The first I/O operation to the channel determines which type of channel it is. If the first operation is IO$_READxBLK (virtual, logical, and physical are all the same for pipes) or IO$_SETMODE!IO$M_WRTATTN, then the channel is a read-only channel. If the first operation is IO$_WRITExBLK or IO$_SETMODE!IO$M_READATTN then the channel becomes a write-only channel. Once the type of a channel has been set, attempts to do the opposite operation (a write to a read channel or a read to a write channel) generate SS$_ILLIOFUNC errors. Sometimes it is desireable to declare the type of a channel before you actually do any I/O to it. The I/O functions IO$_SETMODE!IO$M_READCHAN and IO$_SETMODE!IO$M_WRITECHAN exist for this purpose. - I/O to a pipe is done via the usual IO$_READxBLK, IO$_WRITExBLK, and IO$_WRITEOF function codes. These behave the same way that they do with mailboxes, except that there is no IO$M_NOW modifier (see the next item). The IO$M_READATTN and IO$M_WRTATTN modifiers to IO$_SETMODE are available and function identically with the mailbox driver. There is a IO$M_STREAM modifier to IO$_READxBLK and IO$_WRITExBLK that implements true Unix-style stream-mode I/O (this is the only device in VMS to do this on the $QIO level, in fact). The default is record mode. More about stream mode later. - BUFFERING: Both mailboxes and pipes buffer all in-transit records in non- paged pool. The drivers differ in the quota bookkeeping, however. The mailbox driver grabs a fixed amount of pool quota from the creator of the device at $CREMBX time. The buffer quota is set in the $CREMBX call or defaulted from a SYSGEN parameter. When a program writes to a mailbox, the data are copied into non-paged pool and the buffer quota is decremented accordingly. If the quota reaches zero, then the writing process is put into RWMBX state (if system service resource wait mode is on), or the write failes with SS$_MBFULL status (if system service resource wait mode is off). RWMBX state is quite nasty because it prevents the process from being deleted until and unless somebody empties the mailbox enough to let the write operation complete. However, it does mean that writes to a mailbox never use up process BYTLM quota (the quota having been previously deducted from the creator of the mailbox). I asked several old-time VMS developers and was never able to get a satisfactory explanation or rationalization for the existece of RWMBX state in the system. It seems to cause more harm than good, so I left it out of the pipe driver design. Pipes have a fixed 4096-byte lien on non-paged pool. When a process writes to a pipe, the driver allocates a buffer of the appropriate size from non-paged pool and moves the data into it. If the 4096-byte lien has not been fully used up, then the driver does not deduct any process BYTLM quota from the writer. If the 4096-byte lien has been used up, then the pipe driver deducts the difference from process BYTLM quota--in other words, it is like any run-of-the-mill buffered I/O operation. There is no use of RWMBX state for buffer quota control. - I/O COMPLETION: The normal operation of the mailbox driver is for write operations not to complete until the record was read from the mailbox. One must specify IO$M_NOW if one requires the operation to complete as soon as the data are moved into the mailbox buffer in non-paged pool. Likewise, the mailbox driver provides a IO$M_NOW function for reads to allow a reader to poll mailbox for the presence of messages. The pipe driver does not provide a IO$M_NOW function. A write operation always completes immediately if the message is covered by the 4096-byte lien on non-paged pool. If user proces BYTLM was required to cover all or part of the message, then the write operation does not complete until all of the message is covered by the lien, or until the message is read from the pipe. Thus, a write of a message longer than 4096 bytes will not complete until all but 4096 bytes of it have been read (if mixed record and stream mode I/O is being done, it is possible for messages to be partially read--more about this below). Reads never complete until something has been read. I could have implemented IO$M_NOW, but I chose not to do so. The chosen implementation offers proper quota management (without RWMBX state), and allows for asynchronous operation of the readers and writers in the default I/O case (e.g., RMS I/O), something that doesn't happen with mailboxes. A writer doing RMS I/O to a mailbox stalls until the message is read. With pipes, he does not stall until he gets over 4096 bytes ahead of the reader. The pipe driver design allows efficient processing overlap in pipelines without the need for any special programming. - MAILBOX MODE VS. ULTRIX MODE: In a Unix-style pipeline, several images may be run in succession with their output going down the pipe. RMS thinks the pipe is a mailbox, and so it writes an EOF record to the pipe every time one of the images closes its file on the pipe. In this case, we want to ignore the EOF records and treat the breakage of the pipe at the end of the whole I/O sequence as the EOF condition. However, in "normal" VMS useage, one wants to pass EOF records just as the mailbox driver does. I invented the concept of "Ultrix mode" versus "mailbox mode" to handle this. Pipes are created in VMS mode. The $QIO call IO$_SETMODE!IO$M_ULTRIX places the pipe device in Ultrix mode. IO$M_SETMODE!IO$M_MAILBOX will put it back. There are two differences between the modes: a) In mailbox mode, a IO$_WRITEOF operation puts a EOF record in the pipe. In Ultrix mode, IO$_WRITEOF completes successfully but is a no-op. b) In mailbox mode, reads to a broken pipe terminate with SS$_LINKDISCON status. In Ultrix mode, reads to a broken pipe terminate with SS$_ENDOFFILE status. - BROKEN PIPE NOTIFICATION: The pipe driver keeps counts of the numbers of read and write channels assigned, and two additional state bits: readers- have-existed and writers-have-existed. The readers-have-existed bit is set when the first read channel is assigned. The writers-have-existed bit is set when the first write channel is assigned. A broken pipe condition exists whenever: a) a write operation is pending on the pipe, readers-have-existed is set, but the current count of read channels is zero b) a read operation is pending on the pipe, the pipe is empty, writers-have-existed is set, but the current count of write channels is zero The two "have-existed" bits exist to coordinate startup of the pipe communication. Without those bits, there would be a race condition between the first write to the pipe and the first read to the pipe. It is not an error to be writing to a pipe that has no readers and has never had readers, or to be reading from a pipe that has no writers but has never had writers. There is the potential for a hang condition here if, for example, the reader process dies before it ever gets a chance to open its channel to the pipe. The same potential exists on Unix. In practice, it is not a problem, especially since writes to a pipe cannot put you in a resource-wait state from which there is no exit (RWMBX state). If all writers have exited, readers can continue to read from the pipe without error until they have emptied it. This is necessary so that writers don't have to wait around for all of their data to be read. Reads to a broken pipe complete with SS$_ENDOFFILE status if the pipe has been set in Ultrix mode, or with SS$_LINKDISCON (network partner disconnected logical link) status if the pipe is in mailbox mode (the default). Writes to a broken pipe complete with SS$_LINKDISCON status regardless of mode. - STREAM MODE: The pipe driver provides a modifier, IO$M_STREAM, for both IO$_READxBLK and IO$_WRITExBLK. The presence of the modifier indicates that the I/O operation is to be performed in stream mode rather than in record mode. A stream mode read operation always reads the requested number of bytes from the pipe. It ignores record boundaries. For example, if there are three 10-byte records in the pipe, and a $QIO specifies a 15-byte stream mode read, the first record and the first 5 bytes of the second record will be read and put in the user's buffer as one chunk of data. That will leave the remaining 5 bytes of record 2 and all of record 3 in the pipe. A subsequent $QIO read in record mode will read the 5 bytes of record 2. There is one case where a stream mode read doesn't read exactly the number of bytes that the user specified. That is if end-of-pipe is detected. End-of-pipe is either a EOF record in the pipe, or a broken pipe. In both of these cases, the read in progress terminates with a short byte count. The next read issued picks up the EOF or LINKDISCON condition. This is exactly the Unix semantics for reads from pipes. A stream mode write operation is the same as a record mode write operation except that the write doesn't imply a record boundary. For example, suppose there are three $QIOs specifying stream mode write, each for 5 bytes, followed by two record mode writes, each for 10 bytes. A record mode reader will see two records. The first is 25 bytes long, the second is 10 bytes long. I will send you a copy of the complete pipe driver specification so you can see how this looks in toto. IMPLICATIONS FOR P.TBD INTERPROCESS COMMUNICATION Clearly P.ULTRIX requires Unix-compatible pipes. The driver design outlined above accomplishes this in a way that is compatible with simultaneous use by a record-oriented access method such as RMS. IO$M_STREAM probably isn't necessary: the Ultrix read(2) and write(2) facilities, which are what present a stream mode interface to programs, have to deal with block-oriented devices such as disks and tapes anyway, so they are capable of doing the necessary record blocking and deblocking to make anything appear to be stream-oriented regardless of its underlying record-oriented characteristics. One thing that you get for free with the VMS pipe driver design is that pipes have names. "Named pipes" are a relatively recent innovation in the Unix world and are all the rage these days. It is not as clear that P.VMS needs VAX/VMS-compatible mailboxes. In the vast majority of cases, channels assigned to mailboxes are used either exclusively for reading or exclusively for writing, and therefore pipes would suffice. In fact, use of pipes in place of mailboxes would relieve implementors of all the defensive programming you need with mailboxes to get around the fact that with a mailbox there's no way to tell that the other end of the communications link has gone away. To be conservative, though, it's probably a good idea to provide a mailbox-compatible facility. I think that all of the needs in this space could be addressed by a single I/O facility for interprocess communication. The desireable characteristics are: 1) The pseudo-device object is created by the P.TBD equivalent of dynamic UCB cloning on VAX/VMS. That is, the object is created when an I/O channel is assigned to a template object. It should be possible to get one of these devices without doing an explicit system service call such as SYS$CREMBX or pipe(2). Using dynamic UCB cloning allows the pseudo-devices to be created from command level without any special support (such as a lexical function). 2) The object has two major modes of operation: mailbox mode and pipe mode. Upon creation, the object is in pipe mode. The P.TBD equivalent of a IO$_SETMODE $QIO operation switches the device between mailbox mode and pipe mode. a) In mailbox mode, the device acts like a VAX/VMS mailbox. Channels can be used for either reading or writing. You get no "broken pipe" notification. Operations stall unless a IO$M_NOW modifier is present. b) In pipe mode, the device acts like a Unix pipe. Channels can be used only for reading or writing, but not both. The first operation to a channel determines its type (read-only or write-only). Type can be explicitly declared via a IO$_SETMODE-like call. Broken pipe notification semantics are as for the VAX/VMS pipe driver when operating in Ultrix mode. IO$_WRITEOF is a no-op. IO$M_NOW is ignored--the device always behaves like the VAX/VMS pipe driver as regards stalling. c) The equivalent of IO$M_READATTN and IO$M_WRITEATTN routines should operate the way they do for VAX/VMS mailboxes regardless of mode. These two operations set the mode of the I/O channel. 3) The VMS compatibility library would supply a SYS$CREMBX call that would assign a channel to the pseudo-device template object, put the object in mailbox mode, do IO$_SETMODE-equlvalent calls to set the protection and buffer size characteristics the way the user wanted them, then return the assigned channel to the caller. 4) The P.Ultrix library would supply a pipe(2) call that would assign a channel to the pseudo-device template object, assign another channel to the cloned pipe object, then do a IO$_SETMODE!IO$M_READCHAN-equivalent I/O call to set the first channel read-only, and a IO$M_WRITECHAN- equivalent call to set the second channel write-only. Then it would return both channels to the caller. 5) No equivalent of the RWMBX resource wait state should be provided. If a pipe or mailbox fills, the current I/O operation merely should be stalled. I hope all this stuff is helpful. If there are any specific questions about pipes or mailboxes that I can answer, just ask. --PSW From rich.salz at gmail.com Wed Mar 2 07:25:23 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 1 Mar 2022 16:25:23 -0500 Subject: [TUHS] Pipes and PRISM In-Reply-To: References: Message-ID: The VMS process model is different from Unix; like TOPS-20, it was more a shared address space. I don't remember details, but I do recall that a "logout" call in a DCL script logged you out of the system. Did Softway Systems make kernel changes? I know MSFT's original Posix plan was to do it all in user-space. WSL is a Ubuntu port, so if Softway had kernel changes, I could see how that made things simpler. On Tue, Mar 1, 2022 at 12:05 PM Paul Winalski wrote: > Last week there was a bit of discussion about the different shells > that would eventually lead to srb writing the shell that took his name > and the command syntax and semantics that most modern shells use > today. Some of you may remember, VMS had a command interpreter > called DCL (Digital Command language), part of an attempt to make > command syntax uniform across DEC's different operating systems > (TOPS-20 also used DCL). As DEC started to recognize the value of the > Unix marketplace, a project was born in DEC's Commercial Languages and > Tools group to bring the Unix Bourne shell to VMS and to sell it as a > product they called DEC Shell. > > I had been part of that effort and one of the issues we had to solve > is providing formal UNIX pipe semantics. They of course needed to > somehow implement UNIX style process pipelines. VMS from the > beginning has had an interprocess communications pseudo-device called > the mailbox that can be written to and read from via the usual I/O > mechanism (the QIO system service). A large problem with them is that > it is not possible to detect the "broken pipe" condition with a > mailbox and that feature deficiency made them unsuitable for use with > DEC Shell. So the team had me write a new device driver, based > closely on the mailbox driver, but that could detect broken pipes > lines UNIX-style. > > Shortly after I finished the VMS pipe driver, the team at DECwest had > started work on the MICA project, which was Dave Culter's proposed OS > unification. Dave's team had developed a machine architecture called > PRISM (Proposed RISC Machine) to be the VAX follow-on. For forward > compatibility purposes, PRISM would have to support both Ultrix and > VMS. Dave and team had already written a microkernel-based, > lightweight OS for VAX called VAXeln that was intended for real-time > applications. His new idea was to have a MACH-like microkernel OS > which he called MICA and then to put three user mode personality > modules on top of that: > > P.VMS, implementing the VMS system services and ABI > P.Ultrix, implementing the Unix system calls and ABI > P.TBD, a new OS API and ABI intended to supersede VMS > > So I wrote the attached "why pipes" memo to explain to Cutler's team > why it was important to implement pipes natively in P.TBD if they > wanted that OS to be a viable follow-on to VMS and Ultrix. > > In the end, Dick Sites's 64-bit RISC machine architecture proposal, > which was called Alpha, won out over PRISM. Cutler and a bunch of his > DECwest engineering team went off to Microsoft. Dave's idea of a > microkernel-based OS with multiple personalities of course saw the > light of day originally as NT OS/2, but because of the idea of > multiple personalities, when Microsoft and IBM divorced Dave was able > to quickly pivot to the now infamous Win32 personality, as what would > be called Windows NT. It was also easy for Softway Systems to later > complete the NT POSIX layer for their Interix product, which now a few > generations later is called WSL by Microsoft. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Mar 2 07:38:45 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Mar 2022 13:38:45 -0800 Subject: [TUHS] Pipes and PRISM In-Reply-To: References: Message-ID: <20220301213845.GH7237@mcvoy.com> On Tue, Mar 01, 2022 at 04:25:23PM -0500, Richard Salz wrote: > The VMS process model is different from Unix; like TOPS-20, it was more a > shared address space. I don't remember details, but I do recall that a > "logout" call in a DCL script logged you out of the system. > > Did Softway Systems make kernel changes? I know MSFT's original Posix plan > was to do it all in user-space. WSL is a Ubuntu port, so if Softway had > kernel changes, I could see how that made things simpler. My memory is that the lower level stuff in NT is actually quite pleasant and makes it easy to do POSIX on top. From dave at horsfall.org Wed Mar 2 07:38:56 2022 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 2 Mar 2022 08:38:56 +1100 (EST) Subject: [TUHS] ok-labs.com is not OK Message-ID: Someone on one of these lists seems to be at ok-labs.com; well... aneurin% host ok-labs.com ;; connection timed out; no servers could be reached aneurin% Houston, we have a problem... Could whoever is responsible please sprinkle some fairy dust somewhere? Thanks. -- Dave From clemc at ccc.com Wed Mar 2 07:49:21 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Mar 2022 16:49:21 -0500 Subject: [TUHS] Pipes and PRISM In-Reply-To: References: Message-ID: Very few. They had nt sources. Because of the Unisys law suite against Msft and DEC. Fwiw Dave had defined a hard link link in the file system on disk format but Win32 lacked away to create them. So they had to add that nt call to support it. They also fixed a few bugs but that purely the POSIX layer drive the uk differently and until they pushed it, they had been exposed Dave has started to write the posix.exe sub system but not completed it so they did that of course. But over all nt itself was pretty much as Dave had designed it Remember nt (aka mica) was not designed for windows. Dave never cared what the user interface was. He had fought that war at DEC and mica was his answer as Paul mentioned Eventually Msft bought softway and created the SFU product. When Linux took off they cancelled it and. It the deal with canonical who helped them with WSL. Btw Steve Walli gave a great USENIX talk on the whole softway/interix experience at some point. He had some choice comments which decorum will not allow me to repeat here. On Tue, Mar 1, 2022 at 4:32 PM Richard Salz wrote: > The VMS process model is different from Unix; like TOPS-20, it was more a > shared address space. I don't remember details, but I do recall that a > "logout" call in a DCL script logged you out of the system. > > Did Softway Systems make kernel changes? I know MSFT's original Posix plan > was to do it all in user-space. WSL is a Ubuntu port, so if Softway had > kernel changes, I could see how that made things simpler. > > > On Tue, Mar 1, 2022 at 12:05 PM Paul Winalski > wrote: > >> Last week there was a bit of discussion about the different shells >> that would eventually lead to srb writing the shell that took his name >> and the command syntax and semantics that most modern shells use >> today. Some of you may remember, VMS had a command interpreter >> called DCL (Digital Command language), part of an attempt to make >> command syntax uniform across DEC's different operating systems >> (TOPS-20 also used DCL). As DEC started to recognize the value of the >> Unix marketplace, a project was born in DEC's Commercial Languages and >> Tools group to bring the Unix Bourne shell to VMS and to sell it as a >> product they called DEC Shell. >> >> I had been part of that effort and one of the issues we had to solve >> is providing formal UNIX pipe semantics. They of course needed to >> somehow implement UNIX style process pipelines. VMS from the >> beginning has had an interprocess communications pseudo-device called >> the mailbox that can be written to and read from via the usual I/O >> mechanism (the QIO system service). A large problem with them is that >> it is not possible to detect the "broken pipe" condition with a >> mailbox and that feature deficiency made them unsuitable for use with >> DEC Shell. So the team had me write a new device driver, based >> closely on the mailbox driver, but that could detect broken pipes >> lines UNIX-style. >> >> Shortly after I finished the VMS pipe driver, the team at DECwest had >> started work on the MICA project, which was Dave Culter's proposed OS >> unification. Dave's team had developed a machine architecture called >> PRISM (Proposed RISC Machine) to be the VAX follow-on. For forward >> compatibility purposes, PRISM would have to support both Ultrix and >> VMS. Dave and team had already written a microkernel-based, >> lightweight OS for VAX called VAXeln that was intended for real-time >> applications. His new idea was to have a MACH-like microkernel OS >> which he called MICA and then to put three user mode personality >> modules on top of that: >> >> P.VMS, implementing the VMS system services and ABI >> P.Ultrix, implementing the Unix system calls and ABI >> P.TBD, a new OS API and ABI intended to supersede VMS >> >> So I wrote the attached "why pipes" memo to explain to Cutler's team >> why it was important to implement pipes natively in P.TBD if they >> wanted that OS to be a viable follow-on to VMS and Ultrix. >> >> In the end, Dick Sites's 64-bit RISC machine architecture proposal, >> which was called Alpha, won out over PRISM. Cutler and a bunch of his >> DECwest engineering team went off to Microsoft. Dave's idea of a >> microkernel-based OS with multiple personalities of course saw the >> light of day originally as NT OS/2, but because of the idea of >> multiple personalities, when Microsoft and IBM divorced Dave was able >> to quickly pivot to the now infamous Win32 personality, as what would >> be called Windows NT. It was also easy for Softway Systems to later >> complete the NT POSIX layer for their Interix product, which now a few >> generations later is called WSL by Microsoft. >> >> -Paul W. >> > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry at jon.es Wed Mar 2 07:51:41 2022 From: terry at jon.es (Terry Jones) Date: Tue, 01 Mar 2022 21:51:41 +0000 Subject: [TUHS] Lorinda Cherry In-Reply-To: <202202220002.21M02d4g023128@cuzuco.com> References: <202202220002.21M02d4g023128@cuzuco.com> Message-ID: <9B4B0854-92D1-4DAC-A0C2-8782F1587326@jon.es> I’m also a fan of dc, and still a daily user after 40 years (not much in this group, I know, but a pretty good chunk of my life at least). To get more functionality, I wrote a Python RPN calculator (with some key bindings identical to dc). It makes 300+ functions from standard Python libraries directly available and you can push Python objects and functions onto the stack. See https://github.com/terrycojones/rpnpy Terry From: TUHS on behalf of Brian Walden Reply to: Brian Walden Date: Tuesday, 22. February 2022 at 01:02 To: Subject: [TUHS] Lorinda Cherry I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt calculator was an HP-45 (circa 1973) RPN felt right. However I think dc pre-dates ALL HP calculators, since there was one in the 1st Edition written in assembly. I extened my version of dc (way before gnu existed) based on common buttons I used from HP calculators: CMD WHAT # comment, to new line ~ change sign of top of stack (CHS key) | 1/top of stack (1/x key) e push 99 digits of e (2.718..) on the stack @ push 99 digits of pi on the stack (looks like a circle) r reverse top of stack (x<>y key) I had been fascinated with pi stemimg from the Star Trek epsiode Wolf in the Fold where Spock uses it to usa all computing power "Computer, this is a Class A compulsory directive. Compute to the last digit the value of pi." "As we know, the value of pi is a transcendental figure without resolution. The computer banks will work on this problem to the exclusion of all else until we order it to stop." As it was supposed to be "arbitrary precision" here was my tool. So I wrote Machin formula in dc slowing increasing the scale and printing the results. In the orginal dc, yes the whole part was arbitrary, but the decimal part (scale) was limited to 99. Well that became a disappiontment. (this program is lost to time) So I decided to rewrite it but increasing pi as a whole numbers instead of increasing scale (ex. 31415, 314159, 3141592, ... etc) I still have that program which is simply this -- [sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ 1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx if you run it you'll notice the last 1 to 2 digits are wrong due to precision. The next problem became small memory. I still have thes saved output before it crashed at 1024 digits. No idea what specs of the machine it was run on anymore its really old -- 3141592653589793238462643383279502884197169399375105820974944592307816\ 4062862089986280348253421170679821480865132823066470938446095505822317\ 2535940812848111745028410270193852110555964462294895493038196442881097\ 5665933446128475648233786783165271201909145648566923460348610454326648\ 2133936072602491412737245870066063155881748815209209628292540917153643\ 6789259036001133053054882046652138414695194151160943305727036575959195\ 3092186117381932611793105118548074462379962749567351885752724891227938\ 1830119491298336733624406566430860213949463952247371907021798609437027\ 7053921717629317675238467481846766940513200056812714526356082778577134\ 2757789609173637178721468440901224953430146549585371050792279689258923\ 5420199561121290219608640344181598136297747713099605187072113499999983\ 7297804995105973173281609631859502445945534690830264252230825334468503\ 5261931188171010003137838752886587533208381420617177669147303598253490\ 4287554687311595628638823537875937519577818577805321712268066130019278\ 76611195909216420198938095257201065485862972 out of space: salloc all 8587356 rel 8587326 headmor 1 nbytes -28318 stk 71154 rd 125364 wt 125367 beg 125364 last 125367 83 11 0 30 IOT trap - core dumped But I was much happier with that. On a side note: programming dc is hard. There was no comment character. And it's a pain to read, and it's a pain to debug. When I discovered the Chudnovsky algorithm for pi, of course I implemented it in dc -- [0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP 7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx At 99 digits of scale it ran out in 7 rounds, but now with that limitation removed and large memeories it just goes on and on..... -Brian PS: Thanks for the fast OpenBSD version of dc, Otto. Otto Moerbeek wrote: > On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote: > >> On Feb 17, 2022, at 1:18 PM, Dave Horsfall wrote: > >> > > >> > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > >> > > >> >> Watching the prime number generator (from the Wikipedia page on dc) > >> >> running on the 11/23 is much more entertaining than doing it on the > >> >> modern workstation I'm typing this on: > >> >> > >> >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > >> > > >> > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > >> > FreeBSD box. > >> > >> That may be because FreeBSD continues computing primes while the MacOS > >> dc gives up after a while! > >> > >> freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while > >> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > >> ^C 11.93 real 11.79 user 0.13 sys > >> $ wc xxx > >> 47161 47161 319109 xxx > >> $ size `which dc` > >> text data bss dec hex filename > >> 238159 2784 11072 252015 0x3d86f /usr/bin/dc > >> > >> MacOS (m1 pro, prob. 2Ghz) > >> $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx > >> time: command terminated abnormally > >> 1.00 real 0.98 user 0.01 sys > >> [2] 37135 segmentation fault command time dc <<< > xxx > >> $ wc xxx > >> 7342 7342 42626 xxx > >> $ size `which dc` > >> __TEXT __DATA __OBJC others dec hex > >> 32768 16384 0 4295016448 4295065600 100018000 > >> > > MacOS uses the GNU implementation which has a long standing issue with > > deep recursion. It even cannot handle the tail recursive calls used > > here and will run out of its stack. > > -Otto -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Mar 2 08:09:51 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Mar 2022 17:09:51 -0500 Subject: [TUHS] Pipes and PRISM In-Reply-To: References: Message-ID: Btw look at Mach if you want to understand nt. The Mach and Nt tasks are very lightweight and primitive so you can build much more complex processes from them On Tue, Mar 1, 2022 at 4:49 PM Clem Cole wrote: > Very few. They had nt sources. Because of the Unisys law suite against > Msft and DEC. Fwiw Dave had defined a hard link link in the file system > on disk format but Win32 lacked away to create them. So they had to add > that nt call to support it. They also fixed a few bugs but that purely > the POSIX layer drive the uk differently and until they pushed it, they had > been exposed > > Dave has started to write the posix.exe sub system but not completed it so > they did that of course. But over all nt itself was pretty much as Dave > had designed it > > Remember nt (aka mica) was not designed for windows. Dave never cared > what the user interface was. He had fought that war at DEC and mica was > his answer as Paul mentioned > > Eventually Msft bought softway and created the SFU product. When Linux > took off they cancelled it and. It the deal with canonical who helped them > with WSL. > > Btw Steve Walli gave a great USENIX talk on the whole softway/interix > experience at some point. He had some choice comments which decorum will > not allow me to repeat here. > > On Tue, Mar 1, 2022 at 4:32 PM Richard Salz wrote: > >> The VMS process model is different from Unix; like TOPS-20, it was more a >> shared address space. I don't remember details, but I do recall that a >> "logout" call in a DCL script logged you out of the system. >> >> Did Softway Systems make kernel changes? I know MSFT's original Posix >> plan was to do it all in user-space. WSL is a Ubuntu port, so if Softway >> had kernel changes, I could see how that made things simpler. >> >> >> On Tue, Mar 1, 2022 at 12:05 PM Paul Winalski >> wrote: >> >>> Last week there was a bit of discussion about the different shells >>> that would eventually lead to srb writing the shell that took his name >>> and the command syntax and semantics that most modern shells use >>> today. Some of you may remember, VMS had a command interpreter >>> called DCL (Digital Command language), part of an attempt to make >>> command syntax uniform across DEC's different operating systems >>> (TOPS-20 also used DCL). As DEC started to recognize the value of the >>> Unix marketplace, a project was born in DEC's Commercial Languages and >>> Tools group to bring the Unix Bourne shell to VMS and to sell it as a >>> product they called DEC Shell. >>> >>> I had been part of that effort and one of the issues we had to solve >>> is providing formal UNIX pipe semantics. They of course needed to >>> somehow implement UNIX style process pipelines. VMS from the >>> beginning has had an interprocess communications pseudo-device called >>> the mailbox that can be written to and read from via the usual I/O >>> mechanism (the QIO system service). A large problem with them is that >>> it is not possible to detect the "broken pipe" condition with a >>> mailbox and that feature deficiency made them unsuitable for use with >>> DEC Shell. So the team had me write a new device driver, based >>> closely on the mailbox driver, but that could detect broken pipes >>> lines UNIX-style. >>> >>> Shortly after I finished the VMS pipe driver, the team at DECwest had >>> started work on the MICA project, which was Dave Culter's proposed OS >>> unification. Dave's team had developed a machine architecture called >>> PRISM (Proposed RISC Machine) to be the VAX follow-on. For forward >>> compatibility purposes, PRISM would have to support both Ultrix and >>> VMS. Dave and team had already written a microkernel-based, >>> lightweight OS for VAX called VAXeln that was intended for real-time >>> applications. His new idea was to have a MACH-like microkernel OS >>> which he called MICA and then to put three user mode personality >>> modules on top of that: >>> >>> P.VMS, implementing the VMS system services and ABI >>> P.Ultrix, implementing the Unix system calls and ABI >>> P.TBD, a new OS API and ABI intended to supersede VMS >>> >>> So I wrote the attached "why pipes" memo to explain to Cutler's team >>> why it was important to implement pipes natively in P.TBD if they >>> wanted that OS to be a viable follow-on to VMS and Ultrix. >>> >>> In the end, Dick Sites's 64-bit RISC machine architecture proposal, >>> which was called Alpha, won out over PRISM. Cutler and a bunch of his >>> DECwest engineering team went off to Microsoft. Dave's idea of a >>> microkernel-based OS with multiple personalities of course saw the >>> light of day originally as NT OS/2, but because of the idea of >>> multiple personalities, when Microsoft and IBM divorced Dave was able >>> to quickly pivot to the now infamous Win32 personality, as what would >>> be called Windows NT. It was also easy for Softway Systems to later >>> complete the NT POSIX layer for their Interix product, which now a few >>> generations later is called WSL by Microsoft. >>> >>> -Paul W. >>> >> -- > Sent from a handheld expect more typos than usual > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Wed Mar 2 09:36:42 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 1 Mar 2022 18:36:42 -0500 Subject: [TUHS] Time for a subject change In-Reply-To: <9B4B0854-92D1-4DAC-A0C2-8782F1587326@jon.es> References: <202202220002.21M02d4g023128@cuzuco.com> <9B4B0854-92D1-4DAC-A0C2-8782F1587326@jon.es> Message-ID: This thread has long since diverged from Lorinda and her death. I'm fine with a discussion of some of Lorinda's work, but let's talk about bc or dc in a separate thread that has nothing to do with Lorinda. On Tue, Mar 1, 2022 at 5:06 PM Terry Jones wrote: > I’m also a fan of dc, and still a daily user after 40 years (not much in > this group, I know, but a pretty good chunk of my life at least). > > > > To get more functionality, I wrote a Python RPN calculator (with some key > bindings identical to dc). It makes 300+ functions from standard Python > libraries directly available and you can push Python objects and functions > onto the stack. See https://github.com/terrycojones/rpnpy > > > > Terry > > > > *From: *TUHS on behalf of Brian Walden < > tuhs at cuzuco.com> > *Reply to: *Brian Walden > *Date: *Tuesday, 22. February 2022 at 01:02 > *To: * > *Subject: *[TUHS] Lorinda Cherry > > > > I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt > > calculator was an HP-45 (circa 1973) RPN felt right. However I think > > dc pre-dates ALL HP calculators, since there was one in the 1st Edition > > written in assembly. > > > > I extened my version of dc (way before gnu existed) > > based on common buttons I used from HP calculators: > > > > CMD WHAT > > # comment, to new line > > ~ change sign of top of stack (CHS key) > > | 1/top of stack (1/x key) > > e push 99 digits of e (2.718..) on the stack > > @ push 99 digits of pi on the stack (looks like a circle) > > r reverse top of stack (x<>y key) > > > > I had been fascinated with pi stemimg from the Star Trek epsiode Wolf > > in the Fold where Spock uses it to usa all computing power > > > > "Computer, this is a Class A compulsory directive. Compute to > > the last digit the value of pi." > > > > "As we know, the value of pi is a transcendental figure without > > resolution. The computer banks will work on this problem to the > > exclusion of all else until we order it to stop." > > > > As it was supposed to be "arbitrary precision" here was my tool. > > > > So I wrote Machin formula in dc slowing increasing the scale and printing > > the results. In the orginal dc, yes the whole part was arbitrary, but the > > decimal part (scale) was limited to 99. Well that became a disappiontment. > > (this program is lost to time) > > > > So I decided to rewrite it but increasing pi as a whole numbers instead > > of increasing scale (ex. 31415, 314159, 3141592, ... etc) > > > > I still have that program which is simply this -- > > > > [sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ > > 1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx > > > > > > if you run it you'll notice the last 1 to 2 digits are wrong due to > precision. > > > > The next problem became small memory. I still have thes saved output before > > it crashed at 1024 digits. No idea what specs of the machine it was run > > on anymore its really old -- > > > > 3141592653589793238462643383279502884197169399375105820974944592307816\ > > 4062862089986280348253421170679821480865132823066470938446095505822317\ > > 2535940812848111745028410270193852110555964462294895493038196442881097\ > > 5665933446128475648233786783165271201909145648566923460348610454326648\ > > 2133936072602491412737245870066063155881748815209209628292540917153643\ > > 6789259036001133053054882046652138414695194151160943305727036575959195\ > > 3092186117381932611793105118548074462379962749567351885752724891227938\ > > 1830119491298336733624406566430860213949463952247371907021798609437027\ > > 7053921717629317675238467481846766940513200056812714526356082778577134\ > > 2757789609173637178721468440901224953430146549585371050792279689258923\ > > 5420199561121290219608640344181598136297747713099605187072113499999983\ > > 7297804995105973173281609631859502445945534690830264252230825334468503\ > > 5261931188171010003137838752886587533208381420617177669147303598253490\ > > 4287554687311595628638823537875937519577818577805321712268066130019278\ > > 76611195909216420198938095257201065485862972 > > out of space: salloc > > all 8587356 rel 8587326 headmor 1 > > nbytes -28318 > > stk 71154 rd 125364 wt 125367 beg 125364 last 125367 > > 83 11 0 > > 30 IOT trap - core dumped > > > > > > But I was much happier with that. > > > > On a side note: programming dc is hard. There was no comment character. > > And it's a pain to read, and it's a pain to debug. > > > > When I discovered the Chudnovsky algorithm for pi, of course I implemented > it > > in dc -- > > > > > [0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP > > 7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx > > > > At 99 digits of scale it ran out in 7 rounds, but now with that limitation > > removed and large memeories it just goes on and on..... > > > > -Brian > > > > PS: Thanks for the fast OpenBSD version of dc, Otto. > > > > Otto Moerbeek wrote: > > On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote: > > > > > On Feb 17, 2022, at 1:18 PM, Dave Horsfall wrote: > > > > > > > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote: > > > > > > > >> Watching the prime number generator (from the Wikipedia page on dc) > > > >> running on the 11/23 is much more entertaining than doing it on the > > > >> modern workstation I'm typing this on: > > > >> > > > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x > > > > > > > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient > > > > FreeBSD box. > > > > > > That may be because FreeBSD continues computing primes while the MacOS > > > dc gives up after a while! > > > > > > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while > > > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > > xxx > > > ^C 11.93 real 11.79 user 0.13 sys > > > $ wc xxx > > > 47161 47161 319109 xxx > > > $ size `which dc` > > > text data bss dec hex filename > > > 238159 2784 11072 252015 0x3d86f /usr/bin/dc > > > > > > MacOS (m1 pro, prob. 2Ghz) > > > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > > xxx > > > time: command terminated abnormally > > > 1.00 real 0.98 user 0.01 sys > > > [2] 37135 segmentation fault command time dc <<< > xxx > > > $ wc xxx > > > 7342 7342 42626 xxx > > > $ size `which dc` > > > __TEXT __DATA __OBJC others dec hex > > > 32768 16384 0 4295016448 4295065600 100018000 > > > > > > > MacOS uses the GNU implementation which has a long standing issue with > > deep recursion. It even cannot handle the tail recursive calls used > > here and will run out of its stack. > > > > -Otto > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silas8642 at hotmail.co.uk Wed Mar 2 09:42:42 2022 From: silas8642 at hotmail.co.uk (silas poulson) Date: Tue, 1 Mar 2022 23:42:42 +0000 Subject: [TUHS] Pipes and PRISM In-Reply-To: References: Message-ID: <2DB72891-BF8E-4084-8678-AC6FDCFCB2BB@hotmail.co.uk> > On 1 Mar 2022, at 21:49, Clem Cole wrote: > Btw Steve Walli gave a great USENIX talk on the whole softway/interix > experience at some point. He had some choice comments which decorum > will not allow me to repeat here. Would you possibly link to talk? I’m having trouble finding recording of it. Thanks, Silas From clemc at ccc.com Wed Mar 2 11:18:59 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Mar 2022 20:18:59 -0500 Subject: [TUHS] Pipes and PRISM In-Reply-To: <2DB72891-BF8E-4084-8678-AC6FDCFCB2BB@hotmail.co.uk> References: <2DB72891-BF8E-4084-8678-AC6FDCFCB2BB@hotmail.co.uk> Message-ID: Don’t think it was put on line. It was a long time ago. I want to say 1998ish. On Tue, Mar 1, 2022 at 6:42 PM silas poulson wrote: > > On 1 Mar 2022, at 21:49, Clem Cole wrote: > > Btw Steve Walli gave a great USENIX talk on the whole softway/interix > > experience at some point. He had some choice comments which decorum > > will not allow me to repeat here. > > > Would you possibly link to talk? I’m having trouble finding recording of > it. > > Thanks, > Silas -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Mar 2 11:19:59 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 1 Mar 2022 20:19:59 -0500 (EST) Subject: [TUHS] Memory on Lion's v6 Message-ID: <20220302011959.0B3D818C087@mercury.lcs.mit.edu> > From: Andrew Hume > the actual configuration of Lions; PDP 11/40 was > 128 Kbytes of core memory > ... > but note that because ... of addressing weirdness (the top 8KB were > memory-mapped to I/O registers), Lions' PDP actually had 112KB of main > memory I think that '112KB' must be an error; the 8KB for the 'I/O page' (as DEC eventually named ir, long after the rest of the world had started using the term :-) were deducted from the _UNIBUS_ address space, meaning a UNIBUS -11 (the 'pure' UNIBUS -11's, i.e. other than the -11/70, -11/44, etc) could have a maximum of 248KB of main memory (which is on the UNIBUS). A pure UNIBUS -11 with 128KB of main memory (like Lions') has... 128KB of main memory. The 'small memory management model' -11's (like the /40, /60, /23, etc) can use at most 64KB of that _at any moment in time_ for user processes (i.e. directly accessible by the CPU, in 'user' mode). (The kernel on such machines is basically retricted to 56KB at any moment in time, since one 'segment/page' - the terminology changed over time - has to be dedicated to the I/O page: the memory management control registers are in that, so once the CPU can no longer 'see' them, it's stuck. Long, potentially interesting digression about, and ways to semi-work around that, elided, unless people want to hear it.) > From: Noel Chiappa > The -11/40 (as it was at first) that I had at LCS had, to start with, > I'm pretty sure, 3 MM11-L units .. - i.e. 48KB. I know this sounds > incredible, and I'm having a hard time believing it myself, wondering > if my memory is failing with age It is: # size /lib/c0 13440+2728+10390=26558 (63676) ('c1' takes 14848+6950+2088=23886, FWIW.) So 'my' -11/40 must have had more than 48KB. MINI-UNIX provides, on an -11/05 type machine with the maximum of 56KB of addressable main memory (if you plugged in 64KB worth, the /05 CPU couldn't 'see' the top 8KB of that), up to 32KB for a user process. So that will just hold the stock V6 C compiler. I'm not now sure how much memory my -11 _did_ have initially, but it's not important. Noel From imp at bsdimp.com Wed Mar 2 12:15:43 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 1 Mar 2022 19:15:43 -0700 Subject: [TUHS] Memory on Lion's v6 In-Reply-To: <20220302011959.0B3D818C087@mercury.lcs.mit.edu> References: <20220302011959.0B3D818C087@mercury.lcs.mit.edu> Message-ID: On Tue, Mar 1, 2022, 6:23 PM Noel Chiappa wrote: > > From: Andrew Hume > > > the actual configuration of Lions; PDP 11/40 was > > 128 Kbytes of core memory > > ... > > but note that because ... of addressing weirdness (the top 8KB were > > memory-mapped to I/O registers), Lions' PDP actually had 112KB of > main > > memory > > I think that '112KB' must be an error; the 8KB for the 'I/O page' (as DEC > eventually named ir, long after the rest of the world had started using the > term :-) were deducted from the _UNIBUS_ address space, meaning a UNIBUS > -11 > (the 'pure' UNIBUS -11's, i.e. other than the -11/70, -11/44, etc) could > have > a maximum of 248KB of main memory (which is on the UNIBUS). > > A pure UNIBUS -11 with 128KB of main memory (like Lions') has... 128KB of > main memory. The 'small memory management model' -11's (like the /40, /60, > /23, etc) can use at most 64KB of that _at any moment in time_ for user > processes (i.e. directly accessible by the CPU, in 'user' mode). > > (The kernel on such machines is basically retricted to 56KB at any moment > in > time, since one 'segment/page' - the terminology changed over time - has > to be > dedicated to the I/O page: the memory management control registers are in > that, so once the CPU can no longer 'see' them, it's stuck. Long, > potentially > interesting digression about, and ways to semi-work around that, elided, > unless people want to hear it.) > > > > From: Noel Chiappa > > > The -11/40 (as it was at first) that I had at LCS had, to start with, > > I'm pretty sure, 3 MM11-L units .. - i.e. 48KB. I know this sounds > > incredible, and I'm having a hard time believing it myself, wondering > > if my memory is failing with age > > It is: > > # size /lib/c0 > 13440+2728+10390=26558 (63676) > > ('c1' takes 14848+6950+2088=23886, FWIW.) So 'my' -11/40 must have had more > than 48KB. > > MINI-UNIX provides, on an -11/05 type machine with the maximum of 56KB of > addressable main memory (if you plugged in 64KB worth, the /05 CPU couldn't > 'see' the top 8KB of that), up to 32KB for a user process. So that will > just hold the stock V6 C compiler. > You made a comment that MINI-UNIX wasn't available outside of Bell... I meant to say that the AUUG newsletters talk about it. It features a letter asking for users of it to share patches. There was also an article about how to get it, though it was an offer to spin a tape for a photocopy of you Western Electric license... Warner I'm not now sure how much memory my -11 _did_ have initially, but it's not > important. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Mar 2 12:26:09 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 1 Mar 2022 21:26:09 -0500 (EST) Subject: [TUHS] Memory on Lion's v6 Message-ID: <20220302022609.B6EF718C095@mercury.lcs.mit.edu> > You made a comment that MINI-UNIX wasn't available outside of Bell... No, I didn't say that. What I _actually_ said was: "don't think they were in wide use outside Bell". Noel PS: Can I appeal to people to please take a few seconds of their time and trim messages they are replying to? Thank you. From paul.winalski at gmail.com Thu Mar 3 04:51:21 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 2 Mar 2022 13:51:21 -0500 Subject: [TUHS] Pipes and PRISM In-Reply-To: References: Message-ID: On 3/1/22, Clem Cole wrote: > Btw look at Mach if you want to understand nt. The Mach and Nt tasks are > very lightweight and primitive so you can build much more complex processes > from them > That's correct, Dave Cutler was very impressed by Mach's microkernel idea and used it to implement VAXeln, a VAX OS for real-time applications (VMS had grown too heavyweight to properly support real-time). He used the same design for MICA and later NT. Cutler had a lot of fights with the Windows developers. They were used to MS-DOS, where there was a single application running with no memory protection, so it could do whatever it pleased as long as it left the system in a usable state when it exited. Windows did cooperative multitasking and it was common practice to insert hooks to intercept system events and procedures. Cutler told them, no, there will be no hooks into the NT privileged kernel--use the system service calls provided by the NT API. Over time, the NT microkernel and the layers on top of it have become less distinct, but the original concept of a microkernel with personality modules on top of it remains. That idea came from Mach. -Paul W. From wkt at tuhs.org Thu Mar 3 07:18:24 2022 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 3 Mar 2022 07:18:24 +1000 Subject: [TUHS] Brenda Baker's Struct Memo Message-ID: <20220302211824.GA12460@minnie.tuhs.org> All, I've just placed this document at https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstruct.pdf Many thanks to Doug for passing it on! Cheers, Warren ----- Forwarded message from Douglas McIlroy ----- Warren, Someone asked if Brenda Baker's original technical memorandum about struct is available. I scanned my copy and passed it on, secure in my belief that the Labs won't care since it is essentially the same as her journal publication. For the memo to be genuinely available, I'd like to send it to TUHS. With that in mind I redacted information about corporate organization and distribution channels. However the memo still bears the AT&T logo and the words "not for publication". Doug ----- End forwarded message ----- From beebe at math.utah.edu Thu Mar 3 07:44:38 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 2 Mar 2022 14:44:38 -0700 Subject: [TUHS] Brenda Baker's Struct Memo Message-ID: Thanks to Doug and Warren for getting Brenda Baker's memo on struct online at https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstruct.pdf She later published a formal article about that work in An Algorithm for Structuring Flowgraphs Journal of the Association for Computing Machinery 24(1) 98--120 January 1977 https://doi.org/10.1145/321992.321999 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From arnold at skeeve.com Thu Mar 3 20:22:43 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 03 Mar 2022 03:22:43 -0700 Subject: [TUHS] Brenda Baker's Struct Memo In-Reply-To: <20220302211824.GA12460@minnie.tuhs.org> References: <20220302211824.GA12460@minnie.tuhs.org> Message-ID: <202203031022.223AMh5E019690@freefriends.org> I have added this to the Git repo. Doug and Warren, much thanks! Arnold Warren Toomey wrote: > All, I've just placed this document at > https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstruct.pdf > > Many thanks to Doug for passing it on! > Cheers, Warren > > ----- Forwarded message from Douglas McIlroy ----- > > Warren, > > Someone asked if Brenda Baker's original technical memorandum about > struct is available. I scanned my copy and passed it on, secure in my > belief that the Labs won't care since it is essentially the same as > her journal publication. > > For the memo to be genuinely available, I'd like to send it to TUHS. > With that in mind I redacted information about corporate organization > and distribution channels. However the memo still bears the AT&T logo > and the words "not for publication". > > Doug > > ----- End forwarded message ----- From kevin.bowling at kev009.com Mon Mar 7 11:02:44 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 6 Mar 2022 18:02:44 -0700 Subject: [TUHS] Documenter's Workbench versions Message-ID: I am reading some UNIX text processing books and am interested in the lineage of Documenter's Workbench. I see documentation of 1.0 (i.e https://archive.org/details/sysv-dwb/page/n5/mode/2up) I see a copy of 2.0 for 3B2 (i.e. https://archives.loomcom.com/3b2/software/Documenters_Workbench/) >From there things get a little less clear, it seems like we jump to 3.2 with SysVR3.2? Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3 One of my books from the late 80s references 3.4 available as a source code purchase independent of UNIX. Then it appears SGI might have had a 4.x strain? (i.e. https://archive.org/details/sgi_Documenters_Workbench_4.1.3) Heirloom is derived from OpenSolaris which is derived from? Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what (I extracted the image, the relnotes inside might as well not exist). Regards, Kevin From lm at mcvoy.com Mon Mar 7 12:42:27 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 6 Mar 2022 18:42:27 -0800 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: <20220307024227.GA25878@mcvoy.com> I can't help with the history but I give you a thumbs up for trying to track it down. The Documenter's Workbench is sort of the unsung hero of Unix. It is why Unix exists, Unix was done to write patents and troff and the Documenter's Workbench was all about that. On Sun, Mar 06, 2022 at 06:02:44PM -0700, Kevin Bowling wrote: > I am reading some UNIX text processing books and am interested in the > lineage of Documenter's Workbench. > > I see documentation of 1.0 (i.e > https://archive.org/details/sysv-dwb/page/n5/mode/2up) > I see a copy of 2.0 for 3B2 (i.e. > https://archives.loomcom.com/3b2/software/Documenters_Workbench/) > > >From there things get a little less clear, it seems like we jump to > 3.2 with SysVR3.2? > > Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3 > > One of my books from the late 80s references 3.4 available as a source > code purchase independent of UNIX. > > Then it appears SGI might have had a 4.x strain? (i.e. > https://archive.org/details/sgi_Documenters_Workbench_4.1.3) > > Heirloom is derived from OpenSolaris which is derived from? > > Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what > (I extracted the image, the relnotes inside might as well not exist). > > Regards, > Kevin -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jaapna at xs4all.nl Mon Mar 7 23:28:29 2022 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Mon, 7 Mar 2022 14:28:29 +0100 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: > I see documentation of 1.0 (i.e > https://archive.org/details/sysv-dwb/page/n5/mode/2up) > I see a copy of 2.0 for 3B2 (i.e. > https://archives.loomcom.com/3b2/software/Documenters_Workbench/) > > From there things get a little less clear, it seems like we jump to > 3.2 with SysVR3.2? The jump might be due to the effect that for quite a while outside AT&T it was marketed by SoftQuad (Toronto). (See also ). jaap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From kevin.bowling at kev009.com Tue Mar 8 02:55:03 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 7 Mar 2022 09:55:03 -0700 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: Interesting. That sounds like a different commercial strain, "SoftQuad was started in order to improve automated typesetting at Toronto's Coach House Press, and for many years developed an enhanced commercial version of the text formatting program troff, developed under license from AT&T, called sqtroff. It was sold with a suite of associated programs, corresponding to AT&T's Documenter's Workbench, under the name SoftQuad Publishing Software (SQPS)." On Mon, Mar 7, 2022 at 6:28 AM Jaap Akkerhuis wrote: > > > > > I see documentation of 1.0 (i.e > > https://archive.org/details/sysv-dwb/page/n5/mode/2up) > > I see a copy of 2.0 for 3B2 (i.e. > > https://archives.loomcom.com/3b2/software/Documenters_Workbench/) > > > > From there things get a little less clear, it seems like we jump to > > 3.2 with SysVR3.2? > > The jump might be due to the effect that for quite a while outside > AT&T it was marketed by SoftQuad (Toronto). (See also > ). > > jaap > From kevin.bowling at kev009.com Tue Mar 8 06:57:02 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 7 Mar 2022 13:57:02 -0700 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: On Sun, Mar 6, 2022 at 6:02 PM Kevin Bowling wrote: > > I am reading some UNIX text processing books and am interested in the > lineage of Documenter's Workbench. > > I see documentation of 1.0 (i.e > https://archive.org/details/sysv-dwb/page/n5/mode/2up) > I see a copy of 2.0 for 3B2 (i.e. > https://archives.loomcom.com/3b2/software/Documenters_Workbench/) > > From there things get a little less clear, it seems like we jump to > 3.2 with SysVR3.2? > > Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3 > > One of my books from the late 80s references 3.4 available as a source > code purchase independent of UNIX. > > Then it appears SGI might have had a 4.x strain? (i.e. > https://archive.org/details/sgi_Documenters_Workbench_4.1.3) > > Heirloom is derived from OpenSolaris which is derived from? http://heirloom.sourceforge.net/doctools/troff.pdf has this particular history, interestingly it seems to be divergent from 2.x and not 3.x. > Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what > (I extracted the image, the relnotes inside might as well not exist). > > Regards, > Kevin From grog at lemis.com Tue Mar 8 14:13:41 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 8 Mar 2022 15:13:41 +1100 Subject: [TUHS] "Applications for UnixWare" available online Message-ID: <20220308041341.GG73556@eureka.lemis.com> Decades ago (mid 1993) I produced a CD-ROM with free software for Novell's UnixWare entitled "Applications for UnixWare". This was at Novell's request, and they distributed the CDs at trade shows. There's nothing very special in the CD, but I recently received a request for it, so I put it up with a minimal description at http://www.lemis.com/grog/Software/Applications-for-UnixWare.php Feel free to copy it (with attribution). Greg -- Sent from my desktop computer. Finger grog at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Wed Mar 9 12:06:42 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 8 Mar 2022 21:06:42 -0500 Subject: [TUHS] Documenter's Workbench versions Message-ID: > The Documenter's Workbench is sort of the unsung hero > of Unix. It is why Unix exists, Unix was done to write patents and > troff and the Documenter's Workbench was all about that. My response along the following lines seems to have gone astray. The prime reason for Unix was the desire of Ken, Dennis, and Joe Ossanna to have a pleasant environment for software development. The fig leaf that got the nod from Multics-burned management was that an early use would be to develop a "stand-alone" word-processing system for use in typing pools and secretarial offices. Perhaps they had in mind "dedicated", as distinct from "stand-alone"; that's what eventuated in various cases, most notably in the legal/patent department and in the AT&T CEO's office. Both those systems were targets of opportunity, not foreseen from the start. When Unix was up and running on the PDP-11, Joe got wind of the legal department having installed a commercial word processor. He went to pitch Unix as an alternative and clinched a trial by promising to make roff able to number lines by tomorrow in order to fulfill a patent-office requirement that the commercial system did not support. Modems were installed so legal-department secretaries could try the Research machine. They liked it and Joe's superb customer service. Soon the legal department got a system of their own. Joe went on to create nroff and troff. Document preparation became a widespread use of Unix, but no stand-alone word-processing system was ever undertaken. Doug From jaapna at xs4all.nl Wed Mar 9 19:41:54 2022 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Wed, 9 Mar 2022 10:41:54 +0100 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: > On Mar 9, 2022, at 3:06, Douglas McIlroy wrote: > > > Document preparation became a widespread use > of Unix, but no stand-alone word-processing system was ever undertaken. I do seem to remember an attempt by some outfit to sell a standalone word processors based on troff, but U don't remember the name. It wasn't a success and failed very quickly. jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From dillera at gmail.com Thu Mar 10 08:30:14 2022 From: dillera at gmail.com (Andrew Diller) Date: Wed, 9 Mar 2022 17:30:14 -0500 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: <512E256C-9AC5-4E0A-8AFF-58EB2CC56EDB@gmail.com> This image on IA installs fine on IRIX 5.x and has a number of binaries and fonts that I assume are used for making nice documentation. https://i.imgur.com/tpCPniW.jpg https://i.imgur.com/rWSmMsg.jpg lrwxr-xr-x 1 root sys 12 Mar 9 14:08 mvt -> /usr/bin/mmt -rwxr-xr-x 1 root sys 31760 Mar 9 14:08 macref -rwxr-xr-x 1 root sys 14304 Mar 9 14:08 hyphen -rwxr-xr-x 1 root sys 111768 Mar 9 14:08 grap -rwxr-xr-x 1 root sys 18592 Mar 9 14:08 makedev -rwxr-xr-x 1 root sys 2993 Mar 9 14:08 mm -rwxr-xr-x 1 root sys 1736 Mar 9 14:08 mmt -rwxr-xr-x 1 root sys 78808 Mar 9 14:08 eqn -rwxr-xr-x 1 root sys 68456 Mar 9 14:08 checkmm -rwxr-xr-x 1 root sys 62328 Mar 9 14:08 daps -rwxr-xr-x 1 root sys 117512 Mar 9 14:08 checkmm1 -rwxr-xr-x 1 root sys 62424 Mar 9 14:08 di10 -rwxr-xr-x 1 root sys 961 Mar 9 14:08 diffmk -rwxr-xr-x 1 root sys 78872 Mar 9 14:08 tbl -rwxr-xr-x 1 root sys 1508 Mar 9 14:08 subj -r-xr-xr-x 1 root sys 2313 Mar 9 14:08 vgrind -rwxr-xr-x 1 root sys 41768 Mar 9 14:08 tc -rwxr-xr-x 1 root sys 152976 Mar 9 14:08 troff -rwxr-xr-x 1 root sys 146088 Mar 9 14:08 pic -rwxr-xr-x 1 root sys 4743 Mar 9 14:08 ndx -rwxr-xr-x 1 root sys 61560 Mar 9 14:08 neqn -rwxr-xr-x 1 root sys 148432 Mar 9 14:08 nroff -rwxr-xr-x 1 root sys 23048 Mar 9 14:08 ptx -rwxr-xr-x 1 root sys 14304 Mar 9 14:08 soelim I'm not familiar enough with dwb to know what to start with.... -andy > On Mar 7, 2022, at 3:57 PM, Kevin Bowling wrote: > > On Sun, Mar 6, 2022 at 6:02 PM Kevin Bowling wrote: > >> Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what >> (I extracted the image, the relnotes inside might as well not exist). >> >> Regards, >> Kevin From kevin.bowling at kev009.com Thu Mar 10 10:44:47 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 9 Mar 2022 17:44:47 -0700 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: <512E256C-9AC5-4E0A-8AFF-58EB2CC56EDB@gmail.com> References: <512E256C-9AC5-4E0A-8AFF-58EB2CC56EDB@gmail.com> Message-ID: On Wed, Mar 9, 2022 at 3:30 PM Andrew Diller wrote: > > This image on IA installs fine on IRIX 5.x and has a number of binaries and fonts that I assume are used for making nice documentation. > > https://i.imgur.com/tpCPniW.jpg > https://i.imgur.com/rWSmMsg.jpg > > > lrwxr-xr-x 1 root sys 12 Mar 9 14:08 mvt -> /usr/bin/mmt > -rwxr-xr-x 1 root sys 31760 Mar 9 14:08 macref > -rwxr-xr-x 1 root sys 14304 Mar 9 14:08 hyphen > -rwxr-xr-x 1 root sys 111768 Mar 9 14:08 grap > -rwxr-xr-x 1 root sys 18592 Mar 9 14:08 makedev > -rwxr-xr-x 1 root sys 2993 Mar 9 14:08 mm > -rwxr-xr-x 1 root sys 1736 Mar 9 14:08 mmt > -rwxr-xr-x 1 root sys 78808 Mar 9 14:08 eqn > -rwxr-xr-x 1 root sys 68456 Mar 9 14:08 checkmm > -rwxr-xr-x 1 root sys 62328 Mar 9 14:08 daps > -rwxr-xr-x 1 root sys 117512 Mar 9 14:08 checkmm1 > -rwxr-xr-x 1 root sys 62424 Mar 9 14:08 di10 > -rwxr-xr-x 1 root sys 961 Mar 9 14:08 diffmk > -rwxr-xr-x 1 root sys 78872 Mar 9 14:08 tbl > -rwxr-xr-x 1 root sys 1508 Mar 9 14:08 subj > -r-xr-xr-x 1 root sys 2313 Mar 9 14:08 vgrind > -rwxr-xr-x 1 root sys 41768 Mar 9 14:08 tc > -rwxr-xr-x 1 root sys 152976 Mar 9 14:08 troff > -rwxr-xr-x 1 root sys 146088 Mar 9 14:08 pic > -rwxr-xr-x 1 root sys 4743 Mar 9 14:08 ndx > -rwxr-xr-x 1 root sys 61560 Mar 9 14:08 neqn > -rwxr-xr-x 1 root sys 148432 Mar 9 14:08 nroff > -rwxr-xr-x 1 root sys 23048 Mar 9 14:08 ptx > -rwxr-xr-x 1 root sys 14304 Mar 9 14:08 soelim > > > I'm not familiar enough with dwb to know what to start with.... It's basically a marketing name for troff and some macro packages. You could try feeding some of these https://github.com/n-t-roff/DWB3.3/tree/master/doc through it to see how it works, although depending on what 4.x really is it may be a bit of a learning experience. Aside from the man pages and official documentation, a lot of popular books were and still are written with it https://www.troff.org/pubs.html > -andy > > > > On Mar 7, 2022, at 3:57 PM, Kevin Bowling wrote: > > > > On Sun, Mar 6, 2022 at 6:02 PM Kevin Bowling wrote: > > > >> Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what > >> (I extracted the image, the relnotes inside might as well not exist). > >> > >> Regards, > >> Kevin > From boomer3200 at gmail.com Thu Mar 10 11:10:59 2022 From: boomer3200 at gmail.com (Dan Plassche) Date: Wed, 9 Mar 2022 20:10:59 -0500 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: On Sun, Mar 6, 2022 at 6:02 PM Kevin Bowling wrote: > > I see a copy of 2.0 for 3B2 (i.e. > https://archives.loomcom.com/3b2/software/Documenters_Workbench/) > > From there things get a little less clear, it seems like we jump to > 3.2 with SysVR3.2? > > Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3 > > Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what > (I extracted the image, the relnotes inside might as well not exist). > > Regards, > Kevin I'd be interested to pin down the timeline and the major feature changes for DWB in relation to the other troff variants as well. Below is a summary of my understanding from looking at the changelogs and spot checking the various codebases. Any additions or corrections would be appreciated. 1979 v7 C/A/T troff released (rewritten from assembler into C) 1980-81 v7 C/A/T troff pulled into System III internally at Bell Labs seemingly without major changes and released in 1982 1982 public domain typesetter independent troff (ditroff or titroff) was the last free release as a standalone set of files on request 1983 SVR1 bundled C/A/T troff from 1981 1984 SVR2 containing DWB 2.0 incorporating ditroff (no postscript output yet though) 1987 SVR3 unbundled all troff versions and offered DWB 2+ as an add-on package 1988 postscript output added to DWB 2+ 1989 SVR4 bundled DWB 2+ (Solaris and Unixware) with changes through mid-1988 198907 DWB 3.0 changed font tables to ascii from old binary format 199004 DWB 3.1 retired nroff for monolithic troff binary with -a flag for simplified ascii output (for example, tables are not formatted for true hardcopy output in ascii format) I think sqtroff from Softquad was primarily sold from 1987-88 and the main enhancement was more detailed error tracing with an improved ditroff output language including early laserjet and postscript support. I've only seen mentions of sqtroff 2.x releases in that timeframe. I've been looking for the Softquad documentation and software without much luck; apparently James Clark had a copy of the Technical Reference manual (ISBN 0-88910-326-7) that he used to write groff. Best, Dan Plassche From dillera at gmail.com Thu Mar 10 12:17:54 2022 From: dillera at gmail.com (Andrew Diller) Date: Wed, 9 Mar 2022 21:17:54 -0500 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: <512E256C-9AC5-4E0A-8AFF-58EB2CC56EDB@gmail.com> Message-ID: <283C2A81-4F64-4644-A836-D359E85492E5@gmail.com> Thanks for the info. I managed to delve into the release notes for this package on IRIX. Seems like IRIX has a really nice tool called strangely enough 'relnotes' which will parse and show the release notes like man pages. Here are some snippets from the DWB: ------------ Software Option Product Documenter's Workbench Version 4.1.3 Product Code SC4-DWB-4.1.3 System Software Requirements IRIX 5.3 or later ------------ However they do mention this: ------------- 1.3 Product_Support Silicon Graphics, Inc., provides a comprehensive product support maintenance program for its products. If you are in North America and would like support for your Silicon Graphics-supported products, contact the Technical Assistance Center at 1-800-800-4SGI. If you are outside North America, contact the Silicon Graphics subsidiary or authorized distributor in your country. --------------- But they may not answer :) -andy > On Mar 9, 2022, at 7:44 PM, Kevin Bowling wrote: > > > It's basically a marketing name for troff and some macro packages. > You could try feeding some of these > https://github.com/n-t-roff/DWB3.3/tree/master/doc through it to see > how it works, although depending on what 4.x really is it may be a bit > of a learning experience. > > Aside from the man pages and official documentation, a lot of popular > books were and still are written with it > https://www.troff.org/pubs.html > From oz at silentrunning.ca Fri Mar 11 03:21:05 2022 From: oz at silentrunning.ca (ozan yigit) Date: Thu, 10 Mar 2022 12:21:05 -0500 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: This is accurate. I was briefly involved with sqtroff, because it was brought to York U by one of the founders (david slocombe) to publish York's newsletter. see this for coach house press history. possibly the first (outside bell) unix-based publisher. https://publishing.sfu.ca/2015/12/coach-house-press-early-digital-period/ ... oz On Mon, Mar 7, 2022, at 11:55 AM, Kevin Bowling wrote: > Interesting. That sounds like a different commercial strain, "SoftQuad > was started in order to improve automated typesetting at Toronto's > Coach House Press, and for many years developed an enhanced commercial > version of the text formatting program troff, developed under license > from AT&T, called sqtroff. It was sold with a suite of associated > programs, corresponding to AT&T's Documenter's Workbench, under the > name SoftQuad Publishing Software (SQPS)." > > On Mon, Mar 7, 2022 at 6:28 AM Jaap Akkerhuis wrote: > > > > > > > > > I see documentation of 1.0 (i.e > > > https://archive.org/details/sysv-dwb/page/n5/mode/2up) > > > I see a copy of 2.0 for 3B2 (i.e. > > > https://archives.loomcom.com/3b2/software/Documenters_Workbench/) > > > > > > From there things get a little less clear, it seems like we jump to > > > 3.2 with SysVR3.2? > > > > The jump might be due to the effect that for quite a while outside > > AT&T it was marketed by SoftQuad (Toronto). (See also > > ). > > > > jaap > > > ozan s. yigit http://nextbit.blogspot.com *to live fully is to wage constant battle against the mundane.* -- guy tal -------------- next part -------------- An HTML attachment was scrubbed... URL: From amonakov at ispras.ru Sat Mar 12 18:00:54 2022 From: amonakov at ispras.ru (Alexander Monakov) Date: Sat, 12 Mar 2022 11:00:54 +0300 (MSK) Subject: [TUHS] pcc struct return quirk Message-ID: Hello, I'm trying to understand a quirk in 32-bit x86 code generation conventions: on Linux, when returning a structure from a function by value: struct S { int i, j; }; struct S f(int x) { return (struct S){x, sizeof(void*)}; } the caller reserves space for the returned structure and passes a pointer to that space as an 'invisible' extra argument, which is prepended to the argument list; the callee returns this pointer (although the caller knows it anyway); it's as if the function is transformed to struct S *f(struct S *ret, int x) { ret->i = x; ret->j = sizeof(void*); return ret; } with one essential difference: the function 'f' itself is responsible for popping the extra argument off the stack (the 'x' argument is popped by its caller). This necessitates using the return-with-immediate ('ret 4') instruction instead of the normal 'ret'; this is the only instance where this variant of the 'ret' instruction is used in code generation for C programs on Linux normally. I wonder how this exception came to be. Early versions of GCC (e.g. gcc-1.27) did not implement this convention, i.e. the caller was responsible for popping the invisible pointer similar to the normal arguments. The "callee-pops" variant was implemented later for "compatibility with other compilers", and the option that controls this is called -fpcc-struct-return, which also disables returning small structures in registers (in the example above GCC would return the value in EDX:EAX register pair). Operating systems differ on following this convention. For example, FreeBSD and OpenBSD do not, and neither does Windows. Looking at 386BSD tree in unix-history-repo, I see that it used GCC, not PCC. Where can I look at the history of x86 code generation development in PCC? Do I understand correctly that i386 code generation in PCC evolved in parallel with GCC, and at some point GCC was convinced to adopt the (less efficient) PCC calling convention by default? Did PCC prefer to do this stack adjustment for the invisible pointer on the callee side for some other platform, and the behavior was merely carried over to the i386 port? Thank you. Alexander From athornton at gmail.com Sun Mar 13 14:43:51 2022 From: athornton at gmail.com (Adam Thornton) Date: Sat, 12 Mar 2022 21:43:51 -0700 Subject: [TUHS] [PiDP-11] Fun with Fortran on the PiDP-11 In-Reply-To: References: <458c38a5-584e-4280-b239-87ec9fc2d933n@googlegroups.com> <223b2bdf-d9fe-2665-1928-fcacfbf0df44@softjar.se> <59d64292-27a9-40d1-a4b5-47851cf47557n@googlegroups.com> <412e00f8-0b2b-4637-838a-5bee04a247b3n@googlegroups.com> <90526a51-cbaf-4179-bbb4-f3d031d68519n@googlegroups.com> <6ae062ff-ca71-4f1e-9acb-dcf909f6f52en@googlegroups.com> <6eda2dc2-9138-4dbc-8490-09c5c2f648f4n@googlegroups.com> Message-ID: <79BCFAD2-EFAD-4DAA-90F0-DED7699D61FA@gmail.com> > On Mar 12, 2022, at 2:02 PM, Rob Pike wrote: > > Indeed. Be careful about the code Numerical Recipes if you are doing > important numerical work. > For simple stuff it's fine, of course, but floating point is a > minefield that requires expert navigation. > > -rob That's the seductive trap of floating-point numbers, isn't it? They invite us to think about them as if they were the real numbers, but they are very, very much *not* the real numbers. And yet, most of the time, for most applications, if you treat them as if they were, you get plausible results. Adam From wkt at tuhs.org Sun Mar 13 15:24:40 2022 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 13 Mar 2022 15:24:40 +1000 Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: <20220313052440.GA26092@minnie.tuhs.org> On Sun, Mar 06, 2022 at 06:02:44PM -0700, Kevin Bowling wrote: > I am reading some UNIX text processing books and am interested in the > lineage of Documenter's Workbench. Ozan Yigit just gave me a copy of DWB 1.0 to add to the Unix Archive: https://www.tuhs.org/Archive/Applications/Documenters_Workbench I have a complete distro of dwb. was obtained by me while I was at the Dept. of Computer Science at York University to drive our Imagen laser printer. The content is simply man pages and sources. Nothing else was included in the tape. (no long copyright notice etc). Whatever paperwork we had filled to get the tape probably lost in the paper clippings of time. The files indicate this is "DOCUMENTER'S WORKBENCH 1.0". The file dates are from 1986, but I don't recall when we actually requested the tape. Cheers, Warren From boomer3200 at gmail.com Mon Mar 14 10:17:15 2022 From: boomer3200 at gmail.com (Dan Plassche) Date: Sun, 13 Mar 2022 20:17:15 -0400 (EDT) Subject: [TUHS] Documenter's Workbench versions In-Reply-To: References: Message-ID: <97175b9e-32ea-f29-ebdd-bab065b72e3f@.local> Following-up with a correction and some details about user-facing changes in Documenter's Workbench. > > 1984 SVR2 containing DWB 2.0 incorporating ditroff (no postscript > output yet though) My mistake. I was glancing at a late copy of the 3B2 SVR2 source with DWB 2.0 and should have written 1.0 here. DWB 1.0 was released in 1984 at the same time as SVR2. Changes from v7 troff are the inclusion of ditroff as troff, C/A/T troff as otroff, the mm macros, pic, and sroff. The sroff command provided a faster simplified interpreter for line printer output. > 1987 SVR3 unbundled all troff versions and offered DWB 2+ as > an add-on package DWB 2.0 was released in 1986. This verison added grap and the mptx indexing macros while removing otroff and sroff. Elan eroff for DOS and sqtroff were based on DWB 2. DWB 2+ was generally available after 1987 as an optional binary add-on package at added cost. SVR4 troff included the postscript output formatter added to the codebase in mid-1988 (tracked in Research UNIX v9), but not grap. > 198907 DWB 3.0 changed font tables to ascii from old binary format > > 199004 DWB 3.1 retired nroff for monolithic troff binary with -a flag > for simplified ascii output (for example, tables are not formatted > for true hardcopy output in ascii format) 199202 DWB 3.2 was released with mpm macros for automatic vertical page justification, 8-bit clean i/o, and picasso visual line drawing interface using the OPEN LOOK toolkit 199207 DWB 3.3 contained a new version of tbl and the mpm macro package to customize postscript color and page formats 199311 DWB 3.4 with new spell check, dwb command to guess processor pipeline, postscript file layout tools, and X11 viewers (xhbt for eqn/pic/tbl figures and dwbman for hypertext navigation of manpages) I hope this is a helpful summary. I've been working on a more detailed timeline tracking the versions shipped by different UNIX vendors. Also testing C/A/T troff to postscript converters (Adobe transcript, Chris Lewis' psroff, and jetroff) to approximate older output in comparison to the excellent heirloom doctools. Thanks, Dan Plassche From beebe at math.utah.edu Mon Mar 14 22:58:24 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 14 Mar 2022 06:58:24 -0600 Subject: [TUHS] [tuhs] PDP-11 and early Unix Message-ID: Although the story is well known to members of this list, there is a nice compact history of the PDP-11 and early Unix at this new article: A brief tour of the PDP-11, the most influential minicomputer of all time https://arstechnica.com/gadgets/2022/03/a-brief-tour-of-the-pdp-11-the-most-influential-minicomputer-of-all-time/ It describes PDP-11 assembly language, and shows the booting of a Unix system on a simh instance. It also includes the famous picture of Dennis and Ken at a PDP-11 console, and concludes with a link to an online text of a book about PDP-11 assembly language programming. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From ron at ronnatalie.com Tue Mar 15 00:59:07 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 14 Mar 2022 14:59:07 +0000 Subject: [TUHS] [tuhs] PDP-11 and early Unix In-Reply-To: References: Message-ID: Amusingly, the picture at the top of the article is not of any real PDP-11. It's one of the PiDP-11 simulations. I've got one just like it sitting on my desk here (running 2.9 bsd mocked up to look like an old JHU/BRL UNIX). From clemc at ccc.com Tue Mar 15 01:13:00 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 14 Mar 2022 11:13:00 -0400 Subject: [TUHS] [tuhs] PDP-11 and early Unix In-Reply-To: References: Message-ID: Nelson - thank you. nice article. FYI: I just passed it on the number of the folks that had a bit to do with the 11 at DEC. On Mon, Mar 14, 2022 at 11:07 AM Ron Natalie wrote: > Amusingly, the picture at the top of the article is not of any real PDP-11. > Yep - I smiled like you did. > It's one of the PiDP-11 simulations. I've got one just like it sitting > on my desk here (running 2.9 bsd mocked up to look like an old JHU/BRL > UNIX). > I tend to leave mine running V7, but it can boot a number of systems. My PiDP-8 is running DOS-11, but admit I want to get that running TSS-8, but is has an issue I have not had the time to chance down. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Mar 15 02:56:04 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 14 Mar 2022 12:56:04 -0400 (EDT) Subject: [TUHS] [tuhs] PDP-11 and early Unix Message-ID: <20220314165604.4889918C075@mercury.lcs.mit.edu> > From: "Nelson H. F. Beebe" > there is a nice compact history of the PDP-11 and early Unix at this > new article: Not a bad artcle, but it had a number of minor errors, which I found irritating. They should have gotten an expert to proof it. Here are some: registers could access any other register - as well as memory or direct data - using one of the six different addressing modes I think 'instruction' may have been meant for the first "register"; as written it makes on sense. (Unlike the PDP-10, in the PDP-11, a register can't address another register.) Oh, and there are eight addressing modes. use of labels instead of hard-coded addresses makes it easier to program and makes the code relocatable in memory I'm not sure whether the writer knows the difference between 'PC-relative addressing' (a PDP-11 feature; code that will run at any address, without _any_ changes to the binary) and 'relocatable binary (which uses labels, as he describes). - but is not PDP-11 specific. The program counter can be accessed like any of the other registers ... The program counter is intended to support jump, branching, and other control flow instructions. Uh, no. It's not clear _exactly_ what was meant here, but... having the PC as a general register is for PC-relative addressing of operands, immediate data, and absolute addressing of operands. Jumps, branches, etc don't use the fact that the PC is a general register. These are the key advantages of assembly programming over high-level languages - assembler code always runs faster and uses less memory. Not really, with modern compilers. The number above represents -2. A commenter caught this one. Just use a $ to represent a decimal number In UNIX assembler, "$" means 'immediate data'; a trailing "." means decimal. And a tip of the hatly hat for getting this: Although the ++ and - operators in C are equivalents of DEC and INC instructions, they were inspired by an addressing mode in the PDP-7. right. Noel From clemc at ccc.com Tue Mar 15 04:00:32 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 14 Mar 2022 14:00:32 -0400 Subject: [TUHS] [tuhs] PDP-11 and early Unix In-Reply-To: <20220314165604.4889918C075@mercury.lcs.mit.edu> References: <20220314165604.4889918C075@mercury.lcs.mit.edu> Message-ID: On Mon, Mar 14, 2022 at 12:59 PM Noel Chiappa wrote: > > > Not a bad artcle, but it had a number of minor errors, which I found > irritating. > They should have gotten an expert to proof it. > Sure - but usually these are way more bad than good. Usually way too much urban legend, so I'm thrilled to see the 11 kept alive. > > And a tip of the hatly hat for getting this: > > Although the ++ and - operators in C are equivalents of DEC and INC > instructions, they were inspired by an addressing mode in the PDP-7. > As I said, the authors seem to have done a little homework, although I was under the impression ??Ken?? had created them for B independently (which, of course, was first on the PDP-7). The ++/-- for increment and decrement was just a nice notation since they are such a common occurrence in real code, it's handy to have. But, I did not think the PDP-7 ISA includes addressing modes in the same manner as the 11. I'm probably confused, but I thought PDP-7 is a very simple instruction (and small) with an AC, Link/Indirection and a PC - it reminded me of the PDP-8 more than anything else [although, IIRC it could do both 1's complement and 2's - depending the type of AND instruction]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Tue Mar 15 05:03:08 2022 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 14 Mar 2022 20:03:08 +0100 Subject: [TUHS] [tuhs] PDP-11 and early Unix In-Reply-To: References: <20220314165604.4889918C075@mercury.lcs.mit.edu> Message-ID: On 14/03/22, Clem Cole wrote: > > > > And a tip of the hatly hat for getting this: > > > > Although the ++ and - operators in C are equivalents of DEC and INC > > instructions, they were inspired by an addressing mode in the PDP-7. > > > As I said, the authors seem to have done a little homework, although I was > under the impression ??Ken?? had created them for B independently (which, > of course, was first on the PDP-7). The ++/-- for increment and decrement > was just a nice notation since they are such a common occurrence in real > code, it's handy to have. But, I did not think the PDP-7 ISA includes > addressing modes in the same manner as the 11. I'm probably confused, but > I thought PDP-7 is a very simple instruction (and small) with an AC, > Link/Indirection and a PC - it reminded me of the PDP-8 more than anything > else [although, IIRC it could do both 1's complement and 2's - depending > the type of AND instruction]. The PDP-7 has auto-increment registers at 10-17 that are incremented when addressed indirectly. I don't think it's even possible that the B runtime used them, because of the implied indirection, which is logically separate in B. They might still have been an inspiration, but i didn't get that impression from the copious discussion of that topic. aap From jnc at mercury.lcs.mit.edu Tue Mar 15 06:22:53 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 14 Mar 2022 16:22:53 -0400 (EDT) Subject: [TUHS] [tuhs] PDP-11 and early Unix Message-ID: <20220314202253.2CAFD18C083@mercury.lcs.mit.edu> > From: Clem Cole > I'm thrilled to see the 11 kept alive. Ditto. The most elegant archtecture ever, IMO. > I was under the impression ??Ken?? had created them for B > independently (which, of course, was first on the PDP-7). "The Development of the C Language", by Dennis M. Ritchie: https://www.bell-labs.com/usr/dmr/www/chist.html says: The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1. Note the "probably"; unless Ken remembers, and says something, that's probably the best we are going to get. > I did not think the PDP-7 ISA includes addressing modes in the same > manner as the 11. .. I thought PDP-7 is a very simple instruction (and > small) with an AC, Link/Indirection and a PC - it reminded me of the > PDP-8 more than anything else The PDP-4, -7 and -9 are all the same architecture (very similar to the PDP-1, but simplified a bit), differing only in implementation. (Most PDP-7 code will run on a -9, un-modified.) Basic instructions look like: Instructions had a 4-bit opcode ('000'-'054'), 1 bit of indirect, and 13 bits of address. It was a load-store architecture, with a single accumulator. So, yes, similar to an -8. There are other opcodes for non-memory operations ('074' opcode), and I/O ('070'), using bits in the 'address' field. ('060' opcodes were for the optional EAE.) All of the -4/-7/-9 had the 'auto-increment on locations 010-017' when indirecting through them' feature. Bitsavers has fairly complete docs on them all: http://www.bitsavers.org/pdf/dec/pdp4/ http://www.bitsavers.org/pdf/dec/pdp7/ http://www.bitsavers.org/pdf/dec/pdp9/ Noel From jnc at mercury.lcs.mit.edu Tue Mar 15 06:38:14 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 14 Mar 2022 16:38:14 -0400 (EDT) Subject: [TUHS] [tuhs] PDP-11 and early Unix Message-ID: <20220314203814.3D97C18C085@mercury.lcs.mit.edu> Oops: > Instructions had a 4-bit opcode ('000'-'054') '060' was JMP. > ('060'opcodes were for the optional EAE.) '064'. Noel From wkt at tuhs.org Tue Mar 29 07:03:56 2022 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 29 Mar 2022 07:03:56 +1000 Subject: [TUHS] Alive? Message-ID: <20220328210356.GA18426@minnie.tuhs.org> Just checking that the TUHS list hasn't gone belly up, as it's been pretty quiet for a week :-) Cheers, Warren From lm at mcvoy.com Tue Mar 29 07:29:00 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 28 Mar 2022 14:29:00 -0700 Subject: [TUHS] Alive? In-Reply-To: <20220328210356.GA18426@minnie.tuhs.org> References: <20220328210356.GA18426@minnie.tuhs.org> Message-ID: <20220328212900.GF21103@mcvoy.com> Is it time for vi vs emacs or BSD license vs GPL wars? Be careful what you wish for :-) On Tue, Mar 29, 2022 at 07:03:56AM +1000, Warren Toomey via TUHS wrote: > Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > > Cheers, Warren -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From usotsuki at buric.co Tue Mar 29 07:21:24 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 28 Mar 2022 17:21:24 -0400 (EDT) Subject: [TUHS] Alive? In-Reply-To: <20220328210356.GA18426@minnie.tuhs.org> References: <20220328210356.GA18426@minnie.tuhs.org> Message-ID: On Tue, 29 Mar 2022, Warren Toomey via TUHS wrote: > Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > > Cheers, Warren > *pong* -uso. From jnc at mercury.lcs.mit.edu Tue Mar 29 07:05:54 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Mar 2022 17:05:54 -0400 (EDT) Subject: [TUHS] Alive? Message-ID: <20220328210554.2CB4D18C087@mercury.lcs.mit.edu> > From: Warren Toomey > Just checking that the TUHS list hasn't gone belly up, as it's been > pretty quiet for a week :-) Thank goodness! That's one way to improve the S/N ratio. Noel From sauer at technologists.com Tue Mar 29 07:27:11 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Mon, 28 Mar 2022 16:27:11 -0500 Subject: [TUHS] Alive? In-Reply-To: <20220328210356.GA18426@minnie.tuhs.org> References: <20220328210356.GA18426@minnie.tuhs.org> Message-ID: received. TUHS people must be too distracted by the OSI tangents at internet-history at elists.isoc.org Charlie On 3/28/2022 4:03 PM, Warren Toomey via TUHS wrote: > Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > > Cheers, Warren -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From hellwig.geisse at mni.thm.de Tue Mar 29 07:17:44 2022 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Mon, 28 Mar 2022 23:17:44 +0200 Subject: [TUHS] Alive? In-Reply-To: <20220328210356.GA18426@minnie.tuhs.org> References: <20220328210356.GA18426@minnie.tuhs.org> Message-ID: <1648502264.2646.66.camel@mni.thm.de> Hi Warren, On Di, 2022-03-29 at 07:03 +1000, Warren Toomey via TUHS wrote: > Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > all is well here :-) Best regards, Hellwig From dave at horsfall.org Tue Mar 29 07:43:43 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 29 Mar 2022 08:43:43 +1100 (EST) Subject: [TUHS] Alive? In-Reply-To: <20220328210356.GA18426@minnie.tuhs.org> References: <20220328210356.GA18426@minnie.tuhs.org> Message-ID: On Tue, 29 Mar 2022, Warren Toomey via TUHS wrote: > Just checking that the TUHS list hasn't gone belly up, as it's been > pretty quiet for a week :-) Just lurking (but saving all posts) as I pursue other interests; looking after my diabetes is somewhat high on the list... -- Dave From bakul at iitbombay.org Tue Mar 29 08:24:38 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 28 Mar 2022 15:24:38 -0700 Subject: [TUHS] Alive? In-Reply-To: <20220328210356.GA18426@minnie.tuhs.org> References: <20220328210356.GA18426@minnie.tuhs.org> Message-ID: <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: > > Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > > Cheers, Warren My impression is that there is much less traffic on pretty much all the mailing lists I am on and I am wondering why. From jnc at mercury.lcs.mit.edu Tue Mar 29 09:10:41 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Mar 2022 19:10:41 -0400 (EDT) Subject: [TUHS] Alive? Message-ID: <20220328231041.5F32418C087@mercury.lcs.mit.edu> > From: Bakul Shah > My impression is that there is much less traffic on pretty much all the > mailing lists I am on and I am wondering why. Ukraine? That's certainly been absorbing a lot of my attention (but it seems like it's going to go on for quite a while now). Noel From grog at lemis.com Tue Mar 29 09:23:44 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 29 Mar 2022 10:23:44 +1100 Subject: [TUHS] Alive? In-Reply-To: <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> Message-ID: <20220328232344.GC60301@eureka.lemis.com> On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: > On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: >> >> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty >> quiet for a week :-) > > My impression is that there is much less traffic on pretty much all > the mailing lists I am on and I am wondering why. Yes, I had noticed that too. I had assumed a US holiday or some such. Was there one? Greg -- Sent from my desktop computer. Finger grog at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From andrew at humeweb.com Tue Mar 29 09:29:28 2022 From: andrew at humeweb.com (Andrew Hume) Date: Mon, 28 Mar 2022 16:29:28 -0700 Subject: [TUHS] Alive? In-Reply-To: <20220328232344.GC60301@eureka.lemis.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> Message-ID: LA county had a day off from school: Cezar Chavez day! > On Mar 28, 2022, at 4:23 PM, Greg 'groggy' Lehey wrote: > > On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: >> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: >>> >>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty >>> quiet for a week :-) >> >> My impression is that there is much less traffic on pretty much all >> the mailing lists I am on and I am wondering why. > > Yes, I had noticed that too. I had assumed a US holiday or some > such. Was there one? > > Greg > -- > Sent from my desktop computer. > Finger grog at 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 From ggm at algebras.org Tue Mar 29 09:56:19 2022 From: ggm at algebras.org (George Michaelson) Date: Tue, 29 Mar 2022 09:56:19 +1000 Subject: [TUHS] Alive? In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> Message-ID: If apple formed a union, would it be "united fruit" -that would seem appropriate on Cezar Chavez day... On Tue, Mar 29, 2022 at 9:54 AM Andrew Hume wrote: > > LA county had a day off from school: Cezar Chavez day! > > > On Mar 28, 2022, at 4:23 PM, Greg 'groggy' Lehey wrote: > > > > On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: > >> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: > >>> > >>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty > >>> quiet for a week :-) > >> > >> My impression is that there is much less traffic on pretty much all > >> the mailing lists I am on and I am wondering why. > > > > Yes, I had noticed that too. I had assumed a US holiday or some > > such. Was there one? > > > > Greg > > -- > > Sent from my desktop computer. > > Finger grog at 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 > From bakul at iitbombay.org Tue Mar 29 10:00:22 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 28 Mar 2022 17:00:22 -0700 Subject: [TUHS] Alive? In-Reply-To: <20220328232344.GC60301@eureka.lemis.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> Message-ID: <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> > On Mar 28, 2022, at 4:23 PM, Greg 'groggy' Lehey wrote: > > On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: >> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: >>> >>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty >>> quiet for a week :-) >> >> My impression is that there is much less traffic on pretty much all >> the mailing lists I am on and I am wondering why. > > Yes, I had noticed that too. I had assumed a US holiday or some > such. Was there one? It seems to be a longer term trend than a holiday or a month of Ukraine war. May be people are moving to newer platforms (forums, twitter, reddit, discord) or newer topics. From grog at lemis.com Tue Mar 29 10:31:11 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 29 Mar 2022 11:31:11 +1100 Subject: [TUHS] Alive? In-Reply-To: <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> Message-ID: <20220329003111.GD60301@eureka.lemis.com> On Monday, 28 March 2022 at 17:00:22 -0700, Bakul Shah wrote: >> On Mar 28, 2022, at 4:23 PM, Greg 'groggy' Lehey wrote: >> On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: >>> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: >>>> >>>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty >>>> quiet for a week :-) >>> >>> My impression is that there is much less traffic on pretty much all >>> the mailing lists I am on and I am wondering why. >> >> Yes, I had noticed that too. I had assumed a US holiday or some >> such. Was there one? > > It seems to be a longer term trend than a holiday or a month of > Ukraine war. May be people are moving to newer platforms (forums, > twitter, reddit, discord) or newer topics. I never cease to marvel at peoples' capacity for masochism. But there are other things too, like the daily FreeBSD commit mail, which also seems to have dipped a few days ago. And that's frequently an indication of some more global holiday than Cesar Chavez. But it's interesting to read about Cesar Chavez. Thanks to whoever mentioned it. Greg -- Sent from my desktop computer. Finger grog at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From stewart at serissa.com Tue Mar 29 10:31:14 2022 From: stewart at serissa.com (Lawrence Stewart) Date: Mon, 28 Mar 2022 20:31:14 -0400 Subject: [TUHS] Old screen editors In-Reply-To: <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> Message-ID: <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> At the Stanford Information Systems Lab while I was there 1976-81, we had a series of PDP-11s. The first one I remember was an 11/34 running V6 and later V7. It was later upgraded to, I think a /45 and finally a /70. At first everyone used ed, then Prof. John Gill hacked it to add a command, I think ‘%’ that was the equivalent of .-10,.+10p which on our 9600 baud Hazeltine’s was a glimpse of the future. At some point we got ex/vi, but before that we got the “Rand Editor” re, which was a perfectly functional screen editor, if you squinted a bit. Does anyone here know the place of re in the history? Later, Gill went off for a sabbatical at Yorktown Heights and came back to complain about having to use SOS on the mainframe. He reported, however, that global search and replace was very fast. -L Also a few years later I got Dave Conroy’s version of microemacs. I complained about the key bindings and he told me to use the “change configuration” command, or cc. From sauer at technologists.com Tue Mar 29 10:53:54 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Mon, 28 Mar 2022 19:53:54 -0500 Subject: [TUHS] Old screen editors In-Reply-To: <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> Message-ID: <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> Aaah, just what we need, an editor discussion. My first hands on experience was with PC/IX on an XT. ISC provided INed, which I was told was based on the Rand Editor. INed was a gentle transition from using XEDIT on VM/370, so I was comfortable with INed. But one of my Unix mentors persuaded me to use vi, and that has been my preferred editor since roughly 1985, assuming you count Vim as vi, since I mostly use Vim on Linux, Windows and macOS, only occasionally using real vi. Charlie On 3/28/2022 7:31 PM, Lawrence Stewart wrote: > At the Stanford Information Systems Lab while I was there 1976-81, we had a series of PDP-11s. The first one I remember was an 11/34 running V6 and later V7. It was later upgraded to, I think a /45 and finally a /70. > > At first everyone used ed, then Prof. John Gill hacked it to add a command, I think ‘%’ that was the equivalent of .-10,.+10p which on our 9600 baud Hazeltine’s was a glimpse of the future. > > At some point we got ex/vi, but before that we got the “Rand Editor” re, which was a perfectly > functional screen editor, if you squinted a bit. > > Does anyone here know the place of re in the history? > > Later, Gill went off for a sabbatical at Yorktown Heights and came back to complain about having > to use SOS on the mainframe. He reported, however, that global search and replace was very fast. > > -L > > Also a few years later I got Dave Conroy’s version of microemacs. I complained about the key bindings and he told me to use the “change configuration” command, or cc. > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From usotsuki at buric.co Tue Mar 29 11:10:29 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 28 Mar 2022 21:10:29 -0400 (EDT) Subject: [TUHS] Alive? In-Reply-To: <20220328232344.GC60301@eureka.lemis.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> Message-ID: On Tue, 29 Mar 2022, Greg 'groggy' Lehey wrote: > On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: >> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: >>> >>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty >>> quiet for a week :-) >> >> My impression is that there is much less traffic on pretty much all >> the mailing lists I am on and I am wondering why. > > Yes, I had noticed that too. I had assumed a US holiday or some > such. Was there one? > > Greg Not that I'm aware of... just the clocks going forward. -uso. From chet.ramey at case.edu Tue Mar 29 11:14:21 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 28 Mar 2022 21:14:21 -0400 Subject: [TUHS] Alive? In-Reply-To: <20220328212900.GF21103@mcvoy.com> References: <20220328210356.GA18426@minnie.tuhs.org> <20220328212900.GF21103@mcvoy.com> Message-ID: On 3/28/22 5:29 PM, Larry McVoy wrote: > Is it time for vi vs emacs or BSD license vs GPL wars? Be careful what > you wish for :-) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From henry at henare.com Tue Mar 29 16:37:18 2022 From: henry at henare.com (Henry Mensch) Date: Tue, 29 Mar 2022 02:37:18 -0400 Subject: [TUHS] Alive? In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> Message-ID: <17fd4649d30.282d.27ce34798ec5af9926fa49424fa0531c@henare.com> in the US and the UK, on different weekends afaik. - Henry Mensch On March 28, 2022 21:21:12 Steve Nickolas wrote: > On Tue, 29 Mar 2022, Greg 'groggy' Lehey wrote: > >> On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: >>> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: >>>> >>>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty >>>> quiet for a week :-) >>> >>> My impression is that there is much less traffic on pretty much all >>> the mailing lists I am on and I am wondering why. >> >> Yes, I had noticed that too. I had assumed a US holiday or some >> such. Was there one? >> >> Greg > > Not that I'm aware of... just the clocks going forward. > > -uso. From robpike at gmail.com Tue Mar 29 18:29:52 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 29 Mar 2022 19:29:52 +1100 Subject: [TUHS] Old screen editors In-Reply-To: <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> Message-ID: I used SOS a bit, but did anyone use Stopgap itself, or only its son? -rob On Tue, Mar 29, 2022 at 11:55 AM Charles H Sauer (he/him) wrote: > > Aaah, just what we need, an editor discussion. > > My first hands on experience was with PC/IX on an XT. ISC provided INed, > which I was told was based on the Rand Editor. INed was a gentle > transition from using XEDIT on VM/370, so I was comfortable with INed. > > But one of my Unix mentors persuaded me to use vi, and that has been my > preferred editor since roughly 1985, assuming you count Vim as vi, since > I mostly use Vim on Linux, Windows and macOS, only occasionally using > real vi. > > Charlie > > On 3/28/2022 7:31 PM, Lawrence Stewart wrote: > > At the Stanford Information Systems Lab while I was there 1976-81, we had a series of PDP-11s. The first one I remember was an 11/34 running V6 and later V7. It was later upgraded to, I think a /45 and finally a /70. > > > > At first everyone used ed, then Prof. John Gill hacked it to add a command, I think ‘%’ that was the equivalent of .-10,.+10p which on our 9600 baud Hazeltine’s was a glimpse of the future. > > > > At some point we got ex/vi, but before that we got the “Rand Editor” re, which was a perfectly > > functional screen editor, if you squinted a bit. > > > > Does anyone here know the place of re in the history? > > > > Later, Gill went off for a sabbatical at Yorktown Heights and came back to complain about having > > to use SOS on the mainframe. He reported, however, that global search and replace was very fast. > > > > -L > > > > Also a few years later I got Dave Conroy’s version of microemacs. I complained about the key bindings and he told me to use the “change configuration” command, or cc. > > > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Twitter: CharlesHSauer From ggm at algebras.org Tue Mar 29 18:34:34 2022 From: ggm at algebras.org (George Michaelson) Date: Tue, 29 Mar 2022 18:34:34 +1000 Subject: [TUHS] Old screen editors In-Reply-To: <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> Message-ID: One called ned? It did something unusual to handle > 80 long lines. I think it came off a DECUS tape. I only lasted a week and went back to SOS. Teco was painful. I felt I was being laughed at. I have the manual still and ran a port on BSD for a while but I wound up laughing at myself. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Mar 29 18:40:56 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 29 Mar 2022 02:40:56 -0600 Subject: [TUHS] Old screen editors In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> Message-ID: <202203290840.22T8euk9028535@freefriends.org> Did anyone within the Bell System ever use a screen editor called 'se'? (NOT related to the Georgia Tech se editor [se-editor.org]). I used this on a USG UNIX 4.0 system ~ 1982 when I did some contract programming at Southern Bell. I think it was originally written for the Vax but it had been squeezed to run on a PDP-11/70 also. I've mentioned this in the past, but it seems to been covered over by the sands of time, and that nobody else ever used it. Arnold From pnr at planet.nl Tue Mar 29 20:06:38 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 29 Mar 2022 12:06:38 +0200 Subject: [TUHS] Re.: Alive? Message-ID: <0FD9B7B2-FD77-44FB-9934-69DA029FA0E0@planet.nl> > Just checking that the TUHS list hasn't gone belly up, as it's been pretty > quiet for a week :-) > > Cheers, Warren Not relevant to a sudden dip, but overall my observation is that retro computing interest tends to focus on a period 30-40 years ago. For example, in the late 80’s people were going retro on the LGP-30, the story of Mel, etc. Probably this matches with people retracing their formative years in the industry when they retire. If correct, we should see a rise in interest around early Linux in the upcoming years, with interest in 80’s Unix and early networking declining. We’re probably already past peak for interest in 1970’s Unix. The historical log of this mailing list is important. Documenting historical events will get much harder after the "40 year window" has closed. Paul From jnc at mercury.lcs.mit.edu Tue Mar 29 20:39:02 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 29 Mar 2022 06:39:02 -0400 (EDT) Subject: [TUHS] Old screen editors Message-ID: <20220329103902.42B9218C085@mercury.lcs.mit.edu> > From: George Michaelson > Teco was painful. Some of us can recall when the _only_ choices for editing on UNIX (on the PWB1 systems at MIT) were 'ed' and TECO! But to add some real history (not just the usual low S/N flaming about people's opinions of various relatively recent software, which is way too common on this list), the guys at MIT in DSSR/RTS (the group which later did the 68K version of PCC), who had done the port of PDP-11 TECO (in MACRO-11) from the Delphi system at MIT (which preceded adoption of UNIX there) - a comment in one source file alludes to Delphi, so that's where it came from, to UNIX (I think this TECO was written there, and was not a port of a DEC one, since it's all in lower case, and doesn't have other DEC stylisms), after the port, added a '^R mode' similar to the one added to the PDP-10 ITS TECO and used there to write EMACS (in TECO's usual 'line noise' code - historical aside: at one point there was a whole 'Ivory' package for ITS TECO which could 'purify' ITS TECO code so that one copy in core [actual, real core!] could be shared by multiple processes). That was used to write an EMACS-like package for the PDP-11 UNIX TECO (but much simpler than real EMACS), which we used for quite a while before Montgomery EMACS for UNIX showed up. The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the sources and documentation for that TECO, and the ^R-mode code, etc. If anyone is interested in seeing it (or maybe even playing with it, which will need the UNIX MACRO-11), let me know, and I'll upload it. Noel PS: Speaking of the full dump of the MIT-CSR PWB1 UNIX system, I was poking around it a couple of days ago, and I found V6 'multiplexor' kernel drivers - mpio.c and mpx.c, etc - I think thay 'fell off the back of a truck' at Bell, like a lot of other stuff we weren't supposed to have, like the circuit design tools, etc. I'm not sure if I have the user programs to go with them; I think I may have found some of them for Paul Ruizendaal a while back, but the memory has faded. Again, if interested, let me know. From robpike at gmail.com Tue Mar 29 21:05:35 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 29 Mar 2022 22:05:35 +1100 Subject: [TUHS] Old screen editors In-Reply-To: <20220329103902.42B9218C085@mercury.lcs.mit.edu> References: <20220329103902.42B9218C085@mercury.lcs.mit.edu> Message-ID: Be careful, those early multiplexer attempts by Chesson were very buggy. I bounced off them pretty hard, and greg and I had long debugging sessions trying to get ur-Jerq up reliably on them. The pains were one component of dmr proposing streams* as another model. I was using the v7 ones; the v6 ones must be even buggier. -rob * Or as USG later dubbed them, STREAMS. On Tue, Mar 29, 2022 at 9:40 PM Noel Chiappa wrote: > > > From: George Michaelson > > > Teco was painful. > > Some of us can recall when the _only_ choices for editing on UNIX (on the > PWB1 systems at MIT) were 'ed' and TECO! > > But to add some real history (not just the usual low S/N flaming about > people's opinions of various relatively recent software, which is way too > common on this list), the guys at MIT in DSSR/RTS (the group which later did > the 68K version of PCC), who had done the port of PDP-11 TECO (in MACRO-11) > from the Delphi system at MIT (which preceded adoption of UNIX there) - a > comment in one source file alludes to Delphi, so that's where it came from, to > UNIX (I think this TECO was written there, and was not a port of a DEC one, > since it's all in lower case, and doesn't have other DEC stylisms), after the > port, added a '^R mode' similar to the one added to the PDP-10 ITS TECO and > used there to write EMACS (in TECO's usual 'line noise' code - historical > aside: at one point there was a whole 'Ivory' package for ITS TECO which could > 'purify' ITS TECO code so that one copy in core [actual, real core!] could be > shared by multiple processes). That was used to write an EMACS-like package > for the PDP-11 UNIX TECO (but much simpler than real EMACS), which we used for > quite a while before Montgomery EMACS for UNIX showed up. > > The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the > sources and documentation for that TECO, and the ^R-mode code, etc. If anyone > is interested in seeing it (or maybe even playing with it, which will need > the UNIX MACRO-11), let me know, and I'll upload it. > > Noel > > PS: Speaking of the full dump of the MIT-CSR PWB1 UNIX system, I was poking > around it a couple of days ago, and I found V6 'multiplexor' kernel drivers - > mpio.c and mpx.c, etc - I think thay 'fell off the back of a truck' at Bell, > like a lot of other stuff we weren't supposed to have, like the circuit design > tools, etc. I'm not sure if I have the user programs to go with them; I think > I may have found some of them for Paul Ruizendaal a while back, but the memory > has faded. Again, if interested, let me know. From pnr at planet.nl Tue Mar 29 21:21:14 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 29 Mar 2022 13:21:14 +0200 Subject: [TUHS] Paging code in SysV R2 Message-ID: I did not have a lot of time to work on documenting the evolution of paging / virtual memory code in 32V, Sys III and early SysV in the past months, but I did get some more background information that seems worth sharing. My understanding of the virtual memory story at USG is now as follows: Somewhere in 1981/82 a project plan for Unix 5 / System V was made and evolving John Reiser’s virtual memory code for 32V-r3 was part of that plan. “Evolving” in this context meant making it more maintainable and more hardware independent. John’s code assumed a memory page, a disk block and a file block all to be the same size, and it needed to be more general. It was also designed around the VAX MMU and this too needed to be generalised. The person assigned to that job was Bob (Robert) Baron, reporting to Tom Raleigh. The project involved quite a bit of re-architecting and progress was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh tried to pick up where Bob had left off, but progress remained slowish. In parallel, Keith Kelleman and Steve Burroff were working on Unix for the 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which used a more or less ‘modern’ page table design) and developed their idea for the “regions” abstraction to support large, non-contiguous address spaces. It seems that they built on the main working set ideas/concepts in the Reiser/Baron/Raleigh code base, combined these with their “regions” idea, made it multi-processor capable and made it all work on the 3B20. Around that time Tom Raleigh seems to have transferred to Bellcore, and the VAX code base got orphaned. Two young engineers appear to have picked up the work on the VAX code base: Dean Jagels and Jim McCormick. My understanding is that they essentially back ported the 3B20 work to the VAX, falling back on the Reiser/Baron/Raleigh work where necessary. They got it working, and as far as I can tell, this is what got released in 1984 as part of SysV R2.4 for the VAX (the oldest surviving source code for this that I could find). This somewhat tortuous birth may in part explain why Research chose to use the 4BSD virtual memory code for 8th edition. From robpike at gmail.com Tue Mar 29 22:38:37 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 29 Mar 2022 23:38:37 +1100 Subject: [TUHS] Paging code in SysV R2 In-Reply-To: References: Message-ID: "This somewhat tortuous birth may in part explain why Research chose to use the 4BSD virtual memory code for 8th edition." No. There was a short but intense debate about Reiser's vs. BSD's kernel for our 780 in 1980 to '81, before the story you tell gets started. I was not a central player in the decision, far from it, and there were legitimate reasons to go either way, but I think it was mostly due to a stronger feeling of connection with Berkeley than with Holmdel coupled with some personality conflicts at the management level. There were also issues around expected support, and discomfort around the way Reiser's model made some Unix things work a little differently. I don't believe I ever used a computer that felt as fast, for its time, as the Holmdel VAX running Reiser and London's kernel, and I was definitely rooting for that to win. When BSD landed it was not in the same league, not at all. But it had other advantages. -rob From thomas.paulsen at firemail.de Tue Mar 29 22:45:47 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 29 Mar 2022 14:45:47 +0200 Subject: [TUHS] Old screen editors In-Reply-To: <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> Message-ID: Hi, there are s variants of se out there. Only one known to me git://github.com/screen-editor/se.git https://github.com/screen-editor/se Von: Lawrence Stewart Datum: 29.03.2022 02:31:14 An: TUHS at tuhs.org Betreff: [TUHS] Old screen editors At the Stanford Information Systems Lab while I was there 1976-81, we had a series of PDP-11s. The first one I remember was an 11/34 running V6 and later V7. It was later upgraded to, I think a /45 and finally a /70. At first everyone used ed, then Prof. John Gill hacked it to add a command, I think ‘%’ that was the equivalent of .-10,.+10p which on our 9600 baud Hazeltine’s was a glimpse of the future. At some point we got ex/vi, but before that we got the “Rand Editor” re, which was a perfectly functional screen editor, if you squinted a bit. Does anyone here know the place of re in the history? Later, Gill went off for a sabbatical at Yorktown Heights and came back to complain about having to use SOS on the mainframe. He reported, however, that global search and replace was very fast. -L Also a few years later I got Dave Conroy’s version of microemacs. I complained about the key bindings and he told me to use the “change configuration” command, or cc. From clemc at ccc.com Tue Mar 29 23:24:51 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 29 Mar 2022 09:24:51 -0400 Subject: [TUHS] Old screen editors In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> Message-ID: On Tue, Mar 29, 2022 at 4:31 AM Rob Pike wrote: > I used SOS a bit, but did anyone use Stopgap itself, or only its son? > I was going to ask the same question. Funny, I still often (tend) to use line numbers to do multi-line operations not marks - probably because SOS was one of the first editors I learned and first I learned to use really well. Now here is where my memory is hazy. I do remember using SOS on the PDP-10s which had mostly glass TTYs, but for some reason I have memories of using it on an ASR-33 on the TSS/360 - which must be wrong. I thinking, there probably had to have been an IBM editor similar to it that I'm confusing with the TOPS/TENEX. I also have no memories of what editor we used on the original VMS V1.0 machine -- it must have been a member of the TECO family, although again I want to say we had something like SOS. I do remember that learning ed(1) on UNIX was a piece of cake and immediately loved regex for patterns. I was still doing some PDP-10 hacking for the CS-Dept in those days, and bitching that I wanted ed(1) on the 10s after I mastered it. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Mar 29 23:26:42 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 29 Mar 2022 07:26:42 -0600 Subject: [TUHS] Old screen editors In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> Message-ID: <202203291326.22TDQgSf008887@freefriends.org> This is the Georgia Tech 'se' screen editor, originally written in Ratfor as an extension of the Software Tool editor. It was ported to Unix by Dan Forsyth and to termcap/terminfo by me. Dan Cort brought it into the 21st century. It's not related to 's' or any other previous screen editor. Arnold "Thomas Paulsen" wrote: > Hi, > > there are s variants of se out there. Only one known to me > git://github.com/screen-editor/se.git > https://github.com/screen-editor/se > > > > > Von: Lawrence Stewart > Datum: 29.03.2022 02:31:14 > An: TUHS at tuhs.org > Betreff: [TUHS] Old screen editors > > At the Stanford Information Systems Lab while I was there 1976-81, we had > a series of PDP-11s. The first one I remember was an 11/34 running V6 and > later V7. It was later upgraded to, I think a /45 and finally a /70. > > At first everyone used ed, then Prof. John Gill hacked it to add a command, > I think ‘%’ that was the equivalent of .-10,.+10p which on our 9600 baud > Hazeltine’s was a glimpse of the future. > > At some point we got ex/vi, but before that we got the “Rand Editor” re, > which was a perfectly > functional screen editor, if you squinted a bit. > > Does anyone here know the place of re in the history? > > Later, Gill went off for a sabbatical at Yorktown Heights and came back to > complain about having > to use SOS on the mainframe. He reported, however, that global search and > replace was very fast. > > -L > > Also a few years later I got Dave Conroy’s version of microemacs. I complained > about the key bindings and he told me to use the “change configuration” command, > or cc. > > > > From clemc at ccc.com Tue Mar 29 23:37:28 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 29 Mar 2022 09:37:28 -0400 Subject: [TUHS] Old screen editors In-Reply-To: <20220329103902.42B9218C085@mercury.lcs.mit.edu> References: <20220329103902.42B9218C085@mercury.lcs.mit.edu> Message-ID: Check Paul Cantrell's VTECO - Video Teco Manual where has the sources here Video Teco Sourceforge Masters Ward had a nice history here: TecoEditor - worth reading - there are some wonderful quotes. BTW I agree with Ward, while Ed Post was mostly right in his "real Programmer' don't use Pascal" tome (also a classic read), but real TECO users do know what typing their name will do ;-) On Tue, Mar 29, 2022 at 6:39 AM Noel Chiappa wrote: > > From: George Michaelson > > > Teco was painful. > > Some of us can recall when the _only_ choices for editing on UNIX (on the > PWB1 systems at MIT) were 'ed' and TECO! > > But to add some real history (not just the usual low S/N flaming about > people's opinions of various relatively recent software, which is way too > common on this list), the guys at MIT in DSSR/RTS (the group which later > did > the 68K version of PCC), who had done the port of PDP-11 TECO (in MACRO-11) > from the Delphi system at MIT (which preceded adoption of UNIX there) - a > comment in one source file alludes to Delphi, so that's where it came > from, to > UNIX (I think this TECO was written there, and was not a port of a DEC one, > since it's all in lower case, and doesn't have other DEC stylisms), after > the > port, added a '^R mode' similar to the one added to the PDP-10 ITS TECO and > used there to write EMACS (in TECO's usual 'line noise' code - historical > aside: at one point there was a whole 'Ivory' package for ITS TECO which > could > 'purify' ITS TECO code so that one copy in core [actual, real core!] could > be > shared by multiple processes). That was used to write an EMACS-like package > for the PDP-11 UNIX TECO (but much simpler than real EMACS), which we used > for > quite a while before Montgomery EMACS for UNIX showed up. > > The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the > sources and documentation for that TECO, and the ^R-mode code, etc. If > anyone > is interested in seeing it (or maybe even playing with it, which will need > the UNIX MACRO-11), let me know, and I'll upload it. > > Noel > > PS: Speaking of the full dump of the MIT-CSR PWB1 UNIX system, I was poking > around it a couple of days ago, and I found V6 'multiplexor' kernel > drivers - > mpio.c and mpx.c, etc - I think thay 'fell off the back of a truck' at > Bell, > like a lot of other stuff we weren't supposed to have, like the circuit > design > tools, etc. I'm not sure if I have the user programs to go with them; I > think > I may have found some of them for Paul Ruizendaal a while back, but the > memory > has faded. Again, if interested, let me know. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Mar 29 23:45:52 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 29 Mar 2022 09:45:52 -0400 Subject: [TUHS] Old screen editors In-Reply-To: <202203290840.22T8euk9028535@freefriends.org> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> <202203290840.22T8euk9028535@freefriends.org> Message-ID: Arnold, I agree, I do remember seeing it on what I think was the PWB 4.0 tape. IMHO: it was before cshell, termcap, vi et al was released inside of the rest of the Bell System and there seemed to be sometimes "SW from BSD be bad/crude" 'tude. IIRC ber and mmp must have had it running on the Marx's brothers systems in Whippany. But he had vi, so I personally never used it. @Mary Ann - this would have been around the time you were in Columbus and starting the terminfo work. Do you have any memories? On Tue, Mar 29, 2022 at 5:29 AM wrote: > Did anyone within the Bell System ever use a screen editor called 'se'? > (NOT related to the Georgia Tech se editor [se-editor.org]). > > I used this on a USG UNIX 4.0 system ~ 1982 when I did some contract > programming at Southern Bell. I think it was originally written for > the Vax but it had been squeezed to run on a PDP-11/70 also. > > I've mentioned this in the past, but it seems to been covered over > by the sands of time, and that nobody else ever used it. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Mar 30 00:05:26 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 29 Mar 2022 10:05:26 -0400 Subject: [TUHS] Paging code in SysV R2 In-Reply-To: References: Message-ID: Fascinating - thank you. Have you figured out that path from here to the SVR4 code base that was used for the x86 [which I think also went through a few more generations after the SVR4 release]? Clem On Tue, Mar 29, 2022 at 7:22 AM Paul Ruizendaal via TUHS < tuhs at minnie.tuhs.org> wrote: > > I did not have a lot of time to work on documenting the evolution of > paging / virtual memory code in 32V, Sys III and early SysV in the past > months, but I did get some more background information that seems worth > sharing. > > My understanding of the virtual memory story at USG is now as follows: > > Somewhere in 1981/82 a project plan for Unix 5 / System V was made and > evolving John Reiser’s virtual memory code for 32V-r3 was part of that > plan. “Evolving” in this context meant making it more maintainable and more > hardware independent. John’s code assumed a memory page, a disk block and a > file block all to be the same size, and it needed to be more general. It > was also designed around the VAX MMU and this too needed to be generalised. > The person assigned to that job was Bob (Robert) Baron, reporting to Tom > Raleigh. The project involved quite a bit of re-architecting and progress > was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh > tried to pick up where Bob had left off, but progress remained slowish. > > In parallel, Keith Kelleman and Steve Burroff were working on Unix for the > 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which > used a more or less ‘modern’ page table design) and developed their idea > for the “regions” abstraction to support large, non-contiguous address > spaces. It seems that they built on the main working set ideas/concepts in > the Reiser/Baron/Raleigh code base, combined these with their “regions” > idea, made it multi-processor capable and made it all work on the 3B20. > Around that time Tom Raleigh seems to have transferred to Bellcore, and the > VAX code base got orphaned. > > Two young engineers appear to have picked up the work on the VAX code > base: Dean Jagels and Jim McCormick. My understanding is that they > essentially back ported the 3B20 work to the VAX, falling back on the > Reiser/Baron/Raleigh work where necessary. They got it working, and as far > as I can tell, this is what got released in 1984 as part of SysV R2.4 for > the VAX (the oldest surviving source code for this that I could find). > > This somewhat tortuous birth may in part explain why Research chose to use > the 4BSD virtual memory code for 8th edition. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Mar 30 00:35:08 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 29 Mar 2022 08:35:08 -0600 Subject: [TUHS] Old screen editors In-Reply-To: <8CD4B839-ED11-4A97-8D9A-65F78A78FB43@humeweb.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> <202203290840.22T8euk9028535@freefriends.org> <8CD4B839-ED11-4A97-8D9A-65F78A78FB43@humeweb.com> Message-ID: <202203291435.22TEZ8RB021438@freefriends.org> Cool! I bet this was it! It was on a System 4 system. The commands were entered at the top of the screen. I remember almost nothing else about it. Is there any chance you still have the source? Thanks, Arnold Andrew Hume wrote: > se? > > this may be a consequence for using such a bland name for a screen editor, > but i wrote a screen editor called ’se’ in 1981-83, just after we had moved > from piscataway to murray hill. > > it was part of an effort to do office automation style products for Unix, > and came in around the time Unix transitioned from System III through > System 4 through the early days of System V. > > my se was not very good, but i did have denis ritchie as an early tester. > > > On Mar 29, 2022, at 6:45 AM, Clem Cole wrote: > > > > Arnold, I agree, I do remember seeing it on what I think was the PWB 4.0 tape. IMHO: it was before cshell, termcap, vi et al was released inside of the rest of the Bell System and there seemed to be sometimes "SW from BSD be bad/crude" 'tude. IIRC ber and mmp must have had it running on the Marx's brothers systems in Whippany. But he had vi, so I personally never used it. > > > > @Mary Ann - this would have been around the time you were in Columbus and starting the terminfo work. Do you have any memories? > > > > On Tue, Mar 29, 2022 at 5:29 AM > wrote: > > Did anyone within the Bell System ever use a screen editor called 'se'? > > (NOT related to the Georgia Tech se editor [se-editor.org ]). > > > > I used this on a USG UNIX 4.0 system ~ 1982 when I did some contract > > programming at Southern Bell. I think it was originally written for > > the Vax but it had been squeezed to run on a PDP-11/70 also. > > > > I've mentioned this in the past, but it seems to been covered over > > by the sands of time, and that nobody else ever used it. > > > > Arnold > From andrew at humeweb.com Wed Mar 30 00:31:39 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 29 Mar 2022 07:31:39 -0700 Subject: [TUHS] Old screen editors In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> <202203290840.22T8euk9028535@freefriends.org> Message-ID: <8CD4B839-ED11-4A97-8D9A-65F78A78FB43@humeweb.com> se? this may be a consequence for using such a bland name for a screen editor, but i wrote a screen editor called ’se’ in 1981-83, just after we had moved from piscataway to murray hill. it was part of an effort to do office automation style products for Unix, and came in around the time Unix transitioned from System III through System 4 through the early days of System V. my se was not very good, but i did have denis ritchie as an early tester. > On Mar 29, 2022, at 6:45 AM, Clem Cole wrote: > > Arnold, I agree, I do remember seeing it on what I think was the PWB 4.0 tape. IMHO: it was before cshell, termcap, vi et al was released inside of the rest of the Bell System and there seemed to be sometimes "SW from BSD be bad/crude" 'tude. IIRC ber and mmp must have had it running on the Marx's brothers systems in Whippany. But he had vi, so I personally never used it. > > @Mary Ann - this would have been around the time you were in Columbus and starting the terminfo work. Do you have any memories? > > On Tue, Mar 29, 2022 at 5:29 AM > wrote: > Did anyone within the Bell System ever use a screen editor called 'se'? > (NOT related to the Georgia Tech se editor [se-editor.org ]). > > I used this on a USG UNIX 4.0 system ~ 1982 when I did some contract > programming at Southern Bell. I think it was originally written for > the Vax but it had been squeezed to run on a PDP-11/70 also. > > I've mentioned this in the past, but it seems to been covered over > by the sands of time, and that nobody else ever used it. > > Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Wed Mar 30 00:42:07 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 29 Mar 2022 07:42:07 -0700 Subject: [TUHS] Old screen editors In-Reply-To: <202203291435.22TEZ8RB021438@freefriends.org> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> <202203290840.22T8euk9028535@freefriends.org> <8CD4B839-ED11-4A97-8D9A-65F78A78FB43@humeweb.com> <202203291435.22TEZ8RB021438@freefriends.org> Message-ID: <7196E23A-9EE8-48F9-A851-B1CA2DF9D6D6@humeweb.com> alas, no. it should have been on some official source tapes, tho. it was part of some office automation set of software; maybe that was mentioned in the tapes. i too remember nothing about it. outside of doing it because management wanted it, i never optionally used it. > On Mar 29, 2022, at 7:35 AM, arnold at skeeve.com wrote: > > Cool! I bet this was it! It was on a System 4 system. > > The commands were entered at the top of the screen. I remember almost > nothing else about it. > > Is there any chance you still have the source? > > Thanks, > > Arnold > > Andrew Hume wrote: > >> se? >> >> this may be a consequence for using such a bland name for a screen editor, >> but i wrote a screen editor called ’se’ in 1981-83, just after we had moved >> from piscataway to murray hill. >> >> it was part of an effort to do office automation style products for Unix, >> and came in around the time Unix transitioned from System III through >> System 4 through the early days of System V. >> >> my se was not very good, but i did have denis ritchie as an early tester. From pnr at planet.nl Wed Mar 30 01:24:17 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 29 Mar 2022 17:24:17 +0200 Subject: [TUHS] Paging code in SysV R2 In-Reply-To: References: Message-ID: <9316583A-2461-40B9-8B87-15AC4A719198@planet.nl> No, sorry, my scope of interest is mostly 1975-1985. I did read the Mach virtual memory paper from 1988 - from that paper I gather that the data structures used are totally different from those in Sys V or BSD. There is also the VM implementation that Richard Miller did on SysV r1 in 1983. Interestingly, his design seems to parallel the choices made by Reiser a few years before, but it is lighter touch. Both Reiser and Miller refer to Denning and Tenex as prior art. Miller's 1984 Usenix paper about this project argues that doing approximated LRU from the page table data results in a process local working set view, which he argued was preferable to the system global working set view generated in the BSD clock algorithm. Paul > On 29 Mar 2022, at 16:05, Clem Cole wrote: > > Fascinating - thank you. > > Have you figured out that path from here to the SVR4 code base that was used for the x86 [which I think also went through a few more generations after the SVR4 release]? > > Clem > > On Tue, Mar 29, 2022 at 7:22 AM Paul Ruizendaal via TUHS wrote: > > I did not have a lot of time to work on documenting the evolution of paging / virtual memory code in 32V, Sys III and early SysV in the past months, but I did get some more background information that seems worth sharing. > > My understanding of the virtual memory story at USG is now as follows: > > Somewhere in 1981/82 a project plan for Unix 5 / System V was made and evolving John Reiser’s virtual memory code for 32V-r3 was part of that plan. “Evolving” in this context meant making it more maintainable and more hardware independent. John’s code assumed a memory page, a disk block and a file block all to be the same size, and it needed to be more general. It was also designed around the VAX MMU and this too needed to be generalised. The person assigned to that job was Bob (Robert) Baron, reporting to Tom Raleigh. The project involved quite a bit of re-architecting and progress was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh tried to pick up where Bob had left off, but progress remained slowish. > > In parallel, Keith Kelleman and Steve Burroff were working on Unix for the 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which used a more or less ‘modern’ page table design) and developed their idea for the “regions” abstraction to support large, non-contiguous address spaces. It seems that they built on the main working set ideas/concepts in the Reiser/Baron/Raleigh code base, combined these with their “regions” idea, made it multi-processor capable and made it all work on the 3B20. Around that time Tom Raleigh seems to have transferred to Bellcore, and the VAX code base got orphaned. > > Two young engineers appear to have picked up the work on the VAX code base: Dean Jagels and Jim McCormick. My understanding is that they essentially back ported the 3B20 work to the VAX, falling back on the Reiser/Baron/Raleigh work where necessary. They got it working, and as far as I can tell, this is what got released in 1984 as part of SysV R2.4 for the VAX (the oldest surviving source code for this that I could find). > > This somewhat tortuous birth may in part explain why Research chose to use the 4BSD virtual memory code for 8th edition. > > From aap at papnet.eu Wed Mar 30 01:43:45 2022 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 29 Mar 2022 17:43:45 +0200 Subject: [TUHS] Old screen editors In-Reply-To: <20220329103902.42B9218C085@mercury.lcs.mit.edu> References: <20220329103902.42B9218C085@mercury.lcs.mit.edu> Message-ID: On 29/03/22, Noel Chiappa wrote: > The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the > sources and documentation for that TECO, and the ^R-mode code, etc. If anyone > is interested in seeing it (or maybe even playing with it, which will need > the UNIX MACRO-11), let me know, and I'll upload it. By 'upload it' do you mean the full dump or TECO only? That system sounds very interesting and I'd love to see the whole thing. aap From crossd at gmail.com Wed Mar 30 01:57:20 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 29 Mar 2022 11:57:20 -0400 Subject: [TUHS] Paging code in SysV R2 In-Reply-To: <9316583A-2461-40B9-8B87-15AC4A719198@planet.nl> References: <9316583A-2461-40B9-8B87-15AC4A719198@planet.nl> Message-ID: On Tue, Mar 29, 2022 at 11:25 AM Paul Ruizendaal wrote: > No, sorry, my scope of interest is mostly 1975-1985. > > I did read the Mach virtual memory paper from 1988 - from that paper I > gather that the data structures used are totally different from those in > Sys V or BSD. > > There is also the VM implementation that Richard Miller did on SysV r1 in > 1983. Interestingly, his design seems to parallel the choices made by > Reiser a few years before, but it is lighter touch. Both Reiser and Miller > refer to Denning and Tenex as prior art. Miller's 1984 Usenix paper about > this project argues that doing approximated LRU from the page table data > results in a process local working set view, which he argued was preferable > to the system global working set view generated in the BSD clock algorithm. > I brought this up on this list back in 2017, but a few years later, Charles Forsyth in the UK did a VM system for SunOS 4 based on the EMAS system. https://www.terzarima.net/doc/taste.pdf I'm not quite sure when this was written, but it cites papers from 1989, so sometime that year or 1990, would be my guess. - Dan C. > On 29 Mar 2022, at 16:05, Clem Cole wrote: > > > > Fascinating - thank you. > > > > Have you figured out that path from here to the SVR4 code base that was > used for the x86 [which I think also went through a few more generations > after the SVR4 release]? > > > > Clem > > > > On Tue, Mar 29, 2022 at 7:22 AM Paul Ruizendaal via TUHS < > tuhs at minnie.tuhs.org> wrote: > > > > I did not have a lot of time to work on documenting the evolution of > paging / virtual memory code in 32V, Sys III and early SysV in the past > months, but I did get some more background information that seems worth > sharing. > > > > My understanding of the virtual memory story at USG is now as follows: > > > > Somewhere in 1981/82 a project plan for Unix 5 / System V was made and > evolving John Reiser’s virtual memory code for 32V-r3 was part of that > plan. “Evolving” in this context meant making it more maintainable and more > hardware independent. John’s code assumed a memory page, a disk block and a > file block all to be the same size, and it needed to be more general. It > was also designed around the VAX MMU and this too needed to be generalised. > The person assigned to that job was Bob (Robert) Baron, reporting to Tom > Raleigh. The project involved quite a bit of re-architecting and progress > was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh > tried to pick up where Bob had left off, but progress remained slowish. > > > > In parallel, Keith Kelleman and Steve Burroff were working on Unix for > the 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which > used a more or less ‘modern’ page table design) and developed their idea > for the “regions” abstraction to support large, non-contiguous address > spaces. It seems that they built on the main working set ideas/concepts in > the Reiser/Baron/Raleigh code base, combined these with their “regions” > idea, made it multi-processor capable and made it all work on the 3B20. > Around that time Tom Raleigh seems to have transferred to Bellcore, and the > VAX code base got orphaned. > > > > Two young engineers appear to have picked up the work on the VAX code > base: Dean Jagels and Jim McCormick. My understanding is that they > essentially back ported the 3B20 work to the VAX, falling back on the > Reiser/Baron/Raleigh work where necessary. They got it working, and as far > as I can tell, this is what got released in 1984 as part of SysV R2.4 for > the VAX (the oldest surviving source code for this that I could find). > > > > This somewhat tortuous birth may in part explain why Research chose to > use the 4BSD virtual memory code for 8th edition. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Mar 30 02:01:28 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 29 Mar 2022 09:01:28 -0700 Subject: [TUHS] Paging code in SysV R2 In-Reply-To: <9316583A-2461-40B9-8B87-15AC4A719198@planet.nl> References: <9316583A-2461-40B9-8B87-15AC4A719198@planet.nl> Message-ID: <20220329160128.GD26960@mcvoy.com> On Tue, Mar 29, 2022 at 05:24:17PM +0200, Paul Ruizendaal wrote: > No, sorry, my scope of interest is mostly 1975-1985. > > I did read the Mach virtual memory paper from 1988 - from that paper I gather that the data structures used are totally different from those in Sys V or BSD. > > There is also the VM implementation that Richard Miller did on SysV r1 > in 1983. Interestingly, his design seems to parallel the choices made > by Reiser a few years before, but it is lighter touch. Both Reiser and > Miller refer to Denning and Tenex as prior art. Miller's 1984 Usenix > paper about this project argues that doing approximated LRU from the > page table data results in a process local working set view, which he > argued was preferable to the system global working set view generated > in the BSD clock algorithm. I have HUGE respect for the BSD pageout code. I was the guy who first got rid of the rotational delay in UFS which doubled the speed at which you could read data off the disk. Which was nice, but it filled memory with pages and the pageout code could not free them as fast as UFS was making more. So I wrote 13 different attempts at a better pageout system (no, I didn't save the code, it belonged to Sun, I think it is lost at this point). While some of those attempts were better in very specific cases, none of them, not one of them, were as good, in all cases, as the BSD pageout code. That said, it couldn't keep up now that UFS was faster (it couldn't keep up with a single disk, it had no hope of keeping up with multiple disks). So I did an awful hack, that last I checked was still there: if (we are doing sequential reads AND we are about to start paging out) { start freeing pages a window behind where we are reading } The effect was that if you were about to be out of free memory, sequential I/O became a sliding 256K window of pages, the vnode that was using up all the memory became the one that started freeing memory. It was much faster and simpler than having the pageout code scan through every page. It was also an ugly hack, it was just the best I could come up with at the time. The whole effort left me in awe of the BSD pageout code. It's pretty simple but I'd challenge anyone to do better than that code in all use cases. Not saying it can't be done, but when I was at my coding prime, I couldn't do it. I did start down the path of doing a vnode based working set design. I gave up when I realized that the swap vnode was by far the biggest vnode, everyone's brk() came from that and it was all jumbled together. Trying to do a vnode per process got really messy around fork(). I had many a late night design discussion at Antonio's Nut House in Palo Alto with my office mate, Howard Chartok, trying to come up with a design that couldn't be shot down. Perhaps too much beer because we never got to one. I still suspect there is something to be said for a vnode based working set approach. Especially if you brought back the hack I did that put the basename of the vnode in the vnode (Shannon took it out because of "hard links"). Too bad that didn't survive, I wrote a topvn (like top but for vnodes) that was really good at giving you some insight into what was going on. From bryan at bryanstamour.com Wed Mar 30 03:09:44 2022 From: bryan at bryanstamour.com (Bryan St. Amour) Date: Tue, 29 Mar 2022 13:09:44 -0400 Subject: [TUHS] Re.: Alive? In-Reply-To: <0FD9B7B2-FD77-44FB-9934-69DA029FA0E0@planet.nl> References: <0FD9B7B2-FD77-44FB-9934-69DA029FA0E0@planet.nl> Message-ID: <3a2a1569-d89d-b723-95a1-f9ea63eec9a5@bryanstamour.com> On 3/29/22 06:06, Paul Ruizendaal wrote: >> Just checking that the TUHS list hasn't gone belly up, as it's been pretty >> quiet for a week :-) >> >> Cheers, Warren > Not relevant to a sudden dip, but overall my observation is that retro computing interest tends to focus on a period 30-40 years ago. For example, in the late 80’s people were going retro on the LGP-30, the story of Mel, etc. Probably this matches with people retracing their formative years in the industry when they retire. > > If correct, we should see a rise in interest around early Linux in the upcoming years, with interest in 80’s Unix and early networking declining. We’re probably already past peak for interest in 1970’s Unix. Speaking of early Linux, Slackware version 15 was released earlier this year, and I can happily say that it still feels the same way it always has. I don't think the installer has changed much since the early 90's. > > The historical log of this mailing list is important. Documenting historical events will get much harder after the "40 year window" has closed. > > Paul > From jnc at mercury.lcs.mit.edu Wed Mar 30 04:35:38 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 29 Mar 2022 14:35:38 -0400 (EDT) Subject: [TUHS] Old screen editors Message-ID: <20220329183538.A1E5B18C074@mercury.lcs.mit.edu> > From: Angelo Papenhoff > By 'upload it' do you mean the full dump or TECO only? At this point in time, not the full dump (below for why). I have previously uploaded lots of other bits, e.g. (looks quickly): the TCP/IP that was written for it (with the TCP in the 'user process', making for a small system, good for -11/23's and -11/40's); Montgomery EMACS; TECO (already done - along with the MACRO-11, but I still need to do the linker, and the BCPL compiler one needs for the linker). > That system sounds very interesting and I'd love to see the whole thing. Unfortunately, the dump includes _everything_ on the system, including personal email, etc, etc. So I have to curate it anything I upload. I suppose I should put together an 'index page', which lists (and links to) everything that has been uploaded? Noel From jnc at mercury.lcs.mit.edu Wed Mar 30 06:40:25 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 29 Mar 2022 16:40:25 -0400 (EDT) Subject: [TUHS] Old screen editors Message-ID: <20220329204025.6C67318C075@mercury.lcs.mit.edu> > From: Clem Cole > Ward had a nice history here: TecoEditor > - worth reading Yeah, pretty good. A couple of minor points: "TECO Madness -- a moment of convenience, a lifetime of regret" - I have seen this attributed to Dave Moon. "the [ITS] version of TECO was used by Richard Stallman to implement the original Emacs Editor" - accurate if read _just_ the right way, but incorrect in the 'naive' reading. Stallman didn't _originate_ the body of stuff that eventually turned into ITS EMACS, although he did take over maintenance of it once it was rolling; and later wrote Gnu Emacs from scratch himself. The mostly accurate one-line history is the one given in Dan Weinreb's blog "the original (TECO-based) Emacs was created and designed by Guy L. Steele Jr. and David Moon. After they had it working, and it had become established as the standard text editor at the AI lab, Stallman took over its maintenance", to which Moon added "in all fairness I have to say that Stallman greatly improved Emacs after he 'liberated' it from Guy and me". More people were involved than Moon, Steele and Stallman, though; a lot of people were writing stuff before Stallman took over; and even after that, others (like Eugene Ciccarelli, a member of the CSR group) helped a lot with ITS EMACS. Stallman's EMACS paper ("sEMACS: The Extensible, Customizable, Self-Documenting Display Editor") contains _many_ statements that are _demonstrably_ wrong, e.g. "it is simply impossible to implement an extensible system in [languages like PASCAL or C]" ... "This eliminates most popular programming languages except LISP, APL and SNOBOL." Given that I've been using a heavily customized Epsilon for decades, which is written completely in EEL (a dialect of C enhanced with editing primitives like buffers, etc), that's clerly very confused. Noel From dave at horsfall.org Wed Mar 30 06:46:23 2022 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 30 Mar 2022 07:46:23 +1100 (EST) Subject: [TUHS] Alive? In-Reply-To: <17fd4649d30.282d.27ce34798ec5af9926fa49424fa0531c@henare.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <17fd4649d30.282d.27ce34798ec5af9926fa49424fa0531c@henare.com> Message-ID: On Tue, 29 Mar 2022, Henry Mensch wrote: > in the US and the UK, on different weekends afaik. Not to mention AU/NZ; countries have different rules (if they have DST at all); I'm always amused by people who think that their country's local customs (not just DST) are world-wide. > - Henry Mensch > > On March 28, 2022 21:21:12 Steve Nickolas wrote: > > > On Tue, 29 Mar 2022, Greg 'groggy' Lehey wrote: > > > >> On Monday, 28 March 2022 at 15:24:38 -0700, Bakul Shah wrote: > >>> On Mar 28, 2022, at 2:07 PM, Warren Toomey via TUHS wrote: > >>>> > >>>> ???Just checking that the TUHS list hasn't gone belly up, as it's been pretty > >>>> quiet for a week :-) > >>> > >>> My impression is that there is much less traffic on pretty much all > >>> the mailing lists I am on and I am wondering why. > >> > >> Yes, I had noticed that too. I had assumed a US holiday or some > >> such. Was there one? > >> > >> Greg > > > > Not that I'm aware of... just the clocks going forward. > > > > -uso. > > > > > -- Dave From ron at ronnatalie.com Wed Mar 30 06:54:20 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 29 Mar 2022 20:54:20 +0000 Subject: [TUHS] Old screen editors In-Reply-To: <20220329204025.6C67318C075@mercury.lcs.mit.edu> References: <20220329204025.6C67318C075@mercury.lcs.mit.edu> Message-ID: > >Stallman didn't _originate_ the body of stuff that eventually turned into ITS >EMACS, although he did take over maintenance of it once it was rolling; and >later wrote Gnu Emacs from scratch himself. Well, even that is a bit inaccurate. He implemented emacs by wrapping new code around James Gosling's (also licensed as Unipress) EMACS. After a bit of a protracted argument, he finally wrote his own stuff to get the infringing code out. > that I've been using > heavily customized Epsilon for decades, which is written completely in EEL > dialect of C enhanced with editing primitives like buffers, etc), that's clearly very confused. I was an Epsilon user as well. The "self documenting" aspects of EMACS are kind of laughable as well. I'll start with using backspace for the help key and go from there :) From phil at ultimate.com Wed Mar 30 06:50:18 2022 From: phil at ultimate.com (Phil Budne) Date: Tue, 29 Mar 2022 16:50:18 -0400 Subject: [TUHS] Old screen editors In-Reply-To: <20220329204025.6C67318C075@mercury.lcs.mit.edu> References: <20220329204025.6C67318C075@mercury.lcs.mit.edu> Message-ID: <202203292050.22TKoI5q097366@ultimate.com> > Stallman didn't _originate_ the body of stuff that eventually turned into ITS > EMACS, although he did take over maintenance of it once it was rolling; and > later wrote Gnu Emacs from scratch himself. I though early GNU Emacs was based on Gosling Emacs (aka gosmacs). From steve at quintile.net Wed Mar 30 05:09:52 2022 From: steve at quintile.net (Steve Simon) Date: Tue, 29 Mar 2022 20:09:52 +0100 Subject: [TUHS] Old screen editors Message-ID: <2305F69C-26A5-45C4-9F55-DC7A0ECE85BA@quintile.net> I never really used it but i do remember an editor called le on the v7 interdata/Perkin Elmer i used at Leeds poly. I read electronics and we all used vi, the computer science people at a different campus used le on their Interdata; no idea why. anyone any background on le? ihave not seen sight nor sound of it since. -Steve From ron at ronnatalie.com Wed Mar 30 07:46:42 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 29 Mar 2022 21:46:42 +0000 Subject: [TUHS] Old screen editors In-Reply-To: <2305F69C-26A5-45C4-9F55-DC7A0ECE85BA@quintile.net> References: <2305F69C-26A5-45C4-9F55-DC7A0ECE85BA@quintile.net> Message-ID: Was it one of the awful Pukin-Elmer terminals. I hated those things. Then there was the Rand/Interactive Systems INed. We were stuck using that when I worked for Martin. I never learned vi. If there is no EMACS-like thing on the machine, then I just use ed (sometimes I can get by with ex/vi in line mode). The funniest editor story I have is one day I'm working at Martin. Having actually heard of UNIX before (let alone having done kernel and other work) I was sort of the in house expert. One day one of my coworkers calls out to me: "What's all this Bell System crud in the editor?" I'm thinking, well, it's all Bell System crud. What specifically are we talking about. I walk around to see his terminal and find he has been typing 1 repeatedly to the shell prompt invoking our /usr/bin/1 that said "One Bell System, It Works." After that I modded the program to say "You're not in the editor, Bernie." It was almost as much fun as putting "You might have mail." in motd. ------ Original Message ------ From: "Steve Simon" To: tuhs at minnie.tuhs.org Sent: 3/29/2022 3:09:52 PM Subject: Re: [TUHS] Old screen editors > >I never really used it but i do remember an editor called le on the v7 interdata/Perkin Elmer i used at Leeds poly. > >I read electronics and we all used vi, the computer science people at a different campus used le on their Interdata; no idea why. > >anyone any background on le? ihave not seen sight nor sound of it since. > >-Steve > From chris_pinnock at mac.com Wed Mar 30 07:47:29 2022 From: chris_pinnock at mac.com (Chris Pinnock) Date: Tue, 29 Mar 2022 22:47:29 +0100 Subject: [TUHS] NetBSD VMs from 1.0 to present Message-ID: Evening all, Seeing as our leader is worried about aliveness, I felt it fitting to send a link to a part-time project I’m working on. A couple of weeks ago, I fired up Virtualbox and installed NetBSD/i386 1.0 from floppy images. Virtualbox can be persuaded to read 1.2MB floppies - I’ve had less luck on Qemu with this. But after I setup the VM, I quickly converted it to one that Qemu could use. Then I loaded all the source floppies for 1.1 and 1.2 onto the VM, then upgraded the VM to 1.1 then 1.2 by compiling from source. By which time the pcnet network interface worked reliably. NetBSD still provides a pserver CVS method, so I was able then to CVS update, upgrade to 1.3.3 onwards. 1.4.3 -> 1.5.4 involves a change of binary format from a.out -> ELF. From 1.6 onwards, life becaomes simpler because of the build.sh system, but I spent the time to go all the way up to 9.2 via sources between each release. (I managed to build 9.2 from 6.1 as well.) The VMs can be found on this landing page: https://chrispinnock.com/stuff/netbsd/ I’m working on a write-up which I will publish at some point and I’m also working on OpenBSD branching off at NetBSD 1.1 - I’ve build a OpenBSD 2.0 VM from the NetBSD 1.1 VM on the page above. amnesiac# ls -l /ne* -rwxr-xr-x 1 root wheel 19089180 Mar 26 02:47 /netbsd -rwxr-xr-x 1 root wheel 659600 Mar 13 22:09 /netbsd.10 -rwxr-xr-x 1 root wheel 1332275 Mar 13 22:09 /netbsd.11 -rwxr-xr-x 1 root wheel 1477949 Mar 13 16:13 /netbsd.12 -rwxr-xr-x 1 root wheel 1530049 Mar 13 17:47 /netbsd.121 -rwxr-xr-x 1 root wheel 2211878 Mar 14 02:23 /netbsd.133 -rwxr-xr-x 1 root wheel 3407541 Mar 14 05:12 /netbsd.143 -rwxr-xr-x 1 root wheel 4941157 Mar 14 05:50 /netbsd.154.aout -rwxr-xr-x 1 root wheel 5048054 Mar 14 09:20 /netbsd.154.elf -rwxr-xr-x 1 root wheel 6182687 Mar 14 11:53 /netbsd.162 -rwxr-xr-x 1 root wheel 7447216 Mar 14 14:35 /netbsd.203 -rwxr-xr-x 1 root wheel 7476202 Mar 15 01:12 /netbsd.21 -rwxr-xr-x 1 root wheel 8577892 Mar 15 11:50 /netbsd.31 -rwxr-xr-x 1 root wheel 10343742 Mar 15 23:47 /netbsd.4 -rwxr-xr-x 1 root wheel 12002769 Mar 16 05:31 /netbsd.52 -rwxr-xr-x 1 root wheel 13116694 Mar 16 14:53 /netbsd.61 -rwxr-xr-x 1 root wheel 17143555 Mar 17 04:50 /netbsd.72 -rwxr-xr-x 1 root wheel 19695304 Mar 20 09:12 /netbsd.82 -rwxr-xr-x 1 root wheel 19089180 Mar 28 10:46 /netbsd.92 All the best Chris From cowan at ccil.org Wed Mar 30 07:53:46 2022 From: cowan at ccil.org (John Cowan) Date: Tue, 29 Mar 2022 17:53:46 -0400 Subject: [TUHS] Alive? In-Reply-To: References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <17fd4649d30.282d.27ce34798ec5af9926fa49424fa0531c@henare.com> Message-ID: On Tue, Mar 29, 2022 at 4:46 PM Dave Horsfall wrote: > I'm always amused by people who think that their country's local > customs (not just DST) are world-wide. > THEODOTUS. Caesar: you are a stranger here, and not conversant with our laws. The kings and queens of Egypt may not marry except with their own royal blood. Ptolemy and Cleopatra are born king and consort just as they are born brother and sister.BRITANNUS (shocked). Caesar: this is not proper. THEODOTUS (outraged). How! CAESAR (recovering his self-possession). Pardon him. Theodotus: he is a barbarian, and thinks that the customs of his tribe and island are the laws of nature.BRITANNUS. On the contrary, Caesar, it is these Egyptians who are barbarians; and you do wrong to encourage them. I say it is a scandal. ― George Bernard Shaw, Caesar and Cleopatra -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs at ieee.org Wed Mar 30 10:22:00 2022 From: pugs at ieee.org (Tom Lyon) Date: Tue, 29 Mar 2022 17:22:00 -0700 Subject: [TUHS] Old screen editors In-Reply-To: References: <2305F69C-26A5-45C4-9F55-DC7A0ECE85BA@quintile.net> Message-ID: Yes, awful terminals demand different editors. At Amdahl, we had nothing but 3270s for the mainframe UNIX. Dan Walsh wrote an editor - "ned" - which allowed full screen editing. It was actually quite nice, considering. It allowed any "ed" commands in a command line, but ISPF-like block editing elsewhere. I wrote the 3270 driver which allowed "almost" full duplex interaction with UNIX. On Tue, Mar 29, 2022 at 2:47 PM Ron Natalie wrote: > Was it one of the awful Pukin-Elmer terminals. I hated those things. > > Then there was the Rand/Interactive Systems INed. We were stuck using > that when I worked for Martin. > > I never learned vi. If there is no EMACS-like thing on the machine, > then I just use ed (sometimes I can get by with ex/vi in line mode). > > The funniest editor story I have is one day I'm working at Martin. > Having actually heard of UNIX before (let alone having done kernel and > other work) I was sort of the in house expert. One day one of my > coworkers calls out to me: > > "What's all this Bell System crud in the editor?" > > I'm thinking, well, it's all Bell System crud. What specifically are > we talking about. I walk around to see his terminal and find he has > been typing 1 repeatedly to the shell prompt invoking our /usr/bin/1 > that said "One Bell System, It Works." > > After that I modded the program to say "You're not in the editor, > Bernie." > > It was almost as much fun as putting "You might have mail." in motd. > > ------ Original Message ------ > From: "Steve Simon" > To: tuhs at minnie.tuhs.org > Sent: 3/29/2022 3:09:52 PM > Subject: Re: [TUHS] Old screen editors > > > > >I never really used it but i do remember an editor called le on the v7 > interdata/Perkin Elmer i used at Leeds poly. > > > >I read electronics and we all used vi, the computer science people at a > different campus used le on their Interdata; no idea why. > > > >anyone any background on le? ihave not seen sight nor sound of it since. > > > >-Steve > > > > -- - Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Wed Mar 30 10:59:04 2022 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 29 Mar 2022 17:59:04 -0700 Subject: [TUHS] Old screen editors In-Reply-To: <7196E23A-9EE8-48F9-A851-B1CA2DF9D6D6@humeweb.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> <202203290840.22T8euk9028535@freefriends.org> <8CD4B839-ED11-4A97-8D9A-65F78A78FB43@humeweb.com> <202203291435.22TEZ8RB021438@freefriends.org> <7196E23A-9EE8-48F9-A851-B1CA2DF9D6D6@humeweb.com> Message-ID: <6dd95cdf-eb23-03a9-b881-55ce9da68efa@mhorton.net> se(1) is in my UNIX 5.0 manual, which was the internal version of System V release 1. It makes sense that it would be the one Andrew wrote. My recollection is that se was the result of Not Invented Here. There was lots of demand for vi in the internal USG version of UNIX, and it was present in exptools, but not the official distribution of UNIX. (Lots of demand for emacs, too, also in exptools.) Rather than adopt one of them, se was written. I think it appeared about UNIX 4.2. My UNIX 5.0 manual also has vi(1). Once vi was installed, demand for se went away. I'm not sure when it was dropped, but it's not in my SVID.     Mary Ann On 3/29/22 07:42, Andrew Hume wrote: > alas, no. > it should have been on some official source tapes, tho. > it was part of some office automation set of software; > maybe that was mentioned in the tapes. > > i too remember nothing about it. outside of doing it > because management wanted it, i never optionally used it. > >> On Mar 29, 2022, at 7:35 AM, arnold at skeeve.com wrote: >> >> Cool! I bet this was it! It was on a System 4 system. >> >> The commands were entered at the top of the screen. I remember almost >> nothing else about it. >> >> Is there any chance you still have the source? >> >> Thanks, >> >> Arnold >> >> Andrew Hume wrote: >> >>> se? >>> >>> this may be a consequence for using such a bland name for a screen editor, >>> but i wrote a screen editor called ’se’ in 1981-83, just after we had moved >>> from piscataway to murray hill. >>> >>> it was part of an effort to do office automation style products for Unix, >>> and came in around the time Unix transitioned from System III through >>> System 4 through the early days of System V. >>> >>> my se was not very good, but i did have denis ritchie as an early tester. From arnold at skeeve.com Wed Mar 30 15:11:31 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 29 Mar 2022 23:11:31 -0600 Subject: [TUHS] Old screen editors In-Reply-To: <7196E23A-9EE8-48F9-A851-B1CA2DF9D6D6@humeweb.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> <34e2e376-ab10-7125-ef0b-a28538e58d73@technologists.com> <202203290840.22T8euk9028535@freefriends.org> <8CD4B839-ED11-4A97-8D9A-65F78A78FB43@humeweb.com> <202203291435.22TEZ8RB021438@freefriends.org> <7196E23A-9EE8-48F9-A851-B1CA2DF9D6D6@humeweb.com> Message-ID: <202203300511.22U5BVvj016620@freefriends.org> So the question is, does anyone have a UNIX 4.0 source tape? Otherwise, I think it probably really is lost in the sands of time. Thanks, Arnold Andrew Hume wrote: > alas, no. > it should have been on some official source tapes, tho. > it was part of some office automation set of software; > maybe that was mentioned in the tapes. > > i too remember nothing about it. outside of doing it > because management wanted it, i never optionally used it. > > > On Mar 29, 2022, at 7:35 AM, arnold at skeeve.com wrote: > > > > Cool! I bet this was it! It was on a System 4 system. > > > > The commands were entered at the top of the screen. I remember almost > > nothing else about it. > > > > Is there any chance you still have the source? > > > > Thanks, > > > > Arnold > > > > Andrew Hume wrote: > > > >> se? > >> > >> this may be a consequence for using such a bland name for a screen editor, > >> but i wrote a screen editor called ’se’ in 1981-83, just after we had moved > >> from piscataway to murray hill. > >> > >> it was part of an effort to do office automation style products for Unix, > >> and came in around the time Unix transitioned from System III through > >> System 4 through the early days of System V. > >> > >> my se was not very good, but i did have denis ritchie as an early tester. > From lars at nocrew.org Wed Mar 30 15:41:38 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 30 Mar 2022 05:41:38 +0000 Subject: [TUHS] Old screen editors In-Reply-To: (Ron Natalie's message of "Tue, 29 Mar 2022 20:54:20 +0000") References: <20220329204025.6C67318C075@mercury.lcs.mit.edu> Message-ID: <7wh77gkne5.fsf@junk.nocrew.org> Ron Natalie wrote: > Noel Chiappa wrote: >>Stallman didn't _originate_ the body of stuff that eventually turned >>into ITS EMACS, although he did take over maintenance of it once it >>was rolling; and later wrote Gnu Emacs from scratch himself. > > Well, even that is a bit inaccurate. He implemented emacs by wrapping > new code around James Gosling's (also licensed as Unipress) EMACS. Here is GNU Emacs 13 with Gosling code: https://github.com/larsbrinkhoff/emacs-history/blob/sources/decuslib.com/decus/vax85b/gnuemax/emacs/src/display.c From lars at nocrew.org Wed Mar 30 15:36:29 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 30 Mar 2022 05:36:29 +0000 Subject: [TUHS] Old screen editors In-Reply-To: <20220329103902.42B9218C085@mercury.lcs.mit.edu> (Noel Chiappa's message of "Tue, 29 Mar 2022 06:39:02 -0400 (EDT)") References: <20220329103902.42B9218C085@mercury.lcs.mit.edu> Message-ID: <7wlewsknmq.fsf@junk.nocrew.org> Noel Chiappa writes: > historical aside: at one point there was a whole 'Ivory' package for > ITS TECO which could 'purify' ITS TECO code so that one copy in core > [actual, real core!] could be shared by multiple processes. There still is an Ivory package, and it's used by a few EMACS libraries. > That was used to write an EMACS-like package for the PDP-11 UNIX TECO > (but much simpler than real EMACS), which we used for quite a while > before Montgomery EMACS for UNIX showed up. ObUnix. Montgomery EMACS now shows up again, thanks to Noel. I put a copy here, which also references the origin: https://github.com/larsbrinkhoff/emacs-history/tree/sources/ana-3.lcs.mit.edu/%7Ejnc/tech/unix/emacs Montgomery wrote about the history behind his editor: https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Montgomery%20Emacs%20History.txt From thomas.paulsen at firemail.de Wed Mar 30 17:50:41 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 30 Mar 2022 09:50:41 +0200 Subject: [TUHS] Old screen editors In-Reply-To: <7wh77gkne5.fsf@junk.nocrew.org> References: <20220329204025.6C67318C075@mercury.lcs.mit.edu> <7wh77gkne5.fsf@junk.nocrew.org> Message-ID: > Well, even that is a bit inaccurate. He implemented emacs by wrapping > new code around James Gosling's (also licensed as Unipress) EMACS. its generally very well known that RMS hired a programmer doing that. Himself, he only contributed some elisp code. From ralph at inputplus.co.uk Wed Mar 30 18:37:12 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 30 Mar 2022 09:37:12 +0100 Subject: [TUHS] Old screen editors In-Reply-To: <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> References: <20220328210356.GA18426@minnie.tuhs.org> <97CCE4E5-0445-4EB0-8CAE-3C75BBF72CFE@iitbombay.org> <20220328232344.GC60301@eureka.lemis.com> <19FC5DAF-A4C7-4EE0-BF34-91B340910641@iitbombay.org> <11FBF445-4956-427E-8751-60BF5CA88116@serissa.com> Message-ID: <20220330083712.BB43D21D9C@orac.inputplus.co.uk> Hi Lawrence, > At some point we got ex/vi, but before that we got the “Rand Editor” > re, which was a perfectly functional screen editor, if you squinted a > bit. > > Does anyone here know the place of re in the history? RAND's re from 1974 had become Ned, for New Editor by 1977 when Ned's author, Walt Bilofsky, later founder of The Software Toolworks, wrote RAND report R2176. https://www.rand.org/pubs/reports/R2176.html Over the past few years Ned, a text editor utilizing the full capabilities of the CRT display, has been under development and in use at The Rand Corporation... The Ned editor runs on the PDP-11 series of computers under the UNIX operating system. It uses a CRT display to provide a two-dimensional window into a text file... ...rectangular portions of text may be opened, deleted, and moved about... The set of operations may be expanded by user-provided or system-provided text-processing programs... The screen may be divided into several editing windows... Chapter 3 has the history of IDA-CRD → Yale Editor ‘E’ → RAND editor ‘re’ → Ned. -- Cheers, Ralph.