[RFC PATCH 0/5] XAudio PE conversion.

[Rémi Bernon]

On 9/1/21 5:32 PM, Rémi Bernon wrote:
> On 9/1/21 5:13 PM, Stefan Dösinger wrote:
>>
>>
>>> Am 31.08.2021 um 17:47 schrieb Alexandre Julliard <julliard at winehq.org>:
>>>
>>> More important ones would be GnuTLS and libxml2. It may be interesting
>>> to see how well GnuTLS works with your scheme.
>>
>> How will certificates work in a PE GnuTLS? My understanding is that 
>> currently Windows apps running in Wine will automagically pick up 
>> whatever root certificates the distro ships, which seems like a useful 
>> feature to me, in particular in corporate environments that might add 
>> their own internal certs.
>>
> 
> FWIW I had a very quick look yesterday and it seems like there's also a 
> lot of assembly code. I'm not sure that it'd work out easily anyway.


So libxml2/libxslt weren't too bad, there's a bit of plumbing to do 
though, with some xsltconfig.h and xmlversion.h headers expected to be 
found by users of the libraries, so they have to be added either in 
every module, or somewhere in wine private headers.

They also cause a few warnings but that could probably be hidden, and I 
could then convert msxml3 to PE without much trouble.

I updated by wip/wine-ext branch with these changes, and I also fixed a 
few things that were previously broken.

In addition, I modified the way the sources are looked for, to remove 
the umbrella project in favor of individual configure flags (or using 
the existing --with-(png|xml|...) when they existed) to indicate where 
the sources are located.

I think this would be best for flexibility, if Linux distribution desire 
to provide alternate sources for instance. I haven't added any default 
value but in the case we consider adding the sources in the tree that's 
probably how we could do it.


Then, on the other hand, gnutls seems more complicated. It's mostly 
about the nettle library actually, as gnutls is just a facade over it.

As I described, it has all bunch of assembly files for the optimized 
versions of the algorithms, and worst, these asm files seems to actually 
be full of m4 macros. Anyway, they also have generic C versions of the 
algorithms, so we could just use them instead.

However it's not all, as they also have a few generated tables, which 
seem to be target architecture dependent. AFAICS the generators are 
simple C files which we could probably compile too, and generate the 
tables at build time, but that will probably require a bit more 
makedep.c changes (unless I missed an easy way to do it).

There's also of course the consideration about how the certificates are 
going to be found, as described by Stephan.

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