Also, storing the config file in the program folder doesn’t work well with multiple users who each wants their own config.
Let me clarify - I was not doubting Trumgottist. I was finding the rule itself silly, and fail to see the reasoning. Because, as I said, isn’t the program folder the most reasonable place for a config file?
Also to clarify (because your terse “no” leads me to believe I was misunderstood) I’m not speaking against WFrotz for having this rule; I’m showing my perplexity that this rule exists for major OS developers.
I can see that, certainly. Is that the reasoning behind it? The sole reasoning?
EDIT - Zarf, you say “the program folder may be read-only”, not “must be”. Is that a typo or is the read-only state optional? 'Cause that’d make more sense - if the program folder is (optionally) defined as read-only, then yes, I’d expect not to be able to write anything in it.
There’s some security concerns as well (since Vista, you need admin privileges to write in the program folder, so not all users (or programs) are allowed to do that - and that folder protection has been beefed up for each version of Windows). I don’t know any operating systems well besides Windows (including old versions and DOS) and Mac OS X, but I have the impression that this kind of setup is common and that it’s the DOS/Windows 9x way of doing things (config files next to the executable) that’s the odd one out.
In old versions of Windows it’s not read-only, but in current versions it is.
Thank you for going into it. It just came as a total surprise to me. I could certainly understand why other programs would not be allowed to write in a program folder, but the program itself?.. Ah well, these guys who’ve been doing these things for +20years must have their reasons, hey? 
The correct place to put config files is in the user’s home directory, $HOME. /home/username in Unix systems, and C:\Users\Username in Windows. In Windows, it’s usually C:\Users[username]\AppData which holds program data. Or alternatively C:\Users[username]\Documents.
Being able to freely edit the contents of the prgram files folder is, really, a security hole that was plugged with Vista and UAC. It helps stop malicious code from changing the contents of the program files folder, which could (for instance) replace your web browser with a patched version that carbon copies your data to a third party. Keeping user-editable data separate from the actual program binaries with different permissions is a pretty normal and necessary security measure.
Well, that explains why the programs I install keep installing data in AppData and Roaming and sometimes games save their games in Documents -against my express wish-.
It’s so untidy. 
I mean, if it’s the way it is, fine, it’s the way it is. But it feels underhanded, sneaky and dirty.
I don’t see why it’s untidy to write user data to the user folder and program data to the program folder?
It’s a personal opinion, I guess (we’re still entitled to those, right? I’m not advocating, I’m commentating - this seems to be news only to me, but it’s still news and I’m still reacting to it). I find it untidy because I want everything to do with that one program to be in that one place. I dislike it when programs scatter information all over my computer, especially without my knowing. I would have the user folder inside the program folder. I did wonder why Windows Frotz was keeping my settings, at a time when I actually wanted to delete the whole thing, and was quite annoyed to find that it had installed itself somewhere into my computer without telling me.
Of course, now that I know that this is a rule most programs adhere to, it will make it much easier for me to manage things; I now know where to look.
(I recently had a lot of grievances with nitfol, which overrode my extensions for ZCode games and Glulx games and failed to work. Without asking me. It was difficult to set up everything just right again, particularly because I’ve set up something nice where right-clicking a Glulx game gives me a choice of three interpreters. My issue really, I guess, is programs going over my head and doing what they want without asking me. I’m the only person using this computer, therefore anything that exists to facillitate multi-user accounts will only be a hindrance to me - shouldn’t I be able to decide, based on the usage that I make of my computer and based on the assumption I’m not a complete computer illiterate, where to install what I want to install?)
We’re getting a bit off topic now, but…
Where to put saved games is a tricky one if you want to play by the rules. (For most games that isn’t related to Frotz, throwing up a standard file save dialogue would be odd - and not possible for fullscreen games - and most modern games do autosave.) Microsoft have had different recommendations through the years - I think Documents was the recommended place to put it in a few Windows versions (but like you, I always disliked that). There is a special folder for saved games, but most games ignore that one (and it doesn’t exist before Vista). When I had to decide on a location for the game engine I made, I went with AppData.
Well, that’s an assumption MS and Apple (and most developers really) haven’t made since the 90s. And for good reason. The idea is to make things easier to use. You and I don’t always agree with their solutions to accomplish that, but I think it’s a good goal.
I’m guessing you started out with a Unix-like system? We humans make habits that help shape how we view the world. Growing up with MS-DOS (that didn’t separate user data and program data), I very much felt like Peter when moving on to modern operating systems. But I’ve now become used to how things are and don’t mind it anymore.
Multiple user accounts are not just a convenience for shared computers, they’re a necessary security measure for any computer connected to the internet. Pre-UAC Windows was a complete mess; towards the end, it was almost impossible to keep a Windows XP machine uninfected, and any and all malicious code could then subvert system software easily. UAC doesn’t necessarily stop all attacks, but it makes an impact. It also ensures that naive malicious software that tries to mess with system files doesn’t work by default, which is a good thing. I’m not in love with the way MS organised how those files get arranged, but whatever.
While Windows software can write anywhere in the user folder if it wants to, well-behaved software writes configuration files and user data to one of four places: AppData/Local, AppData/LocalLow, AppData/Roaming, and Documents. The three AppData folders are for all intents and purposes identical, the only difference is that, on a local area network where user accounts can move from one machine to another, the Roaming folder gets uploaded to the server so that it “roams” with the user between different machines. Documents is supposed to be where programs stash things that users may want to directly access (Such as saved games, screenshots, logs).
I kinda agree. I’ll comment on a few things, but I’m satisfied and I’d like to thank you and Sequitur for helping me understand this thing I didn’t know about.
I do know that there’s no telling what sort of idiot mistake people will do - and I’ve made more than a few, and not all of them all that long ago! I just wish I had the option, you know?, the option to go “I know what I’m doing. Give me the benefit of the doubt. If I screw up I’ll have no one but myself to blame”.
I actually started with MS-Dos just like you. 
I like control, but I’m not hardcore about it.
I see! That does make good sense… I still wish it were otherwise, but it makes good sense.
I wrote that in response to Sequitur’s “I don’t see why it’s untidy to write user data to the user folder and program data to the program folder?”, my theory being that the difference in background being why they can’t understand your point of view. That you have a DOS background is clear.
Ah, so you did, so you did, quite right, quite right. My mind must have been wondering when I read that part of your post.
It’s possible for the executable to also be written to AppData. This is what I do with Kerkerkruip. It means installing it doesn’t require any permissions.
I think for programs like Frotz which can be run without installing, ideally it could detect if it had been installed or not, and save to AppData normally, or to the executable’s directory only if it’s being run from a removable disc.
Oh I’m young enough to have started out with real Windows and not DOS, but I’ve spent enough time with Unixesque OSes and actively prefer them.
Another new release of Windows Frotz:
http://ifarchive.org/indexes/if-archiveXinfocomXinterpretersXfrotz.html
http://www.davidkinder.co.uk/frotz.html
There are only two small changes this time:
- Font sizes larger than 28 points can now be selected in the options dialog.
- The implementation of the print_table opcode now behaves sensibly when called for the lower window: the contents of the table are printed to the lower window with a carriage return after every row in the table except the last.
Hooray, always happy to see interpreter updates!
After updating a few other Windows ports of interpreters earlier this year, I’ve also now updated Windows Frotz, as described below. Windows Frotz can be downloaded from the IF-Archive, in https://ifarchive.org/indexes/if-archive/infocom/interpreters/frotz/
The changes in detail are:
-
Support for high DPI and changing DPI with Windows 10: if the DPI is changed (from the Display settings app, or by moving the window from one monitor to another with a different DPI) then the interpreter rescales itself appropriately.
-
The toolbar images have been redrawn for a more modern look.
-
If Frotz is running an Infocom game that attempts to play a sound effect (that is, Lurking Horror or Sherlock) but no Blorb sound file can be found, a message comes up telling the user where to download the sound files from.
-
Added a Russian translation of the UI by Nikita Tseykovets.
-
Error messages of the form "@Attempt to address illegal object " now respect the interpreter’s error settings.
4 Likes
I forgot to add that the German and Spanish translations for Windows Frotz are slightly incomplete, as I haven’t been able to contact the people who originally translated it. If you speak either of these languages and would like to help to complete the translations, let me know.
It seems you have the bug I reported to David Griffith for the Unix Frotz:
https://gitlab.com/DavidGriffith/frotz/issues/84