Posted by ChristopherDrum 5 days ago
There is also a detailed write-up about the state of the original source code, the porting process, and the invaluable role Justine Tunney's Cosmpolitan project played in bringing the Zork trilogy (and more) to Windows/Mac/Linux/bsd for arm/x86 machines over the course of a lazy Sunday.
I first played the game, way back - prior to having read the novel. It was mind-blowing. I had no idea what was going on but I got a real sense that it could be pretty funny if I did. So I read the novel eventually, and it was as good as I expected. I don't think I'd gone back to play the game until this week, though.
HHGTTG is a .z3 game and is compatible with this project's build of the Infocom source, should you get the urge to play again in another 30 years.
gcc -Werror=missing-declarations -Werror=redundant-decls
I recommend this for well-maintained code too, just as another way to keep the code smells away. For a lot of projects this will only require adding a bit of `static` that you were too lazy to write.
For well-maintained code, -Werror=all is expected, but switching to it is not trivial in a nasty codebase. It's still worth doing, but it's a whole project.
-Werror=extra is also a good idea once your codebase is clean for all of the above, but you will need to learn to write suppressions, and some of those are compiler-specific.
-Werror=format=2 (requires adding attributes) and -Werror=unused (weird version-dependent interactions with other warnings, so better enable it explicitly) are next, then there's a long tail of obscure warning options that should be considered; many are useful but others should be explicitly disregarded (one particular question of interest that stick out: how hard is it to suppress/restore this within a macro).
Past the trivial, Clang's warnings tend to suck (and they often refuse patches even for parity); GCC's are more useful due to the strength of history. It's still worth using Clang just for the fact that it uses different logic for triggering warnings (and also different warnings available; -Weverything is great for discoverability); just be aware that `__has_warning` isn't very useful (what we really need is `__has_warning_that_actually_works_correctly`, which requires hard-coding known-bug-free compiler versions).
K&R C has no concept of THEN. That's a peculiarity of the ZIP source code, defined as a pure no-op:
#define THEN
What we're seeing here is 40 year old code compile and run with minimal effort. Largely because the C language has respected backwards compatibility.
Yes, there were breaking changes along the way, but they were trivial to resolve in hours. And (more interesting) the author believed that to be true and so persevered.
I saw this recently as well. I run a lot of programs on Windows. Many are 32 bit, written in the 90s for Windows 95, or 98. They all still run. Microsoft bends over backwards to keep things compatible.
I also get to write a lot of web API clients. I tell customers that it won't work forever. Web APIs are constantly changing. The service (especially Google) will change something soon to break it.
The people building those APIs are expecting only currently-maintained apps to run. They have no concept (or experience) of 40 or 30 year old code "just running". Crumbs, if you get 5 years out an API client you're doing well.
Working on this kind of got me re-thinking my approach to my personal projects again. What can I do today to best ensure my own code will be this easy to run in 30 years? As a corollary to that, what can I build today that will be interesting enough to want to run again in 30 years?
It's the era of constant updates. I find it pretty annoying.
In the enterprise world lots of software is more than a decade old, and no one is prepared to "update" it. The mindset in that space is for things to have longevity.
It's more of a mindset I think. Microsoft is clearly very focused on keeping things running. Apple (as a contrast example) is happy to change architecture, remove 32 bit support, and so on.
Even Microsoft seems to be slipping. It seems like these days the (unstoppable!) Windows updates may actually change functionality and UI, which was much less common in the past. And of course the new versions of Windows are more aggressive about updating. They still maintain backwards compatibility for running third-party programs, but I feel like their mindset used to include more stability in their own software as well.
A dacade later, ztools was able to read it's dictionary, and people would ask what it was all about... We distributed libraries on bbses, Napster, all manner or ways to get the media out so people could laugh... And most of them found their way back to the Adams books and recordings. We never distributed the books, unless the 2nd half was deleted... ( Waldens, which was beside Egghead, would to though spurts where Adams books would make the best sellers lists, and fade, and enjoy multiple resurgences. )
Go and buy the books (Douglas Adams) and use them for gifts.
* TinyBasic (1975) was specified (and sometimes implemented) as a VM https://en.wikipedia.org/wiki/Tiny_BASIC
* Apple Pascal (1979) was a UCSD Pascal system. https://en.wikipedia.org/wiki/Apple_Pascal
* The COSMAC VIP computer/console's (1977) games were programmed in CHIP-8, a VM. https://en.wikipedia.org/wiki/CHIP-8
* Scott Adams' text adventures (1978+) used an application-specific VM. https://en.wikipedia.org/wiki/Adventure_International
* Wozniak's SWEET16 contained in Apple II Integer Basic (1977) https://en.wikipedia.org/wiki/SWEET16
* If you count Forth as a VM, it was pretty common. https://en.wikipedia.org/wiki/Forth_(programming_language)
I wonder if the wikipedia articles are lucky enough to be good...
(2) Scott Adams made an adventure interpreter was was similar but less sophisticated than the z-machine but similarly portable, in fact you could write a Scott Adams interpreter in BASIC [1] but he also wrote interpreters in assembly for the most popular platforms
https://6502disassembly.com/a2-scott-adams/interp.html
(3) Infocom developed the games on a PDP-10 machine which might be the last general purpose computer that survived with other than the 8-bit byte. (Though it had bitwise addressing which helped it cope with the industry going in that direction).
[1] Notably if you tried to write an adventure game in straight up BASIC you'd struggle. It's not like you could look up a verb in a hashtable and dispatch to subroutine. You'd be writing incredibly long if-then-else ladders nested inside if-then-else ladders which is bad enough in a civilized language.
"Dave Lebling, co-author of Zork and co-founder of Infocom, gives a postmortem talk on the classic text adventure. Lebling, who currently works as a senior principal software engineer at BAE Systems, created the "grue," co-authored Zork I-III and wrote seven other text adventures. He plans to give an hour-long talk explaining, among other things, the creation of both the mainframe and microcomputer versions of Zork, the trials and tribulations of coding a cutting-edge text parser, and what it was like to experiment with self-publishing at a time when most PC games were sold in hand-packed plastic bags.
https://archive.org/details/creativecomputing-1980-07/page/n...
https://archive.org/details/byte-magazine-1980-12/page/n193/...
https://www.atarimagazines.com/compute/issue67/331_1_Compute...
An Infocom adventure on a machine with 16k RAM also had frequent pauses to fetch from floppy, but it was much more tolerable.
Re verb lookups in Basic: you could use DATA statements and READ in a FOR loop for lookup. I don't know what was typical but that's what I recall from some examples.
[~/Downloads] $ chmod +x zork*
[~/Downloads] $ ./zork1
Cannot open assembly './zork1': File does not contain a valid CIL image.
sudo wget -O /usr/bin/ape https://cosmo.zip/pub/cosmos/bin/ape-$(uname -m).elf
sudo chmod +x /usr/bin/ape
sudo sh -c "echo ':APE:M::MZqFpD::/usr/bin/ape:' >/proc/sys/fs/binfmt_misc/register"
sudo sh -c "echo ':APE-jart:M::jartsr::/usr/bin/ape:' >/proc/sys/fs/binfmt_misc/register"
West of House You are standing in an open field west of a white house, with a boarded front door. There is a small mailbox here.