All modules that call a Unix library contain WoW64 thunks to enable calling the 64-bit Unix library from 32-bit PE code. This means that it is possible to
run 32-bit Windows applications on a purely 64-bit Unix installation. This is called the new WoW64 mode, as opposed to the old WoW64 mode where 32-bit applications run inside a 32-bit Unix process.
Old Proton builds probably won’t backport this (unless it’s completely isolated, idk the code layout of Wine). But are old Proton builds still necessary? Occasionally there’s regressions, but are there really any games that require like a 2 year old Proton build?
There are, but it’s complicated. Doom (2016) for instance - it doesn’t handle the very large Vulkan swap chain that’s possible on some modern graphics cards, crashes on start-up. Someone patched Proton around that time so that Doom would start; the patch was later reverted since it broke other games. Other games based off of that engine - couple of Wolfensteins, Doom Eternal - have the problem fixed in the binaries, and so run on up-to-date Proton, but depending on your hardware, only a few specific, old, versions of Proton, will do for Doom.
Regressions get fixed - that’s okay. Buggy behaviour which depended on regressions that got fixed - that’s a problem.
Does this change run the 32-bit .exe using x86_64 instructions? From the description it just sounds like it allows 64-bit Linux libraries to be used in place of 32-bit ones, but that the Windows layer still operates in native 32-bit mode. This means there is still a need to emulate 32-bit x86 instructions which I don’t think box64 can do at this time (x86_32 translates to arm32 with box86, x86_64 translates to arm64 with box64). If box86 could translate x86_32 to arm64 then this might work as Wine would handle the conversion between 32 and 64 bit addressing and argument passing into the libraries but I’m not familiar with the inner workings there.
There is an experimental Wayland graphics driver. It’s still a work in progress, but already implements many features, such as basic window management, multiple monitors, high-DPI scaling, relative motion events, and Vulkan support.
The completion of the PE/Unix separation means that it’s possible to run existing Windows binaries on ARM64.
WinRT theming supports a dark theme option, with a corresponding toggle in WineCfg.
The default Windows version for new prefixes is set to Windows 10.
All graphical builtin applications report errors with a message box instead of printing messages on the console.
🦀🦀🦀
So in the future no need to install 32 bit packages of wine in a 64 system??? 👀
Correcto. Which means Steam will probably drop 32 bit libs soon. Which means Ubuntu will stop shipping 32 libs. The era is truly coming to an end
Let’s call it “soonish”. The old proton versions still need 32 bit libs if they do not backport the feature.
Old Proton builds probably won’t backport this (unless it’s completely isolated, idk the code layout of Wine). But are old Proton builds still necessary? Occasionally there’s regressions, but are there really any games that require like a 2 year old Proton build?
There are, but it’s complicated. Doom (2016) for instance - it doesn’t handle the very large Vulkan swap chain that’s possible on some modern graphics cards, crashes on start-up. Someone patched Proton around that time so that Doom would start; the patch was later reverted since it broke other games. Other games based off of that engine - couple of Wolfensteins, Doom Eternal - have the problem fixed in the binaries, and so run on up-to-date Proton, but depending on your hardware, only a few specific, old, versions of Proton, will do for Doom.
Regressions get fixed - that’s okay. Buggy behaviour which depended on regressions that got fixed - that’s a problem.
quite a few games need old proton IME
not many, but enough to make a difference.
Come on Steam, show those 32-bit libs the door!
Not the political kind. The shared object kind.
Ok but now I am curious what the difference between 32 and 64 bit liberals would beSince they have longer words, 64-bit liberals would be more intellectual than 32-bit liberals. 32-bit liberals also have a term limit in 14 years.
What does this have to do with rust?
X86 to arm will become easier with this as box64 could handle everything now
Does this change run the 32-bit .exe using x86_64 instructions? From the description it just sounds like it allows 64-bit Linux libraries to be used in place of 32-bit ones, but that the Windows layer still operates in native 32-bit mode. This means there is still a need to emulate 32-bit x86 instructions which I don’t think box64 can do at this time (x86_32 translates to arm32 with box86, x86_64 translates to arm64 with box64). If box86 could translate x86_32 to arm64 then this might work as Wine would handle the conversion between 32 and 64 bit addressing and argument passing into the libraries but I’m not familiar with the inner workings there.
Thanks for correction, not everything, but more
More highlights: