as my brother explained it, windows programmers have a tendency not to bother picking up after themselves. periodically rebooting the computer cleans all the crap they left lying around. before windows, any time you closed a program, it shut down everything it turned on and removed itself from memory. windows software doesn't do that.
Believe it or not, if you use Windows right, it does have those protections. It gives you your own little sandbox to play in. But, someone always finds a way to break out of the sandbox...
Truth be told, the modern Windows system is an actual improvement over the older DOS systems. The things folks used to do with TSRs would curl your hair.
Every system can have memory leaks, rogue pointers, race conditions, bad semaphores, porting issues, compiler errors--the list is endless, and horrifying.
You can write abominations in any language and OS. Believe me, I've seen it. And done it, before debugging...
You know you're in trouble when suddenly, the program that was supposed to take a few K of memory somehow now hogs over a gig.
And then there's hardware issues. The worst problem I ever saw was caused by cosmic rays flipping bits in a cutting edge high density device. They had to take it to a college's nuclear accelerator to find that one.
Plus, standing behind you tapping his watch is the program manager, who, when asked "Do you want it working or do you want it Tuesday?", replies "No! Monday! Monday! We need it Monday!"
In those situations, the Error Recovery parts of the program are almost always neglected. That's the part of the code that is supposed to clean up after itself and terminate gracefully when something goes wrong. But because as long as the program works normally, you don't usually run the Error Recovery code, so it seldom gets tested as well as the ordinary program. You really need a good SQA team to put the brakes on the program manager at that point.
The one advantage Apple has is that it's a closed system. If you're writing code for Apple, or developing hardware, odds are you are an Apple employee or are working closely with them. At the minimum, an Apple employee is going to test your stuff for compatibility (even in the Apple Apps store--it's much more picky than the Android Play Store). They control so much of their system that they have a much better idea on how to test and verify operation.
Contrast the PC world, where anyone can whip out hardware and the drivers for it, and although they're supposed to follow a standard interface, people push the envelope or make up a special variant for them, and they only test it on their hardware. Think of it as the "special snowflakes" of the computer world.
And then, systemic issues come into play. Sure, your program may work, but will running the dozen or so specific apps that are resident (and show up in the toolbar tray at the bottom right) do something to your system to make it incompatible?
It has gotten better. For example, on this system I have two sets of printer drivers running different printers remotely. I only had to reinstall them twice to get them to play together...
