Re: VC++ 6.0, 7.0, and 8.0 Compatibility

[David Wilkinson]

carlm wrote:

> We have existing VC++ 6.0 and 7.0 code, but are upgrading to Visual 2005 and
> intend to use VC++ 8.0 as well. (I, myself, have been stuck in VC++ 6.0 land
> up until now). The question is: Are all these versions compatibile at the
> .exe/.dll level? I am asking only about unmanaged C++ code. Can I mix and
> match .exe's and .dll's from all of these versions? Is there some kind of
> compatibility matrix available somewhere?

Carl:

I think you will find that these compileres are compatible for "C-style"
code, and perhaps also for simple C++ classes. But if you use libraries
(e.g the C++ standard library or MFC) you certainly cannot pass library
objects across a DLL boundary, because the layout of the objects may be
different.

COM interfaces of course are OK.

David Wilkinson

[carlm]

Perhaps it might be a naive perspective, but it would seem that somehow
maintaining backward compatibility between these versions would have been a
goal.
--
Carl

[carlm]

BTW, I realize that "mix and match" would mainly apply to backward
compatibility between components built with different versions of the
compiler, library, and class framework.

--
Carl

[David Wilkinson]

carlm wrote:

> Perhaps it might be a naive perspective, but it would seem that somehow
> maintaining backward compatibility between these versions would have been a
> goal.

Carl:

How can a library be improved if you are not allowed to change the
implementation?

Actually, the binary compatibility with MS compilers is much better than
with many others (e.g. gcc).

David Wilkinson

[carlm]

I think I understand the implication of your response, but backward
compatibility might be achieved in different ways. I am sure that we are not
the only ones who have a significant amount of code deployed in the field who
simply cannot afford to upgrade it wholesale. Upgrading pieces of it while
having a means of maintaining binary compatibility with previous versions
seems necessary.

In any case, if anyone can provide a reference that explores compatibility
issues between these three versions of VC++, it would be greatly appreciated.
--
Carl

[Bruno van Dooren [MVP VC++]]

> BTW, I realize that "mix and match" would mainly apply to backward
> compatibility between components built with different versions of the
> compiler, library, and class framework.

There is no specification of how compiled object are layed out in memory.
I.e. everything that works is correct.
And over the last years, a lot has changed and improved. VC++ has a good
track record for backwards compatibility (better than GCC for example) but
sometimes backwards compatibility has to break in order to allow
improvement.
the VC6 compiler is very very old. VC2005 is brand new.

--

Kind regards,
Bruno van Dooren
bruno_nos_pa...@hotmail.com
Remove only "_nos_pam"

[Carl Daniel [VC++ MVP]]

"carlm" <serv...@community.nospam> wrote in message
news:8AA69EDC-B795-487D...@microsoft.com...

>I think I understand the implication of your response, but backward
> compatibility might be achieved in different ways. I am sure that we are
> not
> the only ones who have a significant amount of code deployed in the field
> who
> simply cannot afford to upgrade it wholesale. Upgrading pieces of it while
> having a means of maintaining binary compatibility with previous versions
> seems necessary.
>
> In any case, if anyone can provide a reference that explores compatibility
> issues between these three versions of VC++, it would be greatly
> appreciated.

Just assume that you can't mix and match at all.

There are only 2 significant exceptions to that rule. 1) Your code is
entirely C, or 2) Your DLLs are COM servers.

Outside those guidelines, there's a chance that a mix and match will work,
but there are many factors that have to be addressed.

-cd

[Igor Tandetnik]

Carl Daniel [VC++ MVP]

<cpdaniel_remove...@mvps.org.nospam> wrote:
> Just assume that you can't mix and match at all.
>
> There are only 2 significant exceptions to that rule. 1) Your code
> is entirely C

You probably mean, the DLL's exposed interface is entirely C.
Implementation can happily use C++ internally.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

[Gary Chang[MSFT]]

Hi Carl,

>if anyone can provide a reference that explores compatibility

>issues between these three versions of VC++, ...

I wish the following link would be helpful:

Compatibility and Compliance Issues in Visual C++
http://msdn2.microsoft.com/en-US/library/2tb15w2z.aspx

Thanks!

Best regards,

Gary Chang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Tom Widmer [VC++ MVP]]

carlm wrote:
> Perhaps it might be a naive perspective, but it would seem that somehow
> maintaining backward compatibility between these versions would have been a
> goal.

Not really an achievable one though. There are several areas of binary
compatibility:

1. C ABI
2. C library ABI
3. C++ ABI
4. C++ library ABI
5. COM

1. has been maintained completely, as far as I know. As long as you keep
your #pragma pack, etc. settings the same, you should be able to pass C
structs to VC6 DLLs and back fine.

2. I'm not sure about. Certainly you cannot "free" memory that was
"malloced" in a VC6 DLL and vice versa. I'm not sure whether you can
fclose a VC6 fopened FILE* or not, but probably not. This is more to do
with the fact that different modules are using different CRT modules
than that they are incompatible in any way - the same problem exists
with two VC6 modules that have statically linked to the CRT.

3. Compatibility has been reasonably well maintained I think. You should
be able to pass C++ objects across VC6/VC8 DLL boundaries OK.

4. Compatibility in this area is almost impossible to maintain without
severely constraining any improvement in the C++ library. There is no
compatibility at all - you cannot safely pass std:: objects across
VC6/VC8 module boundaries.

5. All recent VC versions support COM programming.

Tom

[carlm]

Thanks, Tom. This was a helpful characterization.
--
Carl

[carlm]

Thanks, Gary. This will be a useful starting point.
--
Carl

[carlm]

Thanks, everyone for your posts. Hopefully, there is a little more hope for
VC++ 8.0/7.1/7.0 compatibility than between those versions and VC++ 6.0.
--
Carl

[Tom Widmer [VC++ MVP]]

carlm wrote:
> Thanks, everyone for your posts. Hopefully, there is a little more hope for
> VC++ 8.0/7.1/7.0 compatibility than between those versions and VC++ 6.0.

I don't think so. The compatibility problems apply between all compiler
versions. The only time binary compatibility of C++ dlls using standard
library classes in their interfaces won't be broken is with a service pack.

Just to clarify, there is complete binary compatibility between all
those compiler versions (and in some cases with compilers from other
vendors), providing the library writer wrote their library to be
compatible.

Tom

[Bruno van Dooren [MVP VC++]]

> Thanks, everyone for your posts. Hopefully, there is a little more hope
> for
> VC++ 8.0/7.1/7.0 compatibility than between those versions and VC++ 6.0.

As Tom indicated, there is little chance.
And apart from compatibility, there is the memory ownership issue.
Someone ;-) wrote an article about this for the VCFAQ:
http://vcfaq.mvps.org/lang/9.htm