Call me cynical, but I for one don't believe that true single-package, multi-platform installers will ever be practical in fat-client applications. Here's why:

Execution Problems
MacOS has a cool little paradigm where the application is a folder, not a single binary file, and contains some metadata that can help the OS choose the right binary to run. This is a really cool concept, but it only ports across versions of MacOS, and even then it is fairly limited in its implementation. There is absolutely no similar corresponding paradigm in Windows or the *nixes as far as I know.

A single package file has to be executable across all platforms with a single click from the user, and requiring no interaction on the user's part to choose the correct platform. This means that you need a way to bootstrap the installer on any platform that you are targetting, and that is a nontrivial problem to solve. Admittedly I haven't spend much time trying to find clever solutions, but the concepts I've got off the top of my head are unwiedly, unstable, and not portable to new hardware/OS versions. Ideally we need cooperation between all OSes in running a single bootstrap format (in a perfect world, this would be based on a metadata scheme ala MacOS) but that will never happen because OS vendors see each other as competitors, and interoperability is not exactly Priority Number One.

Sure, a third-party vendor could come along and build a bootstrapping technology very, very easily. In fact, it's a trivial problem; wouldn't take more than a few hours to get right and in a marketable state (think a brain-dead and self-executing version of ZIP files, with a bootstrapping aid running on each target computer). Unfortunately, this requires users to have the bootstrap aid technology, and introduces a chicken-egg market penetration problem that is very, very nontrivial.


Package Volume
A single-package installer must, by definition, contain all the assets from every supported platform. In some trivial cases you can get away with some highly portable data and this space is not a big concern. However, in most non-trivial applications, you will need a lot of platform-specific stuff, both code and data. Even heavy-handed hacks like writing a pcode compiler for binary portability (like Excel did) will help, but they have a huge cost. Basically, you have to spend a ton of effort up-front during development to achieve this, and it may or may not pan out. Even in the case of using a platform-independent data representation and a middle tier to convert to each platform on-the-fly, you have a technically complex layer that is prone to failure, and it costs development time.

For fat-media products, this isn't too big of a deal (indeed, for fat-media like CDs, you can very easily do per-platform installers and fake it to look like a single package). But the real use for single-package installers is thin-media redistribution, be it on USB flash drives, over the Web, or by carrier pigeon. In all of these cases, wasted media space is a bad thing. So you have to take the hit on the development effort, which (and I know from experience) might end up costing a lot more than it sounds like on the surface.

The network stub method is really the best answer to this; IMHO, that's the only way thin-media installs should be done anyways. However, it may not always be an option, and eventually someone will complain that they can't put the entire thing on a CD and reinstall it when they're in B.F.E. and the wireless connection drops out. Being able to rely on a fat pipe to deliver the installation data would really be extremely handy, but that's a luxury we don't have in the real world - yet.


Differing OS paradigms
You touched on this in three major points: familiar interface, CLI support, and uninstallations. This is a serious and difficult problem. Interface design parameters are quite different between OSes (the infamous OK/Cancel problem between Windows and MacOS) if there are even any genuine guidelines at all (*nix). What makes sense in one OS may be completely out of place in another. This means you need a per-platform UI fork so that it feels native to each platform. You cannot ignore this - Java tried to ignore it, and Java UIs have become universally reviled and hated by developers and users alike.

CLI support will have to be implemented in many different ways on each platform. If you want older Windows support, you need a slightly different bag of tricks than just NT-based Windows support. MacOS and the *nixes are again different (although the MacOS CLI, being stolen from BSD, is actually pretty easy to get interoperating with *nix code). This is primarily a technical matter, but the bottom line is that it requires additional code branches per target platform. This means more duplicated logic across platforms, where things are done very similarly, but not similarly enough that they can be translated into pure abstractions and only implemented once.

Finally, things as major as uninstallers can come back to haunt you in a big way. The Mac platform does not have an uninstall concept. There is no centralized location to uninstall programs. The majority of Mac software is set up so you just drag it to the Trash Can and it's gone. In fact, that's the behavior that Apple mandates in their usability guidelines. Personally, I find this to be a completely idiotic decision on Apple's part, but that's how it is, and it's a very painful fact of multi-platform life that Mac users don't have anywhere near the same grasp on the "uninstall" concept as Windows users. This kind of thing has to be taken into account, and it can have massive effects on your system architecture. If, as in my case, your architecture requires an uninstall due to low-level system interactions, it can put a lot of pressure on your user-experience design to make sure that the process makes sense and is accessible to all of your users.



