Comment by mike_hearn

Well, let's see. What do I know about this topic?

I've used Linux since the Slackware days. I also spent years working on Wine, including professionally at CodeWeavers. My name can still be found all over the source code:

https://gitlab.winehq.org/search?search=mike%20hearn&nav_sou...

and I'm listed as an author of the Wine developers guide:

https://wiki.winehq.org/Wine_Developer%27s_Guide

Some of the things I worked on were the times when the kernel made ABI changes that broke Wine, like here, where I work with Linus to resolve a breakage introduced by an ABI incompatible change to the ptrace syscall:

https://lore.kernel.org/all/1101161953.13273.7.camel@littleg...

I also did lots of work on cross-distribution binary compatibility for Linux apps, for example by developing the apbuild tool which made it easy to "cross compile" Linux binaries in ways that significantly increased their binary portability by controlling glibc symbol versions and linker flags:

https://github.com/DeaDBeeF-Player/apbuild/blob/master/Chang...

So I think I know more than my fair share about the guts of how Win32 and Linux work, especially around compatibility. Now, if you had finished reading to the end of the sentence you'd see that I said:

"Linux is really hurt here by the total lack of any unit testing or UI scripting standards"

... unit testing or UI scripting standards. Of course Linux apps often have unit tests. But to drive real world apps through a standard set of user interactions, you really need UI level tests and tools that make UI scripting easy. Windows has tons of these like AutoHotKey, but there is (or was, it's been some years since I looked) a lack of this sort of thing for Linux due to the proliferation of toolkits. Some support accessibility APIs but others are custom and don't.

It's not the biggest problem. The cultural issues are more important. My point is that the reason Win32 is so stable is that for the longest time Microsoft took the perspective that it wouldn't blame app developers for changes in the OS, even when theoretically it could. They also built huge libraries of apps they'd purchased and used armies of manual testers (+automated tests) to ensure those apps still seemed to work on new OS versions. The Wine developers took a similar perspective: they wouldn't refuse to run an app that does buggy or unreasonable things, because the goal is to run all Windows software and not try to teach developers lessons or make beautiful code.