Quick Guide to Installers

Introduction

Watch out for Windows File Protection (WFP): Does Windows say anything when an older installer tries to update a system component, or does it silently reinstall its version?

Some tips:

MSI vs. EXE Installers

From: Gavin Lambert <iss@mirality.co.nz>
 
MSI:
 
   pro:
     sanctioned by Microsoft
     supports "broadcast" installations over network
     supports on-demand or "advertised" installations
 
   con:
     fairly awful tools
     database driven
     bloody hard to get to actually work correctly
     frequently decides to randomly reinstall itself and annoy users
 
EXE: (in general, not just Inno)
 
   pro:
     self-contained, no additional stuff necessary
     works on older versions of Windows
     usually easier to "get into"
     script driven
     more consistent results
     *sometimes* decent tools (I class Inno as having excellent tools) :)
 
   con:
     not sanctioned by Microsoft
     sometimes bad or sparse tools
     if closed-source, might lose support and no longer be updated
     can't be used for "broadcast" or "advertised" installs (except by wrapping with an MSI)

NSIS

HM NIS Edit

NSIS Workbench - FNSIS

Venis IX

PimpBot

GUI for NSIS

Atomic GUI

Mihov NSIS Helper

Inno Setup

Setup2Go

"Setup2GO is is a tool for designing full-featured, 32-bit Windows Software Setup solutions in seconds. Setup2GO supports all 32-bit Windows versions in use today - Windows 95, 98, ME, NT4, 2000, XP."

Instyler

http://www.instyler.com

SmartSetup

Ex-it!

InstallJammer

InstallBase

Web Update Wizard

Agentix AGInstaller

Chief's Installer Pro

IncUpdate

Setup Specialist

FileStream InstallConstruct

SetupStream

CreateInstall

Setup Generator

Ghost Installer Studio

Proggle Installer/GD

AWInstall

Caphyon Advance Installer

DeployMaster 2.6.2

Installer2Go

AGInstaller 1.09

Stardust Setup Packager

GPP Software Setup Builder

LizaJet Installer

Thraex Astrum InstallWizard

Ondemande Software

Advanced Installer

Gammadyne SEAU

EZInstall

TinySetup

Bitrock

VAI

Myncos CBInstaller

Dacris ActiSetup

Tarma Installer

Here's how to create an empty directory:

[Project - Files page] QuickInstall only creates a directory when the first file or subdirectory in it is created. Therefore, you cannot create a truly empty directory.

The recommended way to create an "empty" directory is to add an empty (0-bytes) file to the directory on the Project - Files page and mark it Hidden. The directory will be created when that file is installed, and removed when the file is deleted (and the directory is empty).

[Advanced - Actions page] You can create directories here as well if you use the following action settings:

- Target path: <%ComSpec>
- Arguments: /c mkdir "<ProgGroupDir>\SomeEmptyDir"
- Run options: Synchronous, NOT ShellExecute
- Run program: Hidden

Others as per default. Place this action (using Ctrl+Up and Ctrl+Down) after "Install: Shortcut installation" because that action will create the <ProgGroupDir> parent directory.

In this case, you will have to add a similar RMDIR action to clean up the directory during uninstallation; place that one just before "Uninstall: Shortcut removal". The directory must be empty at that point; if necessary use a

- Arguments: /c DEL /y "<ProgGroupDir>\SomeEmptyDir\*.*"

...action to clean up.

Tips:

  1. To avoid filling the Project > Project Identification parts manually, add the main EXE of your application in Project > Files > AppFolder, then go back to Project > Project Identification, check "Link to main executable", select the EXE: Voilą, Tarma fills the fields automagically
  2. To select the default application target directory, open the Installation tab, and fill the "Application folder" item. Absolute targets are not recommended; You should use eg. <ProgramFiles>\<AppTitle> instead. If you chose an absolute target, eg. C:\MYDIR, as the destination folder, go to the Build section, and uncheck "Treat warnings as errors"; Otherwise, Tarma will fail building the installer as it doesn't recommend using absolute paths
  3. (Pro version only) To select a language other than English, go to Installation > Languages, check "Multilingual support", and select which languages the installer should support. Then, go to the Build section, and select "Build Pro Installer" (Tarma should really check this automatically when the user has selected any option that is only available in the Pro version...)
  4. To have the installer create extra directories during its process, just create an empty folder in Files section
  5. To tell Tarma where to create the installer and under which name, go to the Build section, and fill the "Single Exe" item
  6. To run Tarma from the command-line to build an installer, path\tin  /build  myproject.tin
  7. To tell Tarma to generate a multi-part installer that fits on a floppy,
  8. To create a link to an EXE in the Startup directory, use <Startup> to create a link for All Users, and use <@<ShellFoldersCU>\Startup> to create a link for the user currently logged on

