> In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes
I don't know any Unix examples, but DTSS (Dartmouth Time Sharing
System) "communication files" were used for the purpose. For a fuller
story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf
> This is probably a bit more Plan 9-ish than UNIX-ish
So it was with communication files, which allowed IO system calls to
be handled in userland. Unfortunately, communication files were
complicated and turned out to be an evolutionary dead end. They had
had no ancestral connection to successors like pipes and Plan 9.
Equally unfortunately, 9P, the very foundation of Plan 9, seems to
have met the same fate.
> segaloco wrote:
> In the annals of UNIX gaming, have there ever been notable games that
> have operated as multiple processes, perhaps using formal IPC or even
> just pipes or shared files for communication between separate processes
> (games with networking notwithstanding)?
The machine of the DSSR/RTS group at MIT-LCS, Steve Ward's group (an -11/70
running roughly PWB1) had an implementation of a form of Perquackey:
that was a multi-player game; I'm pretty sure there was a process per player,
and they communicated, I'm pretty sure, through pipes, not files - there was
certainly no IPC in that system.
IIIRC, the way it worked was that there was a parent process, and it spawned
a child process for each terminal that was playing, and the children could
all communicate through pipes. (They had to communicate because in that
version, all the players shared a single set of dice, and once one person had
played a word, the other players couldn't play that word. So speed was
important in playing; people got really addicted to it.)
Alas, although their machine was very similar to CSR's (although ours was an
-11/45 with an Able ENABLE and a lot of memory, making it a lot more like a
/70), and we shared most code between the machines, and I have a full dump of
the CSR machine, we apparently didn't have any of the games on the CSR
machine, so I can't look at the source to confirm exactly how it worked.
I just saw this over on dragonflydigest.com:
It's an article from 2007 about the history and genesis of the Colossal
Cave Adventure game - replete with lots of pics. What I found
fascinating was that the game is based on the author's actual cave
explorations vis a vis the real Colossal Cave. Gives you a whole new
appreciation for the game.
My question is do y'all know of any interesting backstories about games
that were developed and or gained traction on unix? I like some of the
early stuff (wumpus, in particular), but know nothing of origins. Or,
was it all just mindless entertainment designed to wile away the time?
Spacewar, I know a bit about, but not the story, if there is one...
Maybe, somebody needed to develop a new program to simulate the use of
fuel in rockets against gravity and... so... lunar lander was born? I
dunno, as somebody who grew up playing text games, I'd like to think
there was more behind the fun that mindless entertainment... So, how
about it, was your officemate at bell labs tooling away nights writing a
game that had the whole office addicted to playing it, while little did
they know the characters were characterizations of his annoying neighbors?
If you don't mind, if you take the thread off into the distance and away
from unix game origins, please rename the thread quickly :).
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.
Herewith some interesting (somewhat) contemporary papers on early windowing systems:
1. There was a conference in the UK early in 1985 discussing the state of window systems on Unix. Much interesting discussion and two talks by James Gosling, one about NeWS (then still called SunDew), and one about what seems to be SunWindows. It would seem then that these were developed almost in parallel.
2. Then there is a 1986 paper by James Gettys, discussing the 18 month journey towards X10. In particular it focuses on the constraints that Unix set on the design of the X system.
3. Next is the 1989 NeWS book that has a nice overview and history of windowing systems in its chapter 3:
Both the UK conference and the NeWS book mention a Unix kernel-based windowing system done at MIT in 1981 or 1982, “NU" or “NUnix”, by Jack Test. That one had not been mentioned before here and may have been the first graphical windowing work on Unix, preceding the Blit. Who remembers this one?
4. Finally, an undated paper by Stephen Uhler discussing the design of MGR is here:
I’ve not included Rob Pike’s papers, as I assume they are well known on this list.
Some of the above papers may be worthy of stable archiving.
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
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?
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.