5 ms·

I never got why ABI incompatibility is such a big problem. Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Why can't people

I never got why ABI incompatibility is such a big problem. Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Why can't people just respect whatever the convention on each platform is and move on? It's not like you need ABIs to be cross-compatible across platforms.

fsloth 4y ago
I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. There are other problems as well from the "hands off" quality of the standard. Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't.
- dataflow 4y ago
  > I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. Not really. Windows already has specific ABIs that it follows (in NTDLL, MSVCRT, COM DLLs), etc., and that includes virtual functions and exception tables and unwinding and all that. MSVC follows them fine. There's no reason other compilers shouldn't be able to. They just don't seem to want to. > There are other problems as well from the "hands off" quality of the standard. Sure, but none of them imply "it's better to defy the convention by default". You still lessen the friction by following the convention. > Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't. That's an orthogonal problem, it's not like you're somehow making that problem any easier by switching to a different ABI than what you know is already conventional on the platform.
  - pjmlp 4y ago
    Other Windows native compilers do, like C++ Builder. It is really only the UNIX folks refusing to adopt the platform idioms.
  - froh 4y ago
    are they ABIs free or are they patented? I seriously don't know but that would be a sound reason.
    - gpderetta 4y ago
      IIRC there were patents around structured exceptions which made it hard to implement the WIN32 ABI. Not sure about the 64bit ABI.
    - dataflow 4y ago
      That would be a sound reason for the things that were patented, but even the non-patented stuff didn't enjoy compatibility. w.r.t. patents, the only thing I've heard of having been patented is SEH (by Borland, presumably after seeing GCC wasn't implementing the then-patent-less SEH), and even that I'm not sure about the relevance of. (I saw it in the context of WINE, which has to implement the OS-side of it, not the compiler side.)
- deleted 4y ago
  [deleted]
- ogoffart 4y ago
  > I suppose the key reason is ABI is not defined by the language standard? It is hard to define ABI in the language standard, since ABI heavily depends on the architecture. (The ABI specify, for example, the calling conventions and in what register goes what, which depends on what kind of register the CPU has)
chrisseaton 4y ago
> Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Isn't the point of a using a different compiler to let it compile your code in different ways? Having to meet an arbitrary ABI is a limiting restriction you may not want.
- dataflow 4y ago
  That's when you add a flag (or annotation/attribute/whatever) to let users switch to an unconventional ABI when they really want to. That doesn't mean your default choice has to be something that deliberately defies the convention and makes life harder for everyone by default.
bpye 4y ago
LLVM/Clang does mostly support the MSVC C++ ABI today - https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html . I've not used it for anything major but in my limited experience it does work. Native PDB generation also makes debug much more pleasant with tools like WinDbg.
- dataflow 4y ago
  Kind of, but that's kind of my point. It's a relatively recent development, and like you also hint, it's still incomplete. (e.g., IIRC /DEBUG:FASTLINK doesn't work, and I think SEH doesn't have full support either... last time I tried using Clang/LLVM I ran into lack of support for some features I wanted and had to revert to MSVC.) For another, Clang is the exception (no pun intended) rather than the norm among these *nix tools. After refusing to adapt like the rest, it finally caved in. Most *nix folks still don't seem to accept that the sensible thing is to follow the platform (case in point being the comment I replied to). And lastly... it's not even always the default behavior for Clang. The versions you get bundled with (say) MinGW still refuse to follow the platform rules, due to the eagerness to cater to GNU. It's only the MSVC-flavored ones that have any respect for the platform they're trying to support. Then people keep bashing (again no pun intended) Windows for not following UNIX conventions...
  - pjmlp 4y ago
    Yeah, the usual any OS is good, as long as it is an UNIX clone.
  - mook 4y ago
    I believe SEH (possibly for x86?) used a patented algorithm (Wikipedia says it expired in 2014), so it wasn't possible to actually do anything about it earlier than that.
    - gpderetta 4y ago
      IIRC the Windows 64bit exception unwind table model was also different enough (and not well documented) from DWARF that it took a long time to implement it (I'm not sure if it is fully working yet).
formerly_proven 4y ago
It took Microsoft a pretty long time to settle on one C++ ABI. Until then, every major MSVC version had its own, incompatible C++ ABI - no "Windows ABI".
- dataflow 4y ago
  Are you sure? What are you calling "a pretty long time" here? When you say "until then" - when is "then"? What exactly was unsettled at that point that supposedly caused a divergence? I would understand if *nix folks at least tried to adapt to the platform and were then forced to diverge due to a lack of convention for some new feature, but that isn't the case at all. The compilers follow *nix rules for even the most basic name mangling. They don't seem to have made any initial attempt at platform C++ ABI compatibility whatsoever; they just carried the *nix way into Windows.
  - IshKebab 4y ago
    Yes it was recent. I looked it up - it's been stable since Visual Studio 2015.
  - ogoffart 4y ago
    The ABI is only compatible between versions since MSVC 2015: https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-... Also I think the debug and release build are still incompatible.
    - dataflow 4y ago
      That date is pretty misleading unfortunately. And note "it happened recently" and "it took a pretty long time" are different claims. IIRC the aspects of the ABI that "broke" across (say) 2013 and 2015 were generally (if not entirely) for the support of newer features, like thread-safe static initialization. That stuff was only standardized in C++11, which is 4 years, not something I'd call a "long time" (especially considering how long it took everyone to finish implementing C++11). But even worse than that, it's not like GCC had been compatible with the basics before this. It couldn't even bring itself to mangle "void foo() { }" in a platform-compatible way, and it's not like that took until 2015 for Microsoft to settle on.
ordu 4y ago
It's a long tradition of Windows to have some weird ABI. Even before C++ Windows API used "pascal calling convention". And then MS probably intentionally made it difficult to follow their C++ ABI to shun away all other compilers from their platform. They did a lot of this at the time.
- pjmlp 4y ago
  Borland, Intel, Symantec and Watcom managed just fine.

fsloth 4y ago

I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. There are other problems as well from the "hands off" quality of the standard. Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't.

dataflow 4y ago
> I suppose the key reason is ABI is not defined by the language standard? Nor is it is something (AFAIK) that would be standardized on Windows. This is not the same thing as binary compatibility on windows but rather about the internals of virtual function tables and so on. Not really. Windows already has specific ABIs that it follows (in NTDLL, MSVCRT, COM DLLs), etc., and that includes virtual functions and exception tables and unwinding and all that. MSVC follows them fine. There's no reason other compilers shouldn't be able to. They just don't seem to want to. > There are other problems as well from the "hands off" quality of the standard. Sure, but none of them imply "it's better to defy the convention by default". You still lessen the friction by following the convention. > Endemic of how bad the situation is regarding C++ DLL:s is that you can't free memory in a different C++ DLL than where it was allocated. Well, you _can_ but most of the time you shouldn't. That's an orthogonal problem, it's not like you're somehow making that problem any easier by switching to a different ABI than what you know is already conventional on the platform.
- pjmlp 4y ago
  Other Windows native compilers do, like C++ Builder. It is really only the UNIX folks refusing to adopt the platform idioms.
- froh 4y ago
  are they ABIs free or are they patented? I seriously don't know but that would be a sound reason.
  - gpderetta 4y ago
    IIRC there were patents around structured exceptions which made it hard to implement the WIN32 ABI. Not sure about the 64bit ABI.
  - dataflow 4y ago
    That would be a sound reason for the things that were patented, but even the non-patented stuff didn't enjoy compatibility. w.r.t. patents, the only thing I've heard of having been patented is SEH (by Borland, presumably after seeing GCC wasn't implementing the then-patent-less SEH), and even that I'm not sure about the relevance of. (I saw it in the context of WINE, which has to implement the OS-side of it, not the compiler side.)
deleted 4y ago
[deleted]
ogoffart 4y ago
> I suppose the key reason is ABI is not defined by the language standard? It is hard to define ABI in the language standard, since ABI heavily depends on the architecture. (The ABI specify, for example, the calling conventions and in what register goes what, which depends on what kind of register the CPU has)

chrisseaton 4y ago

> Why does every non-Windows compiler insist on bringing a non-Windows ABI to Windows? Isn't the point of a using a different compiler to let it compile your code in different ways? Having to meet an arbitrary ABI is a limiting restriction you may not want.

dataflow 4y ago
That's when you add a flag (or annotation/attribute/whatever) to let users switch to an unconventional ABI when they really want to. That doesn't mean your default choice has to be something that deliberately defies the convention and makes life harder for everyone by default.

bpye 4y ago

LLVM/Clang does mostly support the MSVC C++ ABI today - https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html . I've not used it for anything major but in my limited experience it does work. Native PDB generation also makes debug much more pleasant with tools like WinDbg.

dataflow 4y ago
Kind of, but that's kind of my point. It's a relatively recent development, and like you also hint, it's still incomplete. (e.g., IIRC /DEBUG:FASTLINK doesn't work, and I think SEH doesn't have full support either... last time I tried using Clang/LLVM I ran into lack of support for some features I wanted and had to revert to MSVC.) For another, Clang is the exception (no pun intended) rather than the norm among these *nix tools. After refusing to adapt like the rest, it finally caved in. Most *nix folks still don't seem to accept that the sensible thing is to follow the platform (case in point being the comment I replied to). And lastly... it's not even always the default behavior for Clang. The versions you get bundled with (say) MinGW still refuse to follow the platform rules, due to the eagerness to cater to GNU. It's only the MSVC-flavored ones that have any respect for the platform they're trying to support. Then people keep bashing (again no pun intended) Windows for not following UNIX conventions...
- pjmlp 4y ago
  Yeah, the usual any OS is good, as long as it is an UNIX clone.
- mook 4y ago
  I believe SEH (possibly for x86?) used a patented algorithm (Wikipedia says it expired in 2014), so it wasn't possible to actually do anything about it earlier than that.
  - gpderetta 4y ago
    IIRC the Windows 64bit exception unwind table model was also different enough (and not well documented) from DWARF that it took a long time to implement it (I'm not sure if it is fully working yet).

formerly_proven 4y ago

It took Microsoft a pretty long time to settle on one C++ ABI. Until then, every major MSVC version had its own, incompatible C++ ABI - no "Windows ABI".

dataflow 4y ago
Are you sure? What are you calling "a pretty long time" here? When you say "until then" - when is "then"? What exactly was unsettled at that point that supposedly caused a divergence? I would understand if *nix folks at least tried to adapt to the platform and were then forced to diverge due to a lack of convention for some new feature, but that isn't the case at all. The compilers follow *nix rules for even the most basic name mangling. They don't seem to have made any initial attempt at platform C++ ABI compatibility whatsoever; they just carried the *nix way into Windows.
- IshKebab 4y ago
  Yes it was recent. I looked it up - it's been stable since Visual Studio 2015.
- ogoffart 4y ago
  The ABI is only compatible between versions since MSVC 2015: https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-... Also I think the debug and release build are still incompatible.
  - dataflow 4y ago
    That date is pretty misleading unfortunately. And note "it happened recently" and "it took a pretty long time" are different claims. IIRC the aspects of the ABI that "broke" across (say) 2013 and 2015 were generally (if not entirely) for the support of newer features, like thread-safe static initialization. That stuff was only standardized in C++11, which is 4 years, not something I'd call a "long time" (especially considering how long it took everyone to finish implementing C++11). But even worse than that, it's not like GCC had been compatible with the basics before this. It couldn't even bring itself to mangle "void foo() { }" in a platform-compatible way, and it's not like that took until 2015 for Microsoft to settle on.

ordu 4y ago

It's a long tradition of Windows to have some weird ABI. Even before C++ Windows API used "pascal calling convention". And then MS probably intentionally made it difficult to follow their C++ ABI to shun away all other compilers from their platform. They did a lot of this at the time.

pjmlp 4y ago
Borland, Intel, Symantec and Watcom managed just fine.