Truly amazing software. I only recently learned that Crossover, which enables running windows software (mainly games) on MacOS, is built on Wine and significantly contributes to Wine Development.
Anyone have experience with distributing win32 programs for Linux and/or MacOS by bundling wine? I take it that statically linking is out of the question, but I am guessing you could make an AppImage binary for linux that includes wine, and for MacOS you could include wine in the app bundle. I haven't tried either though. I'm interested in this so I can use win32 as a cross-platform desktop GUI library.
Flathub offers the org.winehq.Wine package, which you can use in the base and base-version fields of your own package's manifest. It wouldn't cause your code to be statically linked with Wine. Your package could then be distributed from your own flatpak remote.
There was an announcement about a year ago of an effort to make a paid flatpak market, apparently to be called Flathub LLC. I don't know if that effort is still active.
I think Qt would yield better results than Wine for most things. Since your comment suggests that you're making proprietary software, you would have to take special care with linking or else submit to the Qt Group's commercial license terms.
Too lazy to dig up the PRs, but Flathub doesn't merge Windows applications using the Wine runtime unless the submitter is also the upstream maintainer. They don't mention this requirement anywhere on the docs, they'll only tell you after you've spent 12 hours getting it to work.
As someone who has tried this, I agree that Winelib is the way to go. Just don't go into it expecting it to "just work" without any code changes. Since NTFS is case-insensitive, it's likely that you'll have to fix your include paths to use the right case. If you used any MSVC compiler extensions, you'll likely need to modify your code to not use them or add `#ifdef __GNUC__` with alternative implementations for GCC. GCC's `-fms-extensions` can emulate some of them, but not all. Winemaker can help you with some of the more wrote aspects of this conversion, but not all of it. It will also produce Makefiles for you, but if you want a single build system that works on all platforms, I'd recommend that you use CMake with a CMake toolchain file targeting Winelib and `winegcc` instead. Visual Studio has pretty good CMake support these days, so it should look pretty much like any other Visual Studio solution when you open it there too.
Once you do get it working, you'll notice that on first run of your application Wine will create a `~/.wine` directory and populate it just like it would if you created a new Wine prefix to run a standard Windows application in. Other than that, it will feel pretty seamless. You'll even get a native application launcher for it (which is really just a shell script to run your project's `.exe` under Wine, but it's hidden from the user so it feels native if you don't look too closely.) Compiling against Winelib has the added benefit that you'll only be using win32 features that Wine supports, and can use native platform libraries (if you choose to do so when you're compiling your application, as described in the Winelib User's Guide) mixed with Windows libraries from Wine. It's nicer and works more smoothly than just running a Windows application you compiled with Visual Studio under a bundled version of Wine, in my experience.
I'm sure that you'd be able to bundle it as an AppImage, but I haven't actually tried that part myself.
This started out with bundling wine in appimages, but is expanded a lot. The author created a new appimage alternative that adds some stuff to make games work more reliably. I’ve used this several times to create portable versions of old windows games for my Steam Deck. It’s awesome!
I've seen a few russian pirated game releases for linux do this, they just bundle a copy of wine (downloaded from the same places as e.g. lutris gets it from), and a start script that sets the WINEPREFIX variable to a pre-populated prefix, with the game already installed and all the needed registry configurations already present.
I suppose you could bundle all this in an AppImage, the annoying part however is that the WINEPREFIX is supposed to be read-write, so you'd have to set it to some place specific to your app, to avoid messing with the user's main prefix. These prefixes are huge (hundreds of MB upon creation), so I'm not sure I'd consider this a desireable solution.
If this is your distribution method, consider having the user install wine before running your app.
I don’t have experience but I have heard of winelib which is a library implementing Win32 APIs. I suppose you don’t compile your code as PE executable, but compile to Linux natively while dynamically linking to winelib.
I'm curious why you'd want this over using a GUI library that is actually cross-platform? The way you've worded things suggests to me that you're building something new.
I want to go back to making desktop programs the way we used to before they turned into web apps that bundled chrome. I know I should just use Qt but I have some experience already with win32, and all the programs I have fond memories of are written with it (foobar2000, winamp, Everything, etc).
Have you considered Tk? Visually, it's quite like Win32, but it's fully cross-platform and (as of Tcl 9.0) has basic screen-reader support – so no mucking around with OLEACC shims or IAccessible2, as you'd need for COMCTL32. And it supports virtually everything Win32 does, with the ability to drop down to platform-specific sorcery (i.e., Win32) if the need arises.
It is. But if you mean .NET WinForms then you don't really need Wine because Wine uses Mono to run .NET executables. If using WPF then you should check out Avalonia UI [1] which is a cross-platform alternative that is also probably better (and has good tooling in VS). There's also .NET MAUI [2] but it's maybe not as good for desktop apps.
I didn't know about WoW64 mode. I remember when trying to install an old windows program I had to install a bunch of 32-bit translation library for audio and stuff. This WoW64 means that I can just simply use 64-bit arch. This is fabulous.
It's a bit different. WOW64 is a compatibility layer that intercepts calls into system libraries from 32-bit apps and translates them into calls to 64-bit libraries. macOS shipped both 32-bit and 64-bit versions of all system libraries, no translation involved.
This is all amazing work. Is there a list of applications/games that previously didn't work that now do (like what Dolphin puts out)? I'd love to understand what the improvements mean in a practical sense.
Congrats on ntsync and new wow64 support! Those are two huge features released last year.
ntsync allows efficient and correct synchronization usage that matches logic of Windows and new wow64 allows running 32-bit Windows programs without 32-bit Linux dependencies.
Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.
Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.
Userland DRMs do all sort of nonsense. Kernel anticheats wouldn't use the syscalls, they're already able to call the kernel routines they want directly.
While I agree that it is amazing work, I feel the need to call out the wine team because, as many likely know, a redditor (admittedly of unknown origin, to me at least) felt the need to go to Valve prior to the wine team. Valve, of course, kicked the PR back over to the wine team, which I actually think is fine. The issue, I think, "may possibly" be the wine team.
The PR was well documented, does not initially appear to be related to AI, and it makes a PITA installer work FFS. Further, my own PRs to wine were accepted for less decades ago and are still in use now.
Forgive the rant, however the redditor in question was scared to send the PR to Wine due to politics. That tells me there is definitely too much middle management in an open source project.
Some news outlets did report on it. However, in my experience after testing the patch applied on top of Wine 11.0, both the Creative Cloud and the Photoshop installer did not work.
I suppose that the thing that the patch fixes is the "offline" Photoshop installers, which are not provided anymore unless if you ask Adobe nicely... or if you get it from third party sources. The PR's creator did say that they didn't pay for Creative Cloud, so I think it is likely that this is what happened.
This made me wonder if anyone had actually tested the patches with a legit Creative Cloud/Photoshop installer, or if everyone just ran with the PR saying "look it works now!!!" but nobody bothered to actually test it. The creator did submit their own precompiled Wine version, however that version is meant to be run via Proton, so I wasn't able to make it work because I don't know how to run things via Proton outside of Steam.
I was able to get the Creative Cloud app in Wine (set to Windows 10 mode) by using some very dubious methods, as in, I asked Claude Code to implement the stub to see what would happen because if AI is sooo good as how people are saying, it should be able to fix things in Wine... right? And surprisingly, it did actually work.
However you aren't able to use Photoshop CC 2021 (the earliest Photoshop version you can install from Creative Cloud, newer versions crash during startup) because the activation popup does not render the input controls. The reason why I think it is trying to render something is because the activation popup background does have the same color as the Adobe website and, if my memory is correct, in Windows that popup is used to ask for your Adobe account credentials.
(Sadly the PR patch does not fix the activation screen)
Of course, if you bypass the activation using... alternatives means, Photoshop CC 2021 does work under Wine, which is why you can find a lot of "Photoshop CC 2021 in Wine!" repositories on GitHub.
Hats off to the Wine team for all the amazing work! Myself and I'm sure many others wouldn't be able to switch to Linux without you. Thank you!
> 16-bit applications are supported in the new WoW64 mode.
I’d like to thank them for this, specifically! I had some old applications that weren’t working in the old WoW mode.
The funny thing (or actually sad) is Windows cannot run win16 anymore.
Truly amazing software. I only recently learned that Crossover, which enables running windows software (mainly games) on MacOS, is built on Wine and significantly contributes to Wine Development.
Crossover is made by Codeweavers who are the devs of Wine.
They're also responsible for Proton in collaboration with Valve. Codeweavers CTO has been project lead of Wine for three decades.
> responsible for Proton
Part of Proton only. Proton is a mix of various projects. Esync, Fsync, Wine, DXVK, and more...
> Codeweavers CTO
Yes Julliard is very famous and key to the project
Anyone have experience with distributing win32 programs for Linux and/or MacOS by bundling wine? I take it that statically linking is out of the question, but I am guessing you could make an AppImage binary for linux that includes wine, and for MacOS you could include wine in the app bundle. I haven't tried either though. I'm interested in this so I can use win32 as a cross-platform desktop GUI library.
You might consider Flatpak packaging.
Flathub offers the org.winehq.Wine package, which you can use in the base and base-version fields of your own package's manifest. It wouldn't cause your code to be statically linked with Wine. Your package could then be distributed from your own flatpak remote.
There was an announcement about a year ago of an effort to make a paid flatpak market, apparently to be called Flathub LLC. I don't know if that effort is still active.
https://discourse.flathub.org/t/request-for-proposals-flathu...
Winelib might also be worth considering, depending on how you are able to navigate the relevant licenses.
https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
I think Qt would yield better results than Wine for most things. Since your comment suggests that you're making proprietary software, you would have to take special care with linking or else submit to the Qt Group's commercial license terms.
Too lazy to dig up the PRs, but Flathub doesn't merge Windows applications using the Wine runtime unless the submitter is also the upstream maintainer. They don't mention this requirement anywhere on the docs, they'll only tell you after you've spent 12 hours getting it to work.
Most people can use the LGPL version of Qt.
Flatpak can be pretty buggy with Wine I've had some programs misbehave cause it to eat up all my ram when using bottles for instance.
Winelib sounds like what you’re describing about static linking: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
As someone who has tried this, I agree that Winelib is the way to go. Just don't go into it expecting it to "just work" without any code changes. Since NTFS is case-insensitive, it's likely that you'll have to fix your include paths to use the right case. If you used any MSVC compiler extensions, you'll likely need to modify your code to not use them or add `#ifdef __GNUC__` with alternative implementations for GCC. GCC's `-fms-extensions` can emulate some of them, but not all. Winemaker can help you with some of the more wrote aspects of this conversion, but not all of it. It will also produce Makefiles for you, but if you want a single build system that works on all platforms, I'd recommend that you use CMake with a CMake toolchain file targeting Winelib and `winegcc` instead. Visual Studio has pretty good CMake support these days, so it should look pretty much like any other Visual Studio solution when you open it there too.
Once you do get it working, you'll notice that on first run of your application Wine will create a `~/.wine` directory and populate it just like it would if you created a new Wine prefix to run a standard Windows application in. Other than that, it will feel pretty seamless. You'll even get a native application launcher for it (which is really just a shell script to run your project's `.exe` under Wine, but it's hidden from the user so it feels native if you don't look too closely.) Compiling against Winelib has the added benefit that you'll only be using win32 features that Wine supports, and can use native platform libraries (if you choose to do so when you're compiling your application, as described in the Winelib User's Guide) mixed with Windows libraries from Wine. It's nicer and works more smoothly than just running a Windows application you compiled with Visual Studio under a bundled version of Wine, in my experience.
I'm sure that you'd be able to bundle it as an AppImage, but I haven't actually tried that part myself.
Good luck!
Check out GameImage!
https://github.com/gameimage/gameimage
This started out with bundling wine in appimages, but is expanded a lot. The author created a new appimage alternative that adds some stuff to make games work more reliably. I’ve used this several times to create portable versions of old windows games for my Steam Deck. It’s awesome!
I've seen a few russian pirated game releases for linux do this, they just bundle a copy of wine (downloaded from the same places as e.g. lutris gets it from), and a start script that sets the WINEPREFIX variable to a pre-populated prefix, with the game already installed and all the needed registry configurations already present. I suppose you could bundle all this in an AppImage, the annoying part however is that the WINEPREFIX is supposed to be read-write, so you'd have to set it to some place specific to your app, to avoid messing with the user's main prefix. These prefixes are huge (hundreds of MB upon creation), so I'm not sure I'd consider this a desireable solution.
If this is your distribution method, consider having the user install wine before running your app.
I don’t have experience but I have heard of winelib which is a library implementing Win32 APIs. I suppose you don’t compile your code as PE executable, but compile to Linux natively while dynamically linking to winelib.
I'm curious why you'd want this over using a GUI library that is actually cross-platform? The way you've worded things suggests to me that you're building something new.
I want to go back to making desktop programs the way we used to before they turned into web apps that bundled chrome. I know I should just use Qt but I have some experience already with win32, and all the programs I have fond memories of are written with it (foobar2000, winamp, Everything, etc).
Win32 and Wine being a lightweight alternative to HTML and Electrum is a fun idea.
Wine is going to require at least as much disk space as Electron. Performance and memory usage should at least be better though.
You might like https://www.lazarus-ide.org/
Have you considered Tk? Visually, it's quite like Win32, but it's fully cross-platform and (as of Tcl 9.0) has basic screen-reader support – so no mucking around with OLEACC shims or IAccessible2, as you'd need for COMCTL32. And it supports virtually everything Win32 does, with the ability to drop down to platform-specific sorcery (i.e., Win32) if the need arises.
Because, as they always say, Win32 is the only stable ABI on Linux.
Perhaps a Windows-only RAD framework? (Admittedly, I can only think of VB6...)
Delphi!
Visial Studio is quite good for gui.
It is. But if you mean .NET WinForms then you don't really need Wine because Wine uses Mono to run .NET executables. If using WPF then you should check out Avalonia UI [1] which is a cross-platform alternative that is also probably better (and has good tooling in VS). There's also .NET MAUI [2] but it's maybe not as good for desktop apps.
[1] https://avaloniaui.net/ [2] https://dotnet.microsoft.com/en-us/apps/maui
Depending on the use case, you might be able to get away with PowerShell with Pinvoke bindings if your code is more script-like than compiled code.
Instead of making your own GUI library, you could just make a shim that translates to whatever framework you want to support.
See: https://learn.microsoft.com/en-us/dotnet/standard/native-int...
That sounds antithetical to the “never just works” philosophy of Linux software.
I didn't know about WoW64 mode. I remember when trying to install an old windows program I had to install a bunch of 32-bit translation library for audio and stuff. This WoW64 means that I can just simply use 64-bit arch. This is fabulous.
WoW64: https://en.wikipedia.org/wiki/WoW64
Is the MacOS equivalent what was deprecated in Catalina, ending compatibility with 32-bit applications?
Crossover maintained compatibility with 32-bit windows applications even after Catalina.
> https://www.codeweavers.com/blog/jwhite/2019/12/10/celebrati...
Which is kind of funny because yet again windows was a better application in terms of longevity than MacOS native.
It's a bit different. WOW64 is a compatibility layer that intercepts calls into system libraries from 32-bit apps and translates them into calls to 64-bit libraries. macOS shipped both 32-bit and 64-bit versions of all system libraries, no translation involved.
Seems like also 16bit apps????
This is all amazing work. Is there a list of applications/games that previously didn't work that now do (like what Dolphin puts out)? I'd love to understand what the improvements mean in a practical sense.
They usually include this info in the point releases[0]. It would be far too much to fit in the 11.0 release notes
[0] https://gitlab.winehq.org/wine/wine/-/releases
Any chance this will improve Solidworks support?
Is Wine ever going to be able to run the current version of Microsoft Office? This is the main app keeping people in Windows.
The "current" version is a cloud-encumbered MS365 product with Copilot+ integration, so probably not.
That being said, apparently the 2016 version is gold-rated on WineHQ: https://appdb.winehq.org/objectManager.php?sClass=applicatio...
I find Office 2016 feels rather similar to current Office 365 as well. For home office stuff I'd never notice the difference.
Our company just deployed Office 2024, which is not cloud-based. There are plenty of companies that can't/won't use the cloud version.
They said “cloud encumbered” not cloud based.
Do you have a version that doesn’t prompt users to use cloud services, and also does not attempt to make outgoing network calls?
I jumped off the MS train about ten years ago, but the office they shipped back then was already cloud encumbered.
Congrats on ntsync and new wow64 support! Those are two huge features released last year.
ntsync allows efficient and correct synchronization usage that matches logic of Windows and new wow64 allows running 32-bit Windows programs without 32-bit Linux dependencies.
I’ve always installed both wine and wine-32bit on Linux. Does this mean I can now delete wine-32bit after this?
Yes, I think up to date wine simply build dropped wine vs wine64 difference. You can check winehq builds.
> NT system calls use the same syscall numbering as recent Windows, to support applications that hardcode syscall numbers.
Other than antivirus software and maybe MAYBE kernel-level "anticheat" slop - who in their right mind does straight syscalls to the kernel?
Some programming language compilers generate asm that does call systemcalls directly. Go for example.
Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.
https://cs.opensource.google/go/go/+/refs/tags/go1.25.6:src/...
Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.
Userland DRMs do all sort of nonsense. Kernel anticheats wouldn't use the syscalls, they're already able to call the kernel routines they want directly.
Does it matter? The closer they get to being indistinguishable from Windows, the better.
The problem is, Windows syscalls change around a lot. Keeping up with that is Sisyphean.
I'd argue that anyone who willingly attempts to program these infernal beasts is not entirely in their right mind to begin with.
anti tamper, drm, library call obfuscation and they all do it wrong, really wrong.
While I agree that it is amazing work, I feel the need to call out the wine team because, as many likely know, a redditor (admittedly of unknown origin, to me at least) felt the need to go to Valve prior to the wine team. Valve, of course, kicked the PR back over to the wine team, which I actually think is fine. The issue, I think, "may possibly" be the wine team.
The PR was well documented, does not initially appear to be related to AI, and it makes a PITA installer work FFS. Further, my own PRs to wine were accepted for less decades ago and are still in use now.
Forgive the rant, however the redditor in question was scared to send the PR to Wine due to politics. That tells me there is definitely too much middle management in an open source project.
I am sure I am not the only person who has no idea what you are talking about. Do you have a link to the PR?
Pretty sure it is this one: https://github.com/ValveSoftware/wine/pull/310
Some news outlets did report on it. However, in my experience after testing the patch applied on top of Wine 11.0, both the Creative Cloud and the Photoshop installer did not work.
I suppose that the thing that the patch fixes is the "offline" Photoshop installers, which are not provided anymore unless if you ask Adobe nicely... or if you get it from third party sources. The PR's creator did say that they didn't pay for Creative Cloud, so I think it is likely that this is what happened.
This made me wonder if anyone had actually tested the patches with a legit Creative Cloud/Photoshop installer, or if everyone just ran with the PR saying "look it works now!!!" but nobody bothered to actually test it. The creator did submit their own precompiled Wine version, however that version is meant to be run via Proton, so I wasn't able to make it work because I don't know how to run things via Proton outside of Steam.
I was able to get the Creative Cloud app in Wine (set to Windows 10 mode) by using some very dubious methods, as in, I asked Claude Code to implement the stub to see what would happen because if AI is sooo good as how people are saying, it should be able to fix things in Wine... right? And surprisingly, it did actually work.
However you aren't able to use Photoshop CC 2021 (the earliest Photoshop version you can install from Creative Cloud, newer versions crash during startup) because the activation popup does not render the input controls. The reason why I think it is trying to render something is because the activation popup background does have the same color as the Adobe website and, if my memory is correct, in Windows that popup is used to ask for your Adobe account credentials.
(Sadly the PR patch does not fix the activation screen)
Of course, if you bypass the activation using... alternatives means, Photoshop CC 2021 does work under Wine, which is why you can find a lot of "Photoshop CC 2021 in Wine!" repositories on GitHub.
https://www.reddit.com/r/linux_gaming/comments/1qdgd73/i_mad...
https://bugs.winehq.org/show_bug.cgi?id=57980