It's amazing how far Wine has come. Proton combines Wine with DVXK and other libraries and allows to play practically any Windows game on Linux with a negligible performance hit. I remember using Proton around 2021 and it already worked fairly well but now the experience is incredibly smooth. 2025 is definitely the year of the Linux gaming desktop.
Linux is gaining ground on desktops so I expect that an increasing number of developers will make sure their apps run on Wine going forward, either by directly contributing to the project or by making the necessary changes in their own programs. I think so far it’s mostly gaming that benefited, because of Valve’s contributions, but generic desktop apps should be easier technically speaking.
Wine has seen a massive improvement since the introduction of WoW64, and now it apparently supports 16-bit programs too. Many thanks to the Wine devs who made this possible.
> Run Windows Applications on Linux, BSD, Solaris and macOS
Obviously it gets used a lot on Linux (not only because of SteamOS using it through Proton, but that certainly contributes), I think I've read about people using it on Darwin, but how much testing/use does it get on the BSDs and Solaris?
Can't speak for Solaris, but the BSDs do get some love from the Wine devs. There are even active BSD gaming communities to make BSD gaming viable, much like Linux+Proton! https://youtu.be/vQpI7SU921A
Wine is not an emulator, as it runs unmodified PE executable by mocking the ABI calls, translating them to Linux equivalent. You can say it is like Windows on Linux, just like Windows on Windows 64, otherwise, WoW64 would be considered an emulator.
The only difference is that only programs that fully uses userspace works, and anything that uses kernel driver will fail miserably. In this sense, games worked out the best because they usually have high level of independence and self-contained, with hardware abstraction layers to make things highly compatible.
If you want to talk about similar stuff, FreeBSD have a Linux compatibility layer similar to Wine. You can use that as a reference, despite both FreeBSD and Linux use ELF, and Windows use PE.
But to be honest at the end of the day, it's just program header describing code sections, library imports/exports and relocations, and this is why you can run Windows app on Linux basically untouched, given you can reverse engineer userspace Windows API calls 100% precisely.
And the legal aspect of it, well...
Also, there is a project called Winlator (https://github.com/brunodev85/winlator) that combines Wine + Box64/Box86 to run x86 games on Wine on Android. Now that is what I call an emulator since Box64/Box86 really is one.
This is true but it is pedantic. When people say “emulator” they usually mean “software that lets me run a program on platforms other than the original intended platform”. They don’t care about the implementation details. At some point we need to internally correct minor errors of terminology because the meaning is clear in context.
It obviously is an emulator though (which uses entirely HLE). Notably, Wine doesn't use the acronym anymore (about page prefixes with "originally known as").
It is not a traditional emulator which is a virtual machine that executes foreign bytecode or ar least uses a virtual hardware setup. QEMU fits that sense of emulator. Wine doesn't.
Wine lets userspace code to be executed as is with the full permissions of the host system. It is more like an alternative executable format support package / subsystem. It needs to emulate the Windows system DLL calls, but everything else is no different than loading a piece of ELF executable and jumping into it.
It's amazing how far Wine has come. Proton combines Wine with DVXK and other libraries and allows to play practically any Windows game on Linux with a negligible performance hit. I remember using Proton around 2021 and it already worked fairly well but now the experience is incredibly smooth. 2025 is definitely the year of the Linux gaming desktop.
Has it gotten better at running applications, as opposed to games? That was the big thing that seemed to still be hit or miss last time I looked.
Linux is gaining ground on desktops so I expect that an increasing number of developers will make sure their apps run on Wine going forward, either by directly contributing to the project or by making the necessary changes in their own programs. I think so far it’s mostly gaming that benefited, because of Valve’s contributions, but generic desktop apps should be easier technically speaking.
Are you trying to say that this is The Year of Linux on the Desktop? :)
(I’d love it to be true, it’s just, you know.)
Changelog item: "#21855 – Lotus Word Pro 9.8: Windows pull down does not show file names". Reported 2010, closed 2025...
How that didn't get closed for being stale is amazing
> 2025 is definitely the year of the Linux gaming desktop.
Wine has seen a massive improvement since the introduction of WoW64, and now it apparently supports 16-bit programs too. Many thanks to the Wine devs who made this possible.
So I'm curious; the tagline/title is,
> Run Windows Applications on Linux, BSD, Solaris and macOS
Obviously it gets used a lot on Linux (not only because of SteamOS using it through Proton, but that certainly contributes), I think I've read about people using it on Darwin, but how much testing/use does it get on the BSDs and Solaris?
Can't speak for Solaris, but the BSDs do get some love from the Wine devs. There are even active BSD gaming communities to make BSD gaming viable, much like Linux+Proton! https://youtu.be/vQpI7SU921A
People writing emulators are the unsung heroes of tech and art preservation /salute
Wine is not an emulator, as it runs unmodified PE executable by mocking the ABI calls, translating them to Linux equivalent. You can say it is like Windows on Linux, just like Windows on Windows 64, otherwise, WoW64 would be considered an emulator.
The only difference is that only programs that fully uses userspace works, and anything that uses kernel driver will fail miserably. In this sense, games worked out the best because they usually have high level of independence and self-contained, with hardware abstraction layers to make things highly compatible.
If you want to talk about similar stuff, FreeBSD have a Linux compatibility layer similar to Wine. You can use that as a reference, despite both FreeBSD and Linux use ELF, and Windows use PE.
But to be honest at the end of the day, it's just program header describing code sections, library imports/exports and relocations, and this is why you can run Windows app on Linux basically untouched, given you can reverse engineer userspace Windows API calls 100% precisely.
And the legal aspect of it, well...
Also, there is a project called Winlator (https://github.com/brunodev85/winlator) that combines Wine + Box64/Box86 to run x86 games on Wine on Android. Now that is what I call an emulator since Box64/Box86 really is one.
Why isn't there something similar for running OSX apps on linux? Should be easier than wine in theory because it's unix based?
There is: https://www.darlinghq.org/
(It is, unfortunately, newer and much less far along, probably purely because there's less dev-hours and dollars in it)
Shush it lets me play Monkey Island on a Mac it’s an emulator
You're practically begging for it...
Wine Is Not an Emulator!
This is true but it is pedantic. When people say “emulator” they usually mean “software that lets me run a program on platforms other than the original intended platform”. They don’t care about the implementation details. At some point we need to internally correct minor errors of terminology because the meaning is clear in context.
How are you able to distinguish when people use a word as it is defined from when they redefine it to something else?
For myself, I make every attempt to use words correctly.
It obviously is an emulator though (which uses entirely HLE). Notably, Wine doesn't use the acronym anymore (about page prefixes with "originally known as").
It is not a traditional emulator which is a virtual machine that executes foreign bytecode or ar least uses a virtual hardware setup. QEMU fits that sense of emulator. Wine doesn't.
Wine lets userspace code to be executed as is with the full permissions of the host system. It is more like an alternative executable format support package / subsystem. It needs to emulate the Windows system DLL calls, but everything else is no different than loading a piece of ELF executable and jumping into it.
True, though as soon as they supported Power PC Mac, emulators have been integrated with it as needed.
Obligatory wine is not an emulator.
But yeah I agree, wine is an awesome emulator, and these people are heroes