I did not want to disrupt the FD 2 discussion, but I could not really let
this comment go unanswered:
"Smells like C++ to me. Rust in essence is a re-implementation of C++ not
C. It tries to pack as much features as it possibly can. "
It's hard for me to see how you can say this if you have done any work in
Rust and C++.
But, short form: Rust is not C++. Full stop.
I did not feel that comment should go unanswered, lest people believe it.
On Wed, Feb 01, 2023 at 01:50:05AM +0000, segaloco via COFF wrote:
> COFF'd
Thanks Matt. Yes please, C vs. Rust should mv to the COFF list.
Cheers, Warren
Hello!
I saw someone playing chess on their pdp-11 and thought it could be an
interesting project to run on my pdp-11. At this point the RK05s are not
yet running so booting unix v6 is not possible.
I then thought that if the source code could be found it might be possible
to get it to run standalone with some modifications.
After some googling I found the archive
https://www.tuhs.org/Archive/Distributions/UNSW/7/record0.tar.gz
which contained a chess.lib file. It appeared that this archive contained
source code for some kind of chess program. I have been told that it isn't
the chess written by Ken Thompson so the question is who wrote it? There
are not many comments in the code. Could be interesting to know more about
this chess implementation.
Just looking through the source files and the mk file show that it is
missing a set of files. The mk file references a set of "b"-prefixed
assembly files, bgen.s, bmove.s, bheur.s and bplay.s which are present in
the archive. But it also references a set of files with "w"-prefix, wgen.s,
wmove.s, wheur.s and wplay.s which are missing.
I also recognise that there is an include file, "old.h" that is included
from all c-modules that most likely is present in the overload.lib which
seems to be an overlay loader.
Anyone that has an idea how this thing was built once upon a time?
/Mattis
A lot of this dates back from the old “tty” days (or at least crt
terminals that were still alphanumeric). Even the concept of putting
a job in the background with & is really a feature of trying to
multiplex multiple tasks on the same dumb terminal. This is indeed
less important with windowing things like the DMDs or modern windowing
workstatiosn when you can just get another window. The Berkeley job
control was an interesting hack. For us at BRL the problem was I
absolutely detested the C shell syntax. The Korn shell hadn’t escaped
from AT&T yet, so, I spent time figuring out how that really worked in
the C shell (not really well documented), mostly by inspection, and then
reimplemented it in the Bourne Shell (we were using the System V source
code version for that). I still couldn’t get traction at BRL for
using the Bourne shell because by that time, tcsh had come out with
command line editing. So back to the shell sources I went. By this
time, 5R2 had come out so I grabbed the shell source form that. I was
very delighted to find that the macros that made C look sorta like Algol
had been unwound and the thing was back to straight C. I reworked
emacs-ish command line editing into the shell. Subsequently, I had a
nice conversation with David Korn at USENIX, being probably at that
point the two most familiar with Bourne shell job control internals. I
also sat down with the guys writing either bash or the pdksh (can’t
remember which) and explained all how this work. As a result my name
ended up in the Linux manpages which was pretty much all I found for a
while when I googled myself.
Years later, I had left the BRL, spent three years as a Rutgers
administrator and was working for a small startup in Virginia. There
was a MIPS workstation there. I was slogging along using ed (my
employees always were amazed that if there was no emacs on the system, I
just used ed, having never learned vi). Not thinking about it, I
attempted to retrieve a backgrounded job by typing “fg.” To my
surprise the shell printed “Job control not enabled.” Hmm, I say.
That sounds like my error message. “set -J” I type. “Job control
enabled.” Hey! This is my shell. Turns out Doug Gwyn put my mods
into his “System V on BSD” distribution tape and it had made its way
into the Mach code base and so every Mach-derived system ended up with
it. Certainly, I found it convenient.
There have been other schemes other than job control to multiplex
terminals. IBM in the AIX that ran on the 370/PS2/i860 had a device
called the High Function Terminal that allowed you to swap screens on
the console. When we implemented the i860 (which was an add in card
for the micro channel), we called our console the Low Function Terminal.
Then after spending some time on MIT’s ITS and TOPS20, I got intrigued
by the fact on those systems you could have a “shell” that persisted
across logins and could be detached and reattached on another device at
another time. I set about making such an implementation. Not
particularly efficient, it essentially grabbed one of the BSD ptys and
spawned the shell there and then a small alternative login shell
forwarded the real tty to that. You could then detach it leaving the
shell running on the PTY and reattach it elsewhere. Much like ITS,
on. login it reminded you that you had a detached shell running and
offered to reattach it rather than spawning a new one (complete with the
ITS-ish: space for yes, rubout for no). It never really caught on.
Oh well, pardon my ramblings.
-Ron
All, w.r.t. FD 2, if your e-mail doesn't mention file
descriptors, can you please change the subject line?
And this, in general, for all TUHS discussions :-)
Thanks! Warren
Some folks here might be interested in this. I haven't read this (not gonna
subscribe), I know nothing about the author (Bradford Morgan White), but I
saw Steve Sinofsky tweet good things about it.
The Network is the Computer
The story of Sun Microsystems and the Java programming language
https://www.abortretry.fail/p/the-network-is-the-computer
> * What do I really mean by workstation? Ex.gr. If an installation had a
> PDP-11 with a single terminal and operator, is it not a workstation? Is it
> the integration of display into the system that differentiates?
Certainly integration is critical. The display should be integral to the
terminal, not simply an available device.
Without that stipulation Ken's original single-user PDP-7 system would
count (unless, perhaps, the system had not yet been christened "Unix").
Doug
Another of Ron’s historical diversions that came to mind.
Most of you probably know of various exploits that can happen now with
setuid programs, but this was pretty loose back in the early days. I
was a budding system programmer back in 1979 at Johns Hopkins. Back
then hacking the UNIX system was generally considered as sport by the
students. The few of us who were on the admin side spent a lot of time
figuring out how it had happened and running around fixing it.
The first one found was the fact that the “su” program decided that if
it couldn’t open /etc/passwd for some reason, things must be really bad
and the invoker should be given a root shell anyhow. The common
exploit would be to open all the available file descriptors (16 I think
back then) and thus there wasn’t one available. That was fixed before
my time at JHU (but I used it on other systems).
One day one of the guys who was shuffling stuff back and forth between
MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05
file system corrupted. I found that the superblock was corrupted.
With some painstaking comparison to another RK05 superblock, I
reconstituded it enough to run icheck -s etc.. and get the thing back.
What I had found was that the output of the “mount” command had been
written on the superblock. WTF? I said, how did this happen.
Interrogating the user yielded the fact that he decided he didn’t want
to see the mount output so he closed file descriptor one prior to
invoking mount. Still it seemed odd.
At JHU we had lots of people with removable packs, so someone had
modified mount to run setuid (with the provision of only allowing
certain devices to be mounted certain places). At his point we had
started with the idea of putting volume labels in the superblock to
identify the pack being mounted. Rather than put the stuff in the
kernel right away, Mike Muuss just hacked reading it from the super
block in the usermode mount program so that he could put the volume
label in /etc/mtab. Now you can probably see where this is headed.
It opens up the disk, seeks to the pack label in the superblock and
reads it (for somereason things were opened RW). Then the output goes
to file descriptor 1 which just happens to be further in the superblock.
I figured this out. Fixed it and told Mike about it. I told him
there were probably other setuid programs around that had the problem
and asked if it was OK if I hacked on things (at the time I yet was not
trusted with the root password). He told me to go ahead, knock
yourself out.
Well I spent the evening closing various combinations of file
descriptors and invoking setuid programs. I found a few more and noted
them. After a while I got tired and went home.
The next day I came in and looked through our paper logbook that we
filled out anytime the machine was shutdown (or crashed). There was a
note from two of the other system admins saying they had shut the system
down to rebuild the accounting file (this was essentially the shadow
password file and some additional per-user information not stored in
/etc/passwd). The first 8 bytes were corrupted. Oh, I say, I think
I might know how that happened. Yeah, we thought you might. Your
user name was what was written over the root entry in the file. The
passwd changing program was one of the ones I tested, but I hadn’t
noticed any ill-effects for it at the time.
