Building DLLs and other Qs

[Jeroen Janssen]

Hello Peter,

As far as I understand .so are linux native shared libraries.

That means you can access linux native APIs from within the shared 
library. This is how wine works, it implements the windows API in .so 
files by using other (non wine) native shared libraries (example is the 
Xfree86 libraries to display certain windows stuff).

A .dll is a Windows (native) DLL, you need a specific loader (in wine) 
to load this dll into memory.

I'm not sure, but I don't think you can access native linux shared 
libraries from with a native windows dll.

Peter Riocreux wrote:
> Before I get onto my questions I would just like to say:
> 
> This mail is not intended to start a flame war
> ----------------------------------------------
> 
> It is intended in a spirit of understanding what is the current
> status.
> 
> First the quick question - I want to install a built-from-CVS wine on
> multiple Fedora Core 1 machines. I can't find a spec file anywhere to
> make an RPM with - should I just pinch one from a FC1 Wine package, or
> is anyone maintaining a set of package-build scripts (RPM, dpkg,
> etc.)?
> 
> Now the more complicated and possibly flame-inducing question. While
> looking round the source tree for a spec file I noticed that all the
> WINE DLLs seem to end up as .dll.so files. I assume this is because
> the native platform's gcc can't build a real DLL, so it is wrapped up
> as a .so and wine (the binary) loads them as such and them does a
> connect-the-dots exercise to make it look to the application as if it
> loaded a real DLL. 
> 
> My understanding is that a cross-compiled gcc would build real DLLs,
> and as wine is able to load them when given them, would there be any
> advantage to building them with a cross-compiling toolchain if one
> were available. I am thinking here of perhaps some kind of loading
> speed improvement (unlikely to be significant if any) or maybe some
> perverse custom installer that looks for specifically named files in
> specific places on the filesystem it sees.
> 
> If there is no advantage, could the converse be true - that there
> would be some benefit to wrapping native DLLs in a .so shell for speed
> improvement - perhaps analysing the DLL on load is very hard work and
> if this were done once and the result saved as a .so .....