On Thursday 10 September 2009 22:10:37 Joe Dluzen wrote:
Hi all,
back a few years ago it didn't: http://www.winehq.org/pipermail/wine-devel/2003-July/018498.html
Does anyone know of the status of LoadLibrary and a .so? Can it load directly or is there a workaround that does not involve multiple processes and some sort of IPC?
thanks, Joe
Hi!
If the problem is to use LoadLibrary() on a native (not windows native but posix or whatever) .so you can always write a wrapper .dll.so that links to the .so and internally calls its functions. The glue code acts as a compatibility layer for the differences and also insulates the native code from the win32 compatible code expectations.
Directly loading a .so just like it were a .dll.so or a .dll doesn't make much sense because: - There are differences in the argument types, calling conventions, register usage, thread local storage, exception frames. - Any file name, handle or similar resource would need conversion. - There are support functions that use mutually incompatible structures (like native free() called on a MSVCRT malloc()ed memory block). - The expected internal structure of a module cannot be loaded - this may not be a big issue but needs work in the loader code to provide a stub.
The other way around, loading a DLL from a non-winelib process is generically not feasable and in all but the most trivial (and tightly controlled) cases needs different processes and IPC. Most Windows DLLs expect a fully functional environment to be already set up including exceptions, synchronization objects, local heaps, security, handles, consoles, user interface, COM. That's what winelib does - it provides this environment.
Paul