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?