Can I use a C style library built with VC6 directly in VC9 project?

We use an internal library(developed by some other team) built with VC6 compiler. This library mainly contains C Style APIs. We have a plan to migrate to Visual Studio 9 compiler. Should I request for the library to be built with VC9 compiler?

A more generic question, On which points ( may be name mangling, optimiza开发者_如何学运维tion etc) a DLL built with two different version of Visual Studio compiler differs?

---

Conflict usually occurs in C Runtime library. The main idea is that memory should be deallocated in module where it was allocated. Then it will be safe to use library that was built with different version of compiler. Another problem is packing of structs, but it has no difference if you use only Visual C++ compiler.

Name mangling is differs from version to version in Visual C++, but it applies only to C++ libraries. If you use C style exporting (for instance, if you have DEF file) then there's nothing to worry about.

This question is not a full duplicate of your, but could be helpful.

---

AFAIK, the Visual C++ name mangling has been stable from release to release.

The main problem is that code compiled with one version has to be linked with the CRTL for that version, and mixing code from multiple versions into the same DLL or EXE won't work because then both object codes expect different RTL routines.

On the other hand, if you link seperate DLLs containing the different libraries it should work. After all, that's the whole point of DLLs.

In that scenario, I would recommend using only extern "C" APIs and (if this is 32-bit code) explicitly specifying the calling convention (__stdcall__ or WINAPI or _cdecl ...)

Also, there's a subtle gotcha when your application has multiple copies of the CRTL: you have multiple heaps! and if an object is allocated on one heap and freed to a different heap, the heap is immediately corrupted and you will crash.

All in all, if you can get them to recompile with your compiler, that's the simplest thing.