Call unmanaged DLL (VS7.0) from VS6.0

Hello newsgroup,

I have to make a confession first: Yes, I'm still using VC6.0 (don't bother
telling me that I should download the 'free' 200* Express Edition, as I want to
use MFC).

Is it possible to call code from an unmanaged Dll written in VS 200[2|3|5] from
VS 6.0 code? AFAIK, MS only changed the way how debug information are stored
inside static libraries, but this shouldn't affect Dlls. To re-phrase the
question: Has the binary layout of classes/structs changed from VS6.0 to VS 200*?

Thanks in advance,
Stuart

David
Wed Oct 24 03:37:28 PDT 2007

Stuart Redmann wrote:
> Hello newsgroup,
>
> I have to make a confession first: Yes, I'm still using VC6.0 (don't
> bother telling me that I should download the 'free' 200* Express
> Edition, as I want to use MFC).
>
> Is it possible to call code from an unmanaged Dll written in VS
> 200[2|3|5] from VS 6.0 code? AFAIK, MS only changed the way how debug
> information are stored inside static libraries, but this shouldn't
> affect Dlls. To re-phrase the question: Has the binary layout of
> classes/structs changed from VS6.0 to VS 200*?

Stuart:

Well, it most certainly will not work if you pass library objects (MFC,
STL ...) across the DLL boundary.

The only patterns that are "guaranteed" to work are a "C" interface and
a "pure interface" interface (a la COM), both using simple types as
arguments.

--
David Wilkinson
Visual C++ MVP

Stuart
Wed Oct 24 04:52:05 PDT 2007

> Stuart Redmann wrote:
>
>> Hello newsgroup,
>>
>> I have to make a confession first: Yes, I'm still using VC6.0 (don't
>> bother telling me that I should download the 'free' 200* Express
>> Edition, as I want to use MFC).
>>
>> Is it possible to call code from an unmanaged Dll written in VS
>> 200[2|3|5] from VS 6.0 code? AFAIK, MS only changed the way how debug
>> information are stored inside static libraries, but this shouldn't
>> affect Dlls. To re-phrase the question: Has the binary layout of
>> classes/structs changed from VS6.0 to VS 200*?

David Wilkinson wrote:
> Well, it most certainly will not work if you pass library objects (MFC,
> STL ...) across the DLL boundary.
>
> The only patterns that are "guaranteed" to work are a "C" interface and
> a "pure interface" interface (a la COM), both using simple types as
> arguments.

That sounds good to me. May I ask you where you have found this particular piece
of information? I'd like to be able to cite MSDN with regard to this.

Regards,
Stuart

David
Wed Oct 24 05:02:49 PDT 2007

Stuart Redmann wrote:
>>> Is it possible to call code from an unmanaged Dll written in VS
>>> 200[2|3|5] from VS 6.0 code? AFAIK, MS only changed the way how debug
>>> information are stored inside static libraries, but this shouldn't
>>> affect Dlls. To re-phrase the question: Has the binary layout of
>>> classes/structs changed from VS6.0 to VS 200*?
>
> David Wilkinson wrote:
>> Well, it most certainly will not work if you pass library objects
>> (MFC, STL ...) across the DLL boundary.
>>
>> The only patterns that are "guaranteed" to work are a "C" interface
>> and a "pure interface" interface (a la COM), both using simple types
>> as arguments.
>
> That sounds good to me. May I ask you where you have found this
> particular piece of information? I'd like to be able to cite MSDN with
> regard to this.

Stuart:

You know the phrase "Everything I know I learned in kindergarten" (I
think it was a book). Well my version of this is "Everything I know I
learned on usenet."

This question comes up quite frequently in the newsgroups, and over the
years I have absorbed the answer (and learned to repeat it). Also, if
you read about how COM works, you will see why pure interfaces are
compiler-independent.

--
David Wilkinson
Visual C++ MVP

Stuart
Wed Oct 24 05:50:07 PDT 2007

>> David Wilkinson wrote:
>>
>>> Well, it most certainly will not work if you pass library objects
>>> (MFC, STL ...) across the DLL boundary.
>>>
>>> The only patterns that are "guaranteed" to work are a "C" interface
>>> and a "pure interface" interface (a la COM), both using simple types
>>> as arguments.
>>
>>
>> That sounds good to me. May I ask you where you have found this
>> particular piece of information? I'd like to be able to cite MSDN with
>> regard to this.

