You're absolutely right, this is the simplest way to go. Though the DLL
contains more than 2500 functions (I had to raise the max constant in
winebuild!) I'm only actually using/missing around 20 of them in my link. I'll
do GetProcAddress for those 20 and see if my nefarious plan is going to work at
all... If it does, then I'll write a script to generate wrappers and publish the
full API in a .so. Thanks for the help!
The one think I wonder is this: Does this mean that there is not currently a way
to import the DLL symbols at link time? If that's the case, then it seems the
process I'm about to go through to generate wrapper code in a .so should become
more encapsulated; maybe made into a tool in the source tree? Let me know, and
I'll keep this in mind as I do it. If I understand correctly, the
automatically-generated .so or .a would be an exact analog to the .lib import
library under windows...
Bret
Quoting [EMAIL PROTECTED]:
> The dead flat simplest way to do this is to simply have the wrappers
> inline in the winelib app. If the dll foo exports bar, the app can just
> do
>
> h = LoadLibrary("foo");
> p = GetProcAddress(h, "bar");
> res = p(...)
> FreeLibrary(h);
>
> Of course, LoadLibrary and FreeLibrary could be just at the start and
> end of the app, and it's just the GetProcAddress that's extra. I'm told
> you can do that in windows if you want to call a function you didn't
> bother to import, so it should always work with winelib, too, no matter
> what other fancy import/export scheme we might develop later.
>
> If you want to segregate the wrappers in a .so, you can do that, but
> then the .so has to define the names the app will call, and contain code
> to load the library (foo.dll) and get and call the address for each one,
> and you need to know how to work the dynamic linker (it's not hard, but
> one more thing).