At this point in history, platforms simply aren't interchangeable. Frankly, I hope it stays that way; as soon as platform differentiation goes away, we've lost something useful. If platforms cease to be differentiated meaningfully, then the platforms are no longer optimal, because at least one of them is doing more than it has to (exhibit A: cell phone OSes getting 3D graphics APIs). Since, inherently, different platforms will always be different in fundamental and potentially highly application-affecting ways, 100% write-once-run-anywhere is a pipe dream. Even more realistic concepts like single-package deployment are, in many cases, a lot more trouble than they are worth.

I'm working on disentangling myself from a multi-platform product. It has a Windows version, a Mac version, and a Linux edition that is used only in embedded scenarios internally. The product shares a fair bit of its platform-independent technology via a client-server architecture, and the rest is 100% per-platform. Each has a separate deployment path. I remain confident that it was the right thing to do, because it let the development team (read: me) focus on getting the implementation right on each platform, and not on trying to get a reusable, global, portable solution that I'd have to hack back apart and make platform-dependent at some point anyways.

And we've never had a single user who couldn't tell if they needed to download the Windows installer or the Mac installer.


So, again, call me cynical... but IMHO single-package deployment is little more than a mildly interesting academic exercise [smile]

At one point in time, I was working on something like this, but became distracted by wanting to actually produce games.

That said, there are a couple of differences between the platforms that ApochPIQ just covered, and it is difficult to find a neutral ground format to ship the installer in (Loki used to use shell scripts with compressed data inside them, this is probably portable). I think the market for cross-platform installers is probably suited very well by InstallAnywhere, but that is commercial software.

I would love to see a Free alternative to InstallAnywhere, especially since it would be free of Macrovision and their compatibility problems with everything.

