alt Hacker NewsA long while ago I found myself helping out with some products MSI installer. I don't think anyone can really point a finger at the Mac and accuse it of having issues by comparison with what seemed to me to be the nightmare from hell of trying to make an installer that would work on various versions of windows.
It's not the fault of MSI per se, although its concept seems utterly frightful to me, but the way DLLs work and are registered and where you have to install them etc. When your app requires an older or newer MSVCRT etc. Also...the registry...something else that makes good old UNIX text file editing seem good to me.
I always thought that libsomelibrary.so.MAJORVERSION.MINORVERSION with symbolic links from libsomelibrary.so.MAJORVERSION and libsomelibrary.so allowed one to create dependencies that made sense - more or less specific as you chose. It also allows different versions of the same library to exist in the same directory such that one is less likely to break existing software when installing something newer (or older).
To be fair it might just be the way Windows tries to keep compatibility for the ages that makes it super difficult. I do think that you tend to get similar outcomes from similar assumptions/requirements and compatibility was indeed very very important till the internet became good enough to offer everyone easy upgrades.
I'm not a big snap or flatpack fan but DMG seems rather in their class - making things simpler. It might be easy to run an MSI after someone has burned many hours testing it to get it to work everywhere but to me it's a non-simple architecture that is made to work by extreme effort. I'd rather a simpler architecture that open source packagers could manage more easily.
As an example, I tried creating an Ubuntu package recently - a plugin for GNU Make that adds some useful functions.....that was SO hard - worse than any MSI experience I ever had - and I gave up. There were millions of confusing instructions and none worked properly. I couldn't work out which way was up or down - I don't know how people do it.
On Artix (an OS which is a little harder to install than Ubuntu) it is an absolute dream to create packages - exceedingly so. It might be that they aren't the greatest packages in the world but something that can be developed easily and got working can also be improved easily.
Windows' CRT setup allows for binary compatibility with older versions. You can go without if you just statically compile the dependencies into your program, but many Windows developers choose to rely on runtime versions which may or may not be shared.
MSI's biggest mistake was probably granting developers the capability of invoking any program they like. The format was originally designed similar to Linux packages. Installation steps were atomic and reversible. If something went wrong (i.e. you ran out of disk space halfway through), the installer can undo every change step by step so you can try again later without overwrite prompts. Unfortunately, adding the ability to call executables means that atomicity is usually lost.
macOS applications seem to just package every single DLL they need inside of their application folder rather than relying on the OS. I'd do the same if I were developing for macOS with how often Apple likes to make breaking changes.
The symlinking trick for .so files often breaks on Linux. Method parameters change, structs get altered, and you can quickly create working-but-unstable versions if you have a different version of the same program. The Windows way, used by Flatpak and Snap, of targetting known-good sets of libraries will work around that. The macOS way (AppImage) also works but doesn't allow for deduplication. It might, if the AppImage would be uncompressed and files would be extent-aligned on a modern file system, but in practice that won't happen.
In theory, Windows and Linux offer the same app installation flow as macOS. AppImage and huge .exe files can be moved around and deleted just as easily. Windows will let you do all kinds of things with desktop.ini, including custom folder backgrounds, and its native .iso support can offer a very similar mount-then-delete flow to .DMG files.