22 Jan
2018
22 Jan
'18
5:01 p.m.
Am 22.01.2018 um 14:25 schrieb Ged Murphy:
Is this really a sync up?
It takes implemented functions are returns them to stubs
I had asked the same question the other day: Given that many
Wine-Staging patches never made it into upstream, could we actually lose
features with the sync to WINE 3.0?
And the answer was "definitely"...
I think now it's time to establish a new strategy of dealing with WINE
DLLs. When ReactOS and WINE were still heavily implementing the
fundamentals, blindly syncing up DLLs to their WINE counterparts may
have been a solution. But nowadays, WINE development has considerably
slowed down. This led to the creation of Wine-Staging after all.
On the other hand, ReactOS has also evolved and needs to maintain
application compatibility over releases. We can hardly guarantee that
when blindly dumping foreign code into our repository.
So what could be a solution?
Even if Wine-Staging has not yet released a 3.x version, they publish a
nice set of patches:
https://github.com/wine-compholio/wine-staging/tree/master/patches
Applying them to our DLLs wherever possible should bring back the
missing features we just lost.
In the long term, we could leverage the power of Git and fork the WINE
repository on GitHub. We could then apply Wine-Staging patches and our
own changes to that repository. Syncing with upstream would now be
possible by merging commits instead of overwriting files. In the end,
DLLs from that repository could be blindly imported into the ReactOS
repo again. No more maintaining of "wininet_ros.diff" and the like :)
I hope we can have a solution before branching for 0.4.8. Otherwise,
I suspect that we will lose many features of 0.4.7 and the recent
history. For instance, DXTn support just got enabled in ReactOS, but it
has always been based on Wine-Staging code.
As James used to say: WINE Is Not Enough!
- Colin