[erinaceousjones]

(After re-reading my own comment, I don't think I'm particularly rebuking what you said, it's turned into a "I hate computers" vent :-))

In my eyes, how Windows and Linux deal with third party software is identical...

The Windows model forever has been "you just double click an .exe or an .msi and it runs".

i.e. outside of stuff published on Windows Store (which many developers will not do), it's down to the developer to:

- Distribute their software and provide an update mechanism (download an exe? Windows Store? chocolatey? Steam / epic games launcher / origin / uplay? jetbrains toolbox? adobe software updater?)

- Deal with the many different environments (i686 vs x84, Windows XP / 7 / 8 / 10 / 10 Home / 10 Pro / 10 Pro N* / 10 Basic Server Education Edition N RT for phones)

- (Probably) bundle their software with the exact version of the libraries they're using (looking at you, "Installing Microsoft VC Redist" and DirectX, every single game that I run), because any in /system32 might be the "wrong" ones

* 10 Pro N = "without media essentials" or something, which I stupidly chose last time I forked out the money for a Windows license. Every time there's a new major Windows update (assuming it doesn't repeatedly fail to update, forcing me to reinstall from scratch,) I need to go and reinstall the Media Feature Pack so Rockstar Launcher and GTAV and $software don't all fail to launch with an obscure error code that means one of 100 things that some corporate web forum rep will not have the answer to... Because none of them put a .log file somewhere ...

So the fact that stuff "just runs" better on Win is more to do with third party developer effort rather than a failing of the OS and distribution. There's no incentive for microsoft to make it work better either, because it's Not Their Problem. A whole slew of software runs like bullshit on Windows too, but we just kind of accept it as it is...

Yet me running a program by installing Wine and double clicking the .exe, or via mono, or running one via a snap image, or an .AppImage, or a docker image (those 3 are essentially containerized environments which should work regardless of distro as they bundle their own libraries a la the windows dll hell, though your kernel version may cause issues, just like windows driver versions do), or my Linux distro's packages... is apparently jumping through more hoops than Windows?

As a power user of both OS'es, they're just as much a pain in the ass as each other.

[rfoo]

One key difference is the OS <-> application interface is defined as a group of system provided dynamic libraries on Windows, not syscalls. So Windows effectively provides a set of very reliable core libraries that is guaranteed to be backward compatible. And as long as you don't use newly added APIs, also forward compatible. While on Linux even libc is decoupled from the kernel, each distribution uses a different version, the application cannot distribute its own libc in any sane way, and the glibc choose to use ELF symbol version to make incompatible changes to frequently used APIs (like memcpy), sabotage bidirectional compatible attempts.

Oh, and there are only one Windows distribution. Not at least 3 major ones.

These both make packaging for Linux hard (requiring kinda funny solutions wrapping up a sysroot as a whole, like Snap or AppImage), while on Windows, the developer builds an exe, and voila, it works everywhere, even on very old systems. There are simply no funky stuffs e.g. glibc symbol version issue.