Wine and mingw-w64 cooperation

Jacek Caban jacek at codeweavers.com
Mon Jun 3 09:43:21 CDT 2019


On 22/05/2019 21:45, Jacek Caban wrote:

>
> - Source code sharing
>
> Technically, we could share much more code than we currently do. 
> Duplicating efforts is quite suboptimal for everyone. Right now 
> mingw-w64 imports a number of platform headers and widl tool from Wine 
> via wine-import.sh script. Wine has a few headers imported from 
> mingw-w64 as well. It works to some extend, but the fact is that we 
> still duplicate more than we share. I'm not yet sure how to fix that 
> entirely, but I'd like us to have a workflow that would limit the 
> duplication.


Let me split it by the region of code:


- Platform headers


We share quite a lot of those already by having changes go to Wine tree 
and being imported by a script. It's not pretty, but does the job. From 
the experience, there are minor things that often prevent using this for 
more headers. One of the most common is that Wine doesn't support 
version and family partitions guards in its headers. While they are 
useless for Wine, they are more important for mingw-w64 (especially 
family partitions). I guess that changing Wine policy should be easy and 
would help to share more.



- importlibs


Those are very different for both projects, keeping it separated makes 
probably more sense.



- CRT headers + msvcrt importlibs


In this case, following Alexandre's cross compilation work, it seems 
like the current solution of having headers adjusted for Wine works well 
and may be even better than trying to sync it. Still, a bit of 
coordination would be nice. What I'm esp. afraid of is how msvcrt 
importlib works. On mingw-w64, it needs some additions to support 
building with different CRTs, most notably UCRT. Those additions were 
already causing problems to Wine. It's fixed now, but it would be nice 
to make sure that we don't break again if we ever need more such 
additions (which is likely as UCRT support matures).


Current Wine solution of using a mix of its own importlib and default 
libmsvcrt.a should work fine in most cases. The case when it won't is 
when default mingw-w64 crt is not msvcrt-os. This is broader problem 
than just for Wine, it just happens to be more critical for Wine. With 
clang there is a solution of explicitly linking CRT DLL. We could 
probably try to upstream something similar to GCC.


Jacek




More information about the wine-devel mailing list