> 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

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