GCC vs MS C++ compiler for maintaining API backwards binary compatibility

Question

I came from the Linux world and know a lot of articles about maintaining backwards binary compatibility (BC) of a dynamic library API written in C++ language. One of them is "Policies/Binary Compatibility Issues With C++" based on the Itanium C++ ABI, which is used by the GCC compiler. But I can't find anything similar for the Microsoft C++ compiler (from MSVC).

I understand that most of the techniques are applicable to the MS C++ compiler and I would like to discover compiler-specific issues related to ABI differences (v-table layout, mangling, etc.)

So, my questions are the following:

• Do you know any differences between MS C++ and GCC compilers when maintaining BC?
• Where can I find information about MS C++ ABI or about maintaining BC of API in Windows?

Any related information will be highly appreciated.
Thanks a lot for your help!

Kelwunn

That all looks good advice no matter which compiler you're using. Actually the text says "This text applies to most C++ ABIs used by compilers which KDE can be built with." and refers to a source for MSVC ABI information too - so this may well already cover the MSVC ABI. – Photodrama

Good question - but the intermixing of API and ABI seems unclear. Both title and text could do with an edit; the title makes no comment about ABI, when I think it should at least reference binary compatibility. – Playwriting

@Photodrama - They are also noted: it's the most complete information found so far on MSVC ABI and name mangling and some of the constraints specified here may not apply to a given compiler. I want to discover compiler-specific issues. – Kelwunn

@Playwriting - I've changed the title to be more binary-specific. – Kelwunn

Hmm, the only ways I can get you to stop editing the tags on this question is either to lock it, or to lock you. I don't want to screw up your bounty, so... Editing a post 17 times to bump it typically results in the post ending up community owned, so you might not want to try that cheesiness on non-bounty questions. – Nehemiah

Answer 1

First of all these policies are general and not refer to gcc only. For example: private/public mark in functions is something specific to MSVC and not gcc.

So basically these rules are fully applicable to MSVC and general compiler as well.

But...

You should remember:

1. GCC/C++ keeps its ABI stable since 3.4 release and it is about 7 years (since 2004) while MSVC breaks its ABI every major release: MSVC8 (2005), MSVC9 (2008), MSVC10 (2010) are not compatible with each other.
2. Some frequently flags used with MSVC can break ABI as well (like Exceptions model)
3. MSVC has incompatible run-times for Debug and Release modes.

So yes you can use these rules, but as in usual case of MSVC it has much more quirks.

See also "Some thoughts on binary compatibility" and Qt keeps they ABI stable with MSVC as well.

Note I have some experience with this as I follow these rules in CppCMS

Cranky

For my curiousity: what's changed in the MSVC ABIs across releases? I haven't seen that, and I can't think of anything other than the runtime libraries (and you can just about work around that if you're careful). – Photodrama

@Photodrama - yes, runtimes are incompatible, defaults had changed, for example between MSVC7 and MSVC8 the default meaning of wchar_t changed, and so on. So basically, it is very bad idea to mix libraries compiled with different compiler versions. – Cranky

Your answer is very good, but I hope for more answers because my current work is based on this programming area. I'm planning to start a bounty today. – Kelwunn

Answer 2

On Windows, you basically have 2 options for long term binary compatibility:

1. COM
2. mimicking COM

Check out my post here. There you'll see a way to create DLLs and access DLLs in a binary compatible way across different compilers and compiler versions.

C++ DLL plugin interface

Creeps

Answer 3

The best rule for MSVC binary compatibility is use a C interface. The only C++ feature you can get away with, in my experience, is single-inheritance interfaces. So represent everything as interfaces which use C datatypes.

Here's a list of things which are not binary compatible:

• The STL. The binary format changes even just between debug/release, and depending on compiler flags, so you're best off not using STL cross-module.
• Heaps. Do not new / malloc in one module and delete / free in another. There are different heaps which do not know about each other. Another reason the STL won't work cross-modules.
• Exceptions. Don't let exceptions propagate from one module to another.
• RTTI/dynamic_casting datatypes from other modules.
• Don't trust any other C++ features.

In short, C++ has no consistent ABI, but C does, so avoid C++ features crossing modules. Because single inheritance is a simple v-table, you can usefully use it to expose C++ objects, providing they use C datatypes and don't make cross-heap allocations. This is the approach used by Microsoft themselves as well, e.g. for the Direct3D API. GCC may be useful in providing a stable ABI, but the standard does not require this, and MSVC takes advantage of this flexibility.

Mobile

MSVC C++ looks even worse when you factor in the potential of horrors like SECURE_SCL and HAS_ITERATOR_DEBUGGING to introduce further binary incompatibilities. – Columbite

Yep, that's part of "depending on compiler flags", yet another reason you can't trust the ABI. – Mobile

I was searching for short answer for ABI compatibility outlined in "Essential COM" book. This looks pretty close. – Manuscript

@Columbite Why are they horrors? Have you used those features? – Eckmann

@0fnt: yes, although quite a few years ago now (when this question was active). For small scale development they're fine and useful, but they caused nothing but trouble for larger scale development when one team attempted to use libs produced by another team: some teams preferred a "pure" approach, others were oblivious and had just gone with MSVC defaults which enabled them. The muddle was eventually resolved by an organization-wide agreement that such extras be eliminated from builds for distribution. – Columbite

@Columbite ABI issues aside, all I'm trying to say is that you're spreading misinformation about the feature themselves. They are not horrors. The ABI issues are. – Eckmann