[RFC PATCH 0/5] XAudio PE conversion.

[Rémi Bernon]

On 6/23/21 5:22 PM, Zebediah Figura (she/her) wrote:
> On 6/23/21 7:37 AM, Rémi Bernon wrote:
>> I'm sending this as an RFC for now as there's been some discussion
>> already about how to handle PE dependencies. I think the approach I'm
>> taking here, by including FAudio headers directly in the source and
>> loading it dynamically is the easiest way, and the least disruptive for
>> building and running Wine, if not the cleanest. All the other solutions
>> have higher friction, either on third party packages, or on the system
>> distribution.
> 
> I don't think this is a very good idea, for several reasons:
> 
> * firstly, it's a huge amount of imported code;
> 

I honestly don't think it is.

> * secondly, the headers can easily change in the near future (and FAudio 
> has usually taken a loose approach to compatibility);
> 

 From what I could see it's usually okay, with new functions and 
structures added when they require a new ABI.

I don't see how this is so different from the current situation, as the 
current source shows it, we only check for the new function presence in 
the public headers.

The struct changes could be a problem, but only if we don't control the 
distribution of the PE FAudio. If we consider FAudio to be provided by 
Wine Mono for instance, it's merely a matter of making sure Wine Mono 
updates also update the headers here.

> * thirdly, at least some distributions actually explicitly don't like 
> this [1].
> 

This more precisely applies to sources, and sources which are already 
packaged as separate Debian packages. This is not the case here, and 
going that way is an entirely separate approach which IMHO has a good 
number of downsides.

> As I've said, I think it's past time we ask distributions what they 
> actually want, and work with them accordingly. My guess is it'll be some 
> variation of pkg-config.
> 

I don't think this is only a matter of discussion with the distros.

Having the dependencies provided by the system creates a much higher 
friction when building and running Wine from source.

Although I like the idea in theory, it's something I don't look forward 
to. Multi-arch is already so much of a mess than people started relying 
on container to build things in a sane environment.

So far Wine will be the first and probably only user ever of these new 
MinGW dependencies, and I don't think it's nice to delegate this to distros.

We can probably use (cross-)pkg-config for the build-time discovery 
(however bad it will be to integrate to configure, I tried but quickly 
bailed out), but then comes the problem to how to load the DLLs at runtime.

We usually compile-in the SO name, because dlopen has a set of builtin 
search paths, but that won't work with PE file, unless we add such paths 
to Wine loader.

I can also pretty easily see DRMs or anti-tamper mechanisms trigger if 
an unknown module is loaded from some non-standard location.

Overall this seems way more complicated, and IMHO too much for this 
particular case.


>> Upstream FAudio now has a pure Win32 backend, which makes it much easier
>> to build as PE. This was never a requirement, and this series should
>> work too with the SDL2 backend, as it tries to load Wine Mono SDL2 and
>> FAudio as a fallback after trying from the prefix system libraries.
>>
>> It could help the transition though, and is going to be required anyway
>> to support WMA decoding. Right now, with or without the Win32 backend,
>> this would also introduce a functional regression as although supported
>> by the new FAudio Win32 backend, it also depends on the WMA decoder MF
>> transform to be implemented, which isn't the case yet in Wine.
> 
> What if Wine is built without MinGW? Do we care about that case? If we 
> don't care about it for XAudio, what about other libraries?
> 

Is this still something we should worry about with the PE conversion? I 
don't see any sane path ahead if we add that problem on top, unless we 
just include FAudio source and be done with it.

To be completely honest I don't really understand the state of XAudio. 
Having just this thin shell just makes everything more complicated than 
it needs.

The DLLs are pretty useless without FAudio, so either we should delegate 
the build of fully functional XAudio DLLs to FAudio which it already 
(partially) supports, or we should be able to build fully functional 
XAudio DLLs directly in Wine tree.

This remarks only applies to some of the dependencies, not ones where 
they are only part of the functionality, or, like winex11.drv just not 
possibly integrated, but it also definitely applies to, say, vkd3d.

I don't completely understand [1] why it's separate and IMHO it makes 
integration and working on both Wine and vkd3d just horribly painful.

[1] Well I understand source ports, but I don't see why having it live 
in Wine would make source ports more complicated. I understand wined3d 
is already used that way, and it should be pretty much possible to do 
the same for vkd3d.

Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>