Wine 10.14 · wine / wine · GitLab
gitlab.winehq.org
The Wine development release 10.14 is now available. What's new in this release: Bundled vkd3d upgraded to version 1.17. Mono engine...

crossposted from https://reddthat.com/post/48963016

What’s new in this release:

  • Bundled vkd3d upgraded to version 1.17.
  • Mono engine updated to version 10.2.0.
  • Support for ping on IPv6.
  • Gitlab CI now running on Debian Trixie.
  • Various bug fixes.

The source is available at https://dl.winehq.org/wine/source/10.x/wine-10.14.tar.xz

Binary packages for various distributions will be available from the respective download sites.

You will find documentation here.

Wine is available thanks to the work of many people. See the file AUTHORS for the complete list.---------

    • StillDepressedMan@reddthat.comOPEnglish
      1·
      3 days ago

      I don’t know. If by usability you mean a better user experience, I don’t think so. I haven’t noticed many improvements in this area for years. That’s why many wine wrappers exist, and I’m fine with that. Personally, I value it more when the wine team focuses on improving the common virus library APIs for better application compatibility.

      • MicKet@swiss.social
        0·
        2 days ago

        @StillDepressedMan
        What I really miss, and I think the Wine Team should focus on that, is a clear difference between Wine and the Installed Application In my opinian A Wine Prefix should only contain the installed application and nothing from the system.

        Also I would like to have at least a Terminal application that meet some standards. Windows cmd is a vomit like shell… but cmd from wine is even more worse than cmd from Windows.

        • StillDepressedMan@reddthat.comOPEnglish
          1·
          24 hours ago

          but cmd from wine is even more worse than cmd from Windows.

          Haha, that’s true.

          A Wine Prefix should only contain the installed application and nothing from the system. Wine imitates Windows, so applications behave just like they would on real Windows — basically, one prefix is like one Windows installation. And in many cases, users even replace Wine’s built‑in DLLs with native ones from Windows, so those files can’t really be hidden because applications expect to see them.

          Wine imitates Windows, so applications behave just like they would on real Windows — basically, one prefix is like one Windows installation. And in many cases, users even replace Wine’s built‑in DLLs with native ones from Windows, so those files can’t really be hidden because applications expect to see them.

          I like Steam’s approach where game files are stored separately together with the prefix settings, and when you launch a game it just runs inside its own Wine prefix. Still, I can easily imagine cases where this setup doesn’t really make sense — for example when you need several programs working together in the same prefix, like some mod installers that expect the main game to be there as well.

          If you’re interested in Steam’s approach, you should also check out UMU launcher and more here bottles UMU integration

          PS: Wine itself is a general‑purpose engine, while the frontends are meant for regular users. Even though I compile it regularly, I haven’t really used plain Wine directly in a long time.