I’m really fond of the way macOS does this, which is to stick this information in the executable.

Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.

This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).

Furthermore, the OS can pick up the extensions, services, etc the app carries within its app bundle and offer them to the user to enable this way. No need to copy files to obscure directories (be it manually or with an installer), and when you trash the app bundle they’re all gone.

This is why merely having a copy of an app is enough to make QuickLook able to preview the filetypes the app is capable of opening. The system picks up the QuickLook extension in the app bundle and enables it.

It’s not perfect since small .plist config files get left behind, but it’s a whole lot more clean by default compared to the Windows approach.

This is just not true, and hasn't been for decades. Many, if not most applications create subdirectories and store stuff in the Library/Application Support directories. Trashing the app bundle leaves all that stuff behind.

It comes down to each individual developer, and generally speaking indie devs are much better behaved than cross platform giants like Adobe. It’s another reason why Mac users often have a preference for native AppKit apps, which are what indie Mac devs tend to build.

Either way, the end result is still better than under Windows because at least macOS doesn’t go out of its way to keep the Application Support folders (user and global) hidden with magic URLs and such. Tick the checkbox to not hide the Library folder in your home folder’s Finder inspector window and the only thing making access harder is gone.

>Either way, the end result is still better than under Windows because at least macOS doesn’t go out of its way to keep the Application Support folders (user and global) hidden with magic URLs and such. Tick the checkbox to not hide the Library folder in your home folder’s Finder inspector window and the only thing making access harder is gone.

The way to access your folders in windows is literally exactly the same -> show hidden folders - the "urls" (%APPDATA%) are just shortcuts because of the historical moving around of stuff. Most devs leave all sorts of trash in OSX application support, check it out, its jam packed. Some apps are now running from there.

It’s not the same because macOS has a setting for Library folder visibility specifically. Keeping that folder easily accessible doesn’t require turning on visibility for all hidden folders/files and then having to wade through a ton of normally invisible junk. ~/Library/Application Support/ is just a plain old path too, no need for magic platform specific keywords.

And yeah, Application Support is full, but as noted the worst offenders are consistently cross platform apps that don’t care to adhere to convention. The Application Support folders for Mac-first apps are usually pretty lightweight/clean, with exception to apps like Logic which use it as a place to keep downloaded assets.

Actually, it does. A few OS versions ago, Apple started hiding the user Library directory. And then obnoxiously RE-hiding it with each OS update if you had cleared its "hidden" attribute.

I think they finally stopped the re-hiding behavior.

None of that compares to the mess that is Windows's user directories. I mean... WTF is all of this stuff? There are two or three copies or shadows of the user-directory structure, and everything is "forbidden..." Windows is just painful and infuriating to use at this point.

> which is to stick this information in the executable

This is neat, shame they went completely the other way with file metadata. It forces a hidden .ds_store file in every single folder a mac touches just to store info like access time. Every other system stores this in the file itself.

Windows does the same thing with 'Thumbs.db' files. They're just hidden from you on Windows systems, just as .DS_Store files are hidden on Unix-like systems; but you'll see them if you use a thumb drive with both types of machines.

So why are the smb shares on my linux file servers full of millions .ds_store files but zero thumbs.db files? I have to run automated scripts to remove them regularly, and try to run the commands on the macs to stop them writing ds_store files to network shares [0]. But still it seems to magically reenable itself every now and then. This is a problem I have never had with windows machines and 'thumbs.db' files.

[0] https://web.archive.org/web/20190714230437/https://support.a...

I didn't think newer versions of Windows generated Thumbs.db either (well I think they do, but in some centralised location I thought rather than in every single individual directory).

"Newer versions" ≥ Vista (2007)

They switched to storing thumbnails locally.

Ah, guess my knowledge was a bit out of date then :) I haven't been a regular Windows user for quite some time. I thought I'd seen Thumbs.db files generated on flash drives by at least 7 though.

Ah okay - I thought maybe it was Windows 7 (I never used Vista) and 7 doesn't feel like four versions ago.

