This release represents a year of development effort and over 7,400 individual changes. It contains a large number of improvements that are listed in the release notes below. The main highlights are:
– Builtin modules in PE format.
– Multi-monitor support.
– XAudio2 reimplementation.
– Vulkan 1.1 support.
Wine allows me to run virtually any Windows game I use on Linux – including League of Legends, my most-played game – so it’s a pretty amazing tool in my book. Since many people no longer directly interact with Wine, using it through tools like Steam’s compatibility tools or Lutris, instead, it’s easy to forget just how important of a project Wine really is.
I’m always happily surprised when wine works, like the other day when windows software for a network KVM just worked. Although I make a point to not go in expecting windows software to run on linux because frequently it does not.
All progress is welcome though, it not only advances linux compatibility, but reactos compatibility as well.
I’ve been using only Linux on my daily driver computers all day every day during the past 13 years or so, and the main reason I can do so is thanks to Wine. For *one* program. It’s proprietary, it’s in maintenance mode, and it will never be ported to any other OS. And there are no alternatives. Fortunately it works 100% in Wine without jumping through hoops. So I’d say that Wine is what allowed me to switch to Linux, absolutely mission critical for me.
> For *one* program. It’s proprietary, it’s in maintenance mode, and it will never be ported to any other OS. And there are no alternatives.
You can’t leave us hanging like that! What is it?
Not sure about everything else on the list but multi-monitor support have made me happy, it was very annoying to restart some apps when you forgot and just moved window to different display.
I’ve been using Wine to run legacy programs that modern Windows has dropped support for and it works very well.
My only concern is that I’ve read some chatter that WINE might drop some of it’s legacy application support to improve modern application compatibility. If that happened I’d have no use for WINE and I might as well just stay on Windows as a big reason for running Linux is removed.
I do get the irony of being a Linux user running WINE, which is why I don’t bag Windows relentlessly!
cpcf,
Perhaps what’s needed is a “winbox” akin to “dosbox”, something with a fixed target that assures that old software will always be accessible regardless of what happens to wine & linux over the years.
Wine is decent, but the problem ironically is that wine is not an emulator (ring a bell?). In some cases with old software an emulator is actually what you want. An API translator, though very fast, has to bridge a growing increasingly complex gap over time. It could make sense to have a 32bit windows emulator (since that is not an evolving target) and allow wine to focus on the present/future.
The problem for wine is that without emulation, the project can get impacted by external decisions that they don’t have a say in, which makes wine vulnerable. For example, what happens if an important distro like ubuntu threatens to yank 32bit dependencies that wine implicitly needs…
https://itsfoss.com/ubuntu-drops-32-bit-desktop/
If we had a “winbox” emulator, it would be trivial to isolate the software being emulated from the host environment. Emulators are intrinsically more portable than call translation. You do loose performance, but presumably with very old software you care more about being able to run it at all.
Alfman, I agree with all of this and long term I’ve no reservations about emulator performance.
Wouldn’t it be nice if MS offered as much, and as a side-effect set later versions of Windows free?
My main issue is legacy software that controls legacy hardware, old hardware that is more than happy with emulated controller performance levels. I suppose in the long term as discussed here once before it could all be done on an ASIC in the future.
You can run multiple versions of WINE on the same system. Just keep an older version for those older programs. Both PlayOnLinux and Lutris allow setting which version of WINE is used with specific apps/games.
JLF65,
While that’s true, sometimes dependencies can be a big obstacle to running older versions. For example, one of my gripes with ffmpeg/libav is that they regularly break the shared libraries & backwards compatibility such that you need to regularly patch software built against it. Consequently distros like debian stable are stuck between two bad choices, updating the shared libraries with breaking changes, or keeping old libraries indefinitely. When the libraries are too old, as they’ve been for me, I’m forced to build the new software myself and without the repository to provide compatible dependencies it becomes “dll-hell”. In theory, a distro could provide all versions of any dependencies you’d ever need, but in practice they only provide the latest ones and require software to use those because otherwise the repos become too gargantuan.
(Aside: there’s been a lot of drama with ffmpeg/libav https://www.reddit.com/r/linux/comments/vvdxn/the_ffmpeglibav_situation/ )
That said, I’ve never built wine myself, so I don’t know how often wine encounters dependency problems. In theory you might take point in time snapshots of wine’s binary + dependencies, but even that can potentially become unwieldy for the wine project since now it’s not only responsible for wine itself, but also all of wine’s external dependencies (which is normally the repo’s job). Hypothetically if wine v1 has a dependency on X11, and wine v2 has a dependency on wayland, does this mean the software supported by wine v1 will always have to use X11? That would be far from ideal.
The emulator idea I suggested to cpcf was something that would not evolve by design, it would have a fixed target for applications from a specific windows era. Unlike wine today the windows calls would not get translated into host calls, instead they would be emulated.
Since wine relies on contemporary hardware & dependencies, it is not useful for software historians. It will probably be a distant event, but at some point our x86 hardware will cease to support 32bit processes in the same way that amd64 stopped allowing us to run 16bit processes on a 64bit host. I was a bit saddened that I couldn’t run my old dos applications, which ran up through windows xp. However dos emulators saved the day, so it might be time to start thinking about doing the same thing for windows. An additional benefit is that an emulator would be much more portable, even to completely different architectures like ARM, etc.
cpcf made a good point, being able to run old windows software is more of a microsoft problem than a linux problem, so it would make sense for them to provide an emulator, but I’m skeptical they have any commercial interest in providing one and I don’t have much faith that it would survive if it wasn’t open source…
Well, I can run every version of WINE from 2.0 to 5.0 on Xubuntu 18.04 without issue. Haven’t tried 1.x. So there’s not much of an issue with dependencies with WINE so far.
Seriously, I have more trouble with the dang DLLs in WINE than with WINE’s linux library dependencies (any trouble being more than no trouble, after all). 😀
JLF65
I agree and haven’t had any issues running wine either, overall I’m pleased with it. However I’ve never tried compiling or running an old wine binary…I only run the version of wine from my distro’s repository, which is already implicitly compatible with the libraries from the same repository. The same is true of ffmpeg too, the dependency issues arise from running different versions. I normally use software from the repo whenever I can to avoid dependency issues.
Anyways, I’ve found that I’ve needed to add 32bit architecture repos using something like this in order to run 32bit windows programs through wine.
Not really a problem as long as these 32bit dependencies are available, but if distros actually did drop support for 32bit, it would be a problem.
Do you use the vanilla Wine and Windows version of LoL client, or something they packaged up? I’d be curious to read about a comparison of the two. Back in the day, I used to have more luck running Wine and unported Windows builds, but I don’t know how far along the various proprietary forked Wine projects (after the LGPL license change) that tend to be used by first party ports are.