434
Bazzite founder might shutdown whole project if Fedora drops support for 32 bit packages (lemmy.ml)
submitted 1 year ago by to c/linux_gaming@lemmy.world
162 comments fedilink hide all child comments
 

https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324/93

you are viewing a single comment's thread
view the rest of the comments
[–] 10 points 1 year ago (5 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 8 points 1 year ago* (4 children)

    It seems to me that 16-bit applications are already basically broken with 32-bit wine if you're running a 64-bit 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 1 year ago* (1 child)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 1 year ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    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)

  • permalink
  • fedilink
  • source
  • parent