If I recall, Windows does not generate thumbs.db files, thus file icons-as-pictures, on any non-local device.

Because Apple thinks nothing of spewing these turds all over every machine and directory you visit from a Mac, which is not just a dick move but also technically incompetent.

The next Mac visitor who comes along will overwrite the turd with his own, so that's a blunder.

Then there's the fact that they could have stored all the turds on the local machine, keyed by URI or path or network address. This would solve both the dickishness and the overwriting problem. And if a remote machine's path or address changed, whoop dee doo... you lost your Finder layout for that directory. Pretty low stakes.

Not to be too annoying, but that file is how it supports the feature on non-posix-compliant file systems (usually FAT). On filesystems that support file-streams (or the original HFS), that metadata is stored on the file itself

You're thinking of resource forks. .DS_Store is stored as ".DS_Store" even on APFS.

Considering how pushy Apple normally are when it comes to forcing their customers to use new things so they can obselete old ones, I am very surprised where Apple have drawn the line in supporting older systems.

Relevant: “The Mac, Metadata, and you” (2001) https://arstechnica.com/gadgets/2001/08/metadata/

First thing I used to install on macOS was Binaryage's superb asepsis utility, which intercepts the creation of .ds_store files and redirects them all to a local container folder, until SIP killed its development.

It always seemed suspicious to me that Apple, a company that is famously obsessed with UI/UX, would settle on such a ridiculous process for storing file metadata.

I mean…that’s just the same thing right?

Same thing as what? Same thing as having an installer modify HKEY_LOCAL_MACHINE\Software\Classes, and having the associations break if you move the program to a thumb drive?

If only everyone actually kept up with Windows development best practices, including Microsoft teams themselves[0].

Configuration via XML files, AppData, registry free COM activation, MSI installers, only to quote a few examples, are decades old by now, at very least since Windows XP.

[0] - To be fair, nowadays many young employees seem to only ever used Windows after joining Microsoft, so what else can we expect, if apparently they don't get the right mentoring.

Is there a book or site documenting these best practices somewhere? I'm getting into windows dev and am curious about them.

I cannot stand AppData, specifically the way it's often used to store files that should be in Documents.

That should be covered by the part about "best practices".

That said, I keep finding more AppData files in my Documents folders than the other way around. Linux software (especially legacy software that doesn't respect the XDG spec) is the worst for that, somehow spreading files and directories across my user profile directory and my documents directory.

I'd never heard of AppData until a few years ago when I went hunting for where some game config file was getting written to.

Seemed like a bunch of disparate things with the most common probably being a dumping ground for programming language library caches (Maven and NuGet and maybe another couple).

I lost my kid's minecraft world because it stored everything under AppData/Local or some nonsense.

How did you lose it? That sounds super frustrating

By backing up everything in important-looking folders (including My Documents, My Games, the Minecraft installation folder), and overlooking AppData as it is 99% download caches, tempfiles, and other garbage.

:) and local state, configuration, and anything an app needs when you do stuff. It's really the local user state in most cases, very important to back up!

On my Win10 desktop it got to 30GB though and the stuff worth backup is actually about 1GB of it.

Let's just call it what it is: a complete mess. Some apps install their binaries in there, some just config files, some all your data.

If there are guidelines (and they are not conflicting) about 1/3 of apps are ignoring them.

Also good luck trying to back it up with robocopy or anything, maybe windows' own backup tool can read it while running on that account, I usually get errors, which I think are mostly fine to ignore.

There's no good guideline - if you want a local cache that transports across user migration, that's the show. Windows doesn't really have a "separate your local disk cache from your backups" method, but you can certainly do the Cleanup Task to remove some things that buy into that modal that's 25 years old :)

