9 ms·

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

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.

Rohansi 8mo ago
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.
- scotty79 8mo ago
  Visial Studio is quite good for gui.
  - Rohansi 8mo ago
    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/ https://avaloniaui.net/ [2] https://dotnet.microsoft.com/en-us/apps/maui https://dotnet.microsoft.com/en-us/apps/maui
- nxobject 8mo ago
  Perhaps a Windows-only RAD framework? (Admittedly, I can only think of VB6...)
  - nine_k 8mo ago
    Delphi!
- radarroark 8mo ago
  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).
  - swinglock 8mo ago
    Win32 and Wine being a lightweight alternative to HTML and Electrum is a fun idea.
    - Rohansi 8mo ago
      Wine is going to require at least as much disk space as Electron. Performance and memory usage should at least be better though.
  - wizzwizz4 8mo ago
    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.
  - purerandomness 8mo ago
    You might like https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
  - badsectoracula 8mo ago
    Someone else mentioned Lazarus, though that is Object/Free Pascal, not C/C++. The API is based on VCL for Delphi which was designed for the Windows API and even though Lazarus is cross-platform and can use multiple backends (actually i've been playing with writing a FLTK backend[0], though it is in primitive stages and FLTK doesn't really like exposing much of its guts), the API has some windows-isms (e.g. colors are 4 bytes where one byte is used a special marker to indicate system colors, just like in Windows) and the backends even have to implement a small subset of the Windows API to work :-P. An alternative in C++ would be wxWidgets which has some (light) MFC inspirations, again feeling somewhat Windowsy though not full-on MFC/Win32 since from the beginning it had to work with X Windows / Motif in addition to Win32 (and AFAIK, the Motif backend still works). Another alternative, even more lightweight would be the aforementioned FLTK. FLTK is also designed to be statically linked with your program (though it can be linked dynamically too if you want) so it only relies on common system libraries (as an example the screenshot in [0] relies only on the C library, the C++ library -because it is needed by FLTK and it is possible to also statically link to that too- and common X11 libraries like libX11, libXft, etc that existed on any Linux desktop system for decades now -- FLTK can also support Wayland, though i haven't tested that). [0] https://i.imgur.com/W6XbLkr.png https://i.imgur.com/W6XbLkr.png
- dfabulich 8mo ago
  Because, as they always say, Win32 is the only stable ABI on Linux.
cmxch 8mo ago
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-interop/pinvoke https://learn.microsoft.com/en-us/dotnet/standard/native-int...
circuit10 8mo ago
Winelib sounds like what you’re describing about static linking: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-Guide https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
- Rayosay 8mo ago
  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!
foresto 8mo ago
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-flathub-program-management/8276 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-Guide#legal-issues 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.
- TingPing 8mo ago
  Most people can use the LGPL version of Qt.
  - nomel 8mo ago
    "People" or "professionals"? Our legal department said we had to buy licenses.
    - zekica 8mo ago
      Both. LGPL doesn't distinguish between commercial and non-commercial use.
      - deleted 8mo ago
        [deleted]
      - nomel 8mo ago
        Sure, but there's a clear practical difference. Most professionals don't have the agency or company backing to allow LGPL, with their companies source code. Most personal users do.
transcriptase 8mo ago
That sounds antithetical to the “never just works” philosophy of Linux software.
mid-kid 8mo ago
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.
darthcircuit 8mo ago
Check out GameImage! https://github.com/gameimage/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!
kccqzy 8mo ago
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.
deleted 8mo ago
[deleted]
treesknees 8mo ago
For MacOS there is Sikarugir (formerly Wineskin.) It lets you bundle a win32 program with a wine runtime as a .app https://github.com/Sikarugir-App/Sikarugir https://github.com/Sikarugir-App/Sikarugir https://github.com/vitor251093/wineskin https://github.com/vitor251093/wineskin

Rohansi 8mo ago

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.

scotty79 8mo ago
Visial Studio is quite good for gui.
- Rohansi 8mo ago
  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/ https://avaloniaui.net/ [2] https://dotnet.microsoft.com/en-us/apps/maui https://dotnet.microsoft.com/en-us/apps/maui
nxobject 8mo ago
Perhaps a Windows-only RAD framework? (Admittedly, I can only think of VB6...)
- nine_k 8mo ago
  Delphi!
radarroark 8mo ago
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).
- swinglock 8mo ago
  Win32 and Wine being a lightweight alternative to HTML and Electrum is a fun idea.
  - Rohansi 8mo ago
    Wine is going to require at least as much disk space as Electron. Performance and memory usage should at least be better though.
- wizzwizz4 8mo ago
  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.
- purerandomness 8mo ago
  You might like https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
- badsectoracula 8mo ago
  Someone else mentioned Lazarus, though that is Object/Free Pascal, not C/C++. The API is based on VCL for Delphi which was designed for the Windows API and even though Lazarus is cross-platform and can use multiple backends (actually i've been playing with writing a FLTK backend[0], though it is in primitive stages and FLTK doesn't really like exposing much of its guts), the API has some windows-isms (e.g. colors are 4 bytes where one byte is used a special marker to indicate system colors, just like in Windows) and the backends even have to implement a small subset of the Windows API to work :-P. An alternative in C++ would be wxWidgets which has some (light) MFC inspirations, again feeling somewhat Windowsy though not full-on MFC/Win32 since from the beginning it had to work with X Windows / Motif in addition to Win32 (and AFAIK, the Motif backend still works). Another alternative, even more lightweight would be the aforementioned FLTK. FLTK is also designed to be statically linked with your program (though it can be linked dynamically too if you want) so it only relies on common system libraries (as an example the screenshot in [0] relies only on the C library, the C++ library -because it is needed by FLTK and it is possible to also statically link to that too- and common X11 libraries like libX11, libXft, etc that existed on any Linux desktop system for decades now -- FLTK can also support Wayland, though i haven't tested that). [0] https://i.imgur.com/W6XbLkr.png https://i.imgur.com/W6XbLkr.png
dfabulich 8mo ago
Because, as they always say, Win32 is the only stable ABI on Linux.

cmxch 8mo ago

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-interop/pinvoke https://learn.microsoft.com/en-us/dotnet/standard/native-int...

circuit10 8mo ago

Winelib sounds like what you’re describing about static linking: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-Guide https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...

Rayosay 8mo ago
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!

foresto 8mo ago

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-flathub-program-management/8276 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-Guide#legal-issues 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.

TingPing 8mo ago
Most people can use the LGPL version of Qt.
- nomel 8mo ago
  "People" or "professionals"? Our legal department said we had to buy licenses.
  - zekica 8mo ago
    Both. LGPL doesn't distinguish between commercial and non-commercial use.
    - deleted 8mo ago
      [deleted]
    - nomel 8mo ago
      Sure, but there's a clear practical difference. Most professionals don't have the agency or company backing to allow LGPL, with their companies source code. Most personal users do.

transcriptase 8mo ago

That sounds antithetical to the “never just works” philosophy of Linux software.

mid-kid 8mo ago

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.

darthcircuit 8mo ago

Check out GameImage! https://github.com/gameimage/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!

kccqzy 8mo ago

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.

deleted 8mo ago

[deleted]

treesknees 8mo ago

For MacOS there is Sikarugir (formerly Wineskin.) It lets you bundle a win32 program with a wine runtime as a .app https://github.com/Sikarugir-App/Sikarugir https://github.com/Sikarugir-App/Sikarugir https://github.com/vitor251093/wineskin https://github.com/vitor251093/wineskin