Linux

The proprietary nature of Windows keeps many of its tricks under wraps. I think many people read about the detailed blogs and news articles Linux inspires and comes off thinking Linux is the obvious superior piece of technology. You used to get tons of books about the Windows internals, but most people writing those books have been hired by Microsoft so you get fewer of them these days.

Windows 9x was absolutely unstable and Windows NT has been the victim of shitty developers. Even in the 9x days, very few crashes came from products written by Microsoft itself in my experience. Linux has the same issue: see the Nvidia driver in just about any facet of computing, from power management to simply providing a basic API for things like Wayland. Windows XP is where Microsoft discovered the problems with their 90s kernel design, and in Vista they fixed a lot of them (user-mode GPU drivers, user-mode USB drivers, all that jazz! The entire GPU driver can crash and all you notice is a quick black screen and programs using hardware acceleration freezing). Vista was obviously released before it was finished, but 7 is where these features began to shine. The 32/64 bit boundary was actually not that big a problem, because Windows already ran on 64 bit all the way back in the 90s. It took a few years for Linux to be available on as many architectures as Windows was.

The backwards compatibility thing is mostly accomplished by putting version numbers in the DLLs and their loading mechanism, and using hot patching through the compatibility layer to put workarounds for programs that don't support them. Microsoft has a vast database of old executables with custom-developed patches and workarounds at the API level for the most important software. For all other software, multiple versions of the DLL are loaded into memory and applications get linked to the version they desire.

Inside a Windows install, you'll find a huge WinSxS folder. This side-by-side assembly does a lot of the heavy lifting when it comes to versions and compatibility. It used/used to use a lot of hard links, so Windows Explorer would get very confused at the size. MS stopped using WinSxS for their own redistributables, but there are still plenty of system libraries stuck in the system.

For redistributables, Microsoft has switched to the same system Linux has: versioned DLL files. Unlike most Linux distros, though, you can keep many versions installed next to each other. Sadly, many Linux programs link to the unversioned DLL, which means breakages galore whenever you update, and old versions of a library will often fight for the right to be the "real" libabcdef.so. Nobody can decide how to solve the versioning issue in Linux because there is no central authority for this stuff, and that's part of the reason why it's so hard to run old executables.

The new fix, just shipping every library with every application, as you stated, isn't great either. Flatpak does a lot of file deduplication (much better than Docker's image level deduplication) so it's not as bad as it seems, but I'd still rather have the libraries provided hy the OS itself in use than have a second copy of the OS especially for running GIMP.

The thing about tools like Qt and zlib is that Windows comes with all that stuff out of the box, and has done so for decades. There's no need to track down the right version of libcurl and libgzip because the target OS has all the functionality you need. Qt is replaced by MFC/ATL/Win32, libgzip is replaced by the Windows compression API, DirectX and its many shapes replace SDL and a bunch of GPU libraries, the list goes on for ages. Almost any Linux package beginning with lib.* has a Windows equivalent in the standard API that's guaranteed to work the same for a couple of years at least. You don't need to deal with a package manager to update them, because Windows Update does that for you. That's why Windows doesn't need a separate package manager for 99% of the binaries apt/dnf/pacman pull in. They still pack winget with Windows 11, though (it's available but not enabled by default in Windows 10)

All configuration happens in the registry. Gnome tried to do the same, which is where dconf comes from, and it's honestly even better. Microsoft was sick and tired of Win3.x ini files everywhere on disk and set up the registry as a central key/value store. It lacked documentation at the time of invention and to this day you'll need MSDN to find out what all of the settings mean, but on the other hand you only get one single configuration file for your entire system. This forces programs and the OS itself to remain backwards compatible and write migration tools rather than just changing up the config file type.

The software distribution problem is actually something Microsoft is trying real hard to solve. The Windows Store can serve any application (not just UWP stuff) but users don't seem to want to use it. There's a modest fee required to use it, so a lot of free stuff avoids the store, but it solves the distribution problem the same way the Mac app store does, and it even includes Android apps for good measure. Store applications are kept inside their own little sandbox just like apps on other platforms. The solution just doesn't seem to stick.

On the other hand, Linux and MacOS do introduce annoying problems like "where do I put user only programs". MacOS has executable folders to make your life a bit easier, but you still end up with a folder full of random stuff. Linux has the XDG standard for storing stuff in ~/.local and ~/.config, but when you try to use that you'll find many programs don't even bother to try to follow the XDG spec because they decided it's wrong and nobody is forcing their hand. The Windows solution (put everything in program files) isn't amazing either, but it works in most cases.

Another annoyance is the lack of programs using MSI files for installers. An MSI installer can be written declaratively, with install and uninstall steps for adding and removing files, and even allows for repairing damaged programs, but everyone wants to write their own self extracting installer. This happened in Linux too, where Oracle wrote a binary installer for Java and VirtualBox guest drivers, and Nvidia still had a weird installer on their website. The APIs and abilities are all there, but programmers choose not to use them, either out of ignorance or out of laziness. Furthermore, Linux had AppImages these days, which behave like MacOS' executable folders in a way and can be put in an Applications folder if you want. I store them in ~/.local/bin myself.

I think the Android style app containment is the best solution so far. It combines a rich OS with tons of APIs (similar to Windows) with a sandboxed environment easily managed by the user. It's not perfect (sharing libraries is possible but only for apps with the same signature) but I think it's a good idea. Flatpak and Snap are both trying to solve the problem in a similar way, and perhaps after a few more years of teething issues we'll end up with a great solution. Having been directed to a Flatpak only system on the Steam Deck, I've honestly changed my mind about the way Flatpaks work, though the many Nvidia huge driver containers still irk me to no end.

As for your printer issue: I know the feeling, printers just suck. I've had as many fights with Apple's CUPS on Linux as I've had with Windows' shitty drivers. For many printers, just right clicking them and clicking "install" from the network center just seems to work. For others (especially the modern ones) you need stupid workarounds. The ancient laser printers that work flawlessly once the software runs are all dependent on drivers that were buggy when they were released in the 90s and Windows has since fixed a lot of security vulnerabilities in its print system that not every printer driver likes.

I've honestly considered setting up a Raspberry Pi in readonly mode to fix the printer issue on my dad's laser printer because the HP driver disappeared from the internet, but after extracting it from a backup or the driver CD everything suddenly worked.

I honestly don't recognise your Office problems at all. I've used every Office version between Office 97 and Office 2016 in incremental fashion, and documents always just seemed to work right for me. You can even interoperate with older versions by specifically saving files for an older version, which many open source alternatives simply can't do.

That said, with the HUGE attack surface of Microsoft Office, you really shouldn't be using versions that are out of date. Just for security reasons alone I wouldn't want to deal with a company that still used Office 2007 everywhere. Year-branded Office releases receive 5-10 years of updates (depending on the version, they're clearly marked online) so you know exactly when you should be buying a new license. As a business, the price of Office really shouldn't be what's killing you, and the same is true with Windows licenses. They're investments into tools and business continuity.

The reliance on Office rather than alternatives is annoying for those using LibreOffice and such, but there simply isn't a better offline suite available. Office 365 and Google Docs are the way to go these days in terms of MS Office competition, and neither are a great solution. I use the open source stuff, but I can't deny that it's worse in almost every way other than the user freedom part, and that includes some security considerations.

I share your dream of a connected computer ecosystem! I've drawn up diagrams of a concept to basically share an application between mobile, desktop, and other form factors, based on the Android sandbox and leveraging the cross platform nature of the JVM.