Vivek Dasgupta wrote:
> I also tested one more combination. i.e. i have my mfc application
> <myapp.exe> which uses my single function mfc based dll <mydll.dll>. Now
> i compile myapp.exe linking to libmfc.so & winelib. But i want to use
> native mydll.dll.
> BUt it didn't work.
> SO do I have to also load mydll.dll and GetProcAddress for each function
> in mydll.dll?
For now, that's probably the best solution, though it may not actually
work properly if mydll.dll needs to import from libmfc.
The problem is that myapp.exe is being built with ELF linkage - all the
function calls are being resolved by the ELF linkage mechanisms in ld and
ld.so. Let's say you have myapp.cpp, which makes a call to function Foo()
in mydll.dll. Since you're compiling with ELF tools, ld doesn't know where
to find Foo(), since you can't put mydll.dll on the linker command line
(ld wouldn't know what to do with a PE dll).
This could be worked around with some kind of import library system - IE:
have a tool that can build an ELF stub import library from a PE DLL, with
a initialization routine that would do the LoadLibrary and proc address
resolution for you. But that doesn't exist right now, as far as I know.
Furthermore, even if it did exist, you're going to run into problems with
C++ name mangling if mydll.dll wants to link to mfc: the gcc name mangling
will be different from what mydll expects, so you'll need to make a full
spec file for MFC. You'd probably need the ordinals too.
> All this because some apps use third party dlls for which source code is
> not available and it has to be loaded natively.
> > If you need ordinals in your spec file, the necessary information is in a file
> > MFC42.DEF in the MFC source tree. This file has the mangled names and the
> > ordinals. To create the spec file, you need the unmangled names. The function
> > UnDecorateSymbolName() in the win32 API (see documentation in Visual C++) can
> > unmangle the names. It looks like the spec file can be automatically generated
> > if necessary.
>
> But I suppose we need the mangled names for g++. i.e. unmangle names
> from mfc42.def and use g++ to mangle them and then put them in spec file
> ? I haven't tried this yet.
Yes, this should be what you need if you want your libmfc.so to work with
mydll.dll. The spec file should map the MFC .def name to the g++ mangled
name:
For example, for CWnd::Attach(HWND hWndNew):
The line in the MFC .def file is:
?Attach@CWnd@@QAEHPAUHWND__@@@Z @ 1651 NONAME
And the g++ mangled name is:
Attach__4CWndP6HWND__
So the line in the .spec file should be something like:
1651 stdcall ?Attach@CWnd@@QAEHPAUHWND__@@@Z(ptr ptr) Attach__4CWndP6HWND__
> Also while compiling MFC (or any app) the attribute errors are very
> important. There were a few crashes due to ignoring of attribute
> (stdcall/cdecl) by the compiler. This causes both
> the called function and the calling function to free the used stack
> space resulting in misplacement of stack pointer.
> For most such cases the compiler issues warnings but for a friend
> function the compiler doesn't give warning and still ignores __stdcall
> attribute. Thus function definition uses __stdcall attribute but when it
> is called it uses __cdecl attribute.
> For such cases we declared the function outside the class without friend
> keyword and it works now.
> You could put this in winelib/mfc howto.
This is a g++ bug that Corel had Cygnus work on for g++ compiler enhancements.
Basically, the compiler was ignoring __stdcall attributes in member functions,
if I recall correctly. I'd try using the latest version of g++ to see if it
fixes the problem, and if not, ask people on the gcc mailing list about it.
You'll also want to edit wine/include/wine/obj_base.h to turn on the
com_interface attribute macros. You need these in order to be able to
use native COM objects from C++ built with g++, or for native code to use
COM objects built using g++. Again, you'll need the latest version of g++
for this to work properly.
> Now I am compiling MFC with -D_AFXDLL . However it is giving problems
> with a type
> IBindStatusCallback in oleimpl.h. This is supposed to come from urlmon.h
> and wine doesn't have urlmon.h. Has anybody complied MFC with -D_AFXDLL?
Corel has not yet sent in patches from the header work that was done for
their MFC development. There was definitely a full implementation of urlmon.h,
and other headers. Jeff - would Corel be willing to make the old win_include
headers like urlmon.h available for WineHQ developers to integrate?
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
