> 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
zabzonk 2 hours ago [-]
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.
Semaphor 46 minutes ago [-]
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.
matt_kantor 29 minutes ago [-]
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?
zabzonk 8 minutes ago [-]
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.
fooqux 37 minutes ago [-]
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.
xg15 2 hours ago [-]
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...
QuantumNomad_ 2 hours ago [-]
> 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.
Hendrikto 28 minutes ago [-]
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more project adopt it, even holdouts like Firefox.
user3939382 14 minutes ago [-]
I contemplated for years and eventually saw someone implement a transparent kernel redirect for programs reaching for ~/.*
fredoralive 2 hours ago [-]
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.
analog_daddy 53 minutes ago [-]
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!
Well, they are supposed to be all in .config, problem is many app developers think they are special little boys that deserve its own directory
delta_p_delta_x 36 minutes ago [-]
%LOCALAPPDATA% on Windows. Or better still, use GetAppContainerFolderPath or SHGetKnownFolderPath with FOLDERID_LocalAppData.
delusional 26 minutes ago [-]
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.
9dev 1 hours ago [-]
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.
Say what you want about AI but one nice aspect of it is that it is more likely to follow these kinds of standards than humans.
mort96 55 minutes ago [-]
You would've preferred binary patching of the executable? Really?
Jedd 2 hours ago [-]
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. : )
lelanthran 2 hours ago [-]
>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
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.
rep_lodsb 39 minutes ago [-]
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").
3form 1 hours ago [-]
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)
jtoledo 2 hours ago [-]
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.
cachius 60 minutes ago [-]
What text was in there that he tried to discard?
NSPG911 2 hours ago [-]
always shove it to `%LOCALAPPDATA%/Temp`, or `~/AppData/Local/Temp`, and don't think otherwise
Rendered at 12:15:07 GMT+0000 (Coordinated Universal Time) with Vercel.
Huh. That is interesting, it was before my time, and I never heard of this :D
But I thought specifically patching something to configure it is such a weird concept that I never would have thought of.
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?
So I guess the moral of the story is: Ensure they always point to the same path, or else...
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
Interfacing with people is never easy.
[1]: https://specifications.freedesktop.org/basedir/latest/
[0]: https://specifications.freedesktop.org/basedir/latest/
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").