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·
    8 days 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.

    • MicKet@swiss.social
      0·
      6 days ago

      @StillDepressedMan

      I have been using this application for years. I convert some games since 10 years from Wine version to wine Version and most of work i had to get it run again is because of wine does nothing to support me.
      It is not just about being able to use it.
      I also used PlayOnLinux and other bottle software and after they died, I had again a lot of work to convert it to other helper software.
      They are not compatibility. And really I do not wish to need them.

      • StillDepressedMan@reddthat.comOPEnglish
        1·
        13 hours ago

        I have been using this application for years. I convert some games since 10 years from Wine version to wine Version and most of work i had to get it run again is because of wine does nothing to support me.

        Do you mean you were writing installers for different frontends?

        I also used PlayOnLinux and other bottle software and after they died, I had again a lot of work to convert it to other helper software.

        I don’t think Bottles will vanish. Yes, there are some problems. The main programmer is doing something else. Running stuff from the console doesn’t work. But I think it’s too good to die.

        And really I do not wish to need them.

        In my honest opinion, I think Wine developers don’t want to build a global database on how a given game should be installed and have it done automatically. Wine is like a kernel—they don’t want to touch “user space.” They want to create an engine that works exactly like Windows, and no workarounds would be needed.

        I think the best way to add workarounds is the WineHQ AppDB.