Jesus 'n Jim
A mainly PC (some Mac) site w/Software, Computer Repair Info, How-To's on Using Computers
Technical Support 1-360-521-2060 (my business line cell)

 

Overview

I also highly recommend you learn to write installers. Installers are used in just about every windows app, and in some mac apps.

WHY write an installer?

Some people don't take the effort because it's too difficult for them to understand. You need to get past that and do some learning. If you want your app to be taken seriously, write an installer.

People who use WINE on linux and DarWINE on mac can also use things with installers (as long as they don't use cmd.exe or command.com).

Without an installer, stuffed in a zip file or a standalone exe, your app is considered a "portable app" according to software disrtributors. this makes it harder for average joe to use and is usually an immediate turn-off, because you have to add it to your PATH, or put it in a directory that is in your PATH, or make a shortcut to run it, etc, and it's messy to set up for average joe.

LISP folk

People who use LISP-like languages (scheme, etc.) are an interesting bunch.

they don't seem to want to learn to write an installer for their programs for some strange reason. they are used to LISP and everything they do is only in LISP. LISP programs to this date have never had an installer. Maybe I am wrong and some have broken out of their shell (pun intended). There is quite a number of real-world uses for LISP programs that have been written.

LISP-like programs, which have GUI parts but a TUI/console/terminal front end, or scheme, may be a script plugin in GIMP in plain source code form, or they may be a binary executable with the compiler built into it (I guess this is how it works and why LISP users like LISP so much). but has no installer.

PLEASE write one for your apps guys, the world is missing out on some great software.

"portable" apps

I will reiterate in case you jumped to this section: without an installer, stuffed in a zip file or a standalone exe, your app is considered a "portable app" according to software disrtributors. this makes it harder for average joe to use and is usually an immediate turn-off, because you have to add it to your PATH, or put it in a directory that is in your PATH, or make a shortcut to run it, etc, and it's messy to set up for average joe.

For those who wish to distribute their apps, "portable app" zip files should be distributed along with an installer separately, this way, the user has the choice of downloading and using either.

Some of these apps should be made available via installers for users who do not wish to fire off a cmd shell to run the thing!

3 kinds of windows installers to choose from

there are 3 kinds of popular Windows installers to choose from. MSI, Innosetup, and NSIS. tinker about with at least these 3 and find out what you like and works best for you. There are other installers that are multi-platform (see last link in list).

how to distribute

I will reiterate in case you jumped to this section: for those who wish to distribute their apps, "portable app" zip files should be distributed along with an installer separately, this way, the user has the choice of downloading and using either.

DON'T put the resulting compiled installer executable in a zip file or any other archive! it's already compressed, and it's a hassle!

distributing software on .ISO cd images

for .ISO cd image distributions, (a different kind of archive, this is OK to put your installer into), if it's a windows installer, make sure you include an autorun.inf file in the root directory which contains the following:

[autorun]
OPEN=\SEMI-ABSOLUTE\PATH\TO\somefile-setup.exe

or, if you want to specify a relative path, and your setup.exe is in the root directory of the ISO,

[autorun]
OPEN=setup.exe

Neither path should include a drive name like D: or E: or F: since

  • you don't know what drive letter the user is going to have on their machine
  • they may put this image in an optical drive emulator (I forget what those are called, but it serves up the cd image as a new drive letter)
  • they may have different drive assignments because they have more then 1 hard drive, so what is D: on your box id F: on theirs...
  • they may have more than 1 optical drive and *you* don't know which one they picked, this may be a jukebox, duplicator, or autochanger...

You should know that Windows' AutoInsert/AutoRun if it is enabled for that drive (usually is) automatically sets the current drive to the optical drive which has your disc in it. Worst case is they have to run the setup program manually and they already know that for their machine.

If you are distributing for multiplatform, you should know that *NIX and Mac do not have any AutoInsert/AutoRun ability. Only Windows does. so be sure to incloude the autorun.inf file. the line endings for this file are cr+lf,so you will have to edit using Notepad++ (a very decent programmer's editor for windows that runs on WINE and DarWINE) or convert using the unix utility that ends like 2dos or todos or something similar. *NIX and Mac line endings are plain lf.

The macintosh typically distributes installers, .dmg hard disk image files, .tar.bz2/.tar.gz tarballs, .zip files, .sit stuffit expander compressed files (great compression by the way for any type of file, including pix and available for windows too), .hqx binhex format files.

*NIX distributes files in quite a few different formats. many kinds of tarballs, .rpm packages, .deb packages, and I am sure I am missing quite a few here.

list of installers

what are they like to program?

INNOSetup and NSIS are 2 choices, and if you don't like one, you usually like the other.

NSIS is like coding in assembly language - sort of, but with sections. it's not quite that bad, actually, at least I think so.

I could never quite grasp INNOSetup's way of doing things, but I am starting to understand - Innosetup is basically like a large .ini file. most people choose innosetup because you just put in a list of files you can get from a dir/s/b command, list of language strings in a suructured way, and you are pretty much done.

MSI is XML based. nearly everything is xml-based these days.

considerations/questions to ask yourself

  • What method do you prefer for programming your installer?
    • data file: XML(MSI)
    • data file: .ini(innosetup)
    • assembler coding (nsis)
    ?
  • Programs these days are considered good if they automatically update themselves over the internet.
    1. can you apply updates with this installer?
    2. how do you plan on doing that?
    3. what will you do about differences in file structure as time goes on, such as new files and old ones needing to be removed, and what about the shortcuts?
    4. is there a brute-force way of doing updates that works for everything? how about updating the updater/downloader?
  • What program do you plan on using (cURL?) for downloading updates/files off the internet? is there a facility built into the installer program, or a module/dll/plugin you can use which adds that functionality? do your research.
  • do you plan on enabling the feature where the installer includes files you specify into itself as a built-in archive into the monolithic, single, all-encompassing setup.exe (or whatever you name it) it generates? some installers can't handle more than 2GB worth of files (NSIS is one of those), possibly because the installer itself is 32-bit, and must run on windows 98, etc (but there are ways around that if they wanted to).
  • do you plan on using a Microsoft Visual Studio compiler? if so, you must use the just-above-mentioned feature to include your whole product in that one installer. hope it's not too big.