On 9/8/21 6:35 PM, Aaron Puchert wrote:
> Am 07.09.21 um 01:36 schrieb Zebediah Figura:
>> For a long time Wine has built all of its Win32 libraries (DLLs and
>> EXEs) as ELF binaries.
> Wait, so I have two directories with libraries:
> * /usr/lib64/wine/x86_64-unix/ containing according to "file": "ELF
> 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked".
> * /usr/lib64/wine/x86_64-windows/ containing according to "file": "PE32+
> executable (DLL) (console) x86-64, for MS Windows" plus some non-libraries.
> 
> So I assume we're only talking about the <arch>-unix directory, right?

Sort of. I'm mainly trying to give historical context in explaining why 
there are even PE-format DLLs, but I didn't explain well enough. Let me 
try to clarify.

It used to be that all libraries were built in ELF format, and sort of 
converted to PE format in memory on the fly. They have an export table 
identical to their Windows counterpart, and are named with a ".dll.so" 
suffix.

For reasons described in [1] from this thread, we started converting 
these DLLs into actual PE format, by compiling them with the MinGW 
cross-compiler, and loading them into memory the same way we load PE 
DLLs. Cross-compiled DLLs have the sufix ".dll".

Most such DLLs could use Wine's CRT libraries (msvcrt.dll) and didn't 
need to call into Unix code. Some did need to call into Unix code (most 
of the core parts of the Windows kernel, but also stuff like GStreamer 
or 3D acceleration libraries). We can't just call Unix code from a DLL 
(for reasons I'll try to explain below) so these got split into two 
pieces, one ending in ".dll" and one ending in ".so". In this case the 
DLL loads the .so through some internal APIs and does what are 
essentially fake syscalls to it.

Currently most, but not all, libraries have been converted or split in 
this way. The x86_64-unix directory holds both the libraries that 
haven't been split, and the .so parts of the libraries that have. I.e. 
it holds both .dll.so and .so files. The x86_64-windows directory holds 
the PE parts of the libraries that have been converted or split, i.e. it 
holds the .dll files.

The PE system dependency question is what stands in the way of 
converting most of the libraries that haven't been split yet.

[1] 
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/2M5KSB3W22X6T5VLGHPEOWJC2X7SF3KW/

> 
>> The list of dependencies that we intend to build using MinGW is no > quite fixed yet, but we expect it to include and be mostly limited>
> to the following:
>>
>> * libvkd3d
>> * libFAudio
>> * libgnutls
>> * zlib (currently included via manual source import)
>> * libmpg123
>> * libgsm
>> * libpng
>> * libjpeg-turbo
>> * libtiff
>> * libfreetype
>> * liblcms2
>> * jxrlib
> What puts a dependency on this list? Wine will typically also use the
> graphics stack, typically provided by Mesa. Why is that not included?
> 
> Here is my very limited understanding of Wine: the <arch>-windows
> directory provides DLLs that a Windows application might need. These are
> regular PE libraries so that Windows applications don't get confused.
> Internally some of these libraries load libraries from <arch>-unix, but
> these aren't exposed to the Windows application. So they can be ELF
> executables, which in turn enables them to link system libraries,
> including those from the above list. That seems like a pretty clean
> design, although I don't know which problems it might produce.
> 
> Now let's say we have something like libfreetype as PE, hence also most,
> if not all libraries in <arch>-unix. Then we could use a unified loader,
> but applications might see all these implementation details.
> Additionally, you'll likely still need to load ELF libraries at some
> point, because I don't think you'll want to build your own Mesa, LLVM,
> and all that comes with it.

Yes, we still need to load actual ELF code. The determining questions 
are something like:

(1) Is it easy to compile in PE format?

(2) Does it need to interact with the host system, say, in terms of 
configuration files?

(3) Does it need to call down into the OS at some level, in ways that 
Windows can't replicate?

So anything that interacts with devices is right out (Mesa, audio 
libraries,