> 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.

Crossover is made by Codeweavers who are the devs of Wine.

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, you would have to take special care with linking or else submit to the Qt Group's commercial license terms.

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.

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.

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.

Is the MacOS equivalent what was deprecated in Catalina, ending compatibility with 32-bit applications?

Some programming language compilers generate asm that does call systemcalls directly. Go for example.

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.

anti tamper, drm, library call obfuscation and they all do it wrong, really wrong.