Believe me when I say that I understand the enormity of the task that I have decided to undertake (or probably more correctly, I have an idea of the scale involved - it'll probably be much bigger that I imagine). But I believe that I have a good plan that should at least hopefully convince people that the task is feasible, even more appropriate in certain environments.

Quote:Originally posted by ApochPiQ
Execution Problems
MacOS has a cool little paradigm where the application is a folder, not a single binary file, and contains some metadata that can help the OS choose the right binary to run. This is a really cool concept, but it only ports across versions of MacOS, and even then it is fairly limited in its implementation. There is absolutely no similar corresponding paradigm in Windows or the *nixes as far as I know.

It is a lovely little system Apple has there, isn't it? Logically its great, everything to do with a program, put it in the same place and work on it from there. I had been intending to look into a way to make it so when the installation is run on Mac OS X, it could be an option in the development of the installer to write the file to one of these types of images. Unfortunatly, it looks like if I do decide to go that route, I'll have to join Apple Developer Connection to get the details on the DMG file format, as there doesn't appear to be any public specifications available.

Quote:A single package file has to be executable across all platforms with a single click from the user, and requiring no interaction on the user's part to choose the correct platform. This means that you need a way to bootstrap the installer on any platform that you are targetting, and that is a nontrivial problem to solve. Admittedly I haven't spend much time trying to find clever solutions, but the concepts I've got off the top of my head are unwiedly, unstable, and not portable to new hardware/OS versions.

There are two methods of execution that I am looking at. The first is as you suggest, the archived data with bootstrap code. However, as you suggest this will add the most overhead to the project, and to me just doesn't feel totally feasible.

The installer file format that I have more or less decided on borrows from existing, proven, working methods. The file downloaded itself will not contain any self executable code, but will rather just contain the data needed to make the program run, as well as instruction on what the tasks necessary to make it work are, be they creating files, altering settings, etc. This file is acted upon by a program that the user will have to have installed previously on their computer, much like MSI, RPM, etc. The difference between this and existing installer formats is that this downloaded file contains all the data necessary to install onto the platforms the developer has chosen to target.

Quote:Ideally we need cooperation between all OSes in running a single bootstrap format (in a perfect world, this would be based on a metadata scheme ala MacOS) but that will never happen because OS vendors see each other as competitors, and interoperability is not exactly Priority Number One.

This is why it might be easier at the moment to pander to Mac OS X and work around their methods until they become more accepted.

Quote:Sure, a third-party vendor could come along and build a bootstrapping technology very, very easily. In fact, it's a trivial problem; wouldn't take more than a few hours to get right and in a marketable state (think a brain-dead and self-executing version of ZIP files, with a bootstrapping aid running on each target computer). Unfortunately, this requires users to have the bootstrap aid technology, and introduces a chicken-egg market penetration problem that is very, very nontrivial.

Since the program would need to be installed, this is essentially the closest we will come to talking about a bootstrap.

This point is a concern of mine. All I can think of is that, like any new technology, it will just have to be aggressively marketed. Unfortunatly, MSI got something of an unfair jump on anyone trying to write something like this [grin]

Quote:Package Volume
A single-package installer must, by definition, contain all the assets from every supported platform. In some trivial cases you can get away with some highly portable data and this space is not a big concern. However, in most non-trivial applications, you will need a lot of platform-specific stuff, both code and data. Even heavy-handed hacks like writing a pcode compiler for binary portability (like Excel did) will help, but they have a huge cost. Basically, you have to spend a ton of effort up-front during development to achieve this, and it may or may not pan out. Even in the case of using a platform-independent data representation and a middle tier to convert to each platform on-the-fly, you have a technically complex layer that is prone to failure, and it costs development time.

For fat-media products, this isn't too big of a deal (indeed, for fat-media like CDs, you can very easily do per-platform installers and fake it to look like a single package). But the real use for single-package installers is thin-media redistribution, be it on USB flash drives, over the Web, or by carrier pigeon. In all of these cases, wasted media space is a bad thing. So you have to take the hit on the development effort, which (and I know from experience) might end up costing a lot more than it sounds like on the surface.

The network stub method is really the best answer to this; IMHO, that's the only way thin-media installs should be done anyways. However, it may not always be an option, and eventually someone will complain that they can't put the entire thing on a CD and reinstall it when they're in B.F.E. and the wireless connection drops out. Being able to rely on a fat pipe to deliver the installation data would really be extremely handy, but that's a luxury we don't have in the real world - yet.

Again, the method I have in mind takes all the necessary code into account, so I don't think I need to discuss this absolutely. The next journal entry on this topic will cover the file format that I have in mind (I still have a few niggling details that I want to work out).

One of the primary concerns that I have heard though, is that what I am talking about is effectively doubling the size of each installer that needs to be downloaded. Since I don't have working code to more accurately judge the actual numbers, I have been able to run some dirty tests using the writt

Well, a high-penetration bootstrap utility is probably the best bet for pulling this off, so more power to you [smile]

Just remember, your main market is programmers, not end users. If you haven't used InstallShield, I strongly recommend getting a license to examine how it works. The installation builder is fully scriptable (and I mean fully) and has an extremely potent script language and library. It also has a nice IDE that more or less tries to mimic Visual Studio, so it feels nice and familiar.

That kind of thing is going to be where you make your mark. MSI is indeed a long way ahead of any other initiative in this area, and platform independence alone won't make up the difference for you because platform independent deployment is not needed by the vast majority of software deployment scenarios at this time.

So the way to pull this off, tactically speaking, is to make sure your installer system would be extremely high-quality in its own right on Windows. Make it better than MSI, cheaper than InstallShield, etc. etc. Do some free licensing wherever possible to increase saturation of the bootstrap portion of the utility - say, make a free version with a prefab wizard-style installer and no scripting support, and charge developers $200 for the scripting system and full IDE. If you can outdo the existing giants in their own domain (and I fully believe this is possible with some thought and time), then you'll be poised to hit the big market, Windows. Making a mark in the Windows domain will get you the saturation you need to get the bootstrap system acceptably close to ubiquitous, and then you can flex the muscle of the multi-platform capability.


In short, multi-platform, single-package deployment is, in terms of all software, a relatively rare need. Make it a perk of a robust deployment system that can stand on its own, and you should be all set; those who need it will use your product because it will be one of the very few that can do it, and those who don't will use your product because it's just plain better than the others.