There's something deeply satisfying about compiling a Win32 desktop application and knowing that single binary will run unmodified on essentially every Windows machine from XP onward, and look nearly identical doing it. High-DPI is the one real caveat, but even that's manageable with a manifest. I'm not sure any other platform-native API comes close to that combination of reach and consistency. Running them on other operating systems is really just a bonus.

▲

dbacar 4 hours ago | parent [-]

I am not sure if this holds, I have witnessed apps that dont work in newer versions of Windows.

▲

bigfatkitten 4 hours ago | parent [-]

They exist but they’re in the minority. Compare this with the Linux world, where userspace compatibility between one major distro release and the next, 12 months apart is very much a roll of the dice.

	▲	MathMonkeyMan 3 hours ago \| parent [-]
		This is true. To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this. But if you want to use... anything else, then it's unlikely to work at all unless you are very specific about your target. There isn't one company deciding that glibc or mesa or whatever is binary backward compatible on every kernel for every platform forever. Microsoft is, somewhat, one such company. That's why System32\*.dll have such stable interfaces -- it's their job to translate whatever late 90s system/graphics facilities some boomer dreamed up into whatever the current Windows hodgepodge of system services support. It's no wonder Microsoft is trying to drop support for hardware like crazy. This implicit compatibility isn't true for all Windows programs, though. Consider Visual Studio. Couldn't compile my console program on my computer and run it on my dad's computer. He had to first install the "Redistributable," which for him and most people might as well be a rootkit and a super scary virus program bad guy.