[erikb]

I don't know why people say that. You don't support Windows XP and Windows 10 either with the same binary.

In contrast to Windows you can provide or pay someone to provide libcurl3 if you want to continue to use it. MS will just say you can go F yourself.

In contrast to Windows you can study the source code and write a wrapper that provides a central API point that you can use in your single code base.

In contrast to Windows you can actually go there and provide patches. Even if the original authors won't merge it you can still use it via a fork etc.

And last but not least I bet there are actually still people supporting and providing libcurl3 binaries to this day and you just need to google their package server and add 2 lines to your installer script (one to add the public key for that package repo and one to add the package repo to your package manager).

PS: If you provide software for sizable amounts of people you need to provide 1-3 out of 3 reasonable Distros: Debian, RHEL, Suse. Even if you just provide one most people can deal with it thanks to VMs or docker.

[FigBug]

For a 32 bit version, a single binary compiled in VS2017 could support XP to 10. For 64 bit, a single binary supports Vista to 10.

In my experience, MS doesn't say go F yourself. They go to extreme lengths to keep old software working.

[pjc50]

> You don't support Windows XP and Windows 10 either with the same binary.

I think you picked a terrible example there, because quite often people do; certainly Vista upwards is quite normal (that was the transition point for lots of APIs).

Windows is much clearer about how you're supposed to solve "DLL hell". You have the OS libraries, which provide a stable API; COM, where interfacing is done at runtime dynamically; and for everything else you put it in your application's directory.

Theoretically if COM components aren't interchangeable - the API has expanded - they should have a different CLSID and therefore not clash.

[youdontknowtho]

This is a common misconception. Microsoft is a little insane about backward compatibility. You can target versions of Windows with a single binary from the latest all the way back to unsupported OS's like XP. There are lot's of companies that take advantage of this. It's one of the reasons why MS has so much trouble moving app developers to the new hotness, even if it's safer, faster, or whatever. Because of that the new hotness doesn't get enough traction to support continued development and they sunset it early which draws even more ire from people.

[21]

I use a Windows audio software binary last compiled in 1997, for Windows 95. It still works just fine on Windows 10 64 bit.

That's 20 years of backward compatibility.