It seems to me that 16-bit applications are already basically broken with 32bit wine if you’re running a 64bit kernel, by default it places extra restrictions over what the hardware already does to prevent apps from loading 16 bit code entirely.
AFAIK, you couldn’t run 16-bit software on native Windows x64, so Wine is exhibiting the same behavior.
Anyway, these 16-bit softwares are old enough that running them in DOSBox or something like that won’t show any significant performance penalty through emulation vs translation.
I always thought it was purely a hardware limitation, but reading up on it I found it’s actually just “virtual 8086 mode” that was dropped, 16-bit protected mode is still available even when running the CPU in “long mode”.
So it rules out DOS apps, but 16bit Win 3.x apps should still run. But it’s probably a compatibility minefield, and even MS decided it wasn’t important (iirc the only thing they kept around was support for 16-bit app installers, but by internally swapping them out with 32-bit versions when run, since it was apparently common for 32-bit 9x apps to still use 16-bit installers so they could show a proper error message when run under Win 3.x)
Yeah most 16 bit stuff is old enough that there’s already a mature reimplementation of the game engine or old enough that it’ll run nicely in a translation layer or VM
From what I’ve seen if an online store provides a 16 bit classic without a reimplementation, it’s bundled with dosbox.
Of course, I’m pretty much blanking on any classic Win16 titles of note. As far as I recall the significant games just kept being DOS games with at most launch from icon. I suppose original Myst because QuickTime, but they released a Win32 build. But this 16 bit stuff was a speculation, this is about the 32 bit stuff that isn’t reasonably accommodated without a 32 bit runtime and certain bits being at odds with Flatpak isolation architecture.
Ok but is that because of fundamental limitations, or just because of bugs?
One’s easier to fix than the other.
If it works like real WoW64, then 16 bit applications won’t work ever but 32 bit applications that don’t work will be because of fixable bugs.
It seems to me that 16-bit applications are already basically broken with 32bit wine if you’re running a 64bit kernel, by default it places extra restrictions over what the hardware already does to prevent apps from loading 16 bit code entirely.
https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#16-bit-applications-fail-to-start
Guessing that’s why they don’t feel it’s that important to continue supporting, seems a VM is the future for these apps.
AFAIK, you couldn’t run 16-bit software on native Windows x64, so Wine is exhibiting the same behavior.
Anyway, these 16-bit softwares are old enough that running them in DOSBox or something like that won’t show any significant performance penalty through emulation vs translation.
I always thought it was purely a hardware limitation, but reading up on it I found it’s actually just “virtual 8086 mode” that was dropped, 16-bit protected mode is still available even when running the CPU in “long mode”.
So it rules out DOS apps, but 16bit Win 3.x apps should still run. But it’s probably a compatibility minefield, and even MS decided it wasn’t important (iirc the only thing they kept around was support for 16-bit app installers, but by internally swapping them out with 32-bit versions when run, since it was apparently common for 32-bit 9x apps to still use 16-bit installers so they could show a proper error message when run under Win 3.x)
Yeah most 16 bit stuff is old enough that there’s already a mature reimplementation of the game engine or old enough that it’ll run nicely in a translation layer or VM
From what I’ve seen if an online store provides a 16 bit classic without a reimplementation, it’s bundled with dosbox.
Of course, I’m pretty much blanking on any classic Win16 titles of note. As far as I recall the significant games just kept being DOS games with at most launch from icon. I suppose original Myst because QuickTime, but they released a Win32 build. But this 16 bit stuff was a speculation, this is about the 32 bit stuff that isn’t reasonably accommodated without a 32 bit runtime and certain bits being at odds with Flatpak isolation architecture.