Appimagekit: Support Windows?

[traverseda]

It would be nice if I could package once (on a nice freindly linux system) and export to other operating systems. Really, I just want to deal with windows as little as possible, but still provide my app on their platform.

Would cygwin support all the system calls appimage needs? Is there a way to do this that doesn't require the user to go through the cumbersome steps of installing the POSIX subsystem?

[probonopd]

You can run AppImages on Windows using "Bash on Windows" aka "Windows Subsystem for Linux".

[traverseda]

Is there a way to do this that doesn't require the [end] user to go through the cumbersome steps of installing the POSIX subsystem?

That is, the posix subsystem for windows, if that was unclear. I don't want to deal with windows, if I wanted to run appimages on windows myself, I'd just do that. But it's not really a solution I can suggest to end-users.

[probonopd]

True. But Windows is out-of-scope here otherwise since we have no clue about it.

[maverick74]

@probonopd I was reading about 0install because of this same idea.

How did they manage to get the same package working for Linux, Mac and Windows?

[probonopd]

Don‘t know, sorry.

[shoogle]

@maverick74, they don't. See Zero Install's Features page:

__Cross-Platform and Cross-Distribution__
A single 0install package can be used across multiple Linux distributions, OS X, Unix and Windows systems __(given that the packaged application itself is written to be cross-platform as well)__.

(emphasis mine)

So technically, yes, the packaging (as in the archive the application is distributed in) can be used on all platforms, but it is up to the application developer to make sure that the application itself works on multiple platforms. This isn't hard with Java or Python, but good luck trying this with C, C++ or other compiled language. For those languages, this page says:

you still need to create separate binary archives for e.g. OS X and Linux, of course

Probably the only way to create a universal binary would be to take the separate binaries for each system (Linux, Windows, macOS, etc) and put them all in one archive, which is exactly what Apple did when they created "universal binaries" for use on Intel and PowerPC systems. However, this results in huge archives...

So, what's the point of Zero Install?

For interpreted or portable languages, Zero Install provides packages that are truly universal (one package works on multiple systems).

For compiled languages, the packages only work on the system they were compiled on (so you need to provide a separate package for each system). However, the packaging format and method of installation is the same on all systems, so developers and users only need to learn one method of packaging and installing applications.

Could AppImage do this?

Short answer: Yes!

AppImages are basically self-extracting compressed archives, which, when extracted, automatically run the payload application contained within the AppImage. It would be difficult to make the self-extracting functionality work on all systems, but if users installed a launcher program like appimaged or AppImageLauncher, then it could extract and (attempt to) run the contents of the AppImage on any system. As with Zero Install, it would be up to the application developer to ensure that the payload application runs on any system.

Should AppImage do this?

Short answer: Not right now.

There is little advantage to having a shared packaging format if the programs inside the packages won't run on all systems anyway. Sure, it means fewer packaging formats for users and developers to learn, but users on macOS and Windows are already familiar with the packaging formats on those systems. It would also create confusion if some AppImages worked on platforms that others didn't work on.

Linux is the only platform that doesn't have a single, universal way to:

1. Package applications (i.e. there is no such thing as a "Linux package", or format that works on all distributions by default)
2. Distribute applications independently (i.e. outside of an app store or distribution repository)
3. Provide portable applications (apps that don't need to be installed) or apps that can be installed for a single user without root privileges

So it makes sense for AppImage to establish itself by filling the gaps in the market that exists on Linux before it considers targeting other platforms.

Zero Install suffers from the Esperanto problem. (Esperanto is a made-up language intended to become the "international language" or "universal second language", but it failed because it was nobody's primary language, so everybody would have to learn it.) If AppImage can establish itself on one platform (i.e. Linux) then there is more chance of it being adopted by others.

[maverick74]

@shoogle thank you for your reply! It's all a lot clear now! :)

[traverseda]

Zero Install suffers from the Esperanto problem.

I'm not sure that's the problem there. The problem, in my opinion, is that it didn't actually simplify anything. Under zero-install you still need to produce builds for a bunch of different platforms.

In the ideal, appimage itself would provide some kind of compatibility shim allowing you to run appimages on other operating-systems, unmodified. One set of tooling, multiple operating-systems.

I do think that if a solution like this can let you build once and run anywhere will quickly take over. Of course apps need to build against a POSIX subsystem. The hard bit is getting POSIX apps to run cleanly on windows. I think it would take a lot of work to do that transparently, but it would be doable.

[shoogle]

it didn't actually simplify anything

Zero-install didn't make compiling any easier, but it meant that developers could use the same packaging format on all platforms (no need to learn the differences between .app, .exe and ELF or where to put icons on each system, etc.). It also meant the process of finding and installing software would be the same on all platforms, which makes things easier for end users.

In the ideal, appimage itself would provide some kind of compatibility shim allowing you to run appimages on other operating-systems, unmodified. One set of tooling, multiple operating-systems

Ideally yes, but we are talking utopian levels of ideal. Windows packaging is not great, but it works well enough and it is what Windows users expect. PortableApps.com fills the niche for the minority of Windows users who want portable builds. As for macOS, AppImage is based on Apple's .app bundle (which was originally NeXTSTEP's packaging format). There is no reason for macOS to adopt AppImage when they already have .app.

I do think that if a solution like this can let you build once and run anywhere will quickly take over.

And yet Java failed to replace native formats in any meaningful way.

[shoogle]

Users are familiar with the idea of having separate downloads for different platforms (Windows, macOS, Linux, etc.) so there's not much point in trying to produce a platform-independent binary.

Users are less familiar with things like processor architectures, but good luck creating a format that works on more than one or two different architectures! (Maybe something like RISC-V will solve this by making processors open source so everybody uses the same standard... or maybe it will just be yet another new architecture that developers have to compile for... or maybe it will turn out like open source software and create 1000 new architectures that we have to compile for!)

Anyway, AppImage's focus has so far been on portability between Linux distributions. This will remove a huge barrier for new Linux users and go a long way to showing that open source systems can be just as easy to use as commercial systems. This by itself is difficult enough to achieve, so I don't think there will be appetite for taking on additional challenges anytime soon.