• The_Decryptor@aussie.zone
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    1 day ago

    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.

    • m-p{3}@lemmy.ca
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 hours ago

      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.

    • Trainguyrom@reddthat.com
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      1 day ago

      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

      • jj4211@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 hours 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.