David Wilkinson wrote:
> This question comes up quite frequently in the newsgroups, and over the
> years I have absorbed the answer (and learned to repeat it). Also, if
> you read about how COM works, you will see why pure interfaces are
> compiler-independent.

Nuts. The COM part is clear to me (I consider myself a Senior COM Programmer
;-), but unfortunately the Dll in question does not use COM. However, the
classes that are used inside this Dll are pretty much COM-like, which means that
all calls are made via virtual methods. I guess I have two alternatives:

A) Convince the third party to make his objects proper COM objects, or

B) just try to call the Dll functions and hope for the best. As far as I can
see, the class inside the Dll contains some implementation members taken from
the VS7.1 STL, so I cannot simply create objects of this class: though the
constructor of the class is available in the Dll, VC6.0 doesn't know the exact
size of those objects.

Maybe I can ask the third party for the right size of the object, and use
placement new with a memory block large enough. Besides, the used STL classes
won't have increased in size for more than let's say factor two, so it should be
safe enough to allocate a memory block twice the size of what VS6.0 would use.

Would you consider alternative B) reasonable?

Thanks,
Stuart

David
Wed Oct 24 06:53:26 PDT 2007

Stuart Redmann wrote:
> David Wilkinson wrote:
>> This question comes up quite frequently in the newsgroups, and over
>> the years I have absorbed the answer (and learned to repeat it). Also,
>> if you read about how COM works, you will see why pure interfaces are
>> compiler-independent.
>
> Nuts. The COM part is clear to me (I consider myself a Senior COM
> Programmer ;-), but unfortunately the Dll in question does not use COM.
> However, the classes that are used inside this Dll are pretty much
> COM-like, which means that all calls are made via virtual methods. I
> guess I have two alternatives:
>
> A) Convince the third party to make his objects proper COM objects, or
>
> B) just try to call the Dll functions and hope for the best. As far as I
> can see, the class inside the Dll contains some implementation members
> taken from the VS7.1 STL, so I cannot simply create objects of this
> class: though the constructor of the class is available in the Dll,
> VC6.0 doesn't know the exact size of those objects.
>
> Maybe I can ask the third party for the right size of the object, and
> use placement new with a memory block large enough. Besides, the used
> STL classes won't have increased in size for more than let's say factor
> two, so it should be safe enough to allocate a memory block twice the
> size of what VS6.0 would use.
>
> Would you consider alternative B) reasonable?

Stuart:

I would consider alternative B very fragile, even if you could get it to
work (which I doubt).

Another way to go is to use VC7.1 to write a wrapper DLL for your 3rd
party DLL which exposes a COM or other "pure interface' interface.
Personally I would not use COM, but if you are comfortable with it this
might be the way for you.

--
David Wilkinson
Visual C++ MVP

Ben
Wed Oct 24 08:32:04 PDT 2007


"Stuart Redmann" <DerTopper@web.de> wrote in message
news:ffni7q$aie$1@news.dtag.de...
>>> David Wilkinson wrote:
>>>
>>>> Well, it most certainly will not work if you pass library objects (MFC,
>>>> STL ...) across the DLL boundary.
>>>>
>>>> The only patterns that are "guaranteed" to work are a "C" interface and
>>>> a "pure interface" interface (a la COM), both using simple types as
>>>> arguments.
>>>
>>>
>>> That sounds good to me. May I ask you where you have found this
>>> particular piece of information? I'd like to be able to cite MSDN with
>>> regard to this.
>
> David Wilkinson wrote:
>> This question comes up quite frequently in the newsgroups, and over the
>> years I have absorbed the answer (and learned to repeat it). Also, if you
>> read about how COM works, you will see why pure interfaces are
>> compiler-independent.
>
> Nuts. The COM part is clear to me (I consider myself a Senior COM
> Programmer ;-), but unfortunately the Dll in question does not use COM.
> However, the classes that are used inside this Dll are pretty much
> COM-like, which means that all calls are made via virtual methods. I guess
> I have two alternatives:

How COM-like is it? You need not only pure interfaces, but also a common
allocator (COM uses the task allocator) for simple data types and delegate
allocation and deallocation of objects to the implementer. For example, you
can never delete an object implemented in the library, you must call the
free function provided by the library for that purpose and let it handle the
destruction. Since constructors can't be pure, you need a factory mechanism
based on C-compatible exported global functions.

If you respect memory ownership and treat objects as opaque pointers which
can only be passed to the library functions (you can read the v-table as
well), you'll be ok. Incidentally this means no inline member functions,
and best is for no concrete class definitions to appear in the public
headers at all.