Eric Pouech wrote:
> there are several issues involved:
> 1/ getting some functions addresses. this can be done using
> LoadLibrary/GetProcAddress functions
> 2/ C++ name mangling; as you known, a C++ compiler uses internally
> what's called mangled names, so that in can distinguish between
> methods with same names, but in different classes, or overloaded
> methods (in the same class). So from a class, method and arguments
> type list a mangled name is created (for example, __5String6GetNthI
> could be String::GetNth(int);) However, name mangling is compiler
> dependent. so if your DLL exports mangled names, you have to take
> care of that
> 3/ the "glue" code is in fact always generated: under Windows, when
> a program loads DLL D and uses some of its entry points, a Windows
> compiler/linker does the following:
> - from D, it creates a small (static) library which is
> linked/embedded inside the program. This libs defines the entry
> point functions for D so that program D can link (all symbols
> resolved). When the program is loaded (or when a function for the
> DLL is called) the address for the effective function (in D) is
> gotten by the program so that a call to that address can be done.
> you can imagine such a 'stub' as:
> int the_function(type1 p1, type2 p2)
> {
> static int (*pf)(type1, type2);
> if (!pf) pf = GetProcAddress(hlib, "the_function");
> return (pf)(p1, p2);
> }
> the glue is only needed to make the bridge between two modules
> (program and DLL) even if they are separate entities
>
> in your case, when the DLL 'big function' returns a function
> pointer, it can be called.
So, I understand is that if one DLL (foo) calls another DLL (bar) then
foo already has stubs for bar compiled in and I don't need to make
stubs for bar if I don't want to call it directly from my WineLib
program?
> 4/ when it returns an object, that's may be a bit more hard. As seen above,
> C++ doesn't specify name mangling, you may run into trouble with:
> - objects layout
> - virtual methods
> interoperability of c++modules compiled by different vendors is not given
> (in your case a windows compiler vs gcc)
>
> those are the main reasons why C++ interfaces to DLL are a bad idea
Yeah, the mixture of C++ mangling and even greater mangling skill of
MS programmers gives us a greatly mangled way of doing simple things
in mangled fashion :)
I am almost sure that my DLLs are compiled with MSVC++ 5.0 or 6.0.
Are there any "demanglers" for MSVC++ such as c++filt in GNU C++? Or
maybe someone knows a place with documentation of MSVC++ object layout
and virtual methods handling?
I am considering using Borland tools to compile a small program which
could be ran in wine. How much of performance I would loose doing
things in that way?
> COM/DCOM tries to fill this gap (as CORBA does)
The vendor also supplied an OLE control as an interface to the dlls.
What if I wanted to use OLE automation in WineLib to get things
working? Do you happen to know what part of Wine source code tree
covers ActiveX controls?
Best regards,
Peter
PS. Thanks a lot. If you gave me your smail address I would send you
a postcard from Poland :)
