^{INSTALLSHIELD 5.1}

_{[Written By SENTHIL KUMAR P ]}

     a software  installation development system using world-renowned InstallShield
     technology in an easy-to-use Installation Development Environment (IDE).
     InstallShield 5.1 Professional Edition gives you the features and
     functionality to author, lay out, build and test bulletproof, professional
     setups with point-and-click ease.

•  Windows 95 or Windows NT 4.0 (Intel) operating system
•   Pentium-class PC
•  32 megabytes of RAM
•  50 megabytes of free disk space
•  Super VGA monitor

The bottom line in any setup is the transfer of files to the target system. Application files naturally fall into groups with similar characteristics: system DLLs, application executable files, help files, and so on. Any such group of files is a candidate for becoming a file group.

File groups are comprised of files with similar characteristics, such as purpose/function, shared or not shared, potentially locked or not locked, compressed or uncompressed, target platform operating system the files support, and languages. It may be useful to think of files and file groups as your (setup author) view of the application.

Scripts

InstallShield's Integrated Development Environment (IDE) includes the InstallShield Script Editor, a full-fledged text editor that supports bookmarks, line markers, syntax coloring, and all the editing commands common to Windows-based text editors.

Syntax coloring

In the Script Editor, keywords, predefined constants, InstallShield function names, and other InstallScript identifiers are color-coded to assist you in identifying InstallScript language elements and to improve readability.
Script editing commands
The Script Editor uses a powerful array of standard text editor navigation and editing commands. The Script Editor supports find, search and replace, columnar text selection, line markers , and bookmarks , just to name a few.

Components

 Components and subcomponents give you almost limitless flexibility to package your application and related software accessories for setup. It may be useful to think of components and subcomponents as your customer's view of your application.
If your setup installs a suite of products, you can make each product in the suite a component: for example, Word Processor, Spreadsheet Program, Database Program, and Drawing Program. Each component (product) could then have subcomponents allowing the user to install optional pieces of the program: help files, tutorials, optional support files such as graphics libraries, and so on. With InstallShield, you are free to take advantage of the component-subcomponent relationship to achieve any setup configuration you desire.

Resources

Lets you add, view, or modify comment text associated with the active shell object (the shell object selected in the Resources pane). This text is not included in the final file media library; it is for your reference during the setup creation process.

Displays a tree control for setup resources: string resources, registry entries, and shell objects (folders/groups and shortcuts/icons).
 

•  String resources
Clicking a string table's icon opens the String Table window, in which you can view and modify the contents of that string table.
•   Registry entries
Right-clicking the Registry Entries folder opens a popup menu from which you can create a new registry set. Clicking a registry set icon opens the Registry Entries window, in which you can view and modify the keys and values in that registry set.
• Shell objects
Right-clicking the icon of a predefined shell object (folder, group, or Program Manager Shell) opens a popup menu from which you can create a new folder or shortcut (under the Explorer Shell) or group or icon (under the Program Manager Shell). Clicking the icon of a folder or group (or shortcut or icon) opens the Folders window (or the Shortcuts window), in which you can view and modify the properties of that folder or group (or shortcut or icon).

The name of a setup resource must not contain any characters that are invalid in folder names. Under the Explorer shell, invalid characters are the following:
\ / : * ? " < > |

Setup Types

InstallShield provides a number of dialog boxes you can use to display setup types for your end user and then return those selections to the setup script.

You must always define at least one setup type for your project in the InstallShield IDE.It is recommended that you offer your end user a choice of setup types.  In order for the component dialogs to correctly display the component choices that you defined in the IDE, there must already be a default setup type selected.  If you do not display one of the setup type dialogs to let your end user select the setup type, then you must call the ComponentSetupTypeSet function to set a default setup type before displaying a component dialog.

If you defined only the standard Typical, Compact, and Custom setup types for your file media library, then call the SetupType or SdSetupType function. These dialogs automatically display these setup types and return the end user's selection to your setup script. They also automate component selection—if the end user selects a setup type, then all the components under that setup type are selected.

However, if you defined setup types beyond Typical, Compact, and Custom, you must call the SdSetupTypeEx function to display all your setup types and return the end user's selection.

If you use the setup script generated by the Project Wizard and chose the Setup Type option in the Project Wizard - Choose Dialogs panel, setup type display and handling is already done for you.
Let's suppose you had created these setup types in the InstallShield IDE:  Typical, Compact, and Custom. Call the SdSetupTypeEx function at the point in your script when you want to offer your end user a choice of setup types to install. The following code displays a dialog box with Typical as the default setup type selection:

   szTitle     = "Choose Setup Type";
   szMsg       = "Highlight the setup type you wish to install," +
                 " then click Next.";
   svSetupType = "Typical";

   SdSetupTypeEx (szTitle, szMsg, "", svSetupType, 0);
