Re: Call unmanaged DLL (VS7.0) from VS6.0
"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.