Bugs:

Quick Install Maker Pro

GVH Setup Maker

VB's PDW

Microsoft's MSI

Wise

As fat and ugly as InstallShield?

INF Tool

InstallShield

Setup Factory

GKSetup

Linder SetupBuilder

QSetup

Resources

Temp Stuff

COMCTL32.DLL: http://www.microsoft.com/permission/copyrgt/cop-soft.htm#COM

Beware of the file list that is created using the VB setup wizard (or come to that the Visual Studio installer) as both tend to add files that should not be distributed. If you have used any API calls in your VB program these will include the dll'd for those API calls and could well crash the users machine big time rewquiring a reinstall of the operating system if you include them in your installation kit. One example is wininet.dll another as stated is MSVCRT40.DLL.

For a vb install you need to include the VB runtimes and any other files identified within the VB development under Project > Components. Highlight any boxes ticked and read the corresponding OCX/DLL. These together with the VB runtimes ARE THE ONLY FILES YOU NEED TO AND SHOULD DISTRIBUTE with your application data and exe file(s). The VB development program will not let you select any components under Project > Components that you are not allowed to distribute (if you can't tivk it - you can't distribute it)

> Some files are version dependent, eg CTL3D32.DLL has different versions for Win NT and 9x I understand. The Crystal Reports runtime has at least one such file as well. Can Inno Setup conditionally install these depending on the target os? Yes, using a MinVersion parameter. See the Common Parameters help topic.

Example: [Files]

Source: "9xonlyfile.dll"; DestDir: "{app}"; MinVersion: "1,0"

Source: "ntonlyfile.dll"; DestDir: "{app}"; MinVersion: "0,1"

Let me see if I can explain this understandably. Before VB5 projects were compiled into "p-code" or pseudocode. That is, they weren't true executables like C/C++ or Pascal:o) programs. They required a "virtual machine" to run. That virtual machine is what we know to be runtime files. The runtime files were basically the same as running your application in the VB IDE. However, in VB5 this changed, you could control how your project was compiled, p-code or native code. If you don't want to mess with runtime files then follow these directions.

-Go to "Project" menu

-Select "<projectname> Properties"

-Select the "Compile" tab

-Select "Compile to Native Code"

-Select Optimization Options This will create a true executable like in C/C++ or Pascal, and you don't have to worry about installing runtime files with your application. If you're worried about bloated code, choose "Optimize for Small Code" Also, compiling to Native code will run faster than p-code, you can also increase the speed by Optimizing for Fast Code. If you're a game programmer, then you can utilize MMX instructions by selecting "Favor Pentium Pro(tm)" I'm not sure how accurate these are, I'm making educated guesses as to what the optimizations mean I haven't had a chance to test some of the optimizations yet. This information came from The Waite Groups Visual Basic 6 Superbible

You're right about the "old" cd's. But I could give you many examples of files that are located in a certain computer's \Windows\System directory, that won't run on each version of Windows. For example, COMCAT.DLL version 5.0 has been installed on my computer, running Win98. But this DLL file won't work on a Windows NT computer. But version 4.xx of the file, which is included on the Visual Studio CD's WILL work on Win9x. So if I would use the COMCAT.DLL file from my \Windows\System directory, my setups wouldn't work on a Windows NT computer. A WinNT pc probably won't even start again after updating the COMCAT.DLL file. I recommend this: get the files you need (see Jordan's page for info on which files you need) from the CD and put them in a new, empty directory on your HD. Then download the latest service pack (3), and extract the newer files from it with a program like WinZip, and overwrite the files in the new directory. You should then use the files from that directory to distribute your programs. I have had many problems installing my program on different programs, until I followed the procedure above. From then on (and after using Inno Setup of course), I have had no problems anymore.

You need to know what files should be pulled from "where."

I've been doing some research on this to see WHERE the VB P&D lizard pulls its "core" files from.

First, a bit of back-track. You CAN install VB6 so that you don't have a KITFILES32 folder. And I'm not even sure that the VB stand-alone product (as opposed to the entire Visual Studio) even has such an install feature. But I believe that one of the options is to be able to create you own custom installs instead of using the P&D. Anyway, on my personal install, I don't have any such folder... I don't have Video Studio, just the standalone VB 6.0 product.

What I do have is: C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist which contains:

I looked through a number of P&D Lists that were output by the wizzard to see what files were taken from where. It seems that the only two CRITICAL files are COMCAT.DLL and MSVCRT40.DLL. These are always sourced from the above directory. However, the others like OLEPRO32.DLL, OLEAUT32.DLL etc. are always taken from WinSys.

Perhaps if I tried to re-install of VB it might create another "redist" folder and there might be more "stuff" in it, but I'm not going to take a chance of screwing up my development machine by doing a re-install of VB, SP3, and Mdac. However, I have modifed my Inno script to pull COMCAT and MSVCRT40 from the VB "redist" folder. Indeed, I have heard from other sources that a Win98 COMCAT.DLL from WinSys can totally trash an NT box.I always wondered why the InstallShieldExpress came with their own versions of comcat and msvcrt40 in a "redist" folder. And I noticed that ISX alwasys pulls these files from its "redist" folder. What is interesting is that while it comes with its own version of OLEPRO32, it does not use it. It's "wizzard" pulls it from WindowsSys, as does the P&D Lizard.

I would think that if OLE... were "critical" files that they also would be in the P&D  "redist" folder.

Can anyone tell me if I can "add" to the VB install so that I have a "full" install... or do I have to uninstall first (No way, Jose!!!) I hope this helps someone out there.

Because the early (pre SP2) versions of the VB 6 Package and Deploy Wizard were so full of bugs, many people on the VB news groups started calling it the "Package and Destroy Lizard" and the name sort of stuck. The SP3 version is a lot better but still has some quirks, mostly relating to what versions of Jet it pulls in as well as some weirdness dealing with Mdac files and some 3rd party ocx files. It also has one of the worst interfaces of any MS program ever written (I personally believe it was written outside of MS and sold to them.) Because of this, most people use it just to create the .lst file, which they use to create scripts for better install programs (like Wise, Inno, etc.)

But the P&D Lizard's bugginess was outdone by InstallShieldExpress's VB Wizard. It would go out and pull in COMDLG32.DLL and one other DLL, both of which should never be distributed because the wrong version can destroy an NT box. Everyone and their dog was really excited when ISE came out with their VB Wiz until they found out how buggy it was (and still is!!). People (or should I say idiots like me) paid $350 for a tool that would make a VB install with zero effort. When we found that it didn't work and that we had to manually add our own files people left ISX in droves for Wise, which I'm told is now the primo install tool. I came to Inno because I like the "script" method. I'm an old person, been programming since 1973 (but still not too good at it :-)), and am used to tools where you write a "script" to make it work (IEBGENNR, IEBPRTPCH, WAAPDSUT, IEBDG etc.) While drag and drop is cool, I like to SEE what the output is and have "control" over it. Inno does this for me. Of course Wise would also, but to get the version that makes a script you have to pay something like $500. As I remember, Inno cost me a lot less than that :-)

The only two things I don't like about Inno is that 1. I can't easily set up a file association between .iss and the compil32.exe so that I could open Inno by clicking on an iss script and 2. when I re-install an app, I get another version of uninstall.xxx. But like I said, the price was right, the support is good, and the community is helpful. Why Jordan doesn't charge a fair price for this is way, way beyond my intellectual abilities... but I'm old and don't have many brain cells left.