I made a similar mistake when upgrading my SSD. There was some token that was stored in there that I needed, and IIRC I had lost the password needed to generate a new token. I only realized that I was even missing it a few weeks later when I needed to use the tool again. luckily I still had the old SSD so nothing happened. This happened even though I'm familiar with locallappdata and have even used it in some apps I created. It's just not the first thing you would think about when doing a backup unless you've already been bit by it before. Apps generally don't tell you if they store something important there, and the tool I was using never tell me where the token was stored. Doesn't help that file explorer hides the folder from you by default.

It is not meant for that, rather blame the developers.

Probably just preference but I hate when apps put things in the documents folder, thats where I want to put the things I've created specifically, not automated config files etc. There should be a 'Preferences' folder or something to separate the chod in AppData from the useful stuff.

>I cannot stand AppData, specifically the way it's often used to store files that should be in Documents.

Which programs do that? Or do you think things like preferences for programs should live among your documents?

A lot of games store save files in appdata. That’s the only thing I (not op) can think of, and one I regularly find annoying (if only slightly).

Yeah I suppose that's the only example I can think of, I noticed a comment later mentioning that that is where minecraft saves things, although I'm not sure I'd want those in with my documents either. They probably should live some place that the user has access to, so I guess that leaves app data or documents, neither feels like a great choice.

What about a standalone executable that just offered the ability to install itself without having a dedicated separate installer?

It would be annoying. If the use-case is as a portable application, but the application would want to let the user know (in a sufficiently loud manner) that it can install itself, then either the user would be forced to pay attention at that aspect every time it opens the application, or that "portable" application will have to somehow pollute the environment with (at least) a note for itself of the fact that user was offered but chose not to install anything. That note is usually just a first change in the system and, for a non trivial application, is way too easily followed by many other kind of saved changes, which in itself looks like a creeping install. Then, if the user would actually choose to install, the app will have to do what, make shortcuts to its current location, which may be a thumb-drive, or another less ideal placement for a program (because how many of us take time to think about file management anyway)? Or, if the application makes a copy of itself to a conventional place (for an application) in the system, then now the useless standalone executable either gets forgotten about or becomes a burden for the user (who has to decide what to do with it).

The most appropriate behavior for a portable application is for it to stay clean by default and only offer the user to explicitly enable persistency-dependent functionality. When the application starts, it checks if there's any previous trace of itself and depending on that it either keeps its portable-like clean behavior or switches to installed-like one.

Why would it have to let the user know via an obtrusive splash or anything? Could just be a very simple unobtrusive option on app launch or a menu item.

Same goes for post install - not too hard to arrange to auto delete the old copy.

I remember a game that did this in like 2006 (it was a small GUI program called drug baron or something like that - you bought and sold drugs and weapons with your sales and purchases affecting the market - like a text-based game without having to use the command line).

It didn't work so well (probably not programmed that well I guess).

I suspect there were a few games like this, but I think the most popular one was called Drug Wars, in case anyone cares to go looking.

Yes, it was very poorly programmed. It always surprised me how popular it was. I think it was kind of a middle- to high-school meme game. I think the main popularity was that A) it was edgy, and B) kids could run it in school computers.

Yeah Drug Wars was probably it.

The really tedious answer is that there's special (very badly documented) magic to installers on Windows. I suppose you could shove an MSI inside the executable, then write it out and shellexec to install the MSI.

After using Microsoft Intune I will never again complain about installers. At least installers mostly work, and when they don't you can run them again.

If I want to use a program once, I’ll just use a portable version. And I’ll be angry if it decides to add itself to the context menu of all Explorer files.

But I agree, for things I use more often, installers are the way to go, and I am not a fan of projects that just give you a zip and ask you to figure out where to put it.

>There are lots of useful actions an installer does that (some, if not most) end users actually want, including but not limited to adding shortcuts to start menu so you can find it or search for it, associating file formats, registering to Windows' program list, etc.

This, I don't really mind unzipping some random small utility, but for things like games and larger applications where you'll actually be saving data and preferences, a real installer that knows how and where to put things following the correct methods for the operating system is much preferred. Then I can run the uninstaller to clean it up when I'm done with it.