• Advertisement
Sign in to follow this  
  • entries
    53
  • comments
    56
  • views
    33665

Installer - #1 The Idea

Sign in to follow this  

385 views

I think it might be time to start getting some feedback on what I have in mind for my first major project, the Cross Platform Installer.

Some examples of such applications already exist in the form of Java JAR files with the application, as well as the installer runtime, bundled inside. This was the same route I took when I was developing the project in college, but quickly discovered that that was a somewhat less that efficient was of handling it.

The first time I wrote this document was over 2 years ago, and as time has gone on and the idea matured, surprisingly little has changed in it. All that has been edited are some implementation ideas, which have been kept back for another entry.

Much (to all) of what is here is already available in existing solutions, and I realise that other packages offer more. The overall difference is that it is designed to work not only on a single operating system, but on many.

I hope that at least some of you might take the time to comment on the ideas here, and perhaps offer additions or suggestions to the list.



The Cross Platform Installer

The Problem

The problem of modern cross-platform software installations affects both software developers and end-users of that software alike.
The impact of which is users of multi-format software are forced to download/purchase multiple copies of software installation files, each one designed for a different root system type (e.g. Windows, Linux, MacOS). Developers are forced to distribute multiple copies of files, versions of which for less popular formats can often be less than intuitive,

The Solution
A successful solution would utilize the ease of a Windows software installation and deliver a single, identical package capable of mimicking this standard across a variety of platforms, easing the installation process and, ultimately, benefiting the end-user. The developer would have a tool that would be capable of creating a single customizable package that could install their software on this variety of platforms, allowing them to apply specific instruction sets to the installation depending on the platform in question.

Feature List
-Familiar, intuitive interface Both the Install Creator and the Installer should have an intuitive, powerful interface. In particular, both should be built upon existing practises of desktop environments, allowing for a degree of familiarity to be apparent from the first use of the application.

-Powerful Command Line Interface The installer should also be able to cater for people who do not use a graphical environment. In this case, a set of equivalent CLI commands should be in place to allow for a similar installation experience. The CLI should follow accepted conventions for command line installations.

-Single file deployment All files regarding the installation are compacted into a single, self-extracting file. This method cuts on the overall size of the installer. Except the case of Network Stub Installation.

-Network Stub Installation Create small, easily downloaded packages that connect to a central resource holding the necessary files, and download and install via the network. Also allows repair functions to be carried out using the most up-to-date versions of files.

-Platform independence Multi-format installers will be capable of installing applications regardless of the platform, maintaining the same overall layout and ease of use.

-Platform biasing The developer is capable of creating an installation routine that will only run on a specified platform (e.g. either Windows or Linux, but not both.). This allows the developer to use the same tool for platform specific installations as platform independent installations.

-System configuration The installer should be capable of making changes or adding entries to system files necessary for the use of the application. These include Windows registry settings and changes to root system files.

-Permissions options Installations can be set to be blocked unless the current user has administration (Windows) or root (Linux) access on the machine.

-Full installation logging An option will exist for an installation to create a text document outlining all changes made to the users system.

-Installation Repair Allow an installation file to analyse individual files and values, and repair any files that do not match those in the installation file. This would allow for easy recovery in the event of installation corruption.

-Automatic uninstaller Separate application created by the installation process capable of rolling back all changes and removing all files created by the system.



Brainfart of the Hour: I wonder why all installers have traditionally been offered in wizard format, even when all you will be offered to change is the path of the installation? Only in corporate/enterprise deployment models is this pattern broken.
Sign in to follow this  


4 Comments


Recommended Comments

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]

Share this comment


Link to comment
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.

Share this comment


Link to comment
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

Share this comment


Link to comment
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.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement