Hi Stefan.But I can see what functions are being called in the object code (thanks nm). Three of which come from wine:
LoadLibraryA
GetProcAddress
FreeLibrary
What you just saw is the bare minimum you need in order to load a library. I'm afraid, however, that it is far from all you need.
First, when you load another library, that library may need any DLL at all. In order to assess how much of Wine you need, you need to also look at the DLLs loaded. Also, please bear in mind that GetProcAddress can load other functions, and those functions called.
Are these all I need?Almost defenitely not.
Yes. That can, potentially, grow to be the entire rest of Windows. Most likely, however, by looking at the DLLs loaded, you can narrow that down, somewhat.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?
What happens if I pass a pointer to a method contained in a windowsSometimes.
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?
The theory goes thus:
An ELF binary can only call other ELF binaries.
A PE (Windows) binary can only call other PE binaries.
Wine invented something called "winelib executable". This is an ELF library that can also link to PE DLLs. It appears that your best bet, if you don't want to embark on massive copy/paste activity, is to create your util as a winelib. There are some disadvantges to that as well (a dependancy on Wine, for one). I'll let someone who's actually worked with winelib answer those parts, however.
ThanksShachar
stefan
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
