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.
Displays a tree control for setup resources: string resources, registry
entries, and shell objects (folders/groups and shortcuts/icons).
The name of a setup resource must not contain any characters that are
invalid in folder names. Under the Explorer shell, invalid characters are
\ / : * ? " < > |
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 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
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
Keys, value names, and values
[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 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
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.
InstallShield has two types of registry-related functions—special and
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
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
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.
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).
Retrieves the value of [Path] or of [DefaultPath] under the per applications path key.
Results in the creation of the per application paths key, and sets the value of [Path] or of [DefaultPath] under that key.
The application uninstallation key stores information enabling uninstallation functionality.
Creates the application uninstallation key and sets the [UninstallString] value under that key.
Retrieves the value of [DisplayName] under the application uninstallation key.
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.
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).
Retrieves a value from under the application information key.
Sets a value under the application information key.
General registry-related functions
Creates a key in the registry. Also allows you to associate a class object with a registry key (advanced users only).
Deletes the specified key from the registry.
Deletes a value from a specified registry key.
Retrieves a value from under a key in the registry.
Checks if a key exists.
Queries a key for its subkeys and value names.
Sets the root key.
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
Opens a connection to a remote registry.
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
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.
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.