4 ms·
For windows that is a very recent change. The ABI used to change with every compiler rev. Further without buyin from the actual standard there’s no gurantee a
by jdsully 7y ago
For windows that is a very recent change. The ABI used to change with every compiler rev.
Further without buyin from the actual standard there’s no gurantee a breaking change won’t be forced by the standard at some point.
- pjmlp 7y agoNot for libraries exposed as DLL or COM. Although one might argue that is only a C++ subset.
- jdsully 7y agoCOM is based off of the C ABI not C++. This was done specifically because C++ does not have a stable ABI.
- pjmlp 7y agoThere is no such thing as C ABI, rather Windows ABI, which you can even select several calling conventions, including Pascal based one. COM is based on the way Visual C++ lays out the VMT, and only masochists use it from bare bones C.
- int_19h 7y agoC ABI is basically structs + functions + function pointers. On Win32, functions and function pointers includes calling conventions, but that's not really important. COM is a C ABI in a sense that its spec defines everything in these terms. Yes, in practice it translates nicely to C++ vtables, but the stability guarantees are defined on the lower level.
- pjmlp 7y agoFrom that point of view, it is also a Pascal ABI.
- int_19h 7y agoSure, and several dozen other languages. That's really what it is - the lowest common denominator that almost every language can work with.
- pjmlp 7y agoAs the OS ABI should be.
- int_19h 7y agoThis is a kind of a chicken and egg thing - it is the OS ABI because everybody supports it, and everybody supports it because it's the OS ABI. I think that the fact that it has the features that it does is mostly a coincidence of timing, and languages popular at the time on platforms that were popular enough. If it happened 15 years later, the feature set might have been larger.
- userbinator 7y agoThe ABI used to change with every compiler rev. That's only because they changed the standard library. The ABI itself didn't change much if at all, I believe you can still get the latest compiler to link with the far more compatible MSVCRT.DLL that's been there since the first Win32 OS (Win95).
- jdsully 7y agoI guess it matters whether you consider name mangling to be a part of the ABI. Name mangling used to change quite frequently. Starting with VS 2015 Microsoft promised to make these changes much less frequent but AFAIK didn't promise to never make changes here. MSVCRT.DLL has kept stability but Microsoft makes no official promises about it. It's considered undocumented. Source: https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019 https://docs.microsoft.com/en-us/cpp/build/reference/decorat...
- userbinator 7y agoMSVCRT.DLL has kept stability but Microsoft makes no official promises about it. That's because it doesn't need to be said. Countless numbers of existing applications would break if it changed, and MS still cares enough about backward compatibility and knows that many huge and important customers depend on them to not do that.
- deleted 7y ago[deleted]
- jdsully 7y agoThis is really moot since MSVCRT is a C runtime lib with MSVCPRT being the the C++ one. Again no stability guarantees are made with any of this. Microsoft promises backward compatibility but not forward compatibility. There is no promise you can link new code with old DLLs. Just that older binaries will still execute unmodified. Very recently with VS2015 they promised "some" forward compatibility and to make fewer changes. In practice there were things you could do to increase the chances of this working. But to call this "stable" would render the term meaningless.