Installation Scripts: Guidelines for Developers at MIT

Software distribution, version control, and installation are three related but different components of software dissemination. In this document, we are concerned with the third component, and we list guidelines for writing installation scripts for MIT-developed software for Windows-based machines and Macintoshes.

I. Recommended tools

For PC/Windows, the recommended tool for building installation scripts is Wise Installation System from Great Lakes Business Solutions. The tool creates and edits Windows Self-Installing Executables, and it can use a complex installation script to conditionally install software components and edit configuration files. MIT does not have a site-license for this tool, but it can be purchased for $199 for each machine used to generate installers. The resulting installers can be distributed and used on any number of machines without additional licensing fees or royalties. Wise Installation System can be ordered from Great Lakes Business Solutions at 1-800-554-8565 (see also their web page ).

For the Macintosh the recommended tool is being reexamined. MIT currently has a site license for InstallerMaker from Alladin Systems. This is a simple tool for creating turnkey installers, which can be used for the installation of MIT-written programs as well as commercial infrastructure components. DCNS has been examining another installation tool for the Macintosh, VISE from MindVision, which has some important capabilities that InstallerMaker lacks. (These functions are [1] the ability to create a log of everything that was done to the system by the installer and [2] the ability to remove or delete incompatible or obsolete files.) It is expected that within the next month or two MIT will negotiate a site license with MindVision for institute use of this product.

In some cases, it may be desirable to separate the files to be installed from the installer and have the installer FTP the needed files during the installation procedure. Additional tools are needed to accomplish this. Developers should contact dosdev@mit.edu or macdev@mit.edu to get the latest information on these extensions.

II. Guidelines for installation scripts

• The installed components of an application should be installed in a way that makes it easy to keep them separate from other software. This should facilitate upgrading or deinstalling them later. One good way of "partitioning" the components of an application would be to install all of them into the application's own directory or hierarchy of directories. If there is a reason to install into multiple root directories or to put components in existing directories, this should be well-documented and be accommodated by an uninstaller.
• Give the user the option of erasing old versions of the application. Allow the user to keep an old version of the application in a different directory if he chooses. If this is not technically feasible or strongly discouraged it should be well documented in the installer and elsewhere.
• Check to make sure there is enough room on the hard disk before starting an installation.
• Determine minimum system configuration to run the application and check it before proceeding with the installation. You might check for the amount of RAM, operating system level, or hardware, e.g., PowerMac vs. 68K.
• Often, an application depends on another software component, such as SQL*Net. At minimum, the installer for such an application should include documentation listing software dependencies, or verify them automatically. Many users would appreciate having the installer allow them (at their option) to request the installation of prerequisite software components without manually running additional installation scripts. If the installer provides this option, care must be taken to avoid having inconsistent versions of software installed by different scripts. The Wise package provides a way of reusing scripts, and this would be a good way of handling scripts for dependent software pieces. The writers of installation scripts should coordinate their efforts if more than one installation script indirectly or directly handles the same prerequisite software component.
• Be aware that overwriting existing files used by more than one application may impact another application. For example, replacing a DLL shared by more than one application may have an adverse affect. In this case, the installer should at a minimum notify the user and ask if a backup of the older file should be preserved on the system. The TNSNames file (a list of databases used by SQL*Net) is another example of a shared file where one application's installation could break another application. The use of FTP to install the newest MIT-standard version of such a file, rather than bundling it with an installation script that might go out of date, is a possible solution.
• Plan for cleanup/deinstallation if things don't work. Maintain a log of components installed to facilitate later trouble-shooting or deinstallation.
• Developers of installers should also remain compliant with the current requirements from OS vendors. Watch this space for more details.