Assuming that the end user selected a Typical or Compact setup type, you can proceed to call the ComponentMoveData function to install the files associated with that setup type. If the end user selected a Custom setup type, display a component dialog box at this point to allow component selection.

This system variable stores the name of the current media libary or script-created component set. During setup initialization, MEDIA is assigned the value of 'DATA', which corresponds to the DATAx.cab file that was created by the media build. If you change the value of this system variable to refer to a script-created component set, you must change the value back to 'DATA' before calling ComponentMoveData, CreateShellObjects, or CreateRegistrySet.

Registry

    Creating Windows setup programs is becoming increasingly complex. Invariably, you will have to create, modify, or read registry entries to integrate your application with others, associate file extensions, map file dependencies, modify environment variables, and so on. InstallShield makes it easy for you, providing almost 20 functions that can write, read, modify, and delete registry entries, even functions for connecting to a remote registry on a network system. You can also create registry entries from the InstallShield IDE.

This section gives an overview of the Windows registry and explains some of the differences between the 32-bit registry and the 16-bit registration database. Even if you are already familiar with these issues, this material will help you find out more about how the InstallScript registry-related functions handle different platforms, work under different root keys, and get logged for uninstallation. You will also find important information on how InstallShield handles reference counts for shared files.
 

• The 32-bit registry
• The 16-bit registration database
• The registry: 16- vs. 32-bit

 
In addition, you need to be aware of some unique characteristics of the InstallScript registry-related functions. InstallShield provides three types of registry-related functions in order to make it easier for you to perform certain setup tasks.

Special registry-related

Work only with certain predefined 32-bit registry keys. (Each is designed for a special purpose under that particular key.)
General registry-related functions
Work with all 32-bit registry keys, including those handled by the special registry-related functions. The general registry-related functions also work with the 16-bit registration database. (There are some restrictions on how some general registry-related functions work with keys handled by the special registry-related functions. Refer to the individual function descriptions for details.)
Remote registry functions
Open and close a connection to a remote registry. (Once you have connected to the remote registry, you can only edit keys and values under either HKEY_LOCAL_MACHINE or HKEY_USERS.)

The 32-bit registry

The registry is a database containing system- and application-related information on Windows 95 and Windows NT systems. The registry stores all kinds of information, including the following:
 
•  The name of the program associated with a given file extension
 
•  The command line expression to be executed when the user opens a file from a shell application
 
•  Application information such as company name, product name, and version number
 
•  Uninstallation information allowing your application to be uninstalled easily without interfering with other software on the system
 
•  The registry also makes it possible to integrate other applications that use OLE (Object Linking and Embedding). The database was designed to allow applications to share specific information.
 
•  Path information allowing your application to run
The registry in Windows 95 and Windows NT consists of several database files. The registry is depicted as a tree structure, much as the Windows File Manager or Windows 95 Explorer represents a file system.
The registry tree structure is similar to the paths on a PC file system, representing unique access pathways to system- and application-related information. A registry key is similar to a file on a PC file system, identifying a unique location for storing information.

Windows 3.1 does not have a registry. Rather, it has a registration database containing one key structure: HKEY_CLASSES_ROOT. The vast majority of system-, user-, and application-related information in Windows 3.1 is stored in .ini and .sys files.

The base keys

The registry consists of a set of keys arranged hierarchically under the My Computer root key. Just under the root key are the four base keys that can be affected by a setup: HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_USER, and HKEY_CLASSES_ROOT

My Computer
      HKEY_LOCAL_MACHINE
      HKEY_USERS
      HKEY_CURRENT_USER
      HKEY_CLASSES_ROOT

Windows 95 contains two base keys in addition to these four: HKEY_CURRENT_CONFIG and HKEY_DYN_DATA. Since these keys are not typically affected by setups, they are not discussed here.
The terms "key" and "subkey" are relative. In the registry, a key that is "below" another key can be referred to as a subkey or as a key, depending on how you wish to refer to it relative to another key in the registry hierarchy. The term "subkey" will not be used in this document unless a key's position relative to a higher-level key is important and needs to be expressed.

Keys, value names, and values

A key is a named location in the registry. A key can contain a subkey, a value name and value pair, and a default (unnamed) value.
A value name and value pair is a two-part data structure under a key. A value name identifies a value for storage under a key. A value is the data associated with a value name. When a value name is unspecified for a value, that value is the default value for that key. There can be only one default (unnamed) value under a key. For example, here is a sample key, a default (unnamed) value, and a named value, and a subkey:

My Computer
    HKEY_LOCAL_MACHINE
        KEY1
            [Default] = VALUE1
            [ValueName] = VALUE2
            KEY2

