The difference between the Linux and the OpenBSD mentality in one example.
The ABI must be changed.
Linux: That was really hard, we are never going to do that again.
OpenBSD: That was really hard, we better get good at it.
My opinion: When your deliverable is made up of source code(like these open source projects are), the ABI and ABI stability is not that important, it is the API(the source interface) that is critical.
In the real world,
- people use operating systems to get work done,
- such work is often done with proprietary software that people buy, and that lot of people get paid to develop
- breaking such software is not acceptable, because it means that suddenly dozens of thousand of people can't work
- telling all those people to "stop working" until their software is fixed is not acceptable either.
People use Linux for work in the real world, and that's why Linux tries very hard not to break ABIs.
Microsoft has had a stable ABI for 30 years, and people still run software compiled 30 years ago on the latest Windows version today.
What this tells you about OpenBSD users, is another story.
This is also the reason why containers are so popular these days, ship a software with all its dependencies to avoid having to recompile stuff each time you upgrade or change the operating system.
Ultimately, it is about the APIs when you're compiling from source, a package that isn't using a new API is going to need the old library, and both might need to be compiled with and linked against the same toolchain. I think Linux and BSDs are closer than one might think here. Packaging and upstreams have both gotten better here over time I think, at least over the last couple of decades I've used Linux. I've only played around with the BSDs in VMs.
MS: "Let's design it so either it never breaks or if we can't avoid that we'll just add a FooEx or Foo2 method call"
This is why so many Win32 methods take structs that have a size parameter that must be filled in. That acts as a version parameter. That's not to say they haven't had ABI fun moments... glares at COM.
I get this feeling every time I read a post on The Old New Thing (Raymond Chen). He'll patiently explain why some weird wart is the way it is, or how misusing some API is bad, and it's always extremely interesting. But at the same time I'm sitting there just thanking my lucky stars I've managed to avoid ever having to write software for that environment, because it's always absolutely bonkers.
I much prefer the EVENT based system Win32 goes with. You can just suspend on the event and not worry about it. The kernel will wake you up when it matters. Also MS seems to have very serious API design rules that help keep usage patterns consistent, which is important in making sure things aren't accidentally misused.
…And that’s without addressing any other parts of the system beyond the console.
I’d still take Linux over Windows every day if the week though.
Whatever version of windows you make your software work on it just works on all future versions.
If you don’t like the old APIs don’t use them.
Being able to put software on a website and have people download and use it immediately is kind of amazing compared to Linux.
COM is very annoying tho. I’ll give you that.
That said, I couldn't name you a Win32 that actually has more than one valid value for said cbSize member. Are there any?
One example: https://source.winehq.org/git/wine.git/blob/62df608d3ed84aac...
https://devblogs.microsoft.com/oldnewthing/20031212-00/?p=41...
um/webauthn.h has a bunch of structures that explicitly document fields added in various dwVersion s. However, no individual structure has changed since being published in the Windows SDK last I checked. e.g.:
//
// The following fields have been added in WEBAUTHN_AUTHENTICATOR_MAKE_CREDENTIAL_OPTIONS_VERSION_2
//
// Cancellation Id - Optional - See WebAuthNGetCancellationId
GUID *pCancellationId;
um/ShlObj_core.h has COMPONENT, which extends and is differentiated from IE4COMPONENT - presumably by dwSize.
It also wouldn't suprise me if cbSize is also used to differentiate between 32-bit and 64-bit versions of the same structure as well, with WoW64 blindly forwarding said structures.
I find it interesting upgrading the SDK could make your code invalid, due to uninitialized struct members. Compiler warnings can catch that sort of thing, thankfully—at least these days.
There are other subtle edge cases as well - like needing to make sure all code (including third party libs) is built with the same defines and settings if they might share said structs without painstaking checking cbSize & never passing by value. (Even that might not be enough when statically linking, as it's an ODR violation - and thus undefined behavior - to mix and match different definitions of the same struct...)
It is absolutely important. ABI instability is the number one reason why packaging software on Linux is difficult. Breaking ABI causes pain even for maintainers of free software projects and packages. The Linux kernel is the only project in a Linux distribution that seems to take it seriously.
I think ISV's disagree.