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.
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.
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.
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. But since your comment suggests that you're making proprietary software, I think you would have to take special care with linking or else submit to the Qt Group's commercial license terms.
That sounds antithetical to the “never just works” philosophy of Linux software.
Winelib sounds like what you’re describing about static linking: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
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.
Perhaps a Windows-only RAD framework? (Admittedly, I can only think of VB6...)
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...
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.
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.
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.
Congrats on ntsync and new wow64 support! Those are two huge features added 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.
> 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?
anti tamper, drm, library call obfuscation and they all do it wrong, really wrong.
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.