Another thing I liked about the ADVENT FORTRAN code is it would detect if its static tables were initialized or not. If not, it would initialize the statics, and then write the executable out overwriting the executable. Then, the next time it ran, it was already initialized!
I used this trick in my editor in 80s. It didn't have a configuration file, one just set ones configuration in the editor, then hit a command to rewrite the executable. It worked like a champ! This greatly speeded up load times for the editor as doing a file lookup for the configuration file on a floppy disk was very slow.
Sadly, this all ended when the operating system would shut down an executable that attempted to modify itself as "malware".
There was a FORTRAN version of ZORK (aka DUNGEON) by Bob Supnik at DEC, which was limited in some ways compared to the MDL version, but also had a "GDT" debug mode where you could inspect and control things like the thief and the troll and the cyclops and the robot.
I think you could tell them to perform commands, even become one of them, or have them pick you up and carry you around. I have a vague memory of being carried around by a robot in Zork, but I can't remember which version, or if that was part of the game or GDT. Something like "ROBOT, TAKE ME". Then it could carry you places you couldn't walk to yourself.
Bob Supnik started translating ZORK to FORTRAN in 1977, and published it on the DECUS tape library in 1978.
You could type "GDT" at any time and it would go:
A booming voice calls out, "Who summons the right hand of the translator?
State your name, cat, and serial number!"
SUPNIK,BARNEY,70524
At your service!
GDT>
“Barney” was Supnik’s cat; 70524 his DEC badge number.
>GDT dates from a very early version of the game, in fact, before the
game was actually finished. I realized early on that debugging an
interactive program with the traditional PRINT statements was going to
be very cumbersome, and that the interactive debug tools of the day
(1978) had no semantic understanding of the program. GDT was the
answer. It enabled me to track when things went wrong, and to simulate
parts of the game that hadn't been implemented yet.
>Originally, GDT was just a command like any other. Once the game was
released, players quickly realized that it offered a simple way to short
circuit the game and to undo mistakes. Lost something to the thief?
Take it back. Getting killed too often? Turn on immortality mode. So
I implemented a variety of challenges to prevent players from entering
GDT without making the mechanism too difficult for me to remember. I
think the INCANT mechanism might have been the final PDP-11 challenge.
>When I did the VAX version, I abandoned all that and went back to GDT as
universally enabled, under control of a run time flag, GDTFLG. I think
I intended to turn GDTFLG off before releasing the VAX version, so that
it would be impossible to get into GDT without patching the binaries;
but in fact the final VAX sources have GDTFLG=1.
I wish I knew which version of ADVENT was the one I looked at. All I recall is it was in FORTRAN circa late 70s, and it ran on the univeristy PDP-10 (which meant it was FORTRAN-10).
Another thing I liked about the ADVENT FORTRAN code is it would detect if its static tables were initialized or not. If not, it would initialize the statics, and then write the executable out overwriting the executable. Then, the next time it ran, it was already initialized!
I used this trick in my editor in 80s. It didn't have a configuration file, one just set ones configuration in the editor, then hit a command to rewrite the executable. It worked like a champ! This greatly speeded up load times for the editor as doing a file lookup for the configuration file on a floppy disk was very slow.
Sadly, this all ended when the operating system would shut down an executable that attempted to modify itself as "malware".