On 9/9/21 10:42 AM, Michael Matz wrote:
On Thu, 9 Sep 2021, Zebediah Figura wrote:
You also have an ELF loader that you don't even need to
maintain yourself (in ld.so), why would you want to use the target
object loader (PE) for the host binaries (the wine code) when you can
load host files perfectly fine already?
Right, I omitted the explanation for the sake of simplicity (not that it
helped very much, my mail still ended up very long). Let me try to
explain in detail; please feel free to ask for further clarification if
The basic reason is that Wine is essentially trying to split itself into
"PE" and "Unix" parts. The idea is that all of the "user"
code is built
in PE format, and only calls into unix code by making a sort of fake
"syscall". The "kernel" code is built in ELF format (or whatever
host system loads).
Okay, define "user" code then. From your initial list of libs:
> * libvkd3d
> * libFAudio
> * libgnutls
> * zlib (currently included via manual source import)
> * libmpg123
> * libgsm
> * libpng
> * libjpeg-turbo
> * libtiff
> * libfreetype
> * liblcms2
> * jxrlib
Why is, for instance, libpng or libfreetype such user code? No Windows
program will make use of facilities of these libraries (and if they do,
they have an explicit dependency on a self-provided freetype.dll). So it
seems your definition of user code extends to something beyond just the
emulated windows program.
I could imagine one thing: you have (of course) code that is part of some
existing PE libs which really are intentionally loaded visibly into the
target process (like any of the well known MS DLLs), but the implemention
of functions in them actually makes use of facilities of the above
libraries (like decoding PNGs). Is that it?
Basically, yeah. For example, libpng is used in Wine by
windowscodecs.dll (which has support for decoding and encoding a bunch
of different image formats) and by user32.dll (which contains most of
the core windowing code, including the ability to decode and paint PNG
window icons.) Both of those are of course 100% user-mode on Windows. It
makes things easier for us if they are on Wine as well.
If so, your argument about the unix<->PE border
makes sense, and I see how
one would like to build the above helper libs such that they can be
included from your existing PE libs. (Either by statically including the
code within the PE libs, or by making the above libs be themself PE DLLs)
But I don't see how much a distro can help here. Especially the
requirement about providing libfoo as PE DLL, but not named libfoo, but
rather libfoo-for-wine-internals, to not overtly pollute the targets
namespace, makes the whole thing fairly specific and un-distro-like.
An extension to the PE loader of wine to support an internal namespace
would help with that: a distro could provide a libfoo PE DLL package
without strange renaming. (And such internal namespace would also help
with some of the raison d'être for the whole stunt: not exposing the libs
metadata to the process would make anti-cheaters not tripp over non
matching memory/disk). Such PE DLL package could then theoretically be
used in other packages that want to build PE executables that directly
make use of e.g. libpng.dll .
But it's still a stretch: you understandably want to use libraries that
exist on the system for 3rdparty stuff you depend on. But the very act of
building it as PE files already makes it non-system-provided. Nothing on
the system except wine would use these files, so the usual arguments of
why system libs are better (heavy testing, quicker updates for bugs)
become weak quickly. If the source code between libfoo.rpm/deb and
libfoo-dll.rpm/deb would be shared (i.e. they fall out of the same package
source container) then at least you would benefit from quick bug fixes,
but I think it's questionable if packagers are happy to have to provide
for a cross compiled libpng package when they actually need to care for
the system libs.
Hmm, rock and hard place? :-)
I don't have a good suggestion. What would be your preference or idea?
Yeah, it's awkward :-(
There's been a lot of internal discussion about this, and there's a lot
of people who are ready to assume that distributions just don't want to
deal with our nonsense, and that we should build everything using
submodules (and probably link it all statically). Actually, this
assumption has been made even without considering the whole
renaming-dynamic-libraries problem (after all, what possible users could
there even be for MinGW libraries in the first place?)
Part of my goal with these mails is to clarify what it is distributions
*actually* want. Some seem quite willing to deal with adding MinGW
packages for us, although none so far has been happy about the concept
of using Wine-specific build script hacks for dynamic libraries.
Even in the absence of any other reason to separate dependencies, there
is still the concept of updating things independently (updating gnutls
on the same schedule, etc.) Granted, I expect most distributions these
days have facilities for tracking static library dependencies and
updating them to match, though obviously that's not ideal either.
Of course, the other bit is, *maybe* it's possible to use unmodified
dynamic libraries. There's been ideas proposed and we're still trying to
work out the kinks and figure out if it's actually plausible. In a sense
I kind of want to ask "assuming we can, what do you want, and assuming
we can't, what do you want".
As for what Wine wants, well... there's disagreement within the project;
some of us would like to see dynamic libraries and out-of-tree
development (because it makes development easier), and some would like
to see static libraries plus submodules or source imports (because it's
easier to write). The Wine maintainer favors the latter.
(Well, I do have a crazy idea: automatically wrap an ELF file into an PE
file and generate the glue automatically during wine build or even on the
fly during load. You then would "properly" load the PE file into the
target process, and that it happens to contain a large blob of bytes that
happens to look like an ELF file is just a random little fun fact. The
ABI switching glue isn't too terrible. But of course that still leaves
the 32bit vs. 64bit problem: the system ELF libs will most often be 64bit,
but you could depend on and wrap the -32bit variants as well if they
This would I think get ugly really quickly, not to mention fragile :-/