Today I came across an article about the MGR window system for Unix:
One thing that interested me was a note that some versions worked on the
> The window system ran on many different hardware platforms, at least
> these: Sun 3/xx workstations running SunOS, which was the the original
> development platform, Sun SPARCstations (SunOS and then ported by me to
> Solaris), Intel x86 based PCs (Coherent, Minix, FreeBSD or Linux),
> Atari ST (under MiNT), AT&T UnixPC (SysV) and the Macintosh.
As the owner of a Macintosh Plus, I think it would be a very interesting
thing to experiment with, but I haven't had much luck finding any more
information about it.
Does anyone know more about MGR, particularly on the Mac? That page has
the source for MGR 0.69, but there's no mention of the Macintosh in it
(aside from comments about how it was supported on older versions...)
I know something!
On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote:
> > o why CTRL/S and CTRL/Q are used for flow control in a shell command
> > line session
> Also would be happy to know.
But I don't know the answer to Ctrl-D. :( And also the bus error
and maybe the segmentation fault if it hasn't to do with a segment
When You Find Out Your Normal Daily Lifestyle Is Called Quarantine
I have on my hands many images of tapes that seems to have been written
by various implementaions of dump. I see the magic numbers 60011 and
60012 in little and big endian at offsets 18 (16-bit version?) and 24
(32-bit version?). I don't know the dating of the tapes, but around
1980 would be a reasonable guess.
Are there some easy to use (ready to run on a modern Unix) tools to
extract files from such tape files?
I'm not looking to restore a file system on disk, just extract the
I'm hoping some of the BSD people here may know.
I've been keeping a git mirror of the PCC Revived project, but in the
past month or so it's gone dark. The website is no longer there, the
CVS repos don't answer, and an email to the mailing list went unanswered.
Does anyone know anything about it? Did it move to somewhere else?
I use pcc for testing, it's much faster than GCC and clang.
And in general, I think it's a cool thing. :-)
Brian's tribute to the brilliant regex mechanism that awk borrowed
from egrep spurred memories.
For more than forty years I claimed credit for stimulating Ken to
liberate grep from ed. Then, thanks to TUHS, I learned that I had
merely caused Ken to spring from the closet a program he had already
made for his own use.
There's a related story for egrep. Al Aho made a deterministic
regular-expression recognizer as a faster replacement for the
non-deterministic recognizer in grep. He also extended the domain of
patterns to full regular expressions, including alternation; thus the
"e" in egrep.
About the same time, I built on Norm Shryer's personal calendar
utility. I wanted to generalize Norm's strict syntax for dates to
cover most any (American) representation of dates, and to warn about
tomorrow's calendar as well as today's--where "tomorrow" could extend
across a weekend or holiday.
Egrep was just the tool I needed for picking the dates out of a
free-form calendar file. I wrote a little program that built an egrep
pattern based on today's date. The following mouthful for Saturday,
August 20 covers Sunday and Monday, too. (Note that, in egrep, newline
is a synonym for |, the alternation operator.)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$)
(^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$)
It worked like a charm, except that it took a good part of a minute to
handle even a tiny calendar file. The reason: the state count of the
deterministic automaton was exponentially larger than the regular
regular expression; and egrep had to build the automaton before it
could run it. Al was mortified that an early serious use of egrep
should be such a turkey.
But Al was undaunted. He replaced the automaton construction with an
equivalent lazy algorithm that constructed a state only when the
recognizer was about to visit it. This made egrep into the brilliant
tool that Brian praised.
What I don't know is whether the calendar program stimulated the idea
of lazy implementation, or whether Al, like Ken before him with grep,
already had the idea up his sleeve.
Hello everyone! I’ve been digging into text editor history, and I found:
“This provided another huge step forward in usability and allowed us to
maintain our modeless approach to screen editing, which was, we feel,
superior to the Vi approach.” from https://www.coulouris.net/cs_history/em_story/
This makes me want to know em’s history outside the usual precursor-to-vi narrative. Does anyone know much about the timeline of em from 1971 (QMC Unix installation) to 1976 (Intro to W M Joy @ UCB)? And does anyone know of developments to it after 1976-04-29? That’s the last date within text in the https://www.coulouris.net/cs_history/em_story/emsource/ files. (Also grumble grumble broken touch feature detection in that shar, which indicates last mod of 1996-02-18).
Anyone other than Coulouris used em in the last 45 years?
> Message: 4
> Date: Wed, 10 Aug 2022 12:29:24 +0200
> From: Holger Veit <hveit01(a)web.de>
> Subject: [TUHS] PCS Munix kernel source
> Hi all,
> I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to
Thank you for sharing this work, most impressive!
> MUNIX was an AT&T SVR3.x implementation ...
Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3).
> The interesting feature of this kernel is the integration of the
> Newcastle Connection network
One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation.
My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail.
I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files?
Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership?
The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?
> And I've received the documents! This is a pastebin with the rough contents of the documentation package.
> https://pastebin.com/jAqqBXA4 <https://pastebin.com/jAqqBXA4>
> Now for some analysis:
I’m interested in the journey of SysV IPC. So far I have established that these originated in CBUnix, with a lot of thinking on how to optimize these around the time that Unix 3.0/4.0/5.0 happened. They did not appear in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that it was not included there either.
This would make Unix 5.0 / SysV R1 the first release with what is now known as SysV IPC. The PDP11 version of R1 has the CBUnix version of shared memory, as the VAX version did not make sense in the limited address space of the PDP11.
From the pastebin summary, it would seem that IPC is not in this documentation either? That would be surprising, and reopens the possibility that IPC was part of Unix 4.0
> I've always believed that pic was so well designed
> because it took a day to get the print out (back then),
I'm afraid this belief is urban legend. Credit for pic is due 100% to
Kernighan, not to the contemporary pace of computing practice.
Even in the 1950s, we had one-hour turnaround at Bell Labs. And the
leap from batch processing had happened well before pic. Turnaround on
modest Unix source files and tests has changed little in the past