Rebase on Wine-9.6+ (Lots breakage / rework to do)

[jrdnjhnstn]

• There are a lot of breaking changes for Wine-8.20+, due to the DECSPECL changes
• There are also a lot of other changes, causing a dozen or so patches to fail to apply

This is all manageable to fix and sort out, and the vast majority is somewhat trivial to fix -- However, it is time-consuming.

Given the scope ~ I'm going to hold off for now

[jrdnjhnstn]

I'll wait until Valve Proton is based on Wine-9.0 so that i can pick up certain rebased patches and avoid doing extra work.

no rush, my current build works fine for my needs

[jrdnjhnstn]

it looks like the the ntsync kernel driver will land in linux-6.10.

ref: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/log/?s=anzwix&h=char-misc-next

So I think I will plan on rebasing Wine-NSPA around then, with the included support in Wine-NSPA to use this, if desired (and will still support Fsync/Futexes)...

I've been a bit lazy and reluctant to rebase Wine-NSPA: as I've seen/heard about numerous people having problems with some VSTs on Wine-9.0+ ~ and tbh, I haven't had any real issues with my current 8.x builds, beyond stuff that isn't unexpected...

anyway, ntsync being merged into the linux kernel is a good point to rebase Wine-NSPA and add that support.

[jrdnjhnstn]

Update:

So all things considered: I'm not going to rebase Wine-NSPA on Wine-9.x (likely at all). More likely, I will wait for Wine-10.x. There are a few reasons for this:

1. WineWayland Support: It simply is NOT ready in Wine-9.x (and won't be). In particular, because while I do use Wayland (via Hyprland), until the subsurfaces work lands for menus: WineWayland is DOA for me (aside from lots of other issues it currently has... Additionally, most wine-realted wrappers are X11 explicit. So for now XWayland really is my best option.

2. I have backported a ton of stuff since May 2024. There are very few interesting bits from Wine-9.x+ to actually grab up, meaning a significant rebase on it -- is pretty much a waste of time for me.

3. I have some Wine-NSPA-specific patchwork that is going to be time-consuming && painful to rebase, when I do. Which makes 2. even less attractive, given the benefits would be absolutely minimal.

This isn't bad news or anything: I don't chase Wine releases anyway, given how often things break during development (and Wine-9.x has been no exception: there has been lots of breakage, issues with yabridge / winelib apps being broken at various points, Ableton Live was broken recently (Wine-9.12), and so on. Meaning, there are ample reasons for me to pick a base, and pull in stuff I want as I go: without worrying about upstream too much.

List of commits (2024):

Wine-NSPA: dwmapi: Sleep in DwmFlush() & gcc fixup
Wine-NSPA: Updates, Debugging && Fixes
Wine-NSPA: Shell32 Updates && PRIOCLASS_ env patch
Wine-NSPA: Support for large page backed file mapping objects
Wine-NSPA: Proton CPU Overrides && Backports
Wine-NSPA: Backports && Updates
Wine-NSPA: ntdll: Dynamic Spin with Adaptive Yield
Wine-NSPA: Various Updates
Wine-NSPA: Misc Updates && Fixes
Wine-NSPA: GCC-14.x Build FIx && Patchwork Updates
Wine-NSPA: Updates. Fixes. Keyed Events Futexes
Updates && Fixups!
Update MSVC (Wine-9.8) && Upstream Fixes
Wine-NSPA: Updates && Maintenance
Wine-NSPA: Updates && Cleanups!
librpti-stuff: librtpi-PI_Support-Core (trim down)
librtpi-stuff: WIP! Backup!
Wine-NSPA: Remove 7x-branch (Archived)

• A chunk of it are upstream backports && Fixes.
• Some of it comes from Proton or CX
• Some are MRs that I've reworked to take advantage of
• A number of performance enhancements

In reality, without rebasing at all. Wine-NSPA is somewhere between Wine-8.19 - 9.12 already. But also includes a ton of uniquely Wine-NSPA stuff, not found elsewhere (inlcuding in Proton, TKG and co).