> 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
> > My recollection is that most CP/M programs were configured via patching.
> Huh. That is interesting, it was before my time, and I never heard of this :D
Yep, it was a thing, and for /some/ programs that were originally CP/M programs (i.e., WordStar 7.0 for DOS) it continued for a long time. The WordStar 7 documentation included patch locations to use (this time, IIRC, for DOS debug.exe) to change various behaviors of the program.
Yes, it was definitely a thing. The patching code had to be in Z80/8080 machine code. I wrote higher performance keyboard and display routines for my copy of Wordstar using this feature.
Stuff like that is also cool (reminds me a bit of modding some games), patching machine code to improve performance of a compiled app? Very cool! (My dad might have done that, he has an old ZX81)
But I thought specifically patching something to configure it is such a weird concept that I never would have thought of.
The ZX81 didn't have so much software around for it - what there was mostly came on tape, or was typed in¹ on the ghastly membrane keyboard, and what there was was very limited in capability (the default RAM size was one kilobyte (yes, just 1024 bytes, though typically you'd buy a "ram pack" upgrade to 16k). Then it was very rapidly superseded by the more capable ZX Spectrum machine. So odds are your Dad didn't patch software on the ZX81 because it was usually already highly optimised to squeeze it into the tiny space available.
What was very common on those devices was using the "poke" command in BASIC to change a handful of values, but while it was possible to change code in this way it was much more common to be changing the value of variables - things corresponding to "number of lives left" and the like. Not all that different.
Fairly quickly, though, the games were entirely in machine code and used fancy loaders (still from tape mostly) so you didn't get access to BASIC. This created a market for devices that let you get at a monitor program - the "Multiface" series of addons². They had at least three generations of that device, but the company slightly weirdly evolved into a music production company³ after that, which is kind of cool.
Er, ok, I'll stop now while I still can...
Edit: PS - you should ask him about it. Tell him another former ZX81 owner says "Hi" and that my fingers still ache from that keyboard. Although I sneer a bit at its capabilities, it kicked off an interest in computing that's still paying the bills 40 something years later...
The line between "configuration" and "modding" is pretty thin.
One could say that the difference is whether the developers intended the changes you're making to be possible or not, but what about programs with dedicated modding APIs?
At the time (early to mid 1980s) I think we would say "patching". The Wordstar devs certainly did mean you to do this - the memory locations available were fully documented, and I seem to remember they supplied a small patch utility to incorporate your code into the Wordstar executable.
< 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.
I noticed this first when I assigned TZ to .tar.xz (or .tar.gz)
as I was lazy. Then things suddenly no longer worked. Turns out
TZ is ... timezone. So you should not define all variables, right?
Well ... how to know that? People can perhaps read tons of documentation,
but I want to ... minimize time investment here. So I learn mostly
by learn-and-doing. And as far as I know there is no trivial way to
know about "this can be dangerous". Those shells are fairly simple
at all times - and not that sophisticated.
TMP versus TEMP may also be trivial but ... who can remember the
differences? And why is it important?
I have come to think that environment variables are useful; I use
them all the time. But they are a bit hackish and not super-elegant
and may have side effects. This is not a very important side effect
per se, as most people will not run into issues such as TZ or having
to think which variable to use and which not, but in the moment when
you DO get surprising results, and you don't know why, this may become
a problem suddenly. I kind of semi-work around by prefixing via:
MY_
This is even less elegant, to then have e. g.:
MY_TEMP = /home/x/temp/
or something like that. But with the prefix "MY_" I rarely
run into problems. So this then becomes my main pointer,
e. g. MY_TEMP_DIRECTORY, and then TEMP and TMP may just
be aliases to that. It's a bit stupid but it is also simple
and kind of works. Beauty is not to be found here, but it is
practical and that is not a bad thing.
In my own ruby code I also have to use ENV[] sometimes, which
is a wrapper over environment variables, but I also try to
be as independent as possible from that. For instance, all
my settings are stored in simple .yml files, and these are
then used to autogenerate environment variables or handle
things in environments where there are no environment
variables available (this is sometimes the case; I had
that issue with .cgi files many years ago, where I wanted
to access all environment variables but for a reason I
don't fully remember, this was not available. Then I
transitioned into those .yml files and that problem went
away; now of course I need to load those .yml files, if
necessary, but this is trivial in ruby, YAML.load_file()
works very well for the most part, and I find this is
more reliable than depending on reading environment
variables output. On some restricted environments this
may be unavailable though; I had that on university campus
running ancient linux systems, so I have to be flexible
in this regard).
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. : )
Fun fact: "/dev/nul" (with only one L) would have worked, even if there is no directory with that name.
That's been a feature since DOS 2.0, there was even an undocumented option AVAILDEV to make the prefix mandatory, instead of having device names present everywhere. But it broke the common trick used to detect if a directory exists ("if exist c:\some\path\nul").
Unix programmer remembered that in there's no /dev/null in DOS and that it's something shorter, and tried null which worked. Didn't check the directory contents afterwards. So basically your first sentence - doesn't seem at all unlikely to me. (I mean, I think it happened to me at least once too)
I've already created a 'NULL' file, but it was not a Unix thing... It was just because I got confused if it was NULL as in the programming languages I usually use.
Part of the philosophy of the slightly odd suckless people is their projects are mostly configured by changing the source code and recompiling. This is I suppose a similar approach in a modern open source vein. Although their general asceticism makes their projects a bit of an acquired taste I suspect.
Ohh acquired taste it is.. I had two stints with suckless software. First, when i was in early twenties when I had a lot of time in the world, and thought the manliest way to talk to a machine is all through low level C code. Had a whole flow to patch it and heck the code is so well written and commented, i was able to understand it. Then, i guess life happened and i discovered more interesting stuff to spend time on.
And now in my late twenties, suckless terminal is the only one that would work reliably on a shitty old enterprise linux system at work. Yeah, we got xterm and konsole (the older one). I am seeing them in a whole different light now. I did not read the source code now and it is effectively a foreign language to me, but just being able to have modern features in it without too many dependencies is a different level of bliss. This time, I am glad I have the flexi patch to the rescue since, i passed on suckless terminal as a real alternative since I don’t want to patch it manually or solve merge conflicts!
Even though I don’t like the elitist attitude of the project, can’t deny they got a point. Why does a terminal emulator need to be so complicated!
> I don’t want to patch it manually or solve merge conflicts
I wonder, is this really such a big problem? How often do people add patches or change their config?
I've configured my st once and haven't touched that build for years. I use only few patches like scrollback, custom colortheme and a "plumb" for few scripts.
I've also had an opportunity recently, to try a "modern" and trendy terminal and I can't see myself switching to something slower (in terms of lag) and using 10x more memory and cpu even when idle for literally zero gain.
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
I wonder how many apps actually read the correct XDG environment variables and obey them, versus just hardcoding paths that match their machine’s config paths (typically ~/.config/*)
I almost want to set up a VM that sets up XDG_CONFIG_HOME as ~/.foobar and see how many apps actually respect it, and how many still write to ~/.config.
A few years ago I had a Windows box where I pointed XDG_CONFIG_HOME et al to the corresponding-ish Windows paths (AppData subdirectories, mostly) so that the many Linux-derived CLI programs I was using wouldn't clutter up my userdir, and it worked pretty well, though there were a few programs that didn't get the memo. Unfortunately I don't remember which ones they were. Most programs get it right, though!
I don’t mind ~/.* for config, especially when the config is just one or two files. What I don’t like is programs like go and cargo treating my $HOME as a dumping ground for every file they want to download and/or cache.
I don't know if anyone is actually using roaming profiles, but config should go into the %APPDATA% folder to support that. %LOCALAPPDATA% is for things that shouldn't be synced to different machines, such as caches.
It all sounds so easy, until you learn about the XDG Base Directory Specification[1]. You're actually supposed to do a whole song and dance around a hierarchical set of environment variables, associated defaults, and resolution orders.
Yea this is something I'd love to see standardised, a distro that was able to enforce a .config folder somehow would be a winner for me. Think weve probably missed the boat though.
As these things go, there obviously is a standard for this called the XDG Base Directory Specification[0], which elegantly solves almost all configuration path needs—and has been ignored, violated, or only partially implemented, since forever.
"Rewind to 1973. The operating system common on microcomputers was CP/M. The CP/M operating system had no environment variables. That sounds like a strange place to start a discussion of environment variables, but it’s actually important."
"Over time, programs were written with MS-DOS as their primary target, and they started to realize that they could use environment variables as a way to store configuration data. In the ensuing chaos of the marketplace, two environment variables emerged as the front-runners for specifying where temporary files should go: TEMP and TMP."
And before that there are a few paragraphs describing the migration of applications from i8080/Z80 based CP/M towards x86 based DOS via mechanical translation.
I was curious seeing this thread, and I just looked and don't get it either. AFAICT the CP/M references could have been entirely omitted and nothing in the narrative about TMP and TEMP would change.
Except that DOS was made to have its first programs ported from CP/M, so it’s relevant to explain that there were no environment variables to inherit from CP/M and no developer habits or program standards to inherit from CP/M programs.
Huh. That is interesting, it was before my time, and I never heard of this :D
> Huh. That is interesting, it was before my time, and I never heard of this :D
Yep, it was a thing, and for /some/ programs that were originally CP/M programs (i.e., WordStar 7.0 for DOS) it continued for a long time. The WordStar 7 documentation included patch locations to use (this time, IIRC, for DOS debug.exe) to change various behaviors of the program.
But I thought specifically patching something to configure it is such a weird concept that I never would have thought of.
What was very common on those devices was using the "poke" command in BASIC to change a handful of values, but while it was possible to change code in this way it was much more common to be changing the value of variables - things corresponding to "number of lives left" and the like. Not all that different.
Fairly quickly, though, the games were entirely in machine code and used fancy loaders (still from tape mostly) so you didn't get access to BASIC. This created a market for devices that let you get at a monitor program - the "Multiface" series of addons². They had at least three generations of that device, but the company slightly weirdly evolved into a music production company³ after that, which is kind of cool.
Er, ok, I'll stop now while I still can...
Edit: PS - you should ask him about it. Tell him another former ZX81 owner says "Hi" and that my fingers still ache from that keyboard. Although I sneer a bit at its capabilities, it kicked off an interest in computing that's still paying the bills 40 something years later...
----
¹ https://spectrumcomputing.co.uk/entry/2000265/Book/Not_Only_...
² https://en.wikipedia.org/wiki/Multiface
³ https://en.wikipedia.org/wiki/Romantic_Robot
One could say that the difference is whether the developers intended the changes you're making to be possible or not, but what about programs with dedicated modding APIs?
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 noticed this first when I assigned TZ to .tar.xz (or .tar.gz) as I was lazy. Then things suddenly no longer worked. Turns out TZ is ... timezone. So you should not define all variables, right? Well ... how to know that? People can perhaps read tons of documentation, but I want to ... minimize time investment here. So I learn mostly by learn-and-doing. And as far as I know there is no trivial way to know about "this can be dangerous". Those shells are fairly simple at all times - and not that sophisticated.
TMP versus TEMP may also be trivial but ... who can remember the differences? And why is it important?
I have come to think that environment variables are useful; I use them all the time. But they are a bit hackish and not super-elegant and may have side effects. This is not a very important side effect per se, as most people will not run into issues such as TZ or having to think which variable to use and which not, but in the moment when you DO get surprising results, and you don't know why, this may become a problem suddenly. I kind of semi-work around by prefixing via:
This is even less elegant, to then have e. g.: or something like that. But with the prefix "MY_" I rarely run into problems. So this then becomes my main pointer, e. g. MY_TEMP_DIRECTORY, and then TEMP and TMP may just be aliases to that. It's a bit stupid but it is also simple and kind of works. Beauty is not to be found here, but it is practical and that is not a bad thing.In my own ruby code I also have to use ENV[] sometimes, which is a wrapper over environment variables, but I also try to be as independent as possible from that. For instance, all my settings are stored in simple .yml files, and these are then used to autogenerate environment variables or handle things in environments where there are no environment variables available (this is sometimes the case; I had that issue with .cgi files many years ago, where I wanted to access all environment variables but for a reason I don't fully remember, this was not available. Then I transitioned into those .yml files and that problem went away; now of course I need to load those .yml files, if necessary, but this is trivial in ruby, YAML.load_file() works very well for the most part, and I find this is more reliable than depending on reading environment variables output. On some restricted environments this may be unavailable though; I had that on university campus running ancient linux systems, so I have to be flexible in this regard).
So I guess the moral of the story is: Ensure they always point to the same path, or else...
Why do we need to adopt extant standards? (I was going to ask, why standardise? But realised that might confound the North Americans. : )
I assume that they first tried /dev/null which failed, so then moved onto just plain null?
Otherwise it would not make sense that a unix programmer did this. More likely ula dos programmer misspelled NUL as null.
That's been a feature since DOS 2.0, there was even an undocumented option AVAILDEV to make the prefix mandatory, instead of having device names present everywhere. But it broke the common trick used to detect if a directory exists ("if exist c:\some\path\nul").
I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.
And now in my late twenties, suckless terminal is the only one that would work reliably on a shitty old enterprise linux system at work. Yeah, we got xterm and konsole (the older one). I am seeing them in a whole different light now. I did not read the source code now and it is effectively a foreign language to me, but just being able to have modern features in it without too many dependencies is a different level of bliss. This time, I am glad I have the flexi patch to the rescue since, i passed on suckless terminal as a real alternative since I don’t want to patch it manually or solve merge conflicts!
Even though I don’t like the elitist attitude of the project, can’t deny they got a point. Why does a terminal emulator need to be so complicated!
https://github.com/bakkeby/st-flexipatch
I wonder, is this really such a big problem? How often do people add patches or change their config?
I've configured my st once and haven't touched that build for years. I use only few patches like scrollback, custom colortheme and a "plumb" for few scripts.
I've also had an opportunity recently, to try a "modern" and trendy terminal and I can't see myself switching to something slower (in terms of lag) and using 10x more memory and cpu even when idle for literally zero gain.
I almost want to set up a VM that sets up XDG_CONFIG_HOME as ~/.foobar and see how many apps actually respect it, and how many still write to ~/.config.
Interfacing with people is never easy.
[1]: https://specifications.freedesktop.org/basedir/latest/
[0]: https://specifications.freedesktop.org/basedir/latest/
The whole story is that Microsoft just never bothered to standardize, despite using it themselves.
"Over time, programs were written with MS-DOS as their primary target, and they started to realize that they could use environment variables as a way to store configuration data. In the ensuing chaos of the marketplace, two environment variables emerged as the front-runners for specifying where temporary files should go: TEMP and TMP."
And before that there are a few paragraphs describing the migration of applications from i8080/Z80 based CP/M towards x86 based DOS via mechanical translation.
It could simply be: When envars were added to MSDOS…