Hi
Damyan Ognyanoff wrote:
> I sugest you to write your app as a .so lib and to
> write a small loader. which can perform additional
> LoadLibrary'c in it's WinMain routine to load MFC and
> your app.
Thanks.. this method works.
i.e. dlopen(libmfc..)
LoadLibrary( mfc..)
GetProcAddress ( for MFC's WinMain)
Call WinMain
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?
All this because some apps use third party dlls for which source code is
not available and it has to be loaded natively.
"Wilbur N. Dale" wrote:
>
> hand, if libmfc is meant for winelib use only, you may not need to list the
> ordinals. I have not tried to create a library with out ordinals so you may
> want to experiment.
It works without ordinals also if only used for winelib as u said.
>
> 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.
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.
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?
Thanks
Vivek
