You're viewing a single thread.
Don't forget that appdata nowadays has 3 sub folders, local, locallow, and roaming.
Also there's C:\programdata
Also some programs just store it in the user folder, the documents folder, or games/ my games folder if they are a game.
It could also be stored in the registry.
Oooh the registry is even more fun.
- HKLM, HKCU? These are statements dreamt up by the utterly deranged
- Store it in software, make your own root folder
- Also for 32 bit programs there wow6432node
- There's also the policies section, but this kind of makes sense to have it split off
- Also make sure to follow the apple methodology of having multiple different key names like Apple, Apple inc., etc
I still have no idea why HK is in front... why is the key hot 🤔... and what key are we talking about...
Oh, yeah, and the different key names... Windows, Windows NT (WITH a white space...), Win...
HKEY means "handle to registry key"... Not that that helps anything.
When code opens a file, device, etc, it's given a "handle" to it, which is an internal reference so that Windows knows which file you're reading or writing, and it keeps track of where you are in the document. Similarly, HKEY_CURRENT_USER is the handle that gives you the current user part of the registry.
I know that, the HOTKEY_* part of it was a mystery, why is the key hot... I mean, why does HK have to stand in front of it, it could be simple like just LM, CU, U (Users... still does nothing and nothing in it gets transfered as a setting in new user accounts), CR, etc.
It's HKEY (handle to key), not HOTKEY. That's what I was trying to say in my comment. There's no "HOTKEY".
Huh... I don't know where I've read this a long time ago, but I could swear it was HOTKEY, not HKEY... your explanation does make sense though, while what I thought never did make sense.
And half the time you'll find it in the registry too. Linux has proven quite well that an OS doesn't need a registry.
Oh, and what's with ProgramData and AppData being two completely different things. I understand the difference between the two directories, but there is no difference between a program and an app. Everywhere else it's Machine/User.
Linux has proven quite well that an OS doesn't need a registry.
Gnomes dconf would like to have a word with you. It's really interesting how the Gnome people seem to get rid of every useful feature as it might confuse the user or be complex, but on the other hand add this registry-like anti-feature to make the system just as unmanageable as Windows.
What you can find in dconf is well organized compared to what is inside of the regedit hell.
Funny thing is, most 3rd-party utility tools don't use registry but a config. Which makes them portable, btw.
Nowadays, yes. Go back 15+ years, the registry was used extesively.
My reasoning as to why, Linux was never a targeted platform for software back then, now it is. There was only GTK back then and it didn't look "nice" (appealing) at all. Plus GTK apps were huge for Windows, since you'd have to also install the GTK runtimes and all that... that just took a lot of disk space, which was expensive back then. Compared to an app that does the same, but spends only 10% of the disk space needed for GTK (you could even go a lot lower with compressors), it's obvious why GTK was never a viable option when making a GUI app.
And since Linux doesn't have a registry (or even if it did, it'll probably be completely optional to have it or not, so you can't rely on users having it installed), you'd have to just save the settings in a file, just like the rest of the FOSS applications. So, it makes no sense to have completely different codebases for the same app for Windows and everything else. In fact, most apps nowadays that aim to be cross platform just use Qt. You can compile it for watever you like, there is no need to keep separate codebases.
there is no difference between a program and an app
Yeah the naming is confusing. The reason is what you said - machine vs app.
Back on Windows 9x, some apps would store files directly in the
C:\Program Filesdirectory. This was 'fine' at the time since every app ran with full permissions. Users were atC:\Windows\Users, but users were optional so not every install used it.Windows XP had a better NT-based permission model (not nearly as improved as Vista, but better than 9x) and allowing regular users to write to the Program Files and Windows folders wasn't really a good idea. It added two directories for settings:
C:\Documents and Settings\username\Application Datafor user-specific dataC:\Documents and Settings\All Users\Application Datafor non-user-specific data
Vista kept the former but moved the latter to
C:\ProgramData. I can't remember why.Windows 7 moved the user stuff to
C:\Users.ProgramData is for admin stuff and things that need to be shared between users. AppData is for personalized settings per user. For example, AnyDesk stores the unattended access password in ProgramData, as well as the ID. Sure they do get copied to AppData when AnyDesk runs on boot/login on any user, but you could also have some user specific options (like language) and they get stored in a separate file in AppData.
What the fuck is local low? I don't understand. Local is Billy G's jizz... I get that... And Roaming is for poor plebs. But why LocalLow? Is it like cache? But I have seens games saving their save files there. I don't understand
The folders actually do make sense.
Roaming: this data can be moved between machines in a domain if you have a roaming profile. E.g. go to another workstation and your browser configuration is the same? Means it's in Roaming.
Local: this data will not be synchronized between machines when you roam. This could be your browser's cache.
LocalLow: like local, but for applications that are "low integrity", like Internet Explorer. These folders have special properties. https://helgeklein.com/blog/internet-explorer-in-protected-mode-how-the-low-integrity-environment-gets-created/
Local is for regular apps, LocalLow is for depressed apps and Roaming is for high apps looking for munchies.
This is by far the best explanation
This is probably what MS thought when naming them... seriously, only Local makes some sense.
You can rename them in the environment variables UI. Has anyone tried this, any software who has the path hardcoded?
Btw, here's the paths.
Has anyone tried this, any software who has the path hardcoded?
I know for certain that some Adobe products did have these paths hardocded (past tense, haven't tried this now), because I moved my home/user directory on D:, yet they persisted to save the settings in
C:\Users.