Using a windows dll from a winelib or possibly native linux app.

[Kevin Cousins]

On Tue, 2003-12-09 at 23:58, Arthur Bergman wrote:
> If we develop the app on a windows box and move it over to the wine
> environment it works, but it would be preferable to have a more native
> approach. So I tried using winelib and have progressed to a point where
> I have an application that compiles using the vendor supplied header
> files under gcc, and a vendor.dll.spec file that describes the DLL.

Well done.  It took me a significant amount of effort just to get that
far in a similar project!



> However when I compile everything, the generated vendor.dll.so file
> does contain the correct symbols but they are undefined. Having played
> around using winemaker and winedump while trying to read up everything
> on winelib I am now stuck and not sure how to proceed forward.

I found a piece of WineLib documentation (sorry: I don't have an
appropriate cross-reference handy) that advocates that you write a shim
layer between your Linux code and your vendor's DLL.

Basically, regardless of how clever WineLib really is, you still can't
statically link an ELF object file against a PE COFF DLL.  That's the
reason you see undefined symbols---they really are undefined!  You can,
however, achieve what you want through another layer of indirection! :) 
Basically, you have to define simple statically-linked definitions for
those symbols which merely call through to the dynamically linked
versions contained in your vendor's DLL.  It works like this:

* the vendor's DLL exports some function

    ReturnType FunctionName(ParameterType)

* you've got to write your own module that wraps this:

    #include <windows.h>
    #include <vendor_dll.h>

    static ReturnType (*FunctionName_pointer) (ParameterType);

    void InitialiseVendorDLL() { /* BE SURE TO CALL THIS SOMEWHERE EARLY */
	HINSTANCE dll;
	dll = LoadLibrary("vendor.dll"); /* N.B. ADD YOUR OWN ERROR CHECKING */
	FunctionName_pointer = GetProcAddress(dll, "FunctionName");
    }
    
    ReturnType FunctionName(ParameterType p) {
	return FunctionName_pointer(p);
    }



Compile and link against /that/ (or similar specialised for your
particular situation), and you're undefined symbols will now have a
definition, and your code should work as advertised.  At the very least,
all this worked for me!



> Thanks

You're welcome.

Please let me know how you get along with this.



> Arthur

--
Kevin.