Re: loading and running windows dlls in a linux program

[Rolf Kalbermatter]

Stefan Sperling <w9rk(a)gmx.net> wrote:
> Three of which come from wine:
>
> LoadLibraryA
>         GetProcAddress
>         FreeLibrary
>
> Are these all I need? In theory, this looks about enough to be able to load
> a shared object... but I will need a lot of other wine internals too,
> in case a dll does a system call (like malloc, which will definitely happen),
> won't I?

Well they probably come from Wine but as they are just the standard Win32
API functions they could be from anywhere. Also note that this closed
source approach wouldn't be possible with the current Wine license anymore.

Have you looked at the according functions? They need to almost completely understand the executable file format layout of Windows files which isn't exactly simple. And I believe the current Wine implementation also supports
loading ELF libraries as DLLs, something you won't really need. Taking this code and integrate it in your own environment will certainly be quite some
work and may actually end up to be a major project of its own!
> What happens if I pass a pointer to a method contained in a windows
> dll?? Will wine take care about low level stuff like keeping track
> of memory layouts of structs and convert them if they are incorrect?
> More precisely: If I reimplement data structures external to the dll but 
> used by it, will the difference in memory layout between the original 
> struct the dll expects and my new implementation under linux matter?

I think you should safely assume that it will indeed matter. The Windows
API is defined on a binary level too, including the calling convention of functions and things such as stucture member alignements. You better make
sure your compiler used assumes the same alignement rules or otherwise
make him do so by using the correct pragmas. This is usually done by using
the official headers of such components, which of course may not be GNU C compilable out of the box.

LoadLibrary and GetProcAddress have not enough information about the
calling convention and alignement constraints used both in the DLL
itself as in the caller to actually do the necessary translation for
you.

Rolf Kalbermatter