CODEWITHSUNDEEP
visual-studiovisual-c++visual-c++-6
John Z. Li
John Z. Li

Reputation: 1995

Is it a good idea to call a dll made of VC++6.0 from Visual Studio 2015

I have to deal with one ancient software module which only support its API being called from VC++6.0.

If I add an indirection layer, that is, wrapping the module in a dynamic library written with VC++6.0 and transferring API to the underlying module. The dll will be called from a VC++ tool chain provided in Visual Studio 2015.

My question is:

  1. Is this doable in principle?
  2. Are there any pitfalls one might want to may attention?
  3. Can it be done in a better way?

Update: I guess that the C ABI is stable through different windows versions as well as corresponding supported VS version. If the dll is made with pure C, this might be done without too much trouble.

Upvotes: 0

Views: 142

Answers (1)

Anders
Anders

Reputation: 101666

There are at least two issues preventing portability between versions/vendors: C++ object/class layout and the C/C++ memory allocators.

To avoid the first issue you should design the visible API as a set of C functions (like most of the Win32 API).

The memory issue can be solved by switching from new/malloc to one of the native Windows functions like LocalAlloc, HeapAlloc or CoTaskMemAlloc. Assuming your old .dll is not statically linked it would theoretically be possible to force newer code to use the malloc in msvcrt.dll but it makes your build setup a bit fragile and it goes against current best practices.

Another alternative is for the middleman .dll to implement everything as a COM object:

EXTERN_C HRESULT WINAPI CreateMyObject(IMyObject**ppv) ...

Upvotes: 1

Related Questions