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.
foresto|1 month ago
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.
OsrsNeedsf2P|1 month ago
TingPing|1 month ago
bobajeff|1 month ago
circuit10|1 month ago
Rayosay|1 month ago
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!
darthcircuit|1 month ago
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!
mid-kid|1 month ago
If this is your distribution method, consider having the user install wine before running your app.
cmxch|1 month ago
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...
treesknees|1 month ago
https://github.com/Sikarugir-App/Sikarugir
https://github.com/vitor251093/wineskin
kccqzy|1 month ago
unknown|1 month ago
[deleted]
Rohansi|1 month ago
radarroark|1 month ago
dfabulich|1 month ago
nxobject|1 month ago
scotty79|1 month ago
transcriptase|1 month ago