go-appimage VS static-wine32

Snap and flatpak run a daemon to integrate into your system. Appimage has an optional daemon to give you the same integration https://github.com/probonopd/go-appimage

Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list.

Only other thing you might want to do is symlink a friendly name for cli

It's possible to make appimages that bundle a libc, although most don't. The go-appimage project contains a static build tool that will bundle the linker and wrap executable invocation in that. The intention seems to be providing support on older systems for programs built with a glibc that is too new, but I'm using it to ship a musl binary that can run on glibc systems.

I look forward to watching the FOSDEM talk this weekend, so perhaps getting ahead of myself. But I'm curious whether you think the move in appimage toward static linking would solve some of the hairy issues you pointed out? For example: https://github.com/AppImage/AppImageKit/issues/1193 and https://github.com/probonopd/go-appimage/

AppImage This seems like a convenient way of keeping Wine isolated from rest of the system. However, the documentation is still in research phase for this: https://github.com/AppImage/AppImageKit/wiki/Bundling-Windows-applications https://github.com/probonopd/go-appimage https://github.com/TheAssassin/AppImageLauncher https://github.com/sudo-give-me-coffee/wine32-deploy

There's an automatic way to make .desktop entries from appimage, I use https://github.com/probonopd/go-appimage/blob/master/src/appimaged/README.md

There are helper programs to help you manage them and integrate them with the system like other package formats.

their is you can use appimaged https://github.com/probonopd/go-appimage

Would be great if most distros (including Ubuntu, Fedora, etc.) would include AppImageLauncher or appimaged by default. Would make it much simpler for most people.

I've spent some time optimizing the build process for static-wine32 so it requires much less manual labor. You still need Docker to build it but link time optimizations are now enabled by default.

static-wine32 updated as well for those of you interested in real performance.

static-wine32 updated as well in case you want to try it out in a sane way ;))

I've spent the month hacking to give you this gem! I hacked the Vulkan loader and Mesa into cooperation and now you can enjoy your 32 bit software without sinking hopelessly into a dependency hell. Nvidia users as usual are not served and they did this to themselves. While many will argue that static-wine32 is to be considered a human rights violation due to its awkwardness, I also addedlink-time optimized dependencies which means you're unlikely to find a faster Wine anywhere else. Mesa alone could get 20% faster if the rumors on the Internet are to be believed.

static-wine32 has been updated accordingly! Liberate yourself from the shackles of dynamic dependencies today!

If you're sick of millions of 32-bit deps I could suggest trying out static-wine32 for a scenario very close to yours. It only needs 32-bit C/C++ standard libraries.

Or if you want the full experience checkout statc-wine32. It includes the latest versions of almost everything statically so no install needed OS-wise. Vulkan not yet supported tho.

static-wine32 updated as well for those with digital masochistic tendencies!

static-wine32 updated and ready to go if you want to free your poor machine from a dependency nightmare!