6 ms·

I always feel the Linux people learn the wrong lesson from these events. The difference between the Linux and the OpenBSD mentality in one example. The ABI mu

by somat 5y ago

I always feel the Linux people learn the wrong lesson from these events. 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.

leeter 5y ago
This forgets MS: 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.
- secondcoming 5y ago
  One flaw with that is that the struct size won't change if you do something like reordering the members (not that anyone would ever do that).
  - leeter 5y ago
    Which they explicitly prohibit, in fact if you look at how they design the APIs they'll deliberately add reserved members to ensure they hold the space so that it's much harder to break.
  - asveikau 5y ago
    Yes, it takes some discipline to keep that working. You need to internalize which changes cause ABI breaks, look for them in code reviews, evangelize that culture to new hires that aren't familiar with the rules (which becomes harder over time as people coming up now tend to spend less time learning C), etc.
- Someone 5y ago
  Example: https://gankra.github.io/blah/c-isnt-a-language/#case-study-minidump_handle_data https://gankra.github.io/blah/c-isnt-a-language/#case-study-...
  - leeter 5y ago
    NGL... that inspired my comment XD
- stouset 5y ago
  While Microsoft's backwards-compatibility guarantees have historically been a strong competitive advantage for them… every time I get a glance into Windows APIs I'm blown away by how much historical garbage they seem to be stuck with. 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.
  - leeter 5y ago
    Honestly? Having written software for both Win32 is actually pretty nice to work in. Better in many ways than the alternatives. Most of the things Raymond goes on about are weird quirks you can ignore for the most part. Whereas there are some very serious hazards running around POSIX if you're not careful that can bite hard. Glares at signals 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.
  - hnlmorg 5y ago
    While I much prefer Linux as a platform, it’s fair to say Linux has more than it’s fair share of historical baggage as well. The entire design of the console for starter: TTYs, ANSI escape sequences used for encoding data in band, typeless byte streams, job control being a weird cross responsibility between the kernel, shell and application, etc. …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.
  - _3u10 5y ago
    It’s so much nicer than Linux. 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.
- orra 5y ago
  > 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 said, I couldn't name you a Win32 that actually has more than one valid value for said cbSize member. Are there any?
  - coldpie 5y ago
    Sure, you can find a fair number with a grep of the Wine source. Try "git grep if.*cbSize", there's a few obvious ones and some less obvious, too. One example: https://source.winehq.org/git/wine.git/blob/62df608d3ed84aac7ce517fd07ea13e48b49b08c:/dlls/shell32/systray.c#l64 https://source.winehq.org/git/wine.git/blob/62df608d3ed84aac...
  - pitterpatter 5y ago
    It's hard to notice sometimes because the a struct FOO is often a typedef to whatever the latest version is in the SDK you're using (FOO1, FOO2, etc).
    - alternatetwo 5y ago
      This happens a lot in the Media SDKs, dsound, ddraw, dplay etc. Not that they're really used nowadays.
  - MaulingMonkey 5y ago
    um/winuser.h has some, although they haven't changed in awhile. WNDCLASSEX gained hIconSm after Windows 3.x. MENUITEMINFO gained hbmpItem in Windows 2000. NONCLIENTMETRICS gained iPaddedBorderWidth in Windows Vista. https://devblogs.microsoft.com/oldnewthing/20031212-00/?p=41523 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/wincrypt.h also has a few structures chopped up with #ifdef ..._HAS_EXTRA_FIELDS s that are presumably differentaited between via cbSize. 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.
- Asooka 5y ago
  Also "make everyone carry their dependencies down to the standard C library". The churn that the userland on Linux distros has is very unfortunate, but it's probably not going to change any time soon. It's not that hard to ship software with minimal dependencies if you know what you're doing, but it sure is easier for Windows.
- ithkuil 5y ago
  AmigaOS2.0 had an interesting API: tag arrays: a variable length key/value pair of parameters
idealmedtech 5y ago
The issue, based on my read, is that lots of existing applications, many of whom are proprietary and may not be supported by their vendors, _depend_ on ABI stability, and a break cause these applications to simply fail, for what appears like no good reason (how many businesses care that their legacy app broke because of supporting a niche CPU architecture?). That's the big issue here, and the historical reason for caution.
- rwmj 5y ago
  This specific issue affected s390x which is pretty niche but the general principle of not breaking ABI affects all architectures.
ggreg84 5y ago
If you can re-compile all your source code, then ABI stability is not that important. 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.
- ece 5y ago
  The source-based Linux distros (Gentoo in my experience) do try to get better at keeping things working and moving forward when ABI breaks occur. Recompiling downstream dependencies (FFIs, libraries/packages), keeping the old library/packages around until a new ones are available, and keeping track of breaks/automating fixes with versioning all happen when for example a new boost or qt version comes out. All of this automated by the package manager. Proprietary packages that require fixed ABIs from certain libraries have *-compat packages in the gentoo repos, and other distros have this too. 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.
- moonbug 5y ago
  no one uses Debian on s/390 for anything important anyway
- alerighi 5y ago
  And even if you can recompile everything, it's still a pain to do so, and it's better to avoid doing so. Also recompiling the software may not be as simple, for example can require modifications of its source code to adapt it to newer versions of the compiler or other libraries that changed, and of course you can't build it on an older system since the ABI changed. 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.
