It's just a different variable: USERPROFILE.

https://stackoverflow.com/a/42700844/512904

> being Linux but mangling it so it technically works on other platforms

Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it.

This is simple and works everywhere:

  char * home = getenv("USERPROFILE");
  if (home) {
      // Use home directory
  }

The answer demonstrating the Windows API way has the following code to accomplish the same thing:

  WCHAR profilePath[MAX_PATH];
  HRESULT result = SHGetFolderPathW(NULL, CSIDL_PROFILE, NULL, 0, profilePath);
  if (SUCCEEDED(result)) {
      // Use home directory
  }

Yeah, I seriously doubt open source developers want to deal with this Windows bullshit. I sure don't. Maybe if you're getting paid.

'This Windows bullshit' is merely the Windows equivalent of a veritable zoo[0] of Unix/POSIX/Linux headers and functions including unistd.h, sys/types.h, sys/socket.h, fcntl.h, sys/ipc.h, semaphore.h, stdarg.h, signal.h, pthread.h, and so on.

Just because you aren't used to it doesn't mean it's 'bullshit'. Might I provide a counterexample to the 'simplicity' of Linux? Developing video games natively on Linux is such a pain point that the industry has standardised around simply translating Windows syscalls and Direct3D shaders to their Linux equivalents, because the latter is so heavily fragmented to develop natively for. Also known as Proton.

[0]: https://en.wikipedia.org/wiki/C_POSIX_library

Whenever dotfiles are mentioned, it's safe to assume we're talking about terminal applications and that the target audience is software developers. This stuff only really matters to us, people who actually care enough about the system itself to not only use a terminal but also to bikeshed configuration formats and file system trees. That's exactly what the article this thread is about and the comment I replied to were talking about: stuff like developer tools and ssh.

Honestly I don't even disagree with you. I think POSIX sucks. I think even the libc sucks. However there is no way you can look at the Windows API mess above and think it's somehow better than the portable and clean getenv function call. Maybe you can "get used" to that cruft but I can't. If I had to deal with code like that the first thing I'd do is abstract it away so I don't have to deal with it anymore. That's exactly how Windows is and should be treated by everyone.

Video games, your counter example, are probably the most platform-specific software imaginable. There's a reason pretty much everybody uses an engine these days. There is no way you can compare that stuff to getting a user's home directory and writing files in there.

Also, for video games it ultimately doesn't matter how sucky the APIs are since it's all about market share anyway and people will use whatever they need to get it done. First parties don't put in effort into porting games to Linux because they don't see the money. Valve puts in effort because it gives them their own platform that they control and therefore leverage over Microsoft and its app store. Emulation and compatibility layers are a proven solution when first parties aren't playing ball. If they don't want to make it work on Linux, people will make it work whether they want it or not.

The former does not in fact work everywhere, it only works on Windows. Once you have your #ifdef, there is absolutely no point in having the wrong Windows-specific code instead of the right Windows-specific code. Also, look at what you're describing as weird bullshit: a function call with an enum, instead of a function call with a string. The only difference is that you haven't bothered to familiarize yourself with the world outside of Linux, so it feels unfamiliar.

Also, you're comparing something it makes zero sense to compare. People are not saying 'you need to fetch $USERPROFILE without calling getenv'. People are saying 'you need to not store random garbage in $USERPROFILE'. Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData, the same way you weren't going to bother calling getpwuid if $HOME was undefined.

> The former does not in fact work everywhere, it only works on Windows.

It's just some example code. Real code will probably try a number of variables.

> Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData

Okay then. Top level post said you needed a Win32 function for this. If you can do that without those functions, I suppose it's easy enough to support.

> calling getpwuid if $HOME was undefined

$HOME is set by login and ssh to whatever is in the passwd database. Can it ever be undefined? Seems like something is seriously wrong if it is.