Status of LoadLibrary and .so

[Joe Dluzen]

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

[Paul Chitescu]

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

[Nicholas LaRoche]

Paul Chitescu wrote:
> 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

Perhaps the step of creating a wrapper dll.so file could be automated by 
a script that checks the exports (or headers/signatures) of the target 
.so file and generates a Win32 C stub for each export. This might reduce 
the development overhead needed to support a native .so library despite 
not being able to load it directly. Instrumenting the target .so library 
within the dll.so file would be required (as the parent points out).

-Nick