Inno Setup Frequently Asked Questions
The Inno Setup Frequently Asked Questions contains supplemental information not found in the documentation.
The content of this page is also available on GitHub where you can suggest new entries or other improvements using the Edit button.
Functionality
Problems
Installation Tasks
Compatibility
Miscellaneous
Functionality
Translating Inno Setup's text into another language does not require modifying the source code. Simply make a copy of the Default.isl file (included with Inno Setup) and start editing the text in it. (Do not directly edit the Default.isl file, otherwise your changes will be lost when you install a new Inno Setup version.) See the "[Messages] Section" topic in the documentation for some important tips.
Once you have finished creating the new .isl file, create a [Languages] section to tell the compiler to use it:
[Languages]
Name: mytrans; MessagesFile: "compiler:MyTranslation.isl"
There are many contributed translations available for download on the Inno Setup Translations page.
Note that the captions of buttons in message boxes can't be translated. These captions are always in the same language as Windows itself. So if the user is running an English edition of Windows, they will see English button captions. This is normal behavior for any application that displays message boxes using the Windows MessageBox() function.
Yes. It does lead byte checking on all filename and constant parsing, so it does not mistake trail bytes for backslashes ("\") or braces ("{").
At the present time, there are no plans for a Windows Installer edition of Inno Setup. "Supporting" Windows Installer would likely involve a near-complete rewrite of the program.
The installer's icon may be changed by setting the SetupIconFile [Setup] section directive. To set the uninstaller's icon, set UninstallDisplayIcon.
Yes, through the Pascal Scripting feature.
Yes, through the Pascal Scripting feature. See the CodeDownloadFiles.iss example script for an example.
No, nor is such a feature planned (it would be abused). If it is your intention to keep user interaction to a minimum, use the Disable* [Setup] section directives.
Yes. Use a {reg:...} constant in DefaultDirName. For example:
[Setup]
DefaultDirName={reg:HKA\Software\My Program,Path|{autopf}\My Program}
See the Constants topic in the documentation for more information on {reg:...} constants, and the {autopf} constant.
Also see the Non Administrative Install Mode topic in the documentation for details on the HKA key value.
No. There is no foolproof method of accessing registry keys belonging to other users.
In order to access a given user's registry hive the user's profile must first be loaded, and in order to do that, authentication is necessary. An uninstaller would not know the user's password.
"But couldn't it call RegLoadKey to manually mount the user's registry hive (NTUSER.DAT)?" Without impersonating the user, the user running the uninstaller would need write permission on the user's profile directory. On Windows XP, user profiles can be marked "private", where no one but the user himself can access the files inside it.
And in a roaming profile setup, it's impossible to even know the path in which a given user's profile resides without authenticating first.
To deal with this situation do what other installers do: simply leave the HKCU keys of other users in place.
This is primarily dependent on which development tool your application was created with. Check its documentation.
If you determine that your application depends on a particular Microsoft DLL that doesn't come preinstalled with Windows then first of all, do not deploy DLLs out of your own Windows directory. Files in your own Windows directory are often tailored for your specific version of Windows, and will not work on other versions of Windows -- or worse (see below). This is especially true when you're running the very latest version of Windows.
Instead, search for versions of the DLL on Microsoft's web site that are deemed "redistributable". (http://www.microsoft.com/downloads/ is a good place to start.) Such versions are normally safe to install on any Windows version (but check the README files to be sure).
If nothing turns up, then probably you aren't allowed to individually deploy the DLL in question.
When deploying an installation that is an "update" (or "add-on") to an existing installation, you probably want the following criteria to be met:
- The update must be installed to the same directory as the original application.
- Any new files installed by the update must be removed when the original application is uninstalled.
- The update should not create a new entry in the Add/Remove Programs list, or alter the original application's entry. Nor should the application name displayed by the uninstaller change.
1 and 2 may be achieved by giving your update installation the same AppId setting as the original application. (If you never set AppId in the original application, then set AppId to the value of AppName used in the original application.) This, when combined with UsePreviousAppDir=yes (the default setting), will cause the update installation to default to the same directory as the original application, and share the same uninstall log file (unins???.dat). Also see the Same Application topic in the documentation for details.
3 may be achieved by setting CreateUninstallRegKey=no and UpdateUninstallLogAppName=no.
Problems
This message is typically displayed if you try to embed a quote (") character in a parameter's data, but do not double it as required. Read the "Parameters in Sections" topic in the documentation for more information.
Your application is most likely not specifying pathnames on the files it is trying to open, so it is expecting to find them in the current directory. Inno Setup by default does not set the "Start In" field on shortcuts its creates; this causes Windows to pick a directory itself, which usually won't be the directory containing your application.
In virtually all cases, this is something that should be corrected at the application level. Properly designed GUI applications should not expect to be started from a particular directory; they should always specify full pathnames on files they open. In Delphi or C++Builder, for example, it's possible to get the full pathname of the directory containing the application EXE by calling: ExtractFilePath(ParamStr(0)). To get the full path of a file named "File.txt" in the application directory, use: ExtractFilePath(ParamStr(0)) + 'File.txt'.
If for some reason you cannot fix this at the application level, you can tell Inno Setup to set the "Start In" field by adding "WorkingDir: {app}" to your [Icons] entries.
This error message is displayed when a file pertaining to the installation (e.g., setup.exe, setup.1) has the wrong size, or part of a file fails a CRC check. It is not displayed for any other reason.
If your installation is distributed over the internet and you're getting a lot of reports of this error, it could be that your web server is delivering partial files by dropping connections prematurely. Have the affected users check the size in the bytes of the file(s) they downloaded.
If your installation is distributed via CD-ROM or floppy disk, it could be that the CD-ROM or floppy disk is bad, or possibly the drive is defective.
This happens when you change AppId between versions, or if AppId is not specified, AppName. If you do that, Setup has no way of knowing that the two versions are of the same application, and thus will create a new entry in Add/Remove Programs. Additionally, a new uninstall log file (unins???.dat) will be created. The obvious solution for this is to not change AppId or AppName.
If you must change AppName in a new version, set AppId to the value of AppId or AppName from the previous version.
This message normally means that you specified the "regserver" flag on a file that doesn't possess the ability to be registered. Remove the "regserver" flag from the [Files] entry and the message will go away.
There are several reasons why a directory may not be removed:
- It already existed prior to installation. By default, the uninstaller plays it safe and doesn't remove directories that the installer didn't create.
- It contains files or subdirectories. Use [UninstallDelete] if you need the uninstaller to delete additional files/directories.
- A running process has the directory as its current directory.
From Tim Rude:
The simplest way to get a batch file to automatically close on exit is to clear the screen at the end of it using the CLS command.
--- batch file 1 ---
@echo off
echo Hello World
echo This batch file does NOT close on exit
--- batch file 2 ---
@echo off
echo Hello World
echo This batch file DOES close on exit
cls
At startup Setup looks in the registry to see if the same application was already installed previously, and if so, it will use the directory of the previous installation as the default directory presented to the user in the wizard. If you uninstall the application and run Setup again, it will use the new DefaultDirName setting. If you wish to disable this feature, set UsePreviousAppDir to "no".
Two files can't have the same name, and since shortcuts are files, two shortcuts therefore can't have the same name.
First, make sure that you are not using the "nowait" or "waituntilidle" flags on the [Run] entry. These flags prevent Setup from waiting until the process completely terminates.
If you aren't using those flags and it still doesn't seem to be waiting for the program to finish, then likely what is happening is that the EXE you're running is spawning some other process and then terminating itself immediately, causing Setup to think the program has finished. This is known to happen with older InstallShield-based installers (to work around it, try using the /SMS switch).
A simple way to check if a program does that is to run "START /WAIT ProgramName.exe" from the command line, and see if you are returned to the command prompt before the program exits.
You are using an old Non Unicode version of Inno Setup.
Your installation requires administrative privileges and is running elevated:
Mapped drives are not available (by default) to any elevated application. This was introduced in Windows Vista.
There is an option to make them available for same user elevation, but this won't help the situation when run from a LUA where the user changes.
Use the Pascal Scripting feature or the [Run] section:
The [Run] section is an oft overlooked yet simple method of performing custom installation tasks. First, write a small program in the development tool of your choice (preferably one that creates stand-alone EXEs, such as Delphi) that performs the desired task, and copy its EXE to your script directory. Next, place an entry in the [Files] script section telling Setup to copy the EXE to the install's temporary directory ("{tmp}"):
[Files]
Source: "ModifyAutoexec.exe"; DestDir: "{tmp}"
Then add a [Run] section entry, telling Setup to execute the EXE after all other installation steps:
[Run]
Filename: "{tmp}\ModifyAutoexec.exe"
If the program needs additional information, such as the value of the "{app}" constant, you could pass it via a command line parameter, i.e.:
[Run]
Filename: "{tmp}\ModifyAutoexec.exe"; Parameters: """{app}"""
You could alternatively incorporate the installation task into your application's main EXE and have it perform the task when called with a special command line parameter. For example:
[Run]
Filename: "{app}\MyProgram.exe"; Parameters: "/DoTheTask"
If the following wildcard is used in a [Files] section entry:
[Files]
Source: "*.htm"; DestDir: "{app}"
you may find that it matches not only files with an .htm extension, but also files with an .html extension.
This happens because in Windows, wildcards match both long filenames and 8.3 aliases ("short filenames"). By default, a file named "webpage.html" will have the 8.3 alias "WEBPAG~1.HTM"; hence, *.htm will match the file.
To avoid this, add an Excludes parameter to explicitly filter out files with an .html extension:
[Files]
Source: "*.htm"; Excludes: "*.html"; DestDir: "{app}"
Add the createallsubdirs flag to your [Files] section entry, and the empty directories will be created at install time.
The [Dirs] section may also be used to create empty directories.
Compare the version numbers on the existing file and the new file by right-clicking them in Windows Explorer and selecting Properties. By default, Inno Setup will not replace an existing file unless the existing file has no version info or has a lower version number.
The binary version numbers of files are what Inno Setup actually compares and the /LOG switch can be handy here. The log will show the binary version numbers of files and why certain files were not replaced.
If you want to force a file to be replaced regardless of its version number, add the ignoreversion flag to the [Files] section entry. This flag should only be used on files private to your application, never on shared system files.
Installation Tasks
First create a file named, for example, "website.url", and place these lines inside it:
[InternetShortcut]
URL=http://web.site.address/
Then add these lines to your script:
[Files]
Source: "website.url"; DestDir: "{app}"
[Icons]
Name: "{group}\Visit My Web Site"; Filename: "{app}\website.url"
Use a WorkingDir parameter on the [Icons] section entry.
First set the [Setup] section directive "ChangesAssociations" to "yes". Then create 5 [Registry] entries as shown below to create a file association.
[Registry]
Root: HKA; Subkey: "Software\Classes\.myp\OpenWithProgids"; ValueType: string; ValueName: "MyProgramFile.myp"; ValueData: ""; Flags: uninsdeletevalue
".myp" is the extension we're associating. "MyProgramFile.myp" is the internal name for the file type as stored in the registry. Make sure you use a unique name for this so you don't inadvertently overwrite another application's registry key.
Root: HKA; Subkey: "Software\Classes\MyProgramFile.myp"; ValueType: string; ValueName: ""; ValueData: "My Program File"; Flags: uninsdeletekey
"My Program File" above is the name for the file type as shown in Explorer.
Root: HKA; Subkey: "Software\Classes\MyProgramFile.myp\DefaultIcon"; ValueType: string; ValueName: ""; ValueData: "{app}\MyProg.exe,0"
"DefaultIcon" is the registry key that specifies the filename containing the icon to associate with the file type. ",0" tells Explorer to use the first icon from MyProg.exe. (",1" would mean the second icon.)
Root: HKA; Subkey: "Software\Classes\MyProgramFile.myp\shell\open\command"; ValueType: string; ValueName: ""; ValueData: """{app}\MyProg.exe"" ""%1"""
"shell\open\command" is the registry key that specifies the program to execute when a file of the type is double-clicked in Explorer. The surrounding quotes are in the command line so it handles long filenames correctly.
Root: HKA; Subkey: "Software\Classes\Applications\MyProg.exe\SupportedTypes"; ValueType: string; ValueName: ".myp"; ValueData: ""
Also see the Non Administrative Install Mode topic in the documentation for details on the HKA key value.
Environment variables are stored as string values in the registry, so it is possible to manipulate them using the [Registry] section. System-wide environment variables are located at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
User-specific environment variables are located at:
HKEY_CURRENT_USER\Environment
Use the "closeonexit" and "dontcloseonexit" flags in the [Icons] section.
Inno Setup does not currently have a specific feature for doing that, but you can make a copy of a file before it is replaced by using a [Files] section entry similar to this:
Source: "{app}\MyProg.exe"; DestDir: "{app}\backup"; Flags: external skipifsourcedoesntexist uninsneveruninstall
This can be done via MinVersion and/or OnlyBelowVersion parameters on an entry. See the Common Parameters topic in the documentation for details.
The [Dirs], [Files], and [Registry] sections support Permissions parameters for setting permissions on directories, files, and registry keys respectively.
If you have more advanced needs, take a look at SetACL.
There are two different ways to accomplish this:
- Either create a shortcut in the Startup group:
[Icons]
Name: "{autostartup}\My Program"; Filename: "{app}\MyProg.exe"
- Or create a value in the Run key of the registry:
[Registry]
Root: HKA; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"; ValueType: string; ValueName: "MyProg"; ValueData: """{app}\MyProg.exe"""; Flags: uninsdeletevalue
See the Constants topic in the documentation for more information on the {autostartup} constant.
Also see the Non Administrative Install Mode topic in the documentation for details on the HKA key value.
You may run a batch file by specifying the filename directly in the Filename parameter of a [Run] section entry:
[Run]
Filename: "{app}\YourBatchFile.bat"
AppMutex by default will not find mutexes created in user sessions other than the one Setup/Uninstall is running under. This is because each user session has its own kernel namespace.
To detect mutexes created in other sessions, your application must create two mutexes: one with a Global\ prefix and the other without.
Mutexes with the Global\ prefix are accessible from any user session. A like-named mutex must also be created in the session namespace (i.e. without the Global\ prefix) in case the creation of the Global mutex failed due to security restrictions.
Additionally, a special security descriptor must be passed in each of the CreateMutex() calls to ensure the mutex is accessible by different users.
Here is an example of how to create the two mutexes in Delphi:
procedure CreateMutexes(const MutexName: String);
{ Creates the two mutexes checked for by the installer/uninstaller to see if
the program is still running. }
const
SECURITY_DESCRIPTOR_REVISION = 1;
var
SecurityDesc: TSecurityDescriptor;
SecurityAttr: TSecurityAttributes;
begin
{ By default created mutexes are accessible only by the user running
the process. We need our mutexes to be accessible to all users, so
that the mutex detection can work across user sessions. To do this
we use a security descriptor with a null DACL. }
InitializeSecurityDescriptor(@SecurityDesc, SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(@SecurityDesc, True, nil, False);
SecurityAttr.nLength := SizeOf(SecurityAttr);
SecurityAttr.lpSecurityDescriptor := @SecurityDesc;
SecurityAttr.bInheritHandle := False;
CreateMutex(@SecurityAttr, False, PChar(MutexName));
CreateMutex(@SecurityAttr, False, PChar('Global\' + MutexName));
end;
...
begin
CreateMutexes('YourMutexNameGoesHere');
end;
In your script, set AppMutex as follows:
[Setup]
AppMutex=YourMutexNameGoesHere,Global\YourMutexNameGoesHere
The recommended way to install an OCX file is as follows.
[Files]
Source: "ComCtl32.ocx"; DestDir: "{sys}"; Flags: restartreplace sharedfile regserver
Compatibility
See the About page.
A typical Inno Setup installation does not require administrative privileges. However, there are exceptions as noted below.
Things that require administrative privileges:
- Using "PrivilegesRequired=admin" in the script's [Setup] section. This causes Setup to abort with an error message if the user lacks administrative privileges.
- Using the "restartreplace" flag in the [Files] section. This flag causes Inno Setup to call the MoveFileEx function, which attempts to write to "HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Session Manager". Write access to this key is restricted to Administrators.
- Writing to any key under HKEY_USERS\.DEFAULT using the [Registry] section. Write access to this key is restricted to Administrators.
- Using the "regserver" flag in the [Files] section. In most cases registering a DLL involves writing to HKEY_CLASSES_ROOT, a privilege not granted to ordinary users.
- Using the "sharedfile" flag is the [Files] section. This flag causes Inno Setup to create/update a value in "HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ SharedDLLs". Ordinary users are not allowed to write to that key.
- Writing to any key under HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT using the [Registry] section. Ordinary users are not allowed to write to those keys.
Inno Setup itself does not require write access to the Windows directory, or any other registry key not mentioned above.
What is different when an installation is run by a user without administrative privileges?
- The registry key for the Add/Remove Programs Control Panel entry is created under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE. Thus, only the user who installed the program will see an Add/Remove Programs entry for it.
- The "{group}" constant always points to the current user's profile, as opposed to the All Users profile.
- The program may be uninstalled by any user. (When an administrator installs a program, only an administrator is allowed to uninstall it.)
Also see the Non Administrative Install Mode topic in the documentation for details.
Miscellaneous
Inno Setup places no arbitrary limits on how many files, shortcuts, registry entries, etc. that you may include in an installation.
When Cancel is clicked, Setup will begin reverting changes it's made so far in the very same manner as the Uninstall program. Thus, a partially installed application isn't left over.
A temporary file with a name like "_iu14D2N.tmp" is created when you uninstall a program that used Inno Setup as its installer. The reason the file remains in the directory after the uninstall process has completed is that Windows does not allow running executables to delete themselves. So what it does is schedule the file to be deleted automatically the next time your computer is restarted. If you don't want to wait until then, it is perfectly safe to delete the file manually, provided no uninstallers are currently running.
Note that this behavior is not unique to Inno Setup.
When a file has the regserver flag, Setup will try to register the file even if it wasn't replaced during the installation (e.g., if the existing file was a newer version).
This behavior might on the surface seem superfluous, but in fact it's quite necessary. Whoever installed the file in the first place may not have registered it. Or, the existing file may somehow have gotten unregistered without being deleted. If Setup only registered files that were replaced, then in both of these cases the file would remain in an unregistered state at the end of installation, and your application wouldn't work.
Frequently new users wonder why the uninstaller EXE has numbers in its name (e.g. unins000.exe).
It is because Inno Setup allows multiple applications to be installed to the same directory. When that happens, the first application's uninstaller is named unins000.exe, the second application's uninstaller is named unins001.exe, and so on. If a fixed name were used, then it would only be possible to uninstall the most recently installed application.
If your application needs to create installations on the fly, it is permissible to deploy the files for the Inno Setup compiler along with it, provided the terms of the Inno Setup license are followed.
Site contents Copyright © 1997-2024 Jordan Russell. All rights reserved.
Portions Copyright © 2000-2024 Martijn Laan. All rights reserved.
| 
Home