Calling PE DLLs

[Daniel Stodden]

hi all.

sorry in case this email will get delivered twice to the list.
i subscribed yesterday an promptly used the wrong mail address
to post. so here i post again.

i'm stuck at the process of loading PE dlls.

like some others before me, i've got a native w32 dll which i
would like to hook into on a linux box. no source code available.
the case is almost identical to

http://www.winehq.com/hypermail/wine-devel/2003/12/index.html#231

though, there's not much application code yet, except a small test
program written by myself, currently only meant to call a single
function on the dll.

so, using winemaker does not seem to spit out anything usable, 
and there seems to be no official documentation on how to use 
winebuild here.

the program is called test.c, calling symbols from a vendor-supplied
header file.
created test.o through winegcc:

winegcc -Wall -O2  -I.  -c -o test.o test.c

let's call the library vendor.dll again.
i've played with winedump, finally got a vendor.dll.spec.

i'm calling winebuild to get a .def as follows:

winebuild --def -E vendor.dll.spec -o libvendor.def

then, one of my better guesses on how to proceed seemed to be:

winebuild --dll -fPIC -E vendor.dll.spec -L. -lvendor test.o -o
libvendor.dll.s

the assembler code looks reasonable. though, linking fails with
duplicate symbols:

winegcc   test.o libvendor.dll.o  -o test
[..]
: multiple definition of `__wine_spec_nt_header'

: multiple definition of `__wine_spec_file_name'

i'm aware that i could probably avoid all of this by just using
LoadLibrary() and resolving the symbols at runtime. otoh, the approach
above is potentially simpler, if i just knew how. :)

could someone please enlighten me? what am i doing wrong?

thanks,
daniel

[Mike McCormack]

Daniel Stodden wrote:
> though, there's not much application code yet, except a small test
> program written by myself, currently only meant to call a single
> function on the dll.
>
> so, using winemaker does not seem to spit out anything usable, 
> and there seems to be no official documentation on how to use 
> winebuild here.

Why not just use LoadLibrary("vendor.dll") and GetProcAddress() in you 
winelib application instead of mucking round with winegcc and winebuild 
in order to directly link your dll?

Mike

[Daniel Stodden]

On Wed, 2005-11-02 at 18:28 +0900, Mike McCormack wrote:
> Daniel Stodden wrote:
> > though, there's not much application code yet, except a small test
> > program written by myself, currently only meant to call a single
> > function on the dll.
> >
> > so, using winemaker does not seem to spit out anything usable, 
> > and there seems to be no official documentation on how to use 
> > winebuild here.
>
> Why not just use LoadLibrary("vendor.dll") and GetProcAddress() in you 
> winelib application instead of mucking round with winegcc and winebuild 
> in order to directly link your dll?

you're right. as i said, that's an obvious option.

but since linking directly would work on windows and since
the .def-mechanism with wine tools is supposed to support just that, and
since, for the purpose in question, i really don't see the point in
programming the dynamic loader manually, why not give it a try as well?

but basically you're right.

regards,
daniel

[Alexandre Julliard]

Daniel Stodden  writes:
> then, one of my better guesses on how to proceed seemed to be:
>
> winebuild --dll -fPIC -E vendor.dll.spec -L. -lvendor test.o -o
> libvendor.dll.s
>
> the assembler code looks reasonable. though, linking fails with
> duplicate symbols:
>
> winegcc   test.o libvendor.dll.o  -o test

You shouldn't need any of that. Once you have libvendor.def you should
be able to simply do:

winegcc -o test test.o -lvendor

[Daniel Stodden]

On Wed, 2005-11-02 at 10:54 +0100, Alexandre Julliard wrote:
> Daniel Stodden  writes:
> > then, one of my better guesses on how to proceed seemed to be:
> >
> > winebuild --dll -fPIC -E vendor.dll.spec -L. -lvendor test.o -o
> > libvendor.dll.s
> >
> > the assembler code looks reasonable. though, linking fails with
> > duplicate symbols:
> >
> > winegcc   test.o libvendor.dll.o  -o test
>
> You shouldn't need any of that. Once you have libvendor.def you should
> be able to simply do:
>
> winegcc -o test test.o -lvendor

okay. thanks to your advice, i've got both the compile-time linking as
well runtime loading running now.

works well.

thanks for all the responses.

regards,
daniel