Registry keys and their values are expressed in the following format, similar to the way paths are expressed:
HKEY_LOCAL_MACHINE\KEY1
      [Default] = VALUE1
      [ValueName] = VALUE2

Keys are separated by backslashes (\). Value name and value pairs are entered underneath the entire key expression. The value name is on the left side of the equal sign and the value is on the right.

The 16-bit registration database

Windows 95 and Windows NT both have full 32-bit registries in which applications store information. The registry is composed of several root-level keys with many additional keys under each root-level key. The Windows 95/NT 32-bit registry and the Windows 3.1 16-bit registration database have the root-level key HKEY_CLASSES_ROOT in common.

Windows 3.1 has a 16-bit registration database, which is composed of a default root key and many multiple subkeys under it. The registration database is used mainly to store file, application, and library registration information.

The 16-bit registration database and 32-bit registry also differ slightly in structure. The 32-bit registry allows each key to have a set of name-value pairs associated with it. The 16-bit registration database will store only one value per key. For purposes of compatibility, the 32-bit registry also has a default value for each key, corresponding to the 16-bit registration database's single value.

Viewing the registration database

To view the 16-bit registration database, from the Program Manager, open the File menu and choose Run. Enter regedit /v and click OK. The Registration Info Editor will open, displaying the contents of the 16-bit registration database.

The registry: 16- vs. 32-bit

Windows 95 and Windows NT both have full 32-bit registries in which applications store information. The registry is composed of several root-level keys with many additional keys under each root-level key. The 32-bit Windows 95/NT registry and the Windows 3.1 16-bit registration database have the root-level key HKEY_CLASSES_ROOT in common.
Windows 3.1 has a 16-bit registration database, which is composed of a default root key and many multiple subkeys under it. The registration database is used mainly to store file registration and OLE information, so most applications do not need to modify this database during setup.

The 16-bit registration database and 32-bit registry also differ slightly in structure. The 32-bit registry allows each key to have a set of name-value pairs associated with it. The 16-bit registration database will only store one value per key. For purposes of compatibility, the 32-bit registry also has a default value for each key, corresponding to the 16-bit registration database's single value.

Registry-related functions

InstallShield has two types of registry-related functions—special and general.
The special registry-related functions modify specific keys located under HKEY_LOCAL_MACHINE and can only be used to modify the 32-bit registry, because the 16-bit registration database does not have a KEY_LOCAL_MACHINE key. Therefore, special registry-related functions will work only under Windows 95 or Window NT.
The general registry-related functions are designed to work with all registry keys, including those handled by the special registry-related functions. These functions can affect any key in the 32-bit registry or 16-bit registration database, but general registry-related functions can only work with keys under HKEY_CLASSES_ROOT in the 16-bit registration database.

The InstallShield engine under 16- and 32-bit platforms

