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 _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
