Using winemaker / building wine DLLs

annabunches · Post by **annabunches** » Tue Jun 21, 2011 1:16 pm

Hi.

I'm not sure if this is the correct place for this question, or if the
wine-devel list is more appropriate; please let me know if I should ask
over there.

I'm trying to build, using winemaker/winegcc/etc, a DLL for use with a
Windows binary. This is a somewhat unusual case, in that this library is
actually explicitly being written for a Windows binary that will run in
Linux (I'm basically trying to wrap a Linux system call so that I can
call it from a Windows program).

So, I followed the guide at
http://www.winehq.org/docs/winelib-guide/bindlls, and winemaker gave me
a makefile. I ran winemaker with:

winemaker --nosource-fix --dll --single-target MyLib --nomfc

Running make produced errors related to 32/64-bit incompatibility, which
persisted until I:

1. added -m32 to CEXTRA and
2. added an explicit target for .o files (since the implicit target
doesn't use CEXTRA)

This made the compile fail with errors about missing WinMain, which
makes sense because -shared isn't being specified for compiling the .so.
So, I hacked the makefile again and added -m32, -shared, and -fpic to
MyLib_LDFLAGS.

This finally succeeded, but it only gave me a MyLib.dll.so file; my
understanding is that there should also be a MyLib.so file that I link
against when compiling my Windows binary.

I suspect I'm missing some fundamental assumption about Windows binaries
- that, or the way winemaker is supposed to be used has changed
drastically since that guide was written.

Can anyone give me any pointers here?

Thanks,
- Anna

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-us ... chment.pgp>

Thunderbird · Post by **Thunderbird** » Tue Jun 21, 2011 2:26 pm

Your win32 application will see the winelib dll as any other 'win32 dll'. If you have a win32 version of this dll, link against that one and then you can use the winelib version as drop-in replacement. Another way is to dynamically load the library using 'LoadLibrary' and 'GetProcAddress' then you don't have to link.

I'm not sure if your winelib dll got compiled correctly though since I haven't used winemaker in about a decade. I tend to useplain winegcc/wineg++.

annabunches · Post by **annabunches** » Tue Jun 21, 2011 2:34 pm

On 06/21/2011 03:26 PM, Thunderbird wrote:

Your win32 application will see the winelib dll as any other 'win32 dll'. If you have a win32 version of this dll, link against that one and then you can use the winelib version as drop-in replacement. Another way is to dynamically load the library using 'LoadLibrary' and 'GetProcAddress' then you don't have to link.

I'm not sure if your winelib dll got compiled correctly though since I haven't used winemaker in about a decade. I tend to useplain winegcc/wineg++.

Thanks for the insight - I noticed here:

http://wiki.jswindle.com/index.php/Wine ... _Linux_API

that I should be able to do what I want (which is, basically, call the
Unix system() function from a Windows executable) without jumping
through the hoops of creating a DLL at all.

My only problem is that using winegcc gives me very unexpected output.
winegcc claims that it "tries to provide a MinGW compatible compiler
under Linux." However, when I compile my program with MinGW, I get a
Windows executable. When I compile my program with winegcc, I get a
shell script and a Linux shared object.

Clearly, I am doing something wrong here.

I was hoping, based on this comment from the above link:

"That must be because you're calling the Unix system() function. If you
want system() to work in Wine applications you must link with msvcrt and
call its implementation of system()"

that it would be possible to link against the glibc system() call using
winegcc (with mingw32, it appears to always link against msvcrt from the
mingw32 tree, and wine then interprets that call, and does a fork/exec
instead of an actual system() call).

So, it has been suggested that what I want to do is possible, and I
think it comes down to figuring out how to use winegcc. Documentation
seems to be outdated for winegcc, because the behavior I'm seeing isn't
mentioned anywhere I've yet found.

Thanks,
- Anna

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-us ... chment.pgp>

annabunches · Post by **annabunches** » Tue Jun 21, 2011 3:18 pm

On 06/21/2011 03:33 PM, Anna Wiggins wrote:

My only problem is that using winegcc gives me very unexpected output.
winegcc claims that it "tries to provide a MinGW compatible compiler
under Linux." However, when I compile my program with MinGW, I get a
Windows executable. When I compile my program with winegcc, I get a
shell script and a Linux shared object.

Okay, problem solved - even though 'file' reports that object is a Linux
shared object, it appears to be executable in wine! Well played, wine
developers.

- Anna

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-us ... chment.pgp>

Thunderbird · Post by **Thunderbird** » Tue Jun 21, 2011 6:17 pm

Every program compiled through winelib becomes appears as a library. Any winelib application obviously depends on Wine and even has to be loaded through Wine (Wine has to do a lot of voodoo including emulating windows memory management, file system, registry......). It is how things are supposed to work. A dll will be called '.dll.so'.