marcodiego 5y ago
> 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. I think ISV's disagree.
matheusmoreira 5y ago
> 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. 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.
deleted 5y ago
[deleted]

by somat 5y ago

leeter 5y ago

This forgets MS: 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.

secondcoming 5y ago
One flaw with that is that the struct size won't change if you do something like reordering the members (not that anyone would ever do that).
- leeter 5y ago
  Which they explicitly prohibit, in fact if you look at how they design the APIs they'll deliberately add reserved members to ensure they hold the space so that it's much harder to break.
- asveikau 5y ago
  Yes, it takes some discipline to keep that working. You need to internalize which changes cause ABI breaks, look for them in code reviews, evangelize that culture to new hires that aren't familiar with the rules (which becomes harder over time as people coming up now tend to spend less time learning C), etc.
Someone 5y ago
Example: https://gankra.github.io/blah/c-isnt-a-language/#case-study-minidump_handle_data https://gankra.github.io/blah/c-isnt-a-language/#case-study-...
- leeter 5y ago
  NGL... that inspired my comment XD
stouset 5y ago
While Microsoft's backwards-compatibility guarantees have historically been a strong competitive advantage for them… every time I get a glance into Windows APIs I'm blown away by how much historical garbage they seem to be stuck with. 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.
- leeter 5y ago
  Honestly? Having written software for both Win32 is actually pretty nice to work in. Better in many ways than the alternatives. Most of the things Raymond goes on about are weird quirks you can ignore for the most part. Whereas there are some very serious hazards running around POSIX if you're not careful that can bite hard. Glares at signals 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.
- hnlmorg 5y ago
  While I much prefer Linux as a platform, it’s fair to say Linux has more than it’s fair share of historical baggage as well. The entire design of the console for starter: TTYs, ANSI escape sequences used for encoding data in band, typeless byte streams, job control being a weird cross responsibility between the kernel, shell and application, etc. …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.
- _3u10 5y ago
  It’s so much nicer than Linux. 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.
orra 5y ago
> 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 said, I couldn't name you a Win32 that actually has more than one valid value for said cbSize member. Are there any?
- coldpie 5y ago
  Sure, you can find a fair number with a grep of the Wine source. Try "git grep if.*cbSize", there's a few obvious ones and some less obvious, too. One example: https://source.winehq.org/git/wine.git/blob/62df608d3ed84aac7ce517fd07ea13e48b49b08c:/dlls/shell32/systray.c#l64 https://source.winehq.org/git/wine.git/blob/62df608d3ed84aac...
- pitterpatter 5y ago
  It's hard to notice sometimes because the a struct FOO is often a typedef to whatever the latest version is in the SDK you're using (FOO1, FOO2, etc).
  - alternatetwo 5y ago
    This happens a lot in the Media SDKs, dsound, ddraw, dplay etc. Not that they're really used nowadays.
- MaulingMonkey 5y ago
  um/winuser.h has some, although they haven't changed in awhile. WNDCLASSEX gained hIconSm after Windows 3.x. MENUITEMINFO gained hbmpItem in Windows 2000. NONCLIENTMETRICS gained iPaddedBorderWidth in Windows Vista. https://devblogs.microsoft.com/oldnewthing/20031212-00/?p=41523 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/wincrypt.h also has a few structures chopped up with #ifdef ..._HAS_EXTRA_FIELDS s that are presumably differentaited between via cbSize. 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.
Asooka 5y ago
Also "make everyone carry their dependencies down to the standard C library". The churn that the userland on Linux distros has is very unfortunate, but it's probably not going to change any time soon. It's not that hard to ship software with minimal dependencies if you know what you're doing, but it sure is easier for Windows.
ithkuil 5y ago
AmigaOS2.0 had an interesting API: tag arrays: a variable length key/value pair of parameters

idealmedtech 5y ago

The issue, based on my read, is that lots of existing applications, many of whom are proprietary and may not be supported by their vendors, _depend_ on ABI stability, and a break cause these applications to simply fail, for what appears like no good reason (how many businesses care that their legacy app broke because of supporting a niche CPU architecture?). That's the big issue here, and the historical reason for caution.

rwmj 5y ago
This specific issue affected s390x which is pretty niche but the general principle of not breaking ABI affects all architectures.

ggreg84 5y ago

If you can re-compile all your source code, then ABI stability is not that important. 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.

ece 5y ago
The source-based Linux distros (Gentoo in my experience) do try to get better at keeping things working and moving forward when ABI breaks occur. Recompiling downstream dependencies (FFIs, libraries/packages), keeping the old library/packages around until a new ones are available, and keeping track of breaks/automating fixes with versioning all happen when for example a new boost or qt version comes out. All of this automated by the package manager. Proprietary packages that require fixed ABIs from certain libraries have *-compat packages in the gentoo repos, and other distros have this too. 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.
moonbug 5y ago
no one uses Debian on s/390 for anything important anyway
alerighi 5y ago
And even if you can recompile everything, it's still a pain to do so, and it's better to avoid doing so. Also recompiling the software may not be as simple, for example can require modifications of its source code to adapt it to newer versions of the compiler or other libraries that changed, and of course you can't build it on an older system since the ABI changed. 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.

marcodiego 5y ago

matheusmoreira 5y ago

> 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. 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.

deleted 5y ago

[deleted]