On November 25, 2002 05:39 pm, Francois Gouget wrote:
> However there is no wrapper involved in the above. if you have a
> wrapper, then the load sequence is: wine loads mfcapp.exe.so which is
> the wrapper, and then mfcapp.exe.so then loads mfcapp.dll.so which
> contains the actual application.
But we have a wrapper already, why do we need two of them? It seems to
me one should be enough, if we can instruct wine to load said libs
before loading the app, no?
> I say 'mfcapp' because it's a typical case where you need the arapper.
> The reason for this one is that because of C++ you need to link to the
> mfc library in the Unix sense (Winelib does not know how to import
> virtual table pointers because they are variables, not functions). But
> this causes MFC static initializers to run before the dlls it depends on
> have been loaded and initialized.
Sorry, I have to admit: this linking, importing, etc. is all Chinese to me.
Is this ignorance of importing variables a limitation of Winelib that we
can fix (import libraries?), or is it something fundamentally unfixable?
BTW, can you please take a look here:
http://www.dssd.ca/wine/Winelib-Apps.html#visual-mingw
It seems I'm running in the same problem.
The way I understand it though is a bit different (or so it seems to me):
-- wine calls PROCESS_InitWine (first thing it does in main())
-- PROCESS_InitWine -> open_builtin_exe_file -> wine_dll_load_main_exe
-- wine_dll_load_main_exe -> dlopen_dll
So this one loads the .so, and this triggers the static initializers to
run, thus calling the statically constructed classes, right? And here
the problem happens. Why? Because the kernel & friends have not yet been
loaded?
--
Dimi.