The InstallScript registry-related functions work differently depending upon which platform you're targeting. You choose which platform you're targeting in the Media Build Wizard - Platforms panel. Be very careful to consider all platforms on which your setup will run when selecting a target platform.
The platform you choose to target determines which InstallShield engine file you ship with your setup. InstallShield automatically creates a setup with the correct engine file(s) when you build your setup through the Media Build Wizard. _inst16.ex_ is the 16-bit InstallShield engine file, and _inst32
x.ex_ is the 32-bit InstallShield engine file (x is short for the specific 32-bit Windows platform you're targeting).

Depending on how you build your setup, which InstallScript registry-related functions you call, and the target platform, you will have one of the scenarios listed below. Since the 16- and 32-bit InstallShield engine files behave differently and the 32-bit registry and 16-bit registration database are different, there are a number of considerations when calling registry-related functions. You will have no problems if your setup will always run on the expected platforms, or if you write your setup script appropriately for a cross-platform setup, calling registry-related functions based upon the target platform.

Special registry-related functions

    The special registry-related functions are designed to make it easier for script writers to set up the minimum required 32-bit registry keys and values. The special registry-related functions work only with the per application paths key, the application uninstallation key, or the application information key, as shown below. Refer to the individual function descriptions for more details.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\<per application paths key>

The per application paths key, or App Paths key, stores path information enabling 32-bit Windows to find your application's executable files.

InstallationInfo
Provides the name of the application executable file, which is used to create the per application paths key. The key is not created until RegDBSetItem is called (see below).

RegDBGetItem
Retrieves the value of [Path] or of [DefaultPath] under the per applications path key.

RegDBSetItem
Results in the creation of the per application paths key, and sets the value of [Path] or of [DefaultPath] under that key.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\<application
uninstallation key>

The application uninstallation key stores information enabling uninstallation functionality.

DeinstallStart
Creates the application uninstallation key and sets the [UninstallString] value under that key.

RegDBGetItem
Retrieves the value of [DisplayName] under the application uninstallation key.

RegDBSetItem
Sets the value of [DisplayName] (the name displayed in the Add/Remove Programs window) under the application uninstallation key.

HKEY_LOCAL_MACHINE\Software\<company key>\<product key>\<version key>

Your setup program should create an application information key for each application it installs. The application information key stores information about the application. Windows 3.1 uses .ini files to store such information. Windows 95 and Windows NT use the application information key.

HKEY_LOCAL_MACHINE\Software\<company key>\<product key>\<version key> is collectively known as the application information key. Keys and values created under the \<version key> key are said to be created under the application information key.

InstallationInfo
Uses company name, product name, and product version number to create the keys that together are referred to as the application information key. No values are set under the key until you call the RegDBSetAppInfo function (see below).

RegDBGetAppInfo
Retrieves a value from under the application information key.

RegDBSetAppInfo
Sets a value under the application information key.

General registry-related functions

The general registry-related functions work with any registry key you specify, including the predefined keys handled by the special registry-related functions. These functions also work with the 16-bit registration database

RegDBCreateKeyEx
Creates a key in the registry. Also allows you to associate a class object with a registry key (advanced users only).

RegDBDeleteKey
Deletes the specified key from the registry.

RegDBDeleteValue
Deletes a value from a specified registry key.

RegDBGetKeyValueEx
Retrieves a value from under a key in the registry.

RegDBKeyExist
Checks if a key exists.

RegDBQueryKey
Queries a key for its subkeys and value names.

RegDBSetDefaultRoot
Sets the root key.

RegDBSetKeyValueEx
Sets registry entries.

unInstallShield will uninstall all keys under any key that is logged for uninstallation. Keys created automatically by InstallShield and keys created as a result of calling InstallationInfo and DeinstallStart are logged for uninstallation. When you call RegDBSetKeyValueEx to create keys above which there are no keys logged for uninstallation, your keys will not be uninstalled by unInstallShield, regardless of whether logging was enabled or not (you can Enable and Disable logging). However, when you call RegDBCreateKeyEx while logging is enabled to create a key above which there are no keys logged for uninstallation, your key will be logged for uninstallation. Any keys you create under the logged key will be uninstalled when the logged key is uninstalled.

Remote registry functions

These registry-related functions give you access to a remote registry, where you can create, delete, or retrieve registry keys, value names, and value pairs much as you would on a local registry.

RegDBConnectRegistry
Opens a connection to a remote registry.

RegDBDisConnectRegistry
Closes the connection to a remote registry.

These functions are intended for system administrators for network installations. If you are trying to open a registry on a remote Windows NT system, you must have administrator privileges. If you are trying to open a registry on a remote Windows 95 system, it must already have Remote Administration enabled.
When you access a remote registry with RegDBConnectRegistry, you can read and change keys and values only under HKEY_LOCAL_MACHINE and HKEY_USERS. When you call RegDBConnectRegistry, you must specify which root key you want to be able to edit. You must close and re-open the connection if you want to edit the other root key or one its subkeys. Also remember that you can only call the general registry-related functions to edit these keys and subkeys.

Since you set the root key by calling RegDBConnectRegistry, you cannot call RegDBSetDefaultRoot once you have established a connection to a remote registry. Once you have called RegDBDisConnectRegistry, all calls to registry-related functions will affect the local registry, and you can then call RegDBSetDefaultRoot to change the root key.
 

INI files

Initialization, or profile, files make it possible for you to provide user-specific information for networked applications. Initialization files are used in addition to the Autoexec.bat file, and provide more detailed information. You can store profile, configuration, national language, font, and window driver information in an initialization file. There are three types of initialization (.ini) files:
 
• Win.ini
• System.ini
• Private .ini files
Sections in .ini files follow this format:
[section name]
keyname1=value1
keyname2=value2
keyname3=value3

The [section name] is the name of the application. Place brackets on either side of the section (application) name. The next three lines are keynames with their related values. The keyname, equal sign, and the value must all be on the same line.

Win.ini

Win.ini allows you to set up user-specific information and characteristics on the computer. Items such as the default font, printer drivers, network settings, etc., are included in the initialization file. The items are then used as defaults in any Windows-based application. You can insert or change information in any Windows-supplied section, or you can add your own section(s) to the Win.ini file using InstallScript functions.
System.ini
System.ini contains global information Windows uses when it starts up. You will find keyboard information, device driver aliases, non-Windows application information, etc., in the System.ini file
Private initialization files
You can create your own initialization files that set up characteristics for the application. You can include items such as fonts, Windows drivers, and any other information in a private .ini file.