> My recollection is that most CP/M programs were configured via patching. At least that’s how I configured them. I remember my WordStar manual coming with details about which bytes to patch to do what. There was also a few dozen bytes of patch space set aside for you to write your own subroutines, in case you needed to add custom support for your printer.

Huh. That is interesting, it was before my time, and I never heard of this :D

A great example of a decision that likely received little to no thought from an early developer but that has long legs and will stick around forever.

< Rewind to 1973. The operating system common on microcomputers was CP/M

OK. I love Raymond’s blog but this is crazy. Microcomputers existed only as a prototype in 1973 (things like Intel’s Intellec dev systems) and there were no operating systems for them. Strictly speaking, Kildall did start developing CP/M in 1973, but at that point it ran only on a simulator on a PDP-10 mainframe.

1979, sure. 1973? Way too early…

I didn't know it was such a chaos.

So I guess the moral of the story is: Ensure they always point to the same path, or else...

> My recollection is that most CP/M programs were configured via patching.

I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.

I'm confused by the CP/M reference. Author says it'll be important later then proceeds to explain how it had nothing to do with CP/M or the 8080 CPU.

1995-ish. Telstra (Australia Telecom). Probably about 50k desktop computers across the organisation. One day a small file turned up in everyone's network home directory called null. A *nix person had evidently had a go at writing a .bat file.

Why do we need to adopt extant standards? (I was going to ask, why standardise? But realised that might confound the North Americans. : )

always shove it to `%LOCALAPPDATA%/Temp`, or `~/AppData/Local/Temp`, and don't think otherwise