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"
For reasons described in  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.
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
to the following:
* zlib (currently included via manual source import)
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
(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