It's almost as if this sort of thing was never standardized, because many of the standards were terribly predisposed and not purpose design, so Microsoft finally shrugged and took a page from the Unix school of design...only several decades late. (Like most "innovations" to Windows, they've existed in OSs much more effectively designed and purpose built.)

They could have had this neatly sorted as early as Windows NT 1, but were too busy trying to browbeat OS/2.
They could have had this neatly sorted by the time Windows 2000 rolled out, but they were too busy trying to see if they could consolidate two incompatible families.

We do something like this with ./play.it, so that all game user data is stored under ~/.local/share/games.
Ironically it is almost trivial to do with Windows and DOS games, but native Linux games give us a much harder time…

https://en.wikipedia.org/wiki/PKCS_12

PKCS #12 is the successor to Microsoft's "PFX"; however, the terms "PKCS #12 file" and "PFX file" are sometimes used interchangeably.

The PFX format has been criticised for being one of the most complex cryptographic protocols

The filename extension for PKCS #12 files is .p12 or .pfx

At some point some moron at Unity HQ decided video game saves are ultra-low-priority and so should go in "appdata local low".

No! Video game saves are high priority and belong in the user's documents! This is ANOTHER issue. "%userprofile%\whatever" is never the appropriate location. One should read the registry to get the proper path for the Saved Games path from the User Shell Folders key. Failure to do so may cause things to work inappropriately for users who use SYMLINKS or profile redirection settings. It may (and by default does) use %userprofile% behind the scenes, but querying the registry is the proper way to get the path.

Well removing it would break backwards compatibility, but they could slowly transition away from using it, just leaving it there as a legacy thing.

I have to disagree here. System environment variables (userdata, apptada, localappdata, programdata, programfiles, temp) are there so people don't have to do that. And such variables (or similar ones) exist on all operating system, the registry doesn't. The OS sets these for convenience and efficiency, so you don't need to run qureies with a platform dependent programming language.
By using environment variables, all you need to do is to change the variable according to the operating system your software runs on. There are only so many variations. On Windows it's "userprofile", on Linux "home", some system might use "userhome", but that's about it. If you write a browser plugin and need the temp directory, how would you access the registry in the first place? And how would you do that on Linux or Mac? No, you would look for the variable "tmp" or "temp". That's the way to go. With these informations you can program on any modern OS. In no case you need to dig into binaries to find standard values. And if the user is a network user, his profile not even on the local hard disc, what would the registry contain?

But speaking of it, what would be the key/value to look up in the registry to get the user home directory? Or the one to Appdata?

people != applications

A person is going to browse. Casual scripting you can use %userprofile%, but, canonically, you should get it from Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. GUID {4C5C32FF-BB9D-43b0-B5B4-2D72E54EAAA4} for Saved Games location. (Using GUIDs rather than human-readable keys is a definite issue...)

Registry is a replacement for environment variables in many ways. (Of course, they don't easily get pulled from command line is a limitation...)

See also:
https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath

https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderid

https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/known-folder-guids-for-file-dialog-custom-places

EDIT: As for "is the registry good or not?" That's a very different discussion. I think defining where to find system-wide paths is a good thing for the registry. Environment variables? Sure they can do it, but it can be obtuse and misused too: (on my system, %appdata% is different than %userprofile%\appdata)! And getting applications out of the habit of trying to stick files in their own install folder was a good thing too. The above is speaking to how it is and is supposed to be in Windows as designed.

FWIW, the browser API should handle that. (See also the above for Unity and it's decision for AppDataLocalLow...)

Same reason config files, cache, temp files etc. locations are inconsistent: devs always know better where to put it to annoy you.

That's true, people write applications.

If you use the MS defined save game folder, then yes, you are on a Windows path and definitly not writing for Linux or Android or anything else, these don't have a standard for savegames, but for program data in general.

The system environment variables are generated from registry entries anyway, also Windows itself relies heavily on these and does not always run queries on the registry.

if you use a platform independent language, you first need to find a way to access the registry. Yes, there usually are frameworks for that, but they don't come as standard. It's not the standard way to do things. These languages usually provide standard directories and user informations (those present on all operating systems) as system properties.

But let's assume that I wanted code, that is specifically made for Windows to get the "live" settings, then I would use for example SHGetFolderPathA command with Shell32.CSIDL_LOCAL_APPDATA, I would not access the registry directly or use hard coded registry keys. I would let this command handle the digging. The kernel and it's extensions offer standard methods for about everything you might want to do in the registry, so programmers can't mess up too much. Using the registry to add context menus? Heck no, there are commands for that which also work with the new Win11 context menu.


That's what I mean. You would not need to access the registry. Most of the time you would rely on the data your runtime environment provides which is enough for most tasks.



I guess our opinions are slightly different :)
I'll just leave it at that.

Pretty much. There is a difference in the scenarios that have been brought up: If you're writing in a framework/environment, it should provide it to you and something sane (and you should request "give me a path to save things"). But if you're not and you're coding paths directly yourself, %userprofile% is not the right way to go and you should be querying the system through its intended method.

It's pretty dumb that one of these very popular frameworks, Unity, has a very stupid place as its given location to save. I had read it's because that folder is "always going to have write access" and they didn't want to have to include permission checks.

That we can agree on :)

Under Godot:

From the programmer's perspective, files are saved under user:// (which the engine then maps to a suitable directory)

By default, on Windows, the path is %APPDATA%\Godot\app_userdata\[project_name]

Source:
https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html

Sounds like you hit the jackpot, thank you! This is one of those rare games that uses the Galaxy directory to allocate its saves, very hard to find, especially if you have hundreds of games installed.

Thank you, very helpful, confirmed me that the path of the saves is right. I imagined there was some such program but I had never investigated.