- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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.---------
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.
@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.
Haha, that’s true.
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.
@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.
Do you mean you were writing installers for different frontends?
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.
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.