Inno Setup is an open-source installation builder for Windows applications by Jordan Russell and Martijn Laan. Since its introduction in 1997, Inno Setup has been trusted by developers and organizations of all sizes to reliably deploy software to millions of PCs worldwide.
Key features:
Support for every Windows release since 2009, including: Windows 11, Windows 10, Windows 11 on Arm, Windows 10 on Arm, Windows Server 2019, Windows Server 2016, Windows 8.1, Windows 8, Windows Server 2012, Windows 7, and Windows Server 2008 R2. (No service packs are required.)
Extensive support for installation of 64-bit applications on the 64-bit editions of Windows. The x64 and Arm64 architectures are both supported.
Extensive support for both administrative and non administrative installations installations.
Supports creation of a single EXE to install your program for easy online distribution. Disk spanning is also supported.
Resizable standard Windows wizard interface, with support for dark mode and custom styles.
Customizable setup types, e.g. Full, Minimal, Custom.
Complete uninstall capabilities.
Installation of files:
The installer has the ability to compare file version info, replace in-use files, use shared file counting, register DLL/OCX's and type libraries, install fonts, download and verify files, and extract archives.
Includes integrated support for "deflate", bzip2, and 7-Zip LZMA/LZMA2 file compression. Also includes support for extended-length paths.
Creation of shortcuts anywhere, including in the Start Menu and on the desktop.
Creation of registry and .INI entries.
Running other programs before, during or after install.
Support for multilingual installs, including right-to-left language support.
Support for password-protected and encrypted installs.
Support for digitally signed installs and uninstalls.
Silent install and silent uninstall.
Unicode installs.
Integrated preprocessor option for advanced compile-time customization.
Integrated Pascal scripting engine option for advanced run-time install and uninstall customization.
Full source code is available from GitHub.
Tiny footprint: only 2 MB overhead with all features included.
All features are fully documented.
Used by Microsoft Visual Studio Code, Git for Windows, and Embarcadero Delphi.
Inno Setup is copyrighted software. There are some restrictions on distribution and use; see the LICENSE.TXT file for details.
All commercial users of Inno Setup are requested to purchase a commercial license.
Installations are created by means of scripts, which are ASCII or Unicode (UTF-8 encoded) text files with a format somewhat similar to .INI files. (No, it's not as complicated as you might be thinking!).
Scripts have an ".iss" (meaning Inno Setup Script) extension. The script controls every aspect of the installation. It specifies which files are to be installed and where, what shortcuts are to be created and what they are to be named, and so on.
Script files are usually edited from inside the "Inno Setup Compiler" Compiler IDE program. After you have finishing writing the script, the next and final step is select "Compile" in the Compiler IDE. What this does is create a complete, ready-to-run Setup program based on your script. By default, this is created in a directory named "Output" under the directory containing the script.
To give you an idea of how this all works, start the Compiler IDE, click File | Open, and select one of the script files in the Examples subdirectory located under the Inno Setup directory. (It may be helpful to use the sample scripts as a template for your own scripts.)
See also:
Script Format Overview
Inno Setup Scripts are arranged into sections. Each section controls a different aspect of the installation. A section is started by specifying the name of the section enclosed in square brackets []. Inside each section is any number of entries.
There are two different main types of sections: those such as [Setup] whose entries contain directive names and values (in the form Directive=Value), and those such as [Files] whose entries are divided into parameters.
Here is an example:
[Setup]
AppName=My Program
[Files]
Source: "MyProg.exe"; DestDir: "{app}"
Note that it is legal to specify multiple sections of the same name.
You can put "comments" in the script (which are ignored by the compiler) by placing a semicolon at the beginning of a line. For example:
; This is a comment. I could put reminders to myself here...
A C-like #include directive is supported, which pulls in lines from a separate file into the script at the position of the #include directive. The syntax is:
#include "filename.txt"
If the filename is not fully qualified, the compiler will look for it in the same directory as the file containing the #include directive. The filename may be prefixed by "compiler:", in which case it looks for the file in the compiler directory.
A #preproc directive is supported, which must be placed on the first line of the file and specifies whether to use the built-in preprocessor, which only supports the above #include directive, or to use Inno Setup Preprocessor (ISPP), which supports many more directives. The syntax is:
#preproc builtin
#preproc ispp
By default, scripts use ISPP if available, and .isl files use the built-in preprocessor.
If an Unicode file is used, it must be UTF-8 encoded.
All of the sections in a script, with the exception of [Setup], [Messages], [CustomMessages], [LangOptions], and [Code], contain lines separated into parameters. The following is an example of a [Files] section:
Each parameter consists of a name, followed by a colon, and then a value. Unless otherwise noted, parameters are optional in that they assume a default value if they are not specified. Multiple parameters on a line are separated by semicolons, and can be listed in any order.
The value of a parameter is traditionally surrounded in double quotes (") when it contains a user-defined string, such as a filename. Using quotes is not required, though, but by doing so it makes it possible to embed leading and trailing spaces in the value, as well as semicolons and double-quote characters.
To embed a double-quote character inside a quoted value, use two consecutive double-quote characters. For example:
"This "" contains "" embedded "" quotes"
The compiler would see that as:
This " contains " embedded " quotes
If you want the value of a parameter to be a single double-quote character, use four double-quote characters: """". The outer two are needed to surround the string in quotes; the inner two are used to embed a single double-quote character.
The majority of the script entries can have constants embedded in them. These are predefined strings enclosed in brace characters { }. Setup or Uninstall translates the constants to their literal values, depending on the user's choices and system configuration. For example, {win}, as described below, would translate to "C:\WINDOWS" on most systems.
A "{" character is treated as the start of the constant. If you want to use that actual character in a place where constants are supported, you must use two consecutive "{" characters. (You do not need to double "}" characters.)
When a backslash immediately follows a constant, Setup or Uninstall will automatically remove the backslash if the value of the constant ends in a backslash already. Thus, if the value of a particular constant is "C:\", {constantname}\file will translate to "C:\file", not "C:\\file". If you want to prevent this from happening, enclose the backslash in { } characters, e.g. {app}{\}.
The application directory, which the user selects on the Select Destination Location page of the wizard.
For example: If you used {app}\MyProg.exe on an entry and the user selected "C:\MYPROG" as the application directory, Setup will translate it to "C:\MYPROG\MyProg.exe".
The system's Windows directory.
For example: If you used {win}\MYPROG.INI on an entry and the system's Windows directory is "C:\WINDOWS", Setup or Uninstall will translate it to "C:\WINDOWS\MYPROG.INI".
The system's System32 directory.
For example: If you used {sys}\CTL3D32.DLL on an entry and the system's Windows System directory is "C:\WINDOWS\SYSTEM", Setup or Uninstall will translate it to "C:\WINDOWS\SYSTEM\CTL3D32.DLL".
On 64-bit Windows, by default, the System32 path returned by this constant maps to the directory containing 32-bit system files, just like on 32-bit Windows. (This can be overridden by enabling 64-bit install mode.)
On 64-bit Windows, the directory containing 64-bit system files. On 32-bit Windows, the directory containing 32-bit system files.
{sysnative} is not accessible to 64-bit installers or any other 64-bit applications, so use its value only to, for example, pass it to a 32-bit application.
On 64-bit Windows, the system's SysWOW64 directory, typically "C:\WINDOWS\SysWOW64". This is the actual directory in which 32-bit system files reside. On 32-bit Windows, 32-bit system files do not reside in a separate SysWOW64 directory, so this constant will resolve to the same directory as {sys} if used there.
Do not use this constant unless you have a specific need to obtain the name of the actual directory in which 32-bit system files reside. Gratuitously using {syswow64} in places where {sys} will suffice may cause problems. (See the documentation for the [Files] section's sharedfile flag for one example.)
The directory in which the Setup files are located.
For example: If you used {src}\MyProg.exe on an entry and the user is installing from "S:\", Setup will translate it to "S:\MyProg.exe".
Program Files. The path of the system's Program Files directory. {commonpf} is equivalent to {commonpf32} unless the install is running in 64-bit install mode, in which case it is equivalent to {commonpf64}.
32-bit Program Files. The path of the system's 32-bit Program Files directory, typically "C:\Program Files" on 32-bit Windows and "C:\Program Files (x86)" on 64-bit Windows.
64-bit Windows only: 64-bit Program Files. The path of the system's 64-bit Program Files directory, typically "C:\Program Files". An exception will be raised if an attempt is made to expand this constant on 32-bit Windows.
Common Files. The path of the system's Common Files directory. {commoncf} is equivalent to {commoncf32} unless the install is running in 64-bit install mode, in which case it is equivalent to {commoncf64}.
32-bit Common Files. The path of the system's 32-bit Common Files directory, typically "C:\Program Files\Common Files" on 32-bit Windows and "C:\Program Files (x86)\Common Files" on 64-bit Windows.
64-bit Windows only: 64-bit Common Files. The path of the system's 64-bit Common Files directory, typically "C:\Program Files\Common Files". An exception will be raised if an attempt is made to expand this constant on 32-bit Windows.
Temporary directory used by Setup or Uninstall. This is not the value of the user's TEMP environment variable. It is a subdirectory of the user's temporary directory which is created by Setup or Uninstall at startup (with a name like "C:\WINDOWS\TEMP\IS-xxxxx.tmp"). All files and subdirectories in this directory are deleted when Setup or Uninstall exits. During Setup, this is primarily useful for extracting files that are to be executed in the [Run] section but aren't needed after the installation.
.NET Framework version 2.0-3.5 install root directory. {dotnet20} is equivalent to {dotnet2032} unless the install is running in 64-bit install mode, in which case it is equivalent to {dotnet2064}.
An exception will be raised if an attempt is made to expand this constant on a system with no .NET Framework version 2.0-3.5 present.
.NET Framework version 4.0 and later install root directory. {dotnet40} is equivalent to {dotnet4032} unless the install is running in 64-bit install mode, in which case it is equivalent to {dotnet4064}.
An exception will be raised if an attempt is made to expand this constant on a system with no .NET Framework version 4.0 or later present.
64-bit Windows only: 64-bit .NET Framework version 4.0 and later install root directory.
An exception will be raised if an attempt is made to expand this constant on a system with no .NET Framework version 4.0 or later present.
Shell Folder Constants
Inno Setup supports another set of directory constants, referred to as shell folder constants. They can be used in the same way as the other directory constants.
The "common" constants refer to the All Users profile.
The "user" constants refer to the profile of the user running Setup. This user is often not the same as the currently logged-in user, so use the "user" constants with caution.
The path to the Start Menu folder, as selected by the user on Setup's Select Start Menu Folder wizard page. This folder is created in the All Users profile unless the installation is running in non administrative install mode, in which case it is created in the current user's profile.
The path to the current user's Common Files folder. Only Windows 7 and later supports {usercf}; if used on previous Windows versions, it will translate to the same directory as {localappdata}\Programs\Common.
The path to the current user's Fonts folder. Only Windows 10 Version 1803 and later supports {userfonts}. Same directory as {localappdata}\Microsoft\Windows\Fonts.
The path to the current user's Program Files folder. Only Windows 7 and later supports {userpf}; if used on previous Windows versions, it will translate to the same directory as {localappdata}\Programs.
Besides the "common" and "user" constants, Inno Setup also supports "auto" constants. These automatically map to their "common" form unless the installation is running in non administrative install mode, in which case they map to their "user" form.
It is recommended you always use these "auto" constants when possible to avoid mistakes.
Inno Setup 6 renamed some of the directory and shell folder constants. The old names are still supported, but it is recommended to update your scripts to the new names (or the "auto" form) and the compiler will issue a warning if you don't.
NAME specifies the name of the environment variable to use.
DefaultValue determines the string to embed if the specified variable does not exist on the user's system.
If you wish to include a comma, vertical bar ("|"), or closing brace ("}") inside the constant, you must escape it via "%-encoding." Replace the character with a "%" character, followed by its two-digit hex code. A comma is "%2c", a vertical bar is "%7c", and a closing brace is "%7d". If you want to include an actual "%" character, use "%25".
NAME and DefaultValue may include constants. Note that you do not need to escape the closing brace of a constant as described above; that is only necessary when the closing brace is used elsewhere.
The full pathname of the system's standard command interpreter, Windows\System32\cmd.exe. Note that the COMSPEC environment variable is not used when expanding this constant.
Extracts and returns the drive letter and colon (e.g. "C:") from the specified path. In the case of a UNC path, it returns the server and share name (e.g. "\\SERVER\SHARE").
Path specifies the path.
If you wish to include a comma, vertical bar ("|"), or closing brace ("}") inside the constant, you must escape it via "%-encoding." Replace the character with a "%" character, followed by its two-digit hex code. A comma is "%2c", a vertical bar is "%7c", and a closing brace is "%7d". If you want to include an actual "%" character, use "%25".
Path may include constants. Note that you do not need to escape the closing brace of a constant as described above; that is only necessary when the closing brace is used elsewhere.
The name of the folder the user selected on Setup's Select Start Menu Folder wizard page. This differs from {group} in that it is only the name; it does not include a path.
(Special-purpose) Translates to the window handle of the Setup wizard window. This handle is set to '0' if the window handle isn't available at the time the translation is done.
Filename specifies the name of the .INI file to read from.
Section specifies the name of the section to read from.
Key specifies the name of the key to read.
DefaultValue determines the string to embed if the specified key does not exist.
If you wish to include a comma, vertical bar ("|"), or closing brace ("}") inside the constant, you must escape it via "%-encoding." Replace the character with a "%" character, followed by its two-digit hex code. A comma is "%2c", a vertical bar is "%7c", and a closing brace is "%7d". If you want to include an actual "%" character, use "%25".
Filename, Section, Key and DefaultValue may include constants. Note that you do not need to escape the closing brace of a constant as described above; that is only necessary when the closing brace is used elsewhere.
Embeds a custom message value based on the active language.
MessageName specifies the name of custom message to read from. See the [CustomMessages] section documentation for more information.
Arguments optionally specifies a comma separated list of arguments to the message value.
If you wish to include a comma, vertical bar ("|"), or closing brace ("}") inside the constant, you must escape it via "%-encoding." Replace the character with a "%" character, followed by its two-digit hex code. A comma is "%2c", a vertical bar is "%7c", and a closing brace is "%7d". If you want to include an actual "%" character, use "%25".
Each argument in Arguments may include constants. Note that you do not need to escape the closing brace of a constant as described above; that is only necessary when the closing brace is used elsewhere.
{cm:LaunchProgram,Inno Setup}
The example above translates to "Launch Inno Setup" if English is the active language.
HKxx specifies the root key; see the [Registry] section documentation for a list of possible root keys.
SubkeyName specifies the name of the subkey to read from.
ValueName specifies the name of the value to read; leave ValueName blank if you wish to read the "default" value of a key.
DefaultValue determines the string to embed if the specified registry value does not exist, or is not a string type (REG_SZ or REG_EXPAND_SZ) and also not a REG_DWORD-type.
If you wish to include a comma, vertical bar ("|"), or closing brace ("}") inside the constant, you must escape it via "%-encoding." Replace the character with a "%" character, followed by its two-digit hex code. A comma is "%2c", a vertical bar is "%7c", and a closing brace is "%7d". If you want to include an actual "%" character, use "%25".
SubkeyName, ValueName, and DefaultValue may include constants. Note that you do not need to escape the closing brace of a constant as described above; that is only necessary when the closing brace is used elsewhere.
If the value is not a string type (REG_SZ or REG_EXPAND_SZ) but a REG_DWORD-type then its value as a decimal string is embedded.
ParamName specifies the name of the command line parameter to read from.
DefaultValue determines the string to embed if the specified command line parameter does not exist, or its value could not be determined.
If you wish to include a comma, vertical bar ("|"), or closing brace ("}") inside the constant, you must escape it via "%-encoding." Replace the character with a "%" character, followed by its two-digit hex code. A comma is "%2c", a vertical bar is "%7c", and a closing brace is "%7d". If you want to include an actual "%" character, use "%25".
ParamName and DefaultValue may include constants. Note that you do not need to escape the closing brace of a constant as described above; that is only necessary when the closing brace is used elsewhere.
{param:Path|{autopf}\My Program}
The example above translates to c:\My Program if the command line /Path="c:\My Program" was specified.
The full pathname of the uninstall program extracted by Setup, e.g. "C:\Program Files\My Program\unins000.exe". This constant is typically used in an [Icons] section entry for creating an Uninstall icon. It is only valid if Uninstallable is yes (the default setting).
The name, organization and serial number, respectively, that the user entered on the User Information wizard page (which can be enabled via the UserInfoPage directive). Typically, these constants are used in [Registry] or [INI] entries to save their values for later use.
The log file name, or an empty string if logging to a log file is not enabled.
There are three optional parameters that are supported by all sections whose entries are separated into parameters. They are:
A space separated list of language names, telling Setup to which languages the entry belongs. If the end user selects a language from this list, the entry is processed (for example: the file is installed).
An entry without a Languages parameter is always processed, unless other parameters say it shouldn't be.
Besides space separated lists, you may also use boolean expressions containing language names. See Components and Tasks parameters for examples of boolean expressions.
Languages: en nl
A minimum Windows version for the entry to be processed. If you use 0 then the entry will never be processed. Build numbers and/or service pack levels may be included. This overrides any MinVersion directive in the script's [Setup] section.
An entry without a MinVersion parameter is always processed, unless other parameters say it shouldn't be.
MinVersion: 6.2
Essentially the opposite of MinVersion. Specifies the minimum Windows version for the entry not to be processed. For example, if you use 6.2 and the user is running Windows 7, the entry will be processed, but if the user is running Windows 8 (which reports its version as 6.2) or later, it will not be processed. Putting 0 means there is no upper version limit. Build numbers and/or service pack levels may be included. This overrides any OnlyBelowVersion directive in the script's [Setup] section.
If 0 is not used: should be higher than 6.1 otherwise the entry is never processed. (Windows Vista/Server 2008 are no longer supported.)
An entry without an OnlyBelowVersion parameter is always processed, unless other parameters say it shouldn't be.
OnlyBelowVersion: 6.2
There are two optional parameters that are supported by all sections whose entries are separated into parameters, except [Types], [Components] and [Tasks]. They are:
A space separated list of component names, telling Setup to which components the entry belongs. If the end user selects a component from this list, the entry is processed (for example: the file is installed).
An entry without a Components parameter is always processed, unless other parameters say it shouldn't be.
[Files]
Source: "MyProg.exe"; DestDir: "{app}"; Components: main
Source: "MyProg.chm"; DestDir: "{app}"; Components: help
Source: "Readme.txt"; DestDir: "{app}"
A space separated list of task names, telling Setup to which task the entry belongs. If the end user selects a task from this list, the entry is processed (for example: the file is installed).
An entry without a Tasks parameter is always processed, unless other parameters say it shouldn't be.
Note that the Don't create a Start Menu folder checkbox on the Select Start Menu Folder wizard page doesn't affect [Icons] entries that have Tasks parameters since they have their own checkboxes.
Besides space separated lists, you may also use boolean expressions containing component or task names as Components and Tasks parameters. Supported operators include not, and, and or. For example:
[Components]
Name: a; Description: a
Name: b; Description: b
[Tasks]
Name: p; Description: a or b; Components: a or b
Name: q; Description: a and b; Components: a and b
Name: r; Description: not a or b; Components: not a or b
Name: s; Description: not (a or b); Components: not (a or b)
Name: t; Description: a or b - old style; Components: a b
This section contains global settings used by the installer and uninstaller. Certain directives are required for any installation you create. Here is an example of a [Setup] section:
[Setup]
AppName=My Program
AppVersion=1.5
DefaultDirName={autopf}\My Program
DefaultGroupName=My Program
By default, any leading or trailing whitespace in a directive's value will be stripped. It is possible to avoid this by surrounding the directive's value in double quotes (").
The following directives can be placed in the [Setup] section:
(bold = required)
Compiler-related
ASLRCompatible
Compression
CompressionThreads
DEPCompatible
DisablePrecompiledFileVerifications
DiskClusterSize
DiskSliceSize
DiskSpanning
Encryption
InternalCompressLevel
LZMAAlgorithm
LZMABlockSize
LZMADictionarySize
LZMAMatchFinder
LZMANumBlockThreads
LZMANumFastBytes
LZMAUseSeparateProcess
MergeDuplicateFiles
MissingMessagesWarning
MissingRunOnceIdsWarning
NotRecognizedMessagesWarning
Output
OutputBaseFilename
OutputDir
OutputManifestFile
ReserveBytes
SignedUninstaller
SignedUninstallerDir
SignTool
SignToolMinimumTimeBetween
SignToolRetryCount
SignToolRetryDelay
SignToolRunMinimized
SlicesPerDisk
SolidCompression
SourceDir
TerminalServicesAware
UsedUserAreasWarning
UseSetupLdr
VersionInfoCompany
VersionInfoCopyright
VersionInfoDescription
VersionInfoOriginalFileName
VersionInfoProductName
VersionInfoProductTextVersion
VersionInfoProductVersion
VersionInfoTextVersion
VersionInfoVersion
Installer-related
Functional: These directives affect the operation of the Setup program, or are saved and used later by the uninstaller.
AllowCancelDuringInstall
AllowNetworkDrive
AllowNoIcons
AllowRootDirectory
AllowUNCPath
AlwaysRestart
AlwaysShowComponentsList
AlwaysShowDirOnReadyPage
AlwaysShowGroupOnReadyPage
AlwaysUsePersonalGroup
AppendDefaultDirName
AppendDefaultGroupName
AppComments
AppContact
AppId
AppModifyPath
AppMutex
AppName
AppPublisher
AppPublisherURL
AppReadmeFile
AppSupportPhone
AppSupportURL
AppUpdatesURL
AppVerName
AppVersion
ArchitecturesAllowed
ArchitecturesInstallIn64BitMode
ArchiveExtraction
ChangesAssociations
ChangesEnvironment
CloseApplications
CloseApplicationsFilter
CloseApplicationsFilterExcludes
CreateAppDir
CreateUninstallRegKey
DefaultDialogFontName
DefaultDirName
DefaultGroupName
DefaultUserInfoName
DefaultUserInfoOrg
DefaultUserInfoSerial
DirExistsWarning
DisableDirPage
DisableFinishedPage
DisableProgramGroupPage
DisableReadyMemo
DisableReadyPage
DisableStartupPrompt
DisableWelcomePage
EnableDirDoesntExistWarning
ExtraDiskSpaceRequired
InfoAfterFile
InfoBeforeFile
LanguageDetectionMethod
LicenseFile
MinVersion
OnlyBelowVersion
Password
PrivilegesRequired
PrivilegesRequiredOverridesAllowed
RedirectionGuard
RestartApplications
RestartIfNeededByRun
SetupArchitecture
SetupLogging
SetupMutex
ShowLanguageDialog
TimeStampRounding
TimeStampsInUTC
TouchDate
TouchTime
Uninstallable
UninstallDisplayIcon
UninstallDisplayName
UninstallDisplaySize
UninstallFilesDir
UninstallLogging
UninstallLogMode
UninstallRestartComputer
UpdateUninstallLogAppName
UsePreviousAppDir
UsePreviousGroup
UsePreviousLanguage
UsePreviousPrivileges
UsePreviousSetupType
UsePreviousTasks
UsePreviousUserInfo
UserInfoPage
Cosmetic: These directives only affect the appearance of the Setup program.
AppCopyright
FlatComponentsList
SetupIconFile
ShowComponentSizes
ShowTasksTreeLines
WizardBackColor
WizardBackColorDynamicDark
WizardBackImageFile
WizardBackImageOpacity
WizardImageAlphaFormat
WizardImageBackColor
WizardImageBackColorDynamicDark
WizardImageFile
WizardImageFileDynamicDark
WizardImageOpacity
WizardImageStretch
WizardKeepAspectRatio
WizardSizePercent
WizardSmallImageBackColor
WizardSmallImageBackColorDynamicDark
WizardSmallImageFile
WizardSmallImageFileDynamicDark
WizardStyle
WizardStyleFile
WizardStyleFileDynamicDark
Obsolete
These directives are obsolete and should not be used in any new scripts.
AlwaysCreateUninstallIcon
BackColor
BackColor2
BackColorDirection
BackSolid
DisableAppendDir
DontMergeDuplicateFiles
MessagesFile
UninstallIconFile
UninstallIconName
UninstallStyle
WindowResizable
WindowShowCaption
WindowStartMaximized
WindowVisible
WizardResizable
This section is optional. It defines all of the setup types Setup will show on the Select Components page of the wizard. During compilation a set of default setup types is created if you define components in a [Components] section but don't define types. If you are using the default (English) messages file, these types are the same as the types in the example below.
The following is a list of the supported parameters:
The internal name of the type. Used as parameter for components in the [Components] section to instruct Setup to which types a component belongs.
Name: "full"
The description of the type, which can include constants. This description is shown during installation.
Description: "Full installation"
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Instructs Setup that the type is a custom type. Whenever the end user manually changes the components selection during installation, Setup will set the setup type to the custom type. Note that if you don't define a custom type, Setup will only allow the user to choose a setup type and they can no longer manually select/unselect components.
Only one type may include this flag.
Flags: iscustom
Common Parameters
This section is optional. It defines all of the components Setup will show on the Select Components page of the wizard for setup type customization.
By itself a component does nothing: it needs to be 'linked' to other installation entries. See Components and Tasks Parameters.
Here is an example of a [Components] section:
[Components]
Name: "main"; Description: "Main Files"; Types: full compact custom; Flags: fixed
Name: "help"; Description: "Help Files"; Types: full
Name: "help\english"; Description: "English"; Types: full
Name: "help\dutch"; Description: "Dutch"; Types: full
The example above generates four components: A "main" component which gets installed if the end user selects a type with name "full" or "compact" and a "help" component which has two child components and only gets installed if the end user selects the "full" type.
The following is a list of the supported parameters:
The internal name of the component.
The total number of \ or / characters in the name of the component is called the level of the component. Any component with a level of 1 or more is a child component. The component listed before the child component with a level of 1 less than the child component, is the parent component. Other components with the same parent component as the child component are sibling components.
A child component can't be selected if its parent component isn't selected. A parent component can't be selected if none of its children are selected, unless a Components parameter directly references the parent component or the parent component includes the checkablealone flag.
If sibling components have the exclusive flag, only one of them can be selected.
Name: "help"
The description of the component, which can include constants. This description is shown to the end user during installation.
Description: "Help Files"
A space separated list of types this component belongs to. If the end user selects a type from this list, this component will be installed.
If the fixed flag isn't used (see below), any custom types (types using the iscustom flag) in this list are ignored by Setup.
Types: full compact
The extra disk space required by this component, similar to the ExtraDiskSpaceRequired directive for the [Setup] section.
Supports digit separators and set in bytes. (1048576 bytes = 1 megabyte)
ExtraDiskSpaceRequired: 1_048_576
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Specifies that the component can be checked when none of its children are. By default, if no Components parameter directly references the component, unchecking all of the component's children will cause the component to become unchecked.
Specifies that the component should not automatically become checked when its parent is checked. Has no effect on top-level components, and cannot be combined with the exclusive flag.
Instructs Setup that this component is mutually exclusive with sibling components that also have the exclusive flag.
Instructs Setup that this component can not be manually selected or unselected by the end user during installation.
Instructs Setup to ask the user to restart the system if this component is installed, regardless of whether this is necessary (for example because of [Files] section entries with the restartreplace flag). Like AlwaysRestart but per component.
Instructs Setup not to warn the user that this component will not be uninstalled after they deselected this component when it's already installed on his/her machine.
Depending on the complexity of your components, you can try to use the [InstallDelete] section and this flag to automatically 'uninstall' deselected components.
Flags: fixed
Common Parameters
This section is optional. It defines all of the user-customizable tasks Setup will perform during installation. These tasks appear as check boxes and radio buttons on the Select Additional Tasks wizard page.
By itself a task does nothing: it needs to be 'linked' to other installation entries. See Components and Tasks Parameters.
Here is an example of a [Tasks] section:
[Tasks]
Name: desktopicon; Description: "Create a &desktop icon"; GroupDescription: "Additional icons:"; Components: main
Name: desktopicon\common; Description: "For all users"; GroupDescription: "Additional icons:"; Components: main; Flags: exclusive
Name: desktopicon\user; Description: "For the current user only"; GroupDescription: "Additional icons:"; Components: main; Flags: exclusive unchecked
Name: quicklaunchicon; Description: "Create a &Quick Launch icon"; GroupDescription: "Additional icons:"; Components: main; Flags: unchecked
Name: associate; Description: "&Associate files"; GroupDescription: "Other tasks:"; Flags: unchecked
The following is a list of the supported parameters:
The internal name of the task.
The total number of \ or / characters in the name of the task is called the level of the task. Any task with a level of 1 or more is a child task. The task listed before the child task with a level of 1 less than the child task, is the parent task. Other tasks with the same parent task as the child task are sibling tasks.
A child task can't be selected if its parent task isn't selected. A parent task can't be selected if none of its children are selected, unless a Tasks parameter directly references the parent task or the parent task includes the checkablealone flag.
If sibling tasks have the exclusive flag, only one of them can be selected.
Name: "desktopicon"
The description of the task, which can include constants. This description is shown to the end user during installation.
Description: "Create a &desktop icon"
The group description of a group of tasks, which can include constants. Consecutive tasks with the same group description will be grouped below a text label. The text label shows the group description.
GroupDescription: "Additional icons"
A space separated list of components this task belongs to. If the end user selects a component from this list, this task will be shown. A task entry without a Components parameter is always shown.
Components: main
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Specifies that the task can be checked when none of its children are. By default, if no Tasks parameter directly references the task, unchecking all of the task's children will cause the task to become unchecked.
Instructs Setup that this task should be unchecked initially when Setup finds a previous version of the same application is already installed.
If the UsePreviousTasks [Setup] section directive is no, this flag is effectively disabled.
Specifies that the task should not automatically become checked when its parent is checked. Has no effect on top-level tasks, and cannot be combined with the exclusive flag.
Instructs Setup that this task is mutually exclusive with sibling tasks that also have the exclusive flag.
Instructs Setup to ask the user to restart the system at the end of installation if this task is selected, regardless of whether it is necessary (for example because of [Files] section entries with the restartreplace flag). Like AlwaysRestart but per task.
Instructs Setup that this task should be unchecked initially.
Flags: unchecked
Common Parameters
This optional section defines any additional directories Setup is to create besides the application directory the user chooses, which is created automatically. Creating subdirectories underneath the main application directory is a common use for this section.
Note that you aren't required to explicitly create directories before installing files to them using the [Files] section, so this section is primarily useful for creating empty directories.
Here is an example of a [Dirs] section:
[Dirs]
Name: "{app}\data"
Name: "{app}\bin"
The example above will, after Setup creates the application directory, create two subdirectories underneath the application directory.
The following is a list of the supported parameters:
The name of the directory to create, which normally will start with one of the directory constants.
Name: "{app}\MyDir"
Specifies additional attributes for the directory. This can include one or more of the following: readonly, hidden, system, notcontentindexed. If this parameter is not specified, Setup does not assign any special attributes to the directory.
If the directory already exists, the specified attributes will be combined with the directory's existing attributes.
Attribs: hidden system
Specifies additional permissions to grant in the directory's ACL (access control list). It is not recommended that you use this parameter if you aren't familiar with ACLs or why you would need to change them, because misusing it could negatively impact system security.
For this parameter to have an effect the directory must be located on a partition that supports ACLs (such as NTFS), and the current user must be able to change the permissions on the directory. In the event these conditions are not met, no error message will be displayed, and the permissions will not be set.
This parameter should only be used on directories private to your application. Never change the ACLs on top-level directories like {sys} or {commonpf}, otherwise you can open up security holes on your users' systems.
In addition, it is recommended that you avoid using this parameter to grant write access on directories containing program files. Granting, for example, everyone-modify permission on the {app} directory will allow unprivileged users to tamper with your application's program files; this creates the potential for a privilege escalation vulnerability. (However, it is safe to change the permissions on a subdirectory of your application's directory which does not contain program files, e.g. {app}\data.)
The specified permissions are set regardless of whether the directory existed prior to installation.
This parameter can include one or more space separated values in the format:
<user or group identifier>-<access type>
The following access types are supported for the [Dirs] section:
Grants "Full Control" permission, which is the same as modify (see below), but additionally allows the specified user/group to take ownership of the directory and change its permissions. Use sparingly; generally, modify is sufficient.
Grants "Modify" permission, which allows the specified user/group to read, execute, create, modify, and delete files in the directory and its subdirectories.
Grants "Read & Execute" permission, which allows the specified user/group to read and execute files in the directory and its subdirectories.
Permissions: users-modify
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Instructs Setup to create the directory as usual, but then delete it once the installation is completed (or aborted) if it's empty. This can be useful when extracting temporary data needed by a program executed in the script's [Run] section.
This flag will not cause directories that already existed before installation to be deleted.
Instructs Setup to enable NTFS compression on the directory. If it fails to set the compression state for any reason (for example, if compression is not supported by the file system), no error message will be displayed.
If the directory already exists, the compression state of any files present in the directory will not be changed.
Instructs the uninstaller to always attempt to delete the directory if it's empty. Normally the uninstaller will only try to delete the directory if it didn't already exist prior to installation.
Instructs the uninstaller to not attempt to delete the directory. By default, the uninstaller deletes any directory specified in the [Dirs] section if it is empty.
Instructs Setup to disable NTFS compression on the directory. If it fails to set the compression state for any reason (for example, if compression is not supported by the file system), no error message will be displayed.
If the directory already exists, the compression state of any files present in the directory will not be changed.
Flags: uninsneveruninstall
Components and Tasks Parameters
Common Parameters
This optional section defines any files Setup is to install on the user's system.
See the Remarks section at the bottom of this topic for some important notes.
The following is a list of the supported parameters:
The name of the source file. The compiler will prepend the path of your installation's source directory if you do not specify a fully qualified pathname.
This can be a wildcard to specify a group of files in a single entry. When a wildcard is used, all files matching it use the same options.
When the flag external is specified but the flag download is not, Source must be the full pathname of an existing file (or wildcard) on the distribution media or the user's system (e.g. "{src}\license.ini").
When the flag external is specified and the flag download is also, Source must be the URL of the file to download.
Constants may only be used when the external flag is specified, because the compiler does not do any constant translating itself.
Source: "MyProg.exe"
Source: "Files\*"
The directory where the file is to be installed on the user's system. Will almost always begin with one of the directory constants. If the specified path does not already exist on the user's system, it will be created automatically, and removed automatically during uninstallation if empty.
DestDir: "{app}"
DestDir: "{app}\subdir"
This parameter specifies a new name for the file when it is installed on the user's system. By default, Setup uses the name from the Source parameter, so in most cases it's not necessary to specify this parameter.
DestName: "MYPROG2.EXE"
Specifies a list of patterns to exclude, separated by commas.
Patterns may include wildcard characters ("*" and "?"). Note that unlike the Source parameter, a simple Unix-style pattern matching routine is used for Excludes. Dots in the pattern are always significant, thus "*.*" will not exclude a file with no extension (instead, use just "*"). Also, question marks always match exactly one character, thus "?????" will not exclude files with names less than five characters long.
If a pattern starts with a backslash ("\") it is matched against the start of a path name, otherwise it is matched against the end of a path name. Thus "\foo" will only exclude a file named "foo" at the base of the tree. On the other hand, "foo" will exclude any file named "foo" anywhere in the tree.
The patterns may include backslashes. "foo\bar" will exclude both "foo\bar" and "subdir\foo\bar". "\foo\bar" will only exclude "foo\bar".
This parameter must be combined with the external flag and specifies the size of the external file in bytes. If this parameter is not specified, Setup retrieves the file size at startup. Primarily useful for files that aren't available at startup, for example files located on a second disk when disk spanning is being used.
If the specified size does not match the actual size, Setup's progress bar will automatically adjust by skipping ahead or pausing as needed during installation.
If the extractarchive flag is also used, the total uncompressed size of all extracted files must be specified.
Supports digit separators and set in bytes. (1048576 bytes = 1 megabyte)
ExternalSize: 1_048_576; Flags: external
Specifies additional attributes for the file. This can include one or more of the following: readonly, hidden, system, notcontentindexed. If this parameter is not specified, Setup does not assign any special attributes to the file.
Attribs: hidden system
Specifies additional permissions to grant in the file's ACL (access control list). It is not recommended that you use this parameter if you aren't familiar with ACLs or why you would need to change them, because misusing it could negatively impact system security.
For this parameter to have an effect the file must be located on a partition that supports ACLs (such as NTFS), and the current user must be able to change the permissions on the file. In the event these conditions are not met, no error message will be displayed, and the permissions will not be set.
This parameter should only be used on files private to your application. Never change the ACLs on shared system files, otherwise you can open up security holes on your users' systems.
The specified permissions are set regardless of whether the file existed prior to installation.
This parameter can include one or more space separated values in the format:
<user or group identifier>-<access type>
The following access types are supported for the [Files] section:
Grants "Full Control" permission, which is the same as modify (see below), but additionally allows the specified user/group to take ownership of the file and change its permissions. Use sparingly; generally, modify is sufficient.
Grants "Modify" permission, which allows the specified user/group to read, execute, modify, and delete the file.
Grants "Read & Execute" permission, which allows the specified user/group to read and execute the file.
Permissions: users-modify
Tells Setup the file is a font that needs to be installed. The value of this parameter is the name of the font as stored in the registry or WIN.INI. This must be exactly the same name as you see when you double-click the font file in Explorer. Note that Setup will automatically append " (TrueType)" to the end of the name.
If the file is not a TrueType font, you must specify the flag fontisnttruetype in the Flags parameter.
It's recommended that you use the flags onlyifdoesntexist and uninsneveruninstall when installing fonts to the {autofonts} directory.
If the installation is running in non administrative install mode, Windows 10 Version 1803 or later is required to successfully install a font.
For compatibility with 64-bit Windows, fonts should not be installed to the {sys} directory. Use {autofonts} as the destination directory instead.
A space separated list of key names or group names from the [ISSigKeys] section, specifying which keys are allowed for the verification done by the issigverify flag.
ISSigAllowedKeys: "exesigner bosskey"
Instructs the compiler or Setup to do a simple SHA-256 hash check instead of a full signature verification, as an alternative to using the issigverify flag. The precise effect of this parameter depends on whether it is combined with the external flag. See the issigverify flag description for more information.
Specifies the password of the archive, which can include constants. Please be aware that this password is stored in an unencrypted form in the resulting Setup file(s), even if you have enabled encryption (using the [Setup] section directive Encryption).
This parameter is ignored if the extractarchive flag isn't also specified.
Specifies the URL of the .issig signature file which should be downloaded, which can include constants. This file is used to verify the file downloaded from the URL specified by the Source parameter.
This parameter is ignored if the download and issigverify flags aren't both also specified.
If this parameter is not set but both these flags are used, Setup will instead append ".issig" (without quotes) to the path portion of the URL specified by the Source parameter. It will then use the result as the URL to download the .issig signature file from.
Specifies the basic authentication username to use for the file download, which can include constants.
This parameter is ignored if the download flag isn't also specified.
Specifies the basic authentication password to use for the file download, which can include constants. Please be aware that this password is stored in an unencrypted form in the resulting Setup file(s), even if you have enabled encryption (using the [Setup] section directive Encryption).
This parameter is ignored if the download flag isn't also specified.
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Causes the {sys} constant to map to the 32-bit System directory when used in the Source and DestDir parameters, the regserver and regtypelib flags to treat the file as 32-bit, and the sharedfile flag to update the 32-bit SharedDLLs registry key. This is the default behavior in 32-bit install mode.
Combining 32bit and regtypelib requires a 32-bit installer.
Causes the {sys} constant to map to the 64-bit System directory when used in the Source and DestDir parameters, the regserver and regtypelib flags to treat the file as 64-bit, and the sharedfile flag to update the 64-bit SharedDLLs registry key. This is the default behavior in 64-bit install mode.
Combining 64bit and regtypelib requires a 64-bit installer.
Disables the compiler's automatic checking for unsafe files. It is strongly recommended that you DO NOT use this flag, unless you are absolutely sure you know what you're doing.
(Not recommended; see below)
Instructs Setup to proceed to comparing time stamps (last write/modified time) if the file being installed already exists on the user's system, and at least one of the following conditions is true:
Neither the existing file nor the file being installed has version info.
The ignoreversion flag is also used on the entry.
The replacesameversion flag isn't used, and the existing file and the file being installed have the same version number (as determined by the files' version info).
If the existing file has an older time stamp (last write/modified time) than the file being installed, the existing file will replaced. Otherwise, it will not be replaced.
Use of this flag is not recommended except as a last resort, because there is an inherent issue with it: NTFS partitions store time stamps in UTC (unlike FAT partitions), which causes local time stamps -- what Inno Setup works with by default -- to shift whenever a user changes their system's time zone or when daylight saving time goes into or out of effect. This can create a situation where files are replaced when the user doesn't expect them to be, or not replaced when the user expects them to be.
Always ask the user to confirm before replacing an existing file.
By default the compiler skips empty directories when it recurses subdirectories searching for the Source filename/wildcard. This flag causes these directories to be created at install time (just like if you created [Dirs] entries for them).
This flag must be combined with recursesubdirs.
Instructs Setup to install the file as usual, but then delete it once the installation is completed (or aborted). This can be useful for extracting temporary data needed by a program executed in the script's [Run] section.
This flag will not cause existing files that weren't replaced during installation to be deleted.
This flag cannot be combined with the isreadme, regserver, regtypelib, restartreplace, sharedfile, or uninsneveruninstall flags.
Don't copy the file to the user's system during the normal file copying stage but do statically compile the file into the installation. This flag is useful if the file is handled by the [Code] section exclusively and extracted using ExtractTemporaryFile, and in that case should be combined with noencryption.
Prevents Setup from verifying the file checksum after extraction. Use this flag on files you wish to modify while already compiled into Setup.
Must be combined with nocompression.
This flag instructs Setup not to copy an existing file, but instead to download it. Optionally use the DownloadUserName and DownloadPassword parameters to specify a basic authentication username and password.
This flag must be combined with the DestName and ExternalSize parameters. When download is combined with extractarchive, the value of DestName is used to determine the archive format and for display and logging purposes.
This flag also must be combined with the external and ignoreversion flags, meaning it should only be used on files private to your application, never on shared system files.
This flag cannot be combined with the comparetimestamp and skipifsourcedoesntexist flags.
Supports HTTPS (but not expired or self-signed certificates) and HTTP. Redirects are automatically followed and proxy settings are automatically used. Safe to use from services.
This flag instructs Inno Setup not to statically compile the file specified by the Source parameter into the installation files, but instead to copy from an existing file on the distribution media or the user's system. See the Source parameter description for more information.
When combined with the download or extractarchive flags, Setup does not copy the file, but instead downloads or extracts it.
This flag instructs Setup not to copy an existing archive file, but instead to extract it. Optionally use the ExtractArchivePassword parameter to specify a password.
The supported archive formats, beyond .7z, and the support for password-protected and multi-volume archives, depend on the ArchiveExtraction [Setup] section directive, that must not be set to basic.
To allow the extraction of archives with custom extensions, such as self-extracting archives, call MapArchiveExtensions.
This flag must be combined with the external and ignoreversion flags, meaning it should only be used on files private to your application, never on shared system files.
This flag is usually combined with the recursesubdirs and createallsubdirs flags.
Using a solid archive is not recommended; extraction performance may degrade depending on the solid block size.
Specify this flag if the entry is installing a non-TrueType font with the FontInstall parameter.
Install the file into the .NET Global Assembly Cache. When used in combination with sharedfile, the file will only be uninstalled when the reference count reaches zero.
To uninstall the file Uninstaller uses the strong assembly name specified by parameter StrongAssemblyName.
An exception will be raised if an attempt is made to use this flag on a system with no .NET Framework present.
Don't compare version info at all; replace existing files regardless of their version number.
This flag should only be used on files private to your application, never on shared system files.
This flag cannot be combined with replacesameversion.
Instructs the compiler or Setup to verify the source file's signature using a key from the [ISSigKeys] section, allowing all keys by default. Use the ISSigAllowedKeys parameter to limit the allowed keys.
The verification requires an .issig signature file to be present in the same directory as the source file, created using the Inno Setup Signature Tool. If flag download is set then the .issig signature file will be downloaded instead. See the DownloadISSigSource parameter description for more information..
The precise effect of this flag depends on whether it is combined with the external flag:
When used without the external flag, the compiler will verify the source file while it is being compressed/stored into the resulting installer. If the verification fails, compilation will abort.
When used with the external flag, Setup will verify the source file during the installation process while it is being copied to the destination directory. Files are always created with temporary names (*.tmp) initially. If the verification fails, the temporary file will be deleted and a "Verification of the source file failed" error message will be displayed to the user (with Skip, Try Again, and Cancel options) and a more detailed error is logged. If the verification succeeds, the temporary file will be renamed to the correct destination name.
When a file entry with the external flag is skipped (i.e., not installed - for example because the ignoreversion flag wasn't used), the source file isn't copied anywhere, so no verification takes place.
Since verification occurs while source files are being compressed/copied, and not in a separate pass, each file's contents are only read once. Thus, enabling verification has little performance impact; the only extra I/O comes from reading the tiny .issig files. Only archives and downloaded files are read twice.
The verification process is protected against the Time-Of-Check to Time-Of-Use (TOCTOU) problem.
This flag cannot be combined with the sign or signonce flags. Use signcheck instead.
File is the "README" file. Only one file in an installation can have this flag. When a file has this flag, the user will be asked if they would like to view the README file after the installation has completed. If Yes is chosen, Setup will open the file, using the default program for the file type. For this reason, the README file should always end with an extension like .txt, .wri, or .doc.
Note that if Setup has to restart the user's computer (as a result of installing a file with the flag restartreplace or if the AlwaysRestart[Setup] section directive is yes), the user will not be given an option to view the README file.
Prevents the compiler from attempting to compress the file. Use this flag on file types that you know can't benefit from compression (for example, JPEG images) to speed up the compilation process and save a few bytes in the resulting installation.
This flag has no effect if combined with the external flag.
Prevents the file from being stored encrypted. Use this flag if you have enabled encryption (using the [Setup] section directive Encryption) but want to be able to extract the file using the [Code] section support function ExtractTemporaryFile before the user has entered the correct password.
This flag has no effect if combined with the external flag.
Prevents the file from being stored with a timestamp. Use this flag to help make builds reproducible, even if you cannot preserve timestamps on source files.
This flag cannot be combined with the comparetimestamp and touch flags.
This flag has no effect if combined with the external flag.
When combined with either the regserver or regtypelib flags, Setup will not display any error message if the registration fails.
Only install the file if a file of the same name already exists on the user's system. This flag may be useful if your installation is a patch to an existing installation, and you don't want files to be installed that the user didn't already have.
Only install the file if it doesn't already exist on the user's system.
Always overwrite a read-only file. Without this flag, Setup will ask the user if an existing read-only file should be overwritten.
By default, when a file being installed has an older version number (or older time stamp, when the comparetimestamp flag is used) than an existing file, Setup will not replace the existing file. (See the Remarks section at the bottom of this topic for more details.) When this flag is used, Setup will ask the user whether the file should be replaced, with the default answer being to keep the existing file.
Instructs the compiler or Setup to also search for the Source filename/wildcard in subdirectories under the Source directory.
Register the DLL/OCX file. With this flag set, Setup will call the DllRegisterServer function exported by the DLL/OCX file, and the uninstaller will call DllUnregisterServer prior to removing the file. When used in combination with sharedfile, the DLL/OCX file will only be unregistered when the reference count reaches zero.
In 64-bit install mode, the file is assumed to be a 64-bit image and will be registered inside a 64-bit process. You can override this by specifying the 32bit flag.
See the Remarks at the bottom of this topic for more information.
Register the type library (.tlb). The uninstaller will unregister the type library (unless the flag uninsneveruninstall is specified). As with the regserver flag, when used in combination with sharedfile, the file will only be unregistered by the uninstaller when the reference count reaches zero.
In 64-bit install mode running on an x64-compatible edition of Windows, the type library will be registered inside a 64-bit process. You can override this by specifying the 32bit flag.
64-bit type libraries can only be (un)registered by 64-bit installers, and 32-bit type libraries only by 32-bit installers.
See the Remarks at the bottom of this topic for more information.
When this flag is used and the file already exists on the user's system and it has the same version number as the file being installed, Setup will compare the files and replace the existing file if their contents differ.
The default behavior (i.e. when this flag isn't used) is to not replace an existing file with the same version number.
This flag has no effect if combined with the extractarchive flag, or if used for a file that lacks a version number.
This flag cannot be combined with ignoreversion.
When an existing file needs to be replaced, and it is in use (locked) by another running process, Setup will by default display an error message. This flag tells Setup to instead register the file to be replaced the next time the system is restarted (by calling MoveFileEx or by creating an entry in WININIT.INI). When this happens, the user will be prompted to restart their computer at the end of the installation process.
NOTE: This flag has no effect if the user does not have administrative privileges. Therefore, when using this flag, it is recommended that you leave the PrivilegesRequired [Setup] section directive at the default setting of admin.
Instructs Setup to enable NTFS compression on the file (even if it didn't replace the file). If it fails to set the compression state for any reason (for example, if compression is not supported by the file system), no error message will be displayed.
Specifies that the file is shared among multiple applications, and should only be removed at uninstall time if no other applications are using it. Most files installed to the Windows System directory should use this flag, including .OCX, .BPL, and .DPL files.
Windows' standard shared file reference-counting mechanism (located in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs) is used to keep track of how many applications depend on the file. Each time the file is installed, the reference count for the file is incremented. (This happens regardless of whether the installer actually replaces the file on disk.) When an application using the file is uninstalled, the reference count is decremented. If the count reaches zero, the file is deleted (with the user's confirmation, unless the uninsnosharedfileprompt flag is also specified).
If Setup is run more than once, the reference count for the file will be incremented more than once. The uninstaller will decrement the reference count the same number of times, however, so no references are leaked (provided the UninstallLogMode [Setup] section directive isn't changed from its default setting of append).
When this flag is used, do not specify {syswow64} in the DestDir parameter; use {sys} instead. Even though {sys} and {syswow64} map to the same underlying directory in 32-bit install mode, the path name must exactly match what every other existing installer is using; otherwise, a second reference count for the file would be created, which could result in the file being removed prematurely. If you need to install a shared file to the 32-bit System directory in 64-bit install mode, specify {sys} in the DestDir parameter and additionally include the 32bit flag.
This flag instructs the compiler to digitally sign the original source files before storing them. Ignored if [Setup] section directive SignTool is not set.
This flag cannot be combined with the issigverify flag. Use signcheck instead.
This flag instructs the compiler to check the original source files for a digital signature before storing them.
This flag instructs the compiler to digitally sign the original source files before storing them, but only if the files are not already signed. Ignored if [Setup] section directive SignTool is not set.
This flag cannot be combined with the issigverify flag. Use signcheck instead.
This flag instructs the compiler -- or Setup, if the external flag is also used -- to silently skip over the entry if the source file does not exist, instead of displaying an error message.
When solid compression is enabled, this flag instructs the compiler to finalize the current compression stream and begin a new one before compressing the file(s) matched by Source. This allows Setup to seek to the file instantly without having to decompress any preceding files first. May be useful in a large, multi-component installation if you find too much time is being spent decompressing files belonging to components that weren't selected.
This flag instructs the compiler to compress the found files sorted by extension before it sorts by path name. This potentially decreases the size of Setup if solid compression is also used.
This flag instructs the compiler to compress the found files sorted by name before it sorts by path name. This potentially decreases the size of Setup if solid compression is also used. If sortfilesbyextension is also used, files are first sorted by extension.
This flag causes Setup to set the time/date stamp of the installed file(s) to that which is specified by the TouchDate and TouchTime [Setup] section directives.
This flag has no effect if combined with the external flag.
When uninstalling the shared file, automatically remove the file if its reference count reaches zero instead of asking the user. Must be combined with the sharedfile flag to have an effect.
When uninstalling the file, remove any read-only attribute from the file before attempting to delete it.
When this flag is used and the file is in use at uninstall time, the uninstaller will queue the file to be deleted when the system is restarted, and at the end of the uninstallation process ask the user if they want to restart. This flag can be useful when uninstalling things like shell extensions which cannot be programmatically stopped. Note that administrative privileges are required for this flag to have an effect.
Never remove the file. This flag can be useful when installing very common shared files that shouldn't be deleted under any circumstances, such as MFC DLLs.
Note that if this flag is combined with the sharedfile flag, the file will never be deleted at uninstall time but the reference count will still be properly decremented.
Instructs Setup to disable NTFS compression on the file (even if it didn't replace the file). If it fails to set the compression state for any reason (for example, if compression is not supported by the file system), no error message will be displayed.
Flags: isreadme
Components and Tasks Parameters
Common Parameters
Remarks
If a file already exists on the user's system, it by default will be replaced according to the following rules:
If the existing file is an older version than the file being installed (as determined by the files' version info), the existing file will be replaced.
If the existing file is the same version as the file being installed, the existing file will not be replaced, except if the replacesameversion flag is used and the content of the two files differs.
If the existing file is a newer version than the file being installed, or if the existing file has version info but the file being installed does not, the existing file will not be replaced.
If the existing file does not have version info, it will be replaced.
Certain flags such as onlyifdoesntexist, ignoreversion, and promptifolder alter the aforementioned rules.
If Setup is unable to replace an existing file because it is in use by another process, it will make up to 4 additional attempts to replace the file, delaying one second before each attempt. If all attempts fail, an error message will be displayed.
Setup registers all files with the regserver or regtypelib flags as the last step of installation. However, if the [Setup] section directive AlwaysRestart is yes, or if there are files with the restartreplace flag, all files get registered on the next reboot (by creating an entry in Windows' RunOnce registry key).
When files with a .HLP extension (Windows help files) are uninstalled, the corresponding .GID and .FTS files are automatically deleted as well. Similarly, when a .CHM (HTML Help) file is deleted, any .CHW (generated index) file is automatically deleted.
This optional section defines any shortcuts Setup is to create in the Start Menu and/or other locations, such as the desktop.
The following is a list of the supported parameters:
The name and location of the shortcut to create. Any of the shell folder constants or directory constants may be used in this parameter.
Keep in mind that shortcuts are stored as literal files so any characters not allowed in normal filenames can't be used here. Also, because it's not possible to have two files with the same name, it's therefore not possible to have two shortcuts with the same name.
The command line filename for the shortcut, which normally begins with a directory constant.
In addition to file and folder names, URLs (web site addresses) may also be specified. When a URL is specified, Setup will create an "Internet Shortcut" (.url) file, and ignore the Parameters, WorkingDir, HotKey, and Comment parameters.
On 64-bit Windows, note that the {sys} constant will map to the native 64-bit System directory when the shortcut is launched by a 64-bit process, such as Windows Explorer. This is true regardless of whether the install is running in 64-bit install mode. To create a shortcut that always points to the 32-bit System directory, use {syswow64} instead. (The same applies to the WorkingDir and IconFilename parameters.)
Optional command line parameters for the shortcut, which can include constants.
Parameters: "/play filename.mid"
The working (or Start In) directory for the shortcut, which specifies the initial current directory for the program. This parameter can include constants.
If this parameter is not specified or is blank, Setup will try to extract a directory name from the Filename parameter. If that fails (unlikely), the working directory will be set to {sys}.
WorkingDir: "{app}"
The hot key (or "shortcut key") setting for the shortcut, which is a combination of keys with which the program can be started.
Note: If you change the shortcut key and reinstall the application, Windows may continue to recognize old shortcut key(s) until you log off and back on or restart the system.
HotKey: "ctrl+alt+k"
Specifies the Comment (or "description") field of the shortcut, which determines the popup hint for it. This parameter can include constants.
Comment: "This is my program"
The filename of a custom icon (located on the user's system) to be displayed. This can be an executable image (.exe, .dll) containing icons or a .ico file. If this parameter is not specified or is blank, Windows will use the file's default icon. This parameter can include constants.
IconFilename: "{app}\myicon.ico"
Note: when Setup is running on 64-bit Windows, it will automatically replace {commonpf32}\'s value in the filename with '%ProgramFiles(x86)%\' to work around a bug in 64-bit Windows: 64-bit Windows replaces it with '%ProgramFiles%\' instead which is incorrect.
Zero-based index of the icon to use in the file specified by IconFilename. Defaults to 0.
If IconIndex is non-zero and IconFilename is not specified or is blank, it will act as if IconFilename is the same as Filename.
IconIndex: 0
Specifies the Windows 7 (or later) Application User Model ID for the shortcut. Ignored on earlier Windows versions. This parameter can include constants.
AppUserModelID: "MyCompany.MyProg"
Specifies the Windows 10 (or later) Application User Model Toast Activator CLSID for the shortcut. Ignored on earlier Windows versions.
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
When this flag is set, Setup will set the "Close on Exit" property of the shortcut. This flag only has an effect if the shortcut points to an MS-DOS application (if it has a .pif extension, to be specific). If neither this flag nor the dontcloseonexit flags are specified, Setup will not attempt to change the "Close on Exit" property.
When this flag is set, the installer will only try to create the icon if the file specified by the Filename parameter exists.
Same as closeonexit, except it causes Setup to uncheck the "Close on Exit" property.
Prevents the Start menu entry for the new shortcut from receiving a highlight on Windows 7 and additionally prevents the new shortcut from being automatically pinned the Start screen on Windows 8 (or later). Ignored on earlier Windows versions.
Prevents a Start menu entry from being pinnable to Taskbar or the Start Menu on Windows 7 (or later). This also makes the entry ineligible for inclusion in the Start menu's Most Frequently Used (MFU) list. Ignored on earlier Windows versions.
When this flag is set, Setup sets the "Run" setting of the icon to "Maximized" so that the program will be initially maximized when it is started.
When this flag is set, Setup sets the "Run" setting of the icon to "Minimized" so that the program will be initially minimized when it is started.
Instructs the uninstaller not to delete the icon.
When this flag is set, specify just a filename (no path) in the Filename parameter, and Setup will retrieve the pathname from the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths" registry key and prepend it to the filename automatically.
Flags: runminimized
Components and Tasks Parameters
Common Parameters
This optional section defines any .INI file entries you would like Setup to set on the user's system.
The following is a list of the supported parameters:
The name of the .INI file you want Setup to modify, which can include constants. If this parameter does not include a path, it will write to the Windows directory. If this parameter is blank, it will write to WIN.INI in the Windows directory.
Filename: "{app}\MyProg.ini"
The name of the section in which to create the entry, which can include constants.
Section: "Settings"
The name of the key to set, which can include constants. If this parameter is not specified or is blank, no key is created.
Key: "Version"
The value to assign to the key, which can use constants. If this parameter is not specified, no key is created.
String: "1.0"
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Assign to the key only if the key doesn't already exist in the file. If this flag is not specified, the key will be set regardless of whether it already existed.
Delete the entry when the program is uninstalled. This can be combined with the uninsdeletesectionifempty flag.
When the program is uninstalled, delete the entire section in which the entry is located. It obviously wouldn't be a good idea to use this on a section that is used by Windows itself (like some of the sections in WIN.INI). You should only use this on sections private to your application.
Same as uninsdeletesection, but deletes the section only if there are no keys left in it. This can be combined with the uninsdeleteentry flag.
Flags: uninsdeleteentry
Components and Tasks Parameters
Common Parameters
This optional section is identical in format to the [UninstallDelete] section, except its entries are processed as the first step of installation.
Inno Setup supports multilingual installations. The [Languages] section defines the languages to make available to the Setup program.
Setup determines the default language to use for its messages in the following order:
It searches for a language whose LanguageID setting (normally specified in the [LangOptions] section of the language's .isl file) matches both the primary language identifier and sublanguage identifier of the current user's UI language or locale (depending on the setting of LanguageDetectionMethod).
If no match is found, it searches for just a primary language identifier match. If two or more available languages have the same primary language identifier, it selects the first one listed in the [Languages] section. Exception: Simplified Chinese is excluded from consideration in this step if the user's UI language or locale (depending on the setting of LanguageDetectionMethod) is Traditional Chinese, and vice versa.
If no match is found, it defaults to the first language specified in the [Languages] section.
If the ShowLanguageDialog [Setup] section directive is set to yes (the default), a Select Language dialog will be displayed which gives the user an opportunity to override the language Setup chose. See the [LangOptions] section help topic for details.
The following is an example of a [Languages] section. It defines two languages: English, based on the standard Default.isl file, and Dutch, based on a third-party translation.
The internal name of the language, which you can set to anything you like. This can used as a prefix on [LangOptions] or [Messages] section entries to have the entries apply to only one language. The {language} constant returns the internal name of the selected language.
Name: "en"
Specifies the name(s) of the .isl file(s) to read the default messages from. The file(s) must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
Each message file may contain a [LangOptions] section, a [Messages] section, and a [CustomMessages] section.
When multiple files are specified, they are read in the order they are specified, thus the last message file overrides any language options or messages from previous files. Any language options or messages in the main script override the ones from message files.
The file is recommended to be UTF-8 encoded, without a BOM.
Specifies the name of an optional license agreement file, overriding the LicenseFile [Setup] section directive.
LicenseFile: "license-Dutch.txt"
Specifies the name of an optional "readme" file, overriding the InfoBeforeFile [Setup] section directive.
InfoBeforeFile: "infobefore-Dutch.txt"
Specifies the name of an optional "readme" file, overriding the InfoAfterFile [Setup] section directive.
InfoAfterFile: "infoafter-Dutch.txt"
A [Messages] section is used to define the messages displayed by the Setup program and uninstaller. Normally, you need not create a [Messages] section in your script file, since all messages are, by default, pulled in from the file Default.isl included with Inno Setup (or whichever file is specified by a [Languages] section entry).
However, particular messages can be overridden by creating a [Messages] section in your script file. To do this, first you will need to know the ID of the message you want to change. This can be easily found by searching Default.isl. For example, say you wanted to change the "&Next" button on the wizard to read "&Forward". The ID of this message is "ButtonNext", so you would create a [Messages] section like this:
[Messages]
ButtonNext=&Forward
Some messages take arguments such as %1 and %2. You can rearrange the order of the arguments (i.e. move the %2 before a %1) and also duplicate arguments if needed (i.e. "%1 ... %1 %2"). On messages with arguments, use two consecutive "%" characters to embed a single "%". "%n" creates a line break.
If you wish to translate all of Inno Setup's text to another language, instead of modifying Default.isl or overriding each message in every script you create, make a copy of Default.isl with another name like MyTranslation.isl. On any installation you wish to use MyTranslation.isl, create a [Languages] section entry pointing to the file.
In cases where there are multiple [Languages] section entries, specifying a [Messages] section entry in your script (as opposed to an .isl file) will by default override that message for all languages. To apply a [Messages] section entry to only one language, prefix it with the language's internal name followed by a period. For example:
en.ButtonNext=&Forward
If a message is missing or not recognized for a language, the compiler will warn you about this, which can be disabled using MissingMessagesWarning and NotRecognizedMessagesWarning.
Special-purpose messages
The BeveledLabel message can be used to specify a line of text that is shown in the lower left corner of the wizard window and uninstaller window. The following is an example:
[Messages]
BeveledLabel=Inno Setup
The HelpTextNote message can be used to specify one or more lines of text that are added to the list of parameters in the summary shown when passing /HELP on the command line. The following is an example:
These special-purpose messages default to an empty string so make sure to provide a non-empty default for all languages from your main script if you want to use these messages.
A [CustomMessages] section is used to define the custom message values for {cm:...} constants. See the Constants documentation for more information.
An example of a task with a description taken from the [CustomMessages] section using a {cm:...} constant:
[CustomMessages]
CreateDesktopIcon=Create a &desktop icon
[Tasks]
Name: desktopicon; Description: "{cm:CreateDesktopIcon}"
Messages may take arguments, from %1 up to %9. You can rearrange the order of the arguments (i.e. move the %2 before a %1) and also duplicate arguments if needed (i.e. "%1 ... %1 %2"). On messages with arguments, use two consecutive "%" characters to embed a single "%". "%n" creates a line break.
In cases where there are multiple [Languages] section entries, specifying a [CustomMessages] section entry in your script (as opposed to an .isl file) will by default override that message for all languages. To apply a [CustomMessages] section entry to only one language, prefix it with the language's internal name followed by a period. For example:
nl.CreateDesktopIcon=Maak een snelkoppeling op het &bureaublad
Currently, the .isl files for all languages that come with Inno Setup have the following custom messages defined and translated for each language (shown here with their English values):
NameAndVersion=%1 version %2
AdditionalIcons=Additional icons:
CreateDesktopIcon=Create a &desktop icon
CreateQuickLaunchIcon=Create a &Quick Launch icon
ProgramOnTheWeb=%1 on the Web
UninstallProgram=Uninstall %1
LaunchProgram=Launch %1
AssocFileExtension=&Associate %1 with the %2 file extension
AssocingFileExtension=Associating %1 with the %2 file extension...
AutoStartProgramGroupDescription=Startup:
AutoStartProgram=Automatically start %1
AddonHostProgramNotFound=%1 could not be located in the folder you selected.%n%nDo you want to continue anyway?
You may use these predefined custom messages in your own script. An example which uses UninstallProgram:
A [LangOptions] section is used to define the language-specific settings, such as fonts, used by the Setup program and uninstaller. Normally, you need not create a [LangOptions] section in your script file, since the language-specific settings are, by default, pulled in from the file Default.isl included with Inno Setup (or whichever file is specified by a [Languages] section entry).
The following is an example of a [LangOptions] section. (The settings listed below are the defaults.)
LanguageName is the native name of the language (so not the English name). It is displayed in the list of available languages on the Select Language dialog in a multilingual installation.
LanguageID is the numeric "language identifier" of the language. Refer to the list of valid language identifiers on MSDN. This, along with LanguageCodePage, is used for the purpose of auto-detecting the most appropriate language to use by default, so be sure it is set correctly. It should always begin with a "$" sign, since language identifiers are in hexadecimal. If no language identifier currently exists for the language, set this to zero.
LanguageCodePage specifies the "code page" (character set) used by the compiler to convert any non-Unicode text in the language's files to Unicode text. Note that any text in the .iss file such as a [CustomMessages] entry for the language is never converted and should be in Unicode already.
If no code page currently exists for the language, set LanguageCodePage to zero and only use Unicode text (UTF-8) in the languages's files.
If the language only uses ASCII characters (like English), set LanguageCodePage to zero as well.
If LanguageCodePage is set to zero but non-Unicode text is used in one of the language's files, the system code page will be used to convert the text in the file to Unicode.
DialogFontName, DialogFontSize, DialogFontBaseScaleWidth, and DialogFontBaseScaleHeight specify the font name and point size to use in dialogs. If no DialogFontName setting is present, then the value of the DefaultDialogFontName [Setup] section directive is used for the font name. If the specified font name does not exist on the user's system or is an empty string, 9-point Segoe UI will be substituted.
Before Inno Setup 6.6, the default font was 8-point Tahoma instead of 9-point Segoe UI. To use this font again without changes in scaling, use:
If you were already using 9-point Segoe UI before Inno Setup 6.6, you will notice a change in scaling when you update. To use your previous scaling, use:
WelcomeFontName and WelcomeFontSize specify the font name and point size to use at the top of the Welcome and Setup Completed wizard pages. If the specified font name does not exist on the user's system or is an empty string, 14-point Segoe UI will be substituted.
Before Inno Setup 6.6, the default font was 12-point Verdana instead of 14-point Segoe UI. To use this font again, use:
WelcomeFontName=Verdana
WelcomeFontSize=12
RightToLeft specifies whether the language is written from right to left. If set to yes, text alignment and reading order will be reversed (with some intentional exceptions), and controls will be arranged from right to left ("flipped").
In cases where there are multiple [Languages] section entries, specifying a [LangOptions] section directive in your script (as opposed to an .isl file) will by default override that directive for all languages. To apply a [LangOptions] section directive to only one language, prefix it with the language's internal name followed by a period. For example:
en.LanguageName=English
Obsolete
Feature removed in 6.4.TitleFontName and TitleFontSize used to specify the font name and point size to use when displaying the application name on the background window (only visible when WindowVisible=yes). If the specified font name does not exist on the user's system, 29-point Arial will be substituted. If the specified font name is an empty string, 29-point Microsoft Sans Serif or MS Sans Serif will be substituted.
Feature removed in 6.4.CopyrightFontName and CopyrightFontSize used to specify the font name and point size to use when displaying the AppCopyright message on the background window (only visible when WindowVisible=yes). If the specified font name does not exist on the user's system, 8-point Arial will be substituted. If the specified font name is an empty string, 8-point Microsoft Sans Serif or MS Sans Serif will be substituted.
This optional section defines any registry keys/values you would like Setup to create, modify, or delete on the user's system.
By default, registry keys and values created by Setup are not deleted at uninstall time. If you want the uninstaller to delete keys or values, you must include one of the uninsdelete* flags described below.
The following is an example of a [Registry] section.
The following is a list of the supported parameters:
The root key. This must be one of the following values:
HKCU
(HKEY_CURRENT_USER)
HKLM
(HKEY_LOCAL_MACHINE)
HKCR
(HKEY_CLASSES_ROOT)
HKU
(HKEY_USERS)
HKCC
(HKEY_CURRENT_CONFIG)
Additionally one special value is allowed:
HKA
(equals HKLM in administrative install mode, HKCU otherwise)
HKCU and HKA should only be used for settings which are compatible with roaming profiles.
Using HKCR is not recommended, use HKA with the Subkey parameter set to "Software\Classes" instead.
The values (including HKA) may have a suffix of 32 or 64. Root key values with a suffix of 32 (for example, HKLM32) map to the 32-bit view of the registry; root key values with a suffix of 64 (for example, HKLM64) map to the 64-bit view of the registry.
Root key values with a suffix of 64 can only be used when Setup is running on 64-bit Windows, otherwise an error will occur. On an installation supporting both 32- and 64-bit architectures, it is possible to avoid the error by adding a Check: IsWin64 parameter, which will cause the entry to be silently skipped when running on 32-bit Windows.
A root key value without a suffix (for example, HKLM) is equivalent to the value with a suffix of 32 (for example, HKLM32) unless the install is running in 64-bit install mode, in which case it is equivalent to the value with a suffix of 64 (for example, HKLM64).
Root: HKLM
The subkey name, which can include constants.
Subkey: "Software\My Company\My Program"
The data type of the value. This must be one of the following:
none
string
expandsz
multisz
dword
qword
binary
If none (the default setting) is specified, Setup will create the key but not a value. In this case the ValueData parameter is ignored.
If string is specified, Setup will create a string (REG_SZ) value.
If expandsz is specified, Setup will create an expand-string (REG_EXPAND_SZ) value.
If multisz is specified, Setup will create a multi-string (REG_MULTI_SZ) value.
If dword is specified, Setup will create a 32-bit integer (REG_DWORD) value.
If qword is specified, Setup will create a 64-bit integer (REG_QWORD) value.
If binary is specified, Setup will create a binary (REG_BINARY) value.
ValueType: string
The name of the value to modify, which can include constants. If this is blank, it will modify the "Default" value.
ValueName: "Version"
The data for the value. If the ValueType parameter is string, expandsz, or multisz, this is a string that can include constants. If the data type is dword or qword, this can be a decimal integer (e.g. "123"), a hexadecimal integer (e.g. "$7B"), or a constant which resolves to an integer. If the data type is binary, this is a sequence of hexadecimal bytes in the form: "00 ff 12 34". If the data type is none, this is ignored.
On a string, expandsz, or multisz type value, you may use a special constant called {olddata} in this parameter. {olddata} is replaced with the previous data of the registry value. The {olddata} constant can be useful if you need to append a string to an existing value, for example, {olddata};{app}. If the value does not exist or the existing value isn't a string type, the {olddata} constant is silently removed. {olddata} will also be silently removed if the value being created is a multisz type but the existing value is not a multi-string type (i.e. it's REG_SZ or REG_EXPAND_SZ), and vice versa.
On a multisz type value, you may use a special constant called {break} in this parameter to embed line breaks (nulls).
ValueData: "1.0"
Specifies additional permissions to grant in the registry key's ACL (access control list). It is not recommended that you use this parameter if you aren't familiar with ACLs or why you would need to change them, because misusing it could negatively impact system security.
For this parameter to have an effect the current user must be able to change the permissions on the registry key. In the event these conditions are not met, no error message will be displayed, and the permissions will not be set.
This parameter should only be used on registry keys private to your application. Never change the ACLs on a top-level key like HKEY_LOCAL_MACHINE\SOFTWARE, otherwise you can open up security holes on your users' systems.
The specified permissions are set regardless of whether the registry key existed prior to installation. The permissions are not set if ValueType is none and the deletekey flag or deletevalue flag is used.
This parameter can include one or more space separated values in the format:
<user or group identifier>-<access type>
The following access types are supported for the [Registry] section:
Grants "Full Control" permission, which is the same as modify (see below), but additionally allows the specified user/group to take ownership of the registry key and change its permissions. Use sparingly; generally, modify is sufficient.
Grants "Modify" permission, which allows the specified user/group to read, create, modify, and delete values and subkeys.
Grants "Read" permission, which allows the specified user/group to read values and subkeys.
Permissions: users-modify
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
When this flag is specified, Setup will create the value only if a value of the same name doesn't already exist. This flag has no effect if the data type is none, or if you specify the deletevalue flag.
When this flag is specified, Setup will first try deleting the entire key if it exists, including all values and subkeys in it. If ValueType is not none, it will then create a new key and value.
To prevent disasters, this flag is ignored during installation if Subkey is blank or contains only backslashes.
When this flag is specified, Setup will first try deleting the value if it exists. If ValueType is not none, it will then create the key if it didn't already exist, and the new value.
When this flag is specified, Setup will not attempt to create the key or any value if the key did not already exist on the user's system. No error message is displayed if the key does not exist.
Typically this flag is used in combination with the uninsdeletekey flag, for deleting keys during uninstallation but not creating them during installation.
Don't display an error message if Setup fails to create the key or value for any reason.
This is only applicable when the ValueType parameter is string or expandsz. When this flag is specified and the value did not already exist or the existing value isn't a string type (REG_SZ or REG_EXPAND_SZ), it will be created with the type specified by ValueType. If the value did exist and is a string type, it will be replaced with the same value type as the pre-existing value.
When the program is uninstalled, set the value's data to a null string (type REG_SZ). This flag cannot be combined with the uninsdeletekey flag.
When the program is uninstalled, delete the entire key, including all values and subkeys in it. It obviously wouldn't be a good idea to use this on a key that is used by Windows itself. You should only use this on keys private to your application.
To prevent disasters, this flag is ignored during installation if Subkey is blank or contains only backslashes.
When the program is uninstalled, delete the key if it has no values or subkeys left in it. This flag can be combined with uninsdeletevalue.
To prevent disasters, this flag is ignored during installation if Subkey is blank or contains only backslashes.
Delete the value when the program is uninstalled. This flag can be combined with uninsdeletekeyifempty.
NOTE: In Inno Setup versions prior to 1.1, you could use this flag along with the data type none and it would function as a "delete key if empty" flag. This technique is no longer supported. You must now use the uninsdeletekeyifempty flag to accomplish this.
Flags: uninsdeletevalue
Components and Tasks Parameters
Common Parameters
The [Run] section is optional, and specifies any number of programs to execute after the program has been successfully installed, but before the Setup program displays the final dialog. The [UninstallRun] section is optional as well, and specifies any number of programs to execute as the first step of uninstallation. Both sections share an identical syntax, except where otherwise noted below.
Programs are executed in the order they appear in the script. By default, when processing a [Run]/[UninstallRun] entry, Setup/Uninstall will wait until the program has terminated before proceeding to the next one, unless the nowait, shellexec, or waituntilidle flags are used.
Note that by default, if a program executed in the [Run] section queues files to be replaced on the next reboot (by calling MoveFileEx or by modifying wininit.ini), Setup will detect this and prompt the user to restart the computer at the end of installation. If you don't want this, set the RestartIfNeededByRun directive to no.
The following is a list of the supported parameters:
The program to execute, or file/folder to open. If Filename is not an executable (.exe or .com) or batch file (.bat or .cmd), you must use the shellexec flag on the entry. This parameter can include constants.
Any extended-length paths, also known as super paths, are always converted back to normal paths.
Filename: "{app}\INIT.EXE"
Valid only in a [Run] section. The description of the entry, which can include constants. This description is used for entries with the postinstall flag. If the description is not specified for an entry, Setup will use a default description. This description depends on the type of the entry (normal or shellexec).
Description: "View the README file"
Optional command line parameters for the program, which can include constants.
Parameters: "/x"
The initial current directory for the program. If this parameter is not specified or is blank, it uses the directory from the Filename parameter; if Filename does not include a path, it will use a default directory. This parameter can include constants.
Any extended-length paths, also known as super paths, are always converted back to normal paths.
WorkingDir: "{app}"
Valid only in a [Run] section. Determines the message displayed on the wizard while the program is executed. If this parameter is not specified or is blank, a default message of "Finishing installation..." will be used. This parameter can include constants.
StatusMsg: "Installing BDE..."
Valid only in an [UninstallRun] section. If the same application is installed more than once, "run" entries will be duplicated in the uninstall log file. By assigning a string to RunOnceId, you can ensure that a particular [UninstallRun] entry will only be executed once during uninstallation. For example, if two or more "run" entries in the uninstall log have a RunOnceId setting of "DelService", only the latest entry with a RunOnceId setting of "DelService" will be executed; the rest will be ignored. Note that RunOnceId comparisons are case-sensitive. If you don't assign a string to RunOnceId, the compiler will warn you about this, which can be disabled using MissingRunOnceIdsWarning.
RunOnceId: "DelService"
Specifies the action to be performed on the file. Must be combined with the shellexec flag. Commonly available verbs include "open" and "print". If this parameter is not specified or is blank, the default verb for the file type will be used (typically "open").
Verb: "print"
This parameter is a set of extra options. Multiple options may be used by separating them by spaces. The following options are supported:
Causes the {sys} constant to map to the 32-bit System directory when used in the Filename and WorkingDir parameters. This is the default behavior in 32-bit install mode.
This flag cannot be combined with the shellexec flag.
Causes the {sys} constant to map to the 64-bit System directory when used in the Filename and WorkingDir parameters. This is the default behavior in 64-bit install mode install.
This flag can only be used when Setup is running on 64-bit Windows, otherwise an error will occur. On an installation supporting both 32- and 64-bit architectures, it is possible to avoid the error by adding a Check: IsWin64 parameter, which will cause the entry to be silently skipped when running on 32-bit Windows.
This flag cannot be combined with the shellexec flag.
If this flag is specified, the command line parameters for the program will not be included in the log file.
If this flag is specified, the wizard will be hidden while the program is running.
If this flag is specified, the output of the program will be included in the log file.
This flag cannot be combined with the nowait, runasoriginaluser, shellexec, and waituntilidle flags.
If this flag is specified, it will not wait for the process to finish executing before proceeding to the next [Run] entry, or completing Setup. Cannot be combined with waituntilidle or waituntilterminated.
Valid only in a [Run] section. Instructs Setup to create a checkbox on the Setup Completed wizard page. The user can uncheck or check this checkbox and thereby choose whether this entry should be processed or not. Previously this flag was called showcheckbox.
If Setup has to restart the user's computer (as a result of installing a file with the flag restartreplace or if the AlwaysRestart[Setup] section directive is yes), there will not be an opportunity for the checkbox to be displayed and therefore the entry will never be processed.
The isreadme flag for entries in the [Files] section is now obsolete. If the compiler detects a entry with an isreadme flag, it strips the isreadme flag from the [Files] entry and inserts a generated [Run] entry at the head of the list of [Run] entries. This generated [Run] entry runs the README file and has flags shellexec, skipifdoesntexist, postinstall and skipifsilent.
If this flag is specified, the spawned process will inherit Setup/Uninstall's user credentials (typically, full administrative privileges).
This is the default behavior when the postinstall flag is not used.
This flag cannot be combined with the runasoriginaluser flag.
Valid only in a [Run] section. If this flag is specified, the spawned process will execute with the (normally non-elevated) credentials of the user that started Setup initially (i.e., the "pre-UAC dialog" credentials).
This is the default behavior when the postinstall flag is used.
If a user launches Setup by right-clicking its EXE file and selecting "Run as administrator", then this flag, unfortunately, will have no effect, because Setup has no opportunity to run any code with the original user credentials. The same is true if Setup is launched from an already-elevated process. Note, however, that this is not an Inno Setup-specific limitation; Windows Installer-based installers cannot return to the original user credentials either in such cases.
This flag cannot be combined with the runascurrentuser flag.
If this flag is specified, it will launch the program in a hidden window. Never use this flag when executing a program that may prompt for user input.
If this flag is specified, it will launch the program or document in a maximized window.
If this flag is specified, it will launch the program or document in a minimized window.
This flag is required if Filename is not a directly executable file (an .exe or .com file). When this flag is set, Filename can be a folder or any registered file type -- including .chm, .doc, and so on. The file will be opened with the application associated with the file type on the user's system, the same way it would be if the user double-clicked the file in Explorer.
By default, when the shellexec flag is used it will not wait until the spawned process terminates. If you need that, you must add the flag waituntilterminated. Note that it cannot and will not wait if a new process isn't spawned -- for example, if Filename specifies a folder.
If this flag is specified in the [Run] section, Setup won't display an error message if Filename doesn't exist.
If this flag is specified in the [UninstallRun] section, the uninstaller won't display the "some elements could not be removed" warning if Filename doesn't exist.
When this flag is used, Filename must be an absolute path.
Valid only in a [Run] section. Instructs Setup to skip this entry if Setup is not running (very) silent.
Valid only in a [Run] section. Instructs Setup to skip this entry if Setup is running (very) silent.
Valid only in a [Run] section. Instructs Setup to initially uncheck the checkbox. The user can still check the checkbox if they wish to process the entry. This flag is ignored if the postinstall flag isn't also specified.
If this flag is specified, it will wait until the process is waiting for user input with no input pending, instead of waiting for the process to terminate. (This calls the WaitForInputIdle Win32 function.) Cannot be combined with nowait or waituntilterminated.
If this flag is specified, it will wait until the process has completely terminated. Note that this is the default behavior (i.e. you don't need to specify this flag) unless you're using shellexec flag, in which case you do need to specify this flag if you want it to wait. Cannot be combined with nowait or waituntilidle.
Flags: postinstall nowait skipifsilent
Components and Tasks Parameters
Common Parameters
This optional section defines any additional files or directories you want the uninstaller to delete, besides those that were installed/created using [Files] or [Dirs] section entries. Deleting .INI files created by your application is one common use for this section. The uninstaller processes these entries as the last step of uninstallation.
Here is an example of a [UninstallDelete] section:
The following is a list of the supported parameters:
Specifies what is to be deleted by the uninstaller. This must be one of the following:
The Name parameter specifies a name of a particular file, or a filename with wildcards.
Functions the same as files except it matches directory names also, and any directories matching the name are deleted including all files and subdirectories in them.
When this is used, the Name parameter must be the name of a directory, but it cannot include wildcards. The directory will only be deleted if it contains no files or subdirectories.
Type: files
Name of the file or directory to delete.
NOTE: Don't be tempted to use a wildcard here to delete all files in the {app} directory. Doing this is strongly recommend against for two reasons. First, users usually don't appreciate having their data files they put in the application directory deleted without warning (they might only be uninstalling it because they want to move it to a different drive, for example). It's better to leave it up to the end users to manually remove them if they want. Also, if the user happened to install the program in the wrong directory by mistake (for example, C:\WINDOWS) and then went to uninstall it there could be disastrous consequences. So again, DON'T DO THIS!
Name: "{win}\MYPROG.INI"
Components and Tasks Parameters
Common Parameters
This optional section defines any keys the compiler and Setup can use to verify files using [Files] section's issigverify flag.
Here are two examples of an [ISSigKeys] section:
[ISSigKeys]
Name: "MyKey1; \
KeyID: "def0147c3bbc17ab99bf7b7a9c2de1390283f38972152418d7c2a4a7d7131a38"; \
KeyFile: "MyKey1.ispublickey"
Name: "MyKey2; \
KeyID: "def020edee3c4835fd54d85eff8b66d4d899b22a777353ca4a114b652e5e7a28"; \
PublicX: "515dc7d6c16d4a46272ceb3d158c5630a96466ab4d948e72c2029d737c823097"; \
PublicY: "f3c21f6b5156c52a35f6f28016ee3e31a3ded60c325b81fb7b1f88c221081a61"
[ISSigKeys]
Name: anna: KeyFile: "anna.ispublickey"; Group: exesigner
Name: ryan; KeyFile: "ryan.ispublickey"; Group: exesigner
Name: ivan; KeyFile: "ivan.ispublickey"; Group: docsigner
; max is trusted for both exe and doc signing
Name: max; KeyFile: "max.ispublickey"; Group: exesigner docsigner
; the boss also has a key
Name: bosskey; KeyFile: "boss.ispublickey"
See the Remarks section at the bottom of this topic for some important notes.
The following is a list of the supported parameters:
The internal name of the key.
Key names are not stored in the resulting Setup file(s), so you may use personal or non-public information in them, like the names of developers.
Name: MyKey
A space separated list of internal group names, specifying how to group the key.
Group names are not stored in the resulting Setup file(s), so you may use personal or non-public information in them, like the names of developer groups.
Group: exesigner docsigner
Specifies the ID of the key. If specified, the compiler uses it to double check the values of parameters KeyFile, PublicX, and PublicY. Is not used for anything else.
Specifies the private or public key file. The compiler will prepend the path of your installation's source directory if you do not specify a fully qualified pathname.
Must be set if parameters PublicX and PublicY aren't set.
If a private key file is specified, only its public information is stored in the resulting Setup file(s).
Specifies the runtime ID of the key, used by ISSigVerify.
Runtime ID's are stored in the resulting Setup file(s), so you should not use personal or non-public information in them.
RuntimeID: def01
Remarks
Keys and key files should be created using Inno Setup Signature Tool.
Created key files are human readable and can be opened with any text editor to get a key's KeyID, PublicX, and PublicY values. Note that none of these values are required if you set the KeyFile parameter instead.
The Inno Setup Example Scripts are located in a separate folder. Please click the "Inno Setup Example Scripts" shortcut created in the Start Menu when you installed Inno Setup, or open the "Examples" folder in your Inno Setup directory.
Inno Setup 7 introduced 64-bit compilers and installers.
Both the 32-bit and 64-bit editions of Inno Setup 7 can be installed side by side, and they can coexist alongside Inno Setup 6.
Great care has been taken to ensure maximum backward compatibility with Inno Setup 6, and compatibility between 32-bit and 64-bit installers.
64-bit Installers:
Set SetupArchitecture to x64 to build a 64-bit x64 installer instead of a 32-bit x86 installer. This also changes the default values of ArchitecturesAllowed and ArchitecturesInstallIn64BitMode to x64compatible, making 64-bit installers default to 64-bit install mode.
Key benefits and differences:
64-bit installers allow a maximum dictionary size for compression methods lzma and lzma2 of 3.8 GB instead of 1 GB. Review the memory requirements listed in the Compression topic before using large dictionary sizes.
64-bit installers have high-entropy ASLR enabled by default. This can help satisfy organizational policies or third-party requirements that mandate 64-bit executables.
64-bit installers fully support 32-bit install mode. To use a 64-bit installer while remaining in 32-bit install mode (for example, because you have been deploying 64-bit applications in 32-bit mode inadvertently), set ArchitecturesInstallIn64BitMode to a blank value to override the new default.
Existing installations made by 32-bit installers can be updated by 64-bit installers without issue, and vice versa.
64-bit Pascal Scripting notes:
In 32-bit installers, type Extended is 10 bytes, while in 64-bit installers it is 8 bytes and just an alias for type Double.
In 32-bit installers, types NativeInt and NativeUInt are 4 bytes, while in 64-bit installers they are 8 bytes. The same is true for all types derived from them, such as HWND.
Example script CodeDll.iss demonstrates how to support both 32-bit and 64-bit installers from a single script.
Please note: Even though types like HWND are 8 bytes (64-bit) in 64-bit processes, 64-bit Windows uses 32-bit handle values for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate from 64-bit to 32-bit or sign extend from 32-bit to 64-bit.
You cannot load 32-bit DLLs in 64-bit installers because Windows does not allow 64-bit processes to load 32-bit DLLs (and vice versa). However, you can always launch both 32-bit and 64-bit EXEs using the Exec function or the [Run] section.
64-bit type libraries (.tlb) can only be (un)registered by 64-bit installers, and 32-bit type libraries only by 32-bit installers.
Support for (un)registering 64-bit type libraries from a 32-bit installer has been dropped.
{sysnative} is not accessible to 64-bit installers or any other 64-bit applications, so use its value only to, for example, pass it to a 32-bit application.
For the moment, 64-bit installers still require WOW64 to be present, so running on Windows Server Core without WOW64 is not yet supported.
64-bit Compiler IDE and ISCC:
Install the 64-bit edition of Inno Setup to run 64-bit versions of the Compiler IDE and ISCC. Both editions read the same scripts and defaults, and either can generate 32-bit or 64-bit installers.
To check which edition you installed, click the "Inno Setup Compiler" shortcut in the Start Menu. The 32-bit edition displays "32-bit" in the title bar, while the 64-bit edition does not.
Key benefits and differences:
Either edition can generate installers of either architecture: 32-bit compilers can build 64-bit installers, and vice versa.
Both editions can be installed side by side and include the same examples and help files.
64-bit compilers generally achieve faster LZMA compression while maintaining full compatibility with existing scripts.
On Arm64-based Windows 11, they use an ARM64EC binary (islzma-Arm64EC.dll) for native performance.
The [Setup] directive LZMAUseSeparateProcess is ignored by 64-bit compilers, because 64-bit processes can directly allocate more memory, eliminating the need for an out-of-process compressor.
Prior to Inno Setup 6 two versions of Inno Setup were available: Non Unicode Inno Setup and Unicode Inno Setup. Starting with Inno Setup 6 there's only one version available: Unicode Inno Setup.
Key features of Unicode Inno Setup are its ability to display any language on any system regardless of the system code page, and its ability to work with Unicode filenames.
To check which edition you installed, click the "Inno Setup Compiler" shortcut in the Start Menu. Non Unicode Inno Setup displays "(a)" in the title bar, while Unicode Inno Setup does not.
Key differences and capabilities:
Unicode Inno Setup supports UTF-8 encoded .iss and .isl files. Starting with Inno Setup 6.3, a BOM is no longer required. UTF-16 is not supported.
Any existing ANSI .isl language files are automatically converted during compilation using the LanguageCodePage setting of the language.
Any [Messages] and [CustomMessages] entries in existing ANSI .iss script files must be converted to Unicode manually if the language used a special LanguageCodePage.
Unicode Inno Setup supports UTF-8 and UTF-16LE encoded .txt files for LicenseFile, InfoBeforeFile, and InfoAfterFile. Starting with Inno Setup 6.3, a BOM is no longer required.
Any language specific plain text ANSI files used for LicenseFile, InfoBeforeFile, or InfoAfterFile are automatically converted during compilation using the LanguageCodePage setting of the language.
The [Setup] directive ShowUndisplayableLanguages is ignored by Unicode Inno Setup.
Existing installations made by non Unicode installers can be updated by Unicode installers without issues, and vice versa.
Unicode Pascal Scripting notes:
The Unicode compiler sees type 'String' as a Unicode string, and 'Char' as a Unicode character. Its 'AnsiString' type hasn't changed and still is an ANSI string. Its 'PChar' type has been renamed to 'PAnsiChar', and using it is generally discouraged now.
The Unicode compiler is more strict about correct ';' usage: it no longer accepts certain missing ';' characters.
Some support functions had their prototype changed: some parameters of CreateOutputMsgMemoPage, RegQueryBinaryValue, RegWriteBinaryValue, OemToCharBuff, CharToOemBuff, LoadStringFromfile, SaveStringToFile, and GetMD5OfString are of type AnsiString now instead of String.
Added new SaveStringsToUTF8File, and GetMD5OfUnicodeString support functions.
Added new 'Int64' type, supported by IntToStr. Also added new StrToInt64, StrToInt64Def, and GetSpaceOnDisk64 support functions.
Added new TStringStream class.
If you want to compile an existing script that imports ANSI Windows API calls with the Unicode compiler, either upgrade to the 'W' Unicode API calls and use 'String' parameters, or keep the 'A' ANSI API calls and start using 'AnsiString' parameters.
The Frequently Asked Questions is now located in a separate document. Please click the "Inno Setup FAQ" shortcut created in the Start Menu when you installed Inno Setup, or open the "isfaq.url" file in your Inno Setup directory.
For the most recent Frequently Asked Questions, go to https://jrsoftware.org/isfaq.php
Below is a list of all the wizard pages Setup may potentially display, and the conditions under which they are displayed.
Welcome
Shown if DisableWelcomePage is set to no.
License Agreement
Shown if LicenseFile is set. Users may proceed to the next page only if the option "I accept the agreement" is selected.
Password
Shown if Password is set. Users may proceed to the next page only after entering the correct password.
Information
Shown if InfoBeforeFile is set.
User Information
Shown if UserInfoPage is set to yes.
Select Destination Location
Shown if DisableDirPage is set to no or auto.
Select Components
Shown if there are any [Components] entries.
Select Start Menu Folder
Shown if there are any [Icons] entries and if DisableProgramGroupPage is set to no or auto.
Select Tasks
Shown if there are any [Tasks] entries, unless the [Tasks] entries are all tied to components that were not selected on the Select Components page.
Ready to Install
Shown by default, but can be disabled via DisableReadyPage.
Preparing to Install
Normally, Setup will never stop or pause on this page. The only time it will is if Setup determines it can't continue or if it detects applications using files that need to be updated.
The former can happen if the PrepareToInstall event function returned an error or if one or more files specified in the [Files] and [InstallDelete] sections were queued (by some other installation) to be replaced or deleted on the next restart. In this case, it tells the user they need to restart their computer and then run Setup again. Note that this check is performed on silent installations too, but any messages are displayed in a message box instead of inside a wizard page.
The latter can happen if CloseApplications is set to yes or force.
Installing
Shown during the actual installation process.
Information
Shown if InfoAfterFile is set.
Setup Completed
Shown by default, but can be disabled in some cases via DisableFinishedPage.
See the AllPagesExample.iss example script for an example which shows all these pages.
Once the actual installation process begins, this is the order in which the various installation tasks are performed:
If CloseApplications was set to yes, Setup closes applications using files that need to be updated.
[InstallDelete] is processed.
The entries in [UninstallDelete] are stored in the uninstall log (which, at this stage, is stored in memory).
The application directory is created, if necessary.
[Dirs] is processed.
A filename for the uninstall log is reserved, if necessary.
[Files] is processed. (File registration does not happen yet.)
[Icons] is processed.
[INI] is processed.
[Registry] is processed.
Files that needed to be registered are now registered, unless the system needs to be restarted, in which case no files are registered until the system is restarted.
The Add/Remove Programs entry for the program is created, if necessary.
The entries in [UninstallRun] are stored in the uninstall log.
The uninstaller EXE and log are finalized and saved to disk. After this is done, the user is forbidden from cancelling the install, and any subsequent errors will not cause what was installed before to be rolled back.
[Run] is processed, except for entries with the postinstall flag, which get processed after the Setup Completed wizard page is shown.
If RestartApplications was set to yes, Setup restarts closed applications which support being restarted.
If ChangesAssociations was set to yes or to a scripted boolean expression evaluating to True, file associations are refreshed now.
If ChangesEnvironment was set to yes or to a scripted boolean expression evaluating to True, other applications are notified at this point.
All entries are processed by the installer in the order they appear in a section.
You can see the order yourself by loading a script into the Compiler IDE and pressing F7 (Step Into) repeatedly: each time Setup or Uninstall is about to process an entry the IDE will pause Setup or Uninstall and show you the entry.
Changes are undone by the uninstaller in the opposite order in which the installer made them. This is because the uninstall log is parsed from end to beginning.
the installer will first record the data for first entry's uninsdeletesectionifempty flag in the uninstall log, create the key of the second entry, and then record the data for the uninsdeleteentry flag in the uninstall log. When the program is uninstalled, the uninstaller will first process the uninsdeleteentry flag, deleting the entry, and then the uninsdeletesectionifempty flag, deleting the section.
Note that the uninstaller processes [UninstallRun] and [UninstallDelete] entries in the same order they appear in the script (not in reverse order).
An installation can run in one of two modes: administrative or non administrative. Which mode is selected is specified by the PrivilegesRequired and PrivilegesRequiredOverridesAllowed [Setup] section directives.
In administrative install mode:
The {group} folder is created in the All Users profile.
The "auto" form of the directory and Shell Folder constants is mapped to the "common" form.
The "user" form of these constants should NOT be used: user-level files and settings must be handled by the application itself, and never in an administrative install mode installer.
The HKA, uninstall info, and font install root keys will be HKEY_LOCAL_MACHINE.
In non administrative install mode:
The {group} folder is created in the current user's profile.
The "auto" form of the directory and Shell Folder constants is mapped to the "user" form.
The HKA, uninstall info, and font install root keys will be HKEY_CURRENT_USER.
Notes:
Regardless of the version of Windows, if the installation is running in administrative install mode then you should be careful about making any per-user area changes: user-level files and settings must be handled by the application itself, and never in an administrative install mode installer. The compiler will warn you about this, which can be disabled using UsedUserAreasWarning.
If the installation is running in non administrative install mode, but administrative privileges are available anyway then Setup or the [Code] section might still make use of these privileges. For this reason the uninstaller will always be marked as requiring administrative privileges in this case, just as if the installation was running in administrative install mode.
An installation can run in one of two modes: 32-bit or 64-bit. 64-bit install mode is selected if the user is running a 64-bit version of Windows and the system's processor architecture is included in the value of the ArchitecturesInstallIn64BitMode [Setup] section directive. Otherwise, 32-bit install mode is used.
How do the two modes of installation differ? Primarily, the differences lie in where things are installed by default.
32-bit install mode
The System32 path returned by the {sys} constant maps to the 32-bit System directory by default.
The {commonpf} constant is equivalent to {commonpf32}.
The {commoncf} constant is equivalent to {commoncf32}.
[Registry] writes to the 32-bit view by default.
The {reg:...} constant reads the 32-bit view by default.
The Reg* [Code] support functions access the 32-bit view by default.
The useapppaths flag of the [Icons] section reads the "App Paths" key in the 32-bit view of the registry.
The regserver and regtypelib flags of the [Files] section load and register files inside a 32-bit process by default. Latter requires a 32-bit installer.
The sharedfile flag of the [Files] section updates the "SharedDLLs" key in the 32-bit view of the registry by default.
The Uninstall key is created in the 32-bit view of the registry.
Both 32-bit and 64-bit installers support 32-bit install mode, see 64-bit Inno Setup.
64-bit install mode
The System32 path returned by the {sys} constant maps to the 64-bit System directory by default when used in the [Dirs], [Files], [InstallDelete], [Run], [UninstallDelete], and [UninstallRun] sections. This is because Setup/Uninstall temporarily disables WOW64 file system redirection when files/directories are accessed by those sections. Elsewhere, System32 and {sys} map to the 32-bit System directory, as is normal in a 32-bit process.
The {commonpf} constant is equivalent to {commonpf64}.
The {commoncf} constant is equivalent to {commoncf64}.
[Registry] writes to the 64-bit view by default.
The {reg:...} constant reads the 64-bit view by default.
The Reg* [Code] support functions access the 64-bit view by default.
The useapppaths flag of the [Icons] section reads the "App Paths" key in the 64-bit view of the registry.
The regserver and regtypelib flags of the [Files] section load and register files inside a 64-bit process by default. Latter requires a 64-bit installer.
The sharedfile flag of the [Files] section updates the "SharedDLLs" key in the 64-bit view of the registry by default.
The Uninstall key is created in the 64-bit view of the registry.
Both 32-bit and 64-bit installers support 64-bit install mode, see 64-bit Inno Setup.
When Setup is a 32-bit x86 application, there are some limitations to be aware of when utilizing its 64-bit installation features:
The System32 path returned by the {sys} constant does not always map to the 64-bit System directory. When Setup/Uninstall is running in 64-bit install mode, it maps to the 64-bit System directory when used in the [Dirs], [Files], [InstallDelete], [Run], [UninstallDelete], and [UninstallRun] sections because Setup temporarily disables WOW64 file system redirection when files/directories are accessed by those sections. Elsewhere, System32 and {sys} map to the 32-bit System directory, as is normal in a 32-bit process.
To easily auto update your application, first make your application somehow detect a new version of your Setup.exe and make it locate or download this new version. Then, to auto update, start your Setup.exe from your application with for example the following command line:
After starting setup.exe, exit your application as soon as possible. Note that to avoid problems with updating your .exe, Setup has an auto retry feature.
Optionally you could also use the skipifsilent and skipifnotsilent flags and make your application aware of a '/updated' parameter to for example show a nice message box to inform the user that the update has completed.
Inno Setup's own installers accept an additional /PORTABLE=1 command line parameter to enable portable mode which causes the installers to install to the desktop by default and to not create an uninstaller nor an entry in the Add/Remove Programs Control Panel applet. For example:
/portable=1 /silent /currentuser
The Inno Setup backup domain can be found at innosetup.nl. It currently just redirects to the main site but in case of emergencies this will be deactivated.
Besides the keyboard commands listed in the menus, the Compiler IDE supports additional keyboard and mouse commands, some of which depend on the active editor key map.
If the Visual Studio Code column is empty then the shortcut for this command is the same as listed in the Classic column.
A single dash (-) means there's no shortcut available for this command in the key map.
Note: a few of the shortcuts below use string representations for special virtual keys. More precisely: ; for VK_OEM_1, . for VK_OEM_PERIOD, / for VK_OEM_2, [ for VK_OEM_4, \ for VK_OEM_5, and ] for VK_OEM_6. Different keyboard layouts usually reposition these special virtual keys or change the characters produced when they are pressed. In the Edit menu these shortcuts are shown using the current system's keyboard layout. For example, when using a French AZERTY keyboard layout the Toggle Line Comment shortcut is shown as Ctrl+: instead of Ctrl+/. If the keyboard layout doesn't support the virtual key then no shortcut will be shown.
Classic
Visual Studio Code
Indent block
Tab
Unindent block
Shift+Tab
Indent lines
-
Ctrl+]
Unindent lines
-
Ctrl+[
Toggle lines comment
Ctrl+/
Delete to start of word
Ctrl+Backspace
Delete to end of word
Ctrl+Delete
Delete to start of line
Ctrl+Shift+Backspace
Delete to end of line
Ctrl+Shift+Delete
Go to start of document (Shift extends selection)
Ctrl+Home
Go to first non-blank character of line
Home
Go to start of line
Alt+Home or Home Home
Go to end of document (Shift extends selection)
Ctrl+End
Go to next paragraph (Shift extends selection)
Ctrl+]
-
Go to previous paragraph (Shift extends selection)
Ctrl+[
-
Go to end of line
End
Go to end of wrapped line
Alt+End
Go to previous word (Shift extends selection)
Ctrl+Left
Go to next word (Shift extends selection)
Ctrl+Right
Go to matching brace
Ctrl+Shift+\
Scroll up
Ctrl+Up
Scroll down
Ctrl+Down
Scroll horizontally
Shift+MouseWheel
Cut selection or line
Ctrl+X or Shift+Delete
Copy selection or line
Ctrl+C or Ctrl+Insert
Cut lines
Ctrl+L
Copy lines
Ctrl+Shift+T
Delete line
Ctrl+Shift+L
Ctrl+Shift+K
Switch line with previous
Ctrl+T
Move selected lines up
Alt+Up
Move selected lines down
Alt+Down
Duplicate selection or copy lines down
Ctrl+D
-
Copy line down
-
Shift+Alt+Down
Lowercase lines
Ctrl+U
Uppercase lines
Ctrl+Shift+U
Extend selection
Shift+Arrow
Select word
DoubleClick
Select line
TripleClick or Click on line number
Select all
Ctrl+A or Ctrl+Click on line number
Add additional cursor or selection
Ctrl+Click or Ctrl+Drag
Alt+Click or Alt+Drag
Remove a selection by clicking it
Ctrl+Click
Alt+Click
Add word as additional selection
Ctrl+DoubleClick
Alt+DoubleClick
Add line as additional selection
Ctrl+TripleClick
Alt+TripleClick
Add additional cursor or selection up
Ctrl+Alt+Up
Add additional cursor or selection down
Ctrl+Alt+Down
Add cursors to line ends
Shift+Alt+I
Add next occurrence of current word or selected text as additional selection
Shift+Alt+.
Ctrl+D
Select all occurrences of current word or selected text
Shift+Alt+;
Ctrl+Shift+L or (only if classic menu keys are not active) Ctrl+F2
Select all matches of last find text (also works when find dialog is open)
Alt+Enter
Revert multiple selections into single one or single selection into empty one
Extend rectangular selection to first non-blank character of line
Shift+Alt+Home
Ctrl+Shift+Alt+Home
Extend rectangular selection to start of line
Shift+Alt+Home Home
Ctrl+Shift+Alt+Home Home
Extend rectangular selection to end of line
Shift+Alt+End
Ctrl+Shift+Alt+End
Fold section
Ctrl+Shift+[
Unfold section
Ctrl+Shift+]
Fold or unfold all sections
Ctrl+Shift+Click in folding margin
Invoke autocomplete
Ctrl+Space or Ctrl+I
Select autocompletion
Tab or Enter
Fillup autocompletion
Space for ISPP directives and Flags and Type parameters \ for constants : for constants and section parameters ] for sections = for section directives ( for [Code]
Invoke parameter hint or show next definition
Ctrl+Shift+Space
Cancel autocomplete or parameter hint
Esc
Toggle overwrite
Insert
Go to tab
Ctrl+1 through Ctrl+9
Close current tab
Ctrl+F4 or Ctrl+W
Switch between the active memo, the active bottom pane, and the active banner
F6
The Compiler IDE supports to use of regular expressions for all of its find and replace operations. This can be enabled and disabled using the Use Regular Expressions option to the Edit menu or its shortcut (Ctrl+Alt+R or Alt+R). Once enabled or disabled, this setting will be preserved across sessions.
When used, regular expressions will only match ranges within a single line, never matching over multiple lines.
Regular expressions must be written in the ECMAScript grammar, generally similar to the grammar used by JavaScript and the .NET languages. Invalid regular expressions will cause an error message.
When replacing using regular expressions the replace string may contain the following special escape sequences:
Escape Sequence
Meaning
$1 through $9 or \1 through \9
Contents of the corresponding capture group
$& or \0
Complete match contents
$$
A literal '$' character
\\, \a, \b, \f, \r, \n, \t, \v
A literal '\', '\a', '\b', etc. character
For example, if the search string was (Ex)(ample) and the replace string was $2$1, when applied to a script saying "Examples" this would modify the script to say "ampleExs". Or if the replace string was $1\r\n$2 this would put a newline between "Ex" and "amples".
You can compile scripts from the command line using the console-mode compiler, ISCC.exe. Command line usage is as follows:
iscc [options]<script name>
Or to read from standard input:
iscc [options] -
iscc "c:\isetup\samples\my script.iss"
As shown in the example above, filenames that include spaces must be enclosed in quotes.
Valid options are:
/O(+|-)
Enable or disable output (overrides Output)
/O<path>
Output files to specified path (overrides OutputDir)
/F<filename>
Specifies an output filename (overrides OutputBaseFilename)
/S<name>=<command>
Sets a SignTool with the specified name and command (any Sign Tools configured using the Compiler IDE will be specified automatically)
/Q
Quiet compile (print error messages only)
/Qp
Enable quiet compile while still displaying progress
Also see Inno Setup Preprocessor: Command Line Compiler for additional options.
ISCC will return an exit code of 0 if the compile was successful, 1 if the command line parameters were invalid or an internal error occurred, or 2 if the compile failed.
Alternatively, scripts can also be compiled by the Compiler IDE from the command line. Command line usage is as follows:
iside /cc <script name>
iside /cc "c:\isetup\samples\my script.iss"
As shown in the example above, filenames that include spaces must be enclosed in quotes.
Running the Compiler IDE from the command line does not suppress the normal progress display or any error messages. The Compiler IDE will return an exit code of 0 if the compile was successful, 1 if the command line parameters were invalid, or 2 if the compile failed.
The Setup Script Wizard can be started from the command line. Command line usage is as follows:
As shown in the example above, wizard names and filenames that include spaces must be enclosed in quotes.
Running the wizard from the command line does not suppress any error messages. The Setup Script Wizard will return an exit code of 0 if there was no error and additionally it will save the generated script file to the specified filename, 1 if the command line parameters were invalid, or 2 if the generated script file could not be saved. If the user cancelled the Setup Script Wizard, an exit code of 0 is returned and no script file is saved.
Inno Setup includes an integrated signature-verification capability that can be used to detect corruption or tampering in your files at compile time, before files are included in an installer being built, or during installation, before Setup copies external files onto a user's system.
Signatures are created using the included Inno Setup Signature Tool utility (ISSigTool.exe) and are stored in separate files with an .issig extension. Because the signatures are stored in separate files — the original files are not touched — any type of file may be signed and verified.
Creation of .issig signatures does not require a certificate from a certificate authority. There is no cost involved.
Note, however, that an .issig signature cannot be used to eliminate an "Unknown publisher" warning message shown by Windows when an installer or other EXE file is started. That requires a completely different kind of signature (Authenticode) embedded inside the EXE file by a different tool (Microsoft's signtool.exe), and it does require a (usually expensive) code-signing certificate from a certificate authority. You can however use both signtool.exe and ISSigTool.exe on a single file, in that order. If you are looking for more information about signtool.exe see SignTool instead.
Quick start: Verifying files at compile time
On the issigtool commands below, prepend the path of your Inno Setup installation, and include quotes. For example: "%ProgramFiles(x86)%\Inno Setup 6\issigtool"
At the command line, generate a new private key file that will be used for signing:
A file named MyKey.isprivatekey will be created in the current directory. You may include a pathname if you wish.
The file should not be shared with others, and should never be committed into a public repository. To reduce the risk of accidental disclosure, it is best to keep the file outside of your source tree.
Create the file we want to sign, then create the signature:
A signature file named MyFile.txt.issig is created.
Inside your Inno Setup script, add an [ISSigKeys] section entry linking to your key file, and a [Files] section entry for MyFile.txt that includes the issigverify flag:
Note: Specifying a public key file instead is preferred; see the Tips & Recommendations section below.
Compile the script. In the compiler output, you should see a line indicating the file was successfully verified:
Compressing: MyFile.txt
Verification successful.
Now let's confirm that the compiler actually does catch corruption or tampering within the file.
Make a modification to MyFile.txt — for example, add or change a character.
Compile the script again. This time, you should get an error like the following:
Signature is not valid for source file "MyFile.txt": file hash incorrect.
Verifying external files during installation
The procedure for setting up verification of external files is essentially the same as the procedure shown above for compile-time verification, except:
The [Files] section entry would include a path in the Source parameter, and include the external flag:
The signature file — MyFile.txt.issig in this example — must exist in the same directory as the Source file during the installation process. (No compile-time verification occurs on external files.)
Although an [ISSigKeys] section entry's KeyFile parameter can point to a private key file as demonstrated above, it is recommended that a public key file be specified instead whenever possible. Unlike a private key file, a public key file does not have to be kept secret, and can be safely committed into a version control repository.
To create a public key file (MyKey.ispublickey) from an existing private key file (MyKey.isprivatekey), run this command:
Alternatively, the public key values may be specified directly inside your script by using the PublicX and PublicY parameters instead of KeyFile.
To avoid having to repeat the same --key-file= parameter on every issigtool command invocation, you may instead set the ISSIGTOOL_KEY_FILE environment variable to the path of your key file.
In cmd.exe or a batch file:
set ISSIGTOOL_KEY_FILE=MyKey.isprivatekey
In PowerShell:
$env:ISSIGTOOL_KEY_FILE = "MyKey.isprivatekey"
The above variable assignments are non-persistent; they only affect the current cmd.exe or PowerShell session.
Command line parameters were invalid or a fatal error occurred
Notes:
Filenames that include spaces must be enclosed in quotes.
Ensure the private key file is secure, as its compromise can affect the validity of your signatures.
The Setup program accepts optional command line parameters. These can be useful to system administrators, and to other programs calling the Setup program.
Disables the This will install... Do you wish to continue? prompt at the beginning of Setup. Of course, this will have no effect if the DisableStartupPrompt[Setup] section directive was set to yes.
Instructs Setup to be silent or very silent. When Setup is silent the wizard and the background window are not displayed but the installation progress window is. When a setup is very silent this installation progress window is not displayed. Everything else is normal so for example error messages during installation are displayed (if you haven't disabled them with the '/SUPPRESSMSGBOXES' command line option explained below) and the startup prompt is (if you haven't disabled it with DisableStartupPrompt or the '/SP-' command line option explained above).
If a restart is necessary and the '/NORESTART' command isn't used (see below) and Setup is silent, it will display a Reboot now? message box. If it's very silent it will reboot without asking.
Instructs Setup to suppress message boxes. Only has an effect when combined with '/SILENT' or '/VERYSILENT'.
The default response in situations where there's a choice is:
Yes in a 'Keep newer file?' situation.
No in a 'File exists, confirm overwrite.' situation.
Abort in Abort/Retry situations.
Cancel in Retry/Cancel situations.
Yes (=continue) in a DiskSpaceWarning/DirExists/DirDoesntExist/NoUninstallWarning/ExitSetupMessage/ConfirmUninstall situation.
Yes (=restart) in a FinishedRestartMessage/UninstalledAndNeedsRestart situation.
The recommended choice in a PrivilegesRequiredOverridesAllowed=dialog situation.
5 message boxes are not suppressible:
The About Setup message box.
The Exit Setup? message box.
The FileNotInDir2 message box displayed when Setup requires a new disk to be inserted and the disk was not found.
Any (error) message box displayed before Setup (or Uninstall) could read the command line parameters.
Any task dialog or message box displayed by [Code] support functions TaskDialogMsgBox and MsgBox (use SuppressibleTaskDialogMsgBox and SuppressibleMsgBox instead).
Instructs Setup to install in administrative install mode. Only has an effect when the [Setup] section directive PrivilegesRequiredOverridesAllowed allows the commandline override.
Instructs Setup to install in non administrative install mode. Only has an effect when the [Setup] section directive PrivilegesRequiredOverridesAllowed allows the commandline override.
Causes Setup to create a log file in the user's TEMP directory detailing file installation and [Run] actions taken during the installation process. This can be a helpful debugging aid. For example, if you suspect a file isn't being replaced when you believe it should be (or vice versa), the log file will tell you if the file was really skipped, and why.
The log file is created with a unique name based on the current date. (It will not overwrite or append to existing files.)
The information contained in the log file is technical in nature and therefore not intended to be understandable by end users. Nor is it designed to be machine-parsable; the format of the file is subject to change without notice.
Same as /LOG, except it allows you to specify a fixed path/filename to use for the log file. If a file with the specified name already exists it will be overwritten. If the file cannot be created, Setup will abort with an error message.
Prevents the user from cancelling during the installation process, by disabling the Cancel button and ignoring clicks on the close button. Useful along with '/SILENT' or '/VERYSILENT'.
Prevents Setup from restarting the system following a successful installation, or after a Preparing to Install failure that requests a restart. Typically used along with /SILENT or /VERYSILENT.
Specifies a custom exit code that Setup is to return when the system needs to be restarted following a successful installation. (By default, 0 is returned in this case.) Typically used along with /NORESTART. See also: Setup Exit Codes
Prevents Setup from closing applications using files that need to be updated by Setup. If /CLOSEAPPLICATIONS was also used, this command line parameter is ignored.
Instructs Setup to load the settings from the specified file after having checked the command line. This file can be prepared using the '/SAVEINF=' command as explained below.
Don't forget to use quotes if the filename contains spaces.
Overrides the default directory name displayed on the Select Destination Location wizard page. A fully qualified pathname must be specified. May include an "expand:" prefix which instructs Setup to expand any constants in the name. For example: '/DIR=expand:{autopf}\My Program'.
Overrides the default folder name displayed on the Select Start Menu Folder wizard page. May include an "expand:" prefix, see '/DIR='. If the [Setup] section directive DisableProgramGroupPage was set to yes, this command line parameter is ignored.
If the specified type exists and isn't a custom type, then any /COMPONENTS parameter will be ignored.
/COMPONENTS="comma separated list of component names"
Overrides the default component settings. Using this command line parameter causes Setup to automatically select a custom type. If no custom type is defined, this parameter is ignored.
Only the specified components will be selected; the rest will be deselected.
If a component name is prefixed with a "*" character, any child components will be selected as well (except for those that include the dontinheritcheck flag). If a component name is prefixed with a "!" character, the component will be deselected.
This parameter does not change the state of components that include the fixed flag.
Deselect all components, then select the "help" and "plugins" components:
/COMPONENTS="help,plugins"
Deselect all components, then select a parent component and all of its children with the exception of one:
/COMPONENTS="*parent,!parent\child"
Specifies a list of tasks that should be initially selected.
Only the specified tasks will be selected; the rest will be deselected. Use the /MERGETASKS parameter instead if you want to keep the default set of tasks and only select/deselect some of them.
If a task name is prefixed with a "*" character, any child tasks will be selected as well (except for those that include the dontinheritcheck flag). If a task name is prefixed with a "!" character, the task will be deselected.
Deselect all tasks, then select the "desktopicon" and "fileassoc" tasks:
/TASKS="desktopicon,fileassoc"
Deselect all tasks, then select a parent task and all of its children with the exception of one:
/TASKS="*parent,!parent\child"
Like the /TASKS parameter, except the specified tasks will be merged with the set of tasks that would have otherwise been selected by default.
If UsePreviousTasks is set to yes, the specified tasks will be selected/deselected after any previous tasks are restored.
Keep the default set of selected tasks, but additionally select the "desktopicon" and "fileassoc" tasks:
/MERGETASKS="desktopicon,fileassoc"
Keep the default set of selected tasks, but deselect the "desktopicon" task:
/MERGETASKS="!desktopicon"
Specifies the password to use. If the [Setup] section directive Password was not set, this command line parameter is ignored.
When an invalid password is specified, this command line parameter is also ignored.
The Setup program may return one of the following exit codes:
0
Setup was successfully run to completion or the /HELP or /? command line parameter was used.
1
Setup failed to initialize.
2
The user clicked Cancel in the wizard before the actual installation started, or chose "No" on the opening "This will install..." message box.
3
A fatal error occurred while preparing to move to the next installation phase (for example, from displaying the pre-installation wizard pages to the actual installation process). This should never happen except under the most unusual of circumstances, such as running out of memory or Windows resources.
4
A fatal error occurred during the actual installation process.
Note: Errors that cause an Abort-Retry-Ignore box to be displayed are not fatal errors. If the user chooses Abort at such a message box, exit code 5 will be returned.
5
The user clicked Cancel during the actual installation process, or chose Abort at an Abort-Retry-Ignore box.
6
The Setup process was forcefully terminated by the debugger (Run | Terminate was used in the Compiler IDE).
7
The Preparing to Install stage determined that Setup cannot proceed with installation.
8
The Preparing to Install stage determined that Setup cannot proceed with installation, and that the system needs to be restarted in order to correct the problem.
Before returning an exit code of 1, 3, 4, 7, or 8, an error message explaining the problem will normally be displayed.
Future versions of Inno Setup may return additional exit codes, so applications checking the exit code should be programmed to handle unexpected exit codes gracefully. Any non-zero exit code indicates that Setup was not run to completion.
The uninstaller program (unins???.exe) accepts optional command line parameters. These can be useful to system administrators, and to other programs calling the uninstaller program.
When specified, the uninstaller will not ask the user for startup confirmation or display a message stating that uninstall is complete. Shared files that are no longer in use are deleted automatically without prompting. Any critical error messages will still be shown on the screen. When '/VERYSILENT' is specified, the uninstallation progress window is not displayed.
If a restart is necessary and the '/NORESTART' command isn't used (see below) and '/VERYSILENT' is specified, the uninstaller will reboot without asking.
Instructs the uninstaller to suppress message boxes. Only has an effect when combined with '/SILENT' and '/VERYSILENT'. See '/SUPPRESSMSGBOXES' under Setup Command Line Parameters for more details.
Causes Uninstall to create a log file in the user's TEMP directory detailing file uninstallation and [UninstallRun] actions taken during the uninstallation process. This can be a helpful debugging aid.
The log file is created with a unique name based on the current date. (It will not overwrite or append to existing files.)
The information contained in the log file is technical in nature and therefore not intended to be understandable by end users. Nor is it designed to be machine-parsable; the format of the file is subject to change without notice.
Same as /LOG, except it allows you to specify a fixed path/filename to use for the log file. If a file with the specified name already exists it will be overwritten. If the file cannot be created, Uninstall will abort with an error message.
Prevents the uninstaller from enabling RedirectionGuard. If /REDIRECTIONGUARD was also used, this command line parameter is ignored.
The uninstaller will return a non-zero exit code if the user cancels or a fatal error is encountered. Programs checking the exit code to detect failure should not check for a specific non-zero value; any non-zero exit code indicates that the uninstaller was not run to completion.
Note that at the moment you get an exit code back from the uninstaller, some code related to uninstallation might still be running. Because Windows doesn't allow programs to delete their own EXEs, the uninstaller creates and spawns a copy of itself in the TEMP directory. This "clone" performs the actual uninstallation, and at the end, terminates the original uninstaller EXE (at which point you get an exit code back), deletes it, then displays the "uninstall complete" message box (if it hasn't been suppressed with /SILENT or /VERYSILENT).
As a convenience to new users who are unfamiliar with which files they should and should not distribute, the compiler will display an error message if one attempts to install certain "unsafe" files using the [Files] section. These files are listed below.
(Note: It is possible to disable the error message by using a certain flag on the [Files] section entry, but this is NOT recommended.)
Any DLL file from own Windows System directory
You should not deploy any DLLs out of your own Windows System directory to {sys} because most of them are tailored for your own specific version of Windows, and will not work when installed on other versions. Often times a user's system will be rendered unbootable if you install a DLL from a different version of Windows. Another reason why it's a bad idea is that when you install programs on your computer, the DLLs may be replaced with different/incompatible versions without your knowledge. This could lead to unexpected and difficult-to-trace problems on users' systems when you build new installations.
Instead of deploying the DLLs from your Windows System directory, you should find versions that are specifically deemed "redistributable". Redistributable DLLs typically work on more than one version of Windows. To find redistributable versions of the Visual Basic and Visual C++ run-time DLLs, see the Inno Setup FAQ.
If you have a DLL residing in the Windows System directory that you are absolutely sure is redistributable, copy it to your script's source directory and deploy it from there instead.
These are all core components of Windows and must never be deployed with an installation. Users may only get new versions of these DLLs by installing a new version of Windows or a service pack or hotfix for Windows.
If DestDir is set to a location other than {sys} and the regserver or regtypelib flag is used, then the above files will be considered "unsafe". These files must never be deployed to and registered in a directory other than {sys} because doing so can potentially cause all programs on the system to use them in favor of the files in {sys}. Problems would result if your copies of the files are older than the ones in {sys}. Also, if your copies of the files were removed, other applications would break.
COMCTL32.DLL
Microsoft does not allow separate redistribution of COMCTL32.DLL (and for good reason - the file differs between platforms), so you should never place COMCTL32.DLL in a script's [Files] section. You can however direct your users to download the COMCTL32 update from Microsoft, or distribute the COMCTL32 update along with your program.
SHDOCVW.DLL, SHLWAPI.DLL, URLMON.DLL, WININET.DLL
These are core components of Internet Explorer and are also used by Windows Explorer. Replacing them may prevent Explorer from starting. If your application depends on these DLLs, or a recent version of them, then your users will need to install a recent version of Internet Explorer to get them.
MSCOREE.DLL
This file is part of the Microsoft .NET Framework. You cannot safely install or update the .NET Framework by including this file with your installation. Call or direct your users to dotnetfx.exe instead.
Inno Setup was created by Jordan Russell and is currently maintained by Martijn Laan (since 5.4.3, released in 2011).
The following is a list of those who have contributed significant code to the Inno Setup project, or otherwise deserve special recognition:
Jean-loup Gailly & Mark Adler: Creators of the zlib compression library that Inno Setup uses.
Julian Seward: Creator of the bzlib compression library that Inno Setup uses.
Igor Pavlov: Creator of the 7-Zip and LZMA SDK libraries that Inno Setup uses.
Vince Valenti: Most of the code for the "Window" [Setup] section directives (1.12.4 - 6.3.3).
Joe White: Code for ChangesAssociations [Setup] section directive (1.2).
Jason Olsen: Most of the code for appending to existing uninstall logs (1.3).
Martijn Laan: Rich Edit 2.0 & URL detection support (1.3.13); Silent uninstallation (1.3.25); System image list support in drive and directory lists (1.3.25); Silent installation (2.0); The [Types], [Components] and [Tasks] sections (2.0); The postinstall flag (2.0); The [Code] section (4.0); Subcomponents and subtasks support (4.0); Many other features after 4.0.
Alex Yackimoff: Portions of TNewCheckListBox (4.0); ISPP (5.4.1).
Carlo Kok: RemObjects Pascal Script (4.0).
Creators of SynEdit: The syntax-highlighting editor used in the Compiler IDE (2.0 - 5.2.4).
Creators of UniSynEdit: The syntax-highlighting editor used in the Compiler IDE (5.3 - 5.3.11).
Creators of Scintilla: The syntax-highlighting editor used in the Compiler IDE (5.4).
Zaher Dirkey: Initial work on improved right-to-left languages support (5.2.3).
Evgeny Karpov of RemObjects Software: Initial work on Unicode support (5.3).
Motaz Alnuweiri: 128x128 and 256x256 sizes of the Compiler IDE and document icons (5.5.3).
DRON: Code for the improved image stretching (5.6).
Sherlock Software: Most of the x86 code for the CreateCallback support function (6.0).
Vizit0r: Code for the "Debug Call Stack" view (6.0.3).
Cristoph Nahr: Code for the .NET version detection (6.0.4).
Sergii Leonov: Code for the Compiler IDE's MsgBox tool (6.1.0) and initial work on its [Registry] tool (6.3.0).
Jens Geyer: Initial work on closeable tabs in the Compiler IDE (6.3.0).
ser163: Code for the Compiler IDE's [Files] tool (6.3.0).
Special thanks to everyone answering questions on the forum and on Stack Overflow, especially: Gavin Lambert, Deanna Hants, Jernej Simončič, Martin Prikryl and TLama.
To support our development efforts, we request that all commercial users of Inno Setup purchase licenses, regardless of the version being used.
Thank you for helping ensure the continued development of this software.
After purchase, you will receive your license key via email. If you do not receive your key in your inbox, please check your spam or junk folder. The sender address is innosetup@mlsoft.nl. Please make sure it is not blocked by your email system.
Once you have received your key, copy and paste it into the 'Enter Commercial License Key' dialog in the Inno Setup Compiler IDE, which can be opened from the 'Help' menu.
Your license key can also be activated for a user by writing it as a single line to the following registry key:
You can do this before or after installation, or even while Inno Setup is running.
A license key is a string of at least 108 characters. It always starts with 'in' and ends with 'no', without the quotes. To users the key is presented as multiple lines of 28 characters per line.
Please note that installers built without a license are not explicitly marked as unlicensed. This means you may choose not to install the license key on a CI machine, even if we ask you to assign a license to it.
Also see Donate to Inno Setup.
We're not requesting that non-commercial users purchase licenses - but donations of any amount, from both non-commercial and commercial users, are accepted and appreciated.
Thank you for helping ensure the continued development of this software.
Also see Purchase Inno Setup.
yes or no or x86 or x64(see below)
This tells the compiler which type of Setup to create. If this is no, it compiles the setup data into at least three files: setup.exe, setup-0.bin, and setup-1.bin. The only reason you would probably want to use no is for debugging purposes. Otherwise, it compiles all setup data into a single EXE
When all setup data is compiled into a single EXE, a "Setup Loader" program is used, called SetupLdr. When using yes or x86, a 32-bit version of SetupLdr is used which runs on systems capable of running 32-bit x86 binaries. This includes systems running x86 Windows, x64 Windows, and also Arm64 Windows 10 and 11 systems, which have the ability to run x86 binaries via emulation.
Otherwise, when using x64, a 64-bit version of SetupLdr is used which runs on systems capable of running x64 binaries. This includes systems running x64 Windows, and also Arm64-based Windows 11 systems, which have the ability to run x64 binaries via emulation.
Matches the value of SetupArchitecture by default.
Note: Do not use no on an installation which uses disk spanning (DiskSpanning=yes). When using yes, the setup program is copied to and run from the user's TEMP directory. This does not happen when using no, and could result in errors if Windows tries to locate the setup.exe file on the disk and can't find it because a different disk is in the drive.
Note: Do not use no to avoid digital signature verification startup delays on a large Setup, use disk spanning instead. See SignTool for more information. Also note that digitally signing Setup when using no will lead to an invalid digital signature for Uninstall.
This required directive specifies the name of the application being installed. Do not include the version number, as that is defined by the AppVersion and/or AppVerName directives. AppName is displayed throughout the Setup program and uninstaller in window titles, wizard pages, and dialog boxes. The value may include constants.
If DisableWelcomePage is set to yes (which it is by default) then AppVerName is displayed in window titles instead of AppName.
The value of this directive is also used as the default value for the AppId, VersionInfoDescription, and VersionInfoProductName directives if those are not specified.
AppName=My Program
See also:
AppVerName
This directive specifies the version number of the application being installed. The value of this directive, which may include constants, is used in the default value for the AppVerName directive, and is displayed in the Version field of the application's Add/Remove Programs entry. It is also used to set the MajorVersion and MinorVersion values in the Uninstall registry key when possible.
This directive is required and cannot be empty if the AppVerName directive is not set.
AppVersion=1.5
AppName version AppVersion, localized according to the active language's NameAndVersion custom message
This directive specifies the name of the application plus its version number. The value of this directive is displayed on the Welcome page of Setup's wizard, and is used as the default title of the application's Add/Remove Programs entry (see UninstallDisplayName). The value may include constants.
If DisableWelcomePage is set to yes (which it is by default) then AppVerName is also displayed in window titles instead of AppName.
This directive is required if the AppVersion directive is not set.
AppVerName=My Program 1.5
AppVerName=My Program version 1.5
AppVerName={cm:NameAndVersion,My Program,1.5}
See also:
AppName
AppName
The value of AppId is stored inside uninstall log files (unins???.dat), and is checked by subsequent installations to determine whether it may append to a particular existing uninstall log. Setup will only append to an uninstall log if the AppId of the existing uninstall log is the same as the current installation's AppId. For a practical example, say you have two installations -- one entitled My Program and the other entitled My Program 1.1 Update. To get My Program 1.1 Update to append to My Program's uninstall log, you would have to set AppId to the same value in both installations.
AppId also determines the actual name of the Uninstall registry key, to which Inno Setup tacks on "_is1" at the end. (Therefore, if AppId is "MyProgram", the key will be named "MyProgram_is1".) Pre-1.3 versions of Inno Setup based the key name on the value of AppVerName.
AppId is a not used for display anywhere, so feel free to make it as cryptic as you desire. The value may include constants.
If you use a {code:..} constant to allow your user to customize AppId, you do not need to return the real value until just before the installation starts: if necessary you may return an empty or generic value at earlier times. If not empty, this value will only be used to attempt to restore previous install settings (like the settings stored by [Setup] section directive UsePreviousAppDir). If empty, it isn't used for anything.
The length of AppId with all constants evaluated should never exceed 127 characters.
AppId=MyProgram
This directive is used to prevent the user from installing new versions of an application while the application is still running, and to prevent the user from uninstalling a running application. It specifies the names of one or more named mutexes (multiple mutexes are separated by commas), which Setup and Uninstall will check for at startup. If any exist, Setup/Uninstall will display the message: "[Setup or Uninstall] has detected that [AppName] is currently running. Please close all instances of it now, then click OK to continue, or Cancel to exit." The value may include constants.
Use of this directive requires that you add code to your application which creates a mutex with the name you specify in this directive. Examples of creating a mutex in Delphi, C, and Visual Basic are shown below. The code should be executed during your application's startup.
Delphi:
CreateMutex(nil, False, 'MyProgramsMutexName');
C:
CreateMutex(NULL, FALSE, "MyProgramsMutexName");
Visual Basic (submitted by Peter Young):
'Place in Declarations section:
Private Declare Function CreateMutex Lib "kernel32" _
Alias "CreateMutexA" _
(ByVal lpMutexAttributes As Long, _
ByVal bInitialOwner As Long, _
ByVal lpName As String) As Long
'Place in startup code (Form_Load or Sub Main):
CreateMutex 0&, 0&, "MyProgramsMutexName"
It is not necessary to explicitly destroy the mutex object upon your application's termination; the system will do this automatically. Nor is it recommended that you do so, because ideally the mutex object should exist until the process completely terminates.
Note that mutex name comparison in Windows is case sensitive.
To specify a mutex name containing a comma, escape the comma with a backslash.
See the topic for CreateMutex in the MS SDK help for more information on mutexes.
This directive is used to prevent Setup from running while Setup is already running. It specifies the names of one or more named mutexes (multiple mutexes are separated by commas), which Setup will check for at startup. If any exist, Setup will display the message: "Setup has detected that Setup is currently running. Please close all instances of it now, then click OK to continue, or Cancel to exit." If none exist, Setup will create the mutex(es) and continue normally. The value may include constants.
To specify a mutex name containing a comma, escape the comma with a backslash.
See the topic for CreateMutex in the MS SDK help for more information on mutexes.
The value of this directive is used as the default value for the VersionInfoCopyright directive if it is not specified.
AppCopyright=Copyright (C) 1997-2005 My Company, Inc.
This string is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppComments=Hello.
This string is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppContact=My Company Customer Support
This string is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
The value of this directive is also used as the default value for the VersionInfoCompany directive if it is not specified.
AppPublisher=My Company, Inc.
AppPublisherURL=http://www.example.com/
A link to the specified URL is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppPublisher=My Company, Inc.
AppPublisherURL=http://www.example.com/
This string, which may be a URL, is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppReadmeFile=http://www.example.com/readme.html
This string is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppSupportPhone=1-800-555-1212
A link to the specified URL is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppSupportURL=http://www.example.com/support.html
A link to the specified URL is displayed on the "Support" dialog of the Add/Remove Programs Control Panel applet. The value may include constants.
AppUpdatesURL=http://www.example.com/updates.html
The value of this required directive is used for the default directory name, which is used in the Select Destination Location page of the wizard. Normally it is prefixed by a directory constant.
If UsePreviousAppDir is yes (the default) and Setup finds a previous version of the same application is already installed, it will substitute the default directory name with the directory selected previously.
If you used:
DefaultDirName={sd}\MYPROG
In Setup, this would typically display:
C:\MYPROG
If you used:
DefaultDirName={autopf}\My Program
In Setup, this would typically display:
C:\Program Files\My Program
yes or no, or a scripted boolean expressionyes
This determines if Inno Setup's automatic uninstaller is to be included in the installation. If this is yes or to a scripted boolean expression evaluating to True the uninstaller is included. Otherwise, no uninstallation support is included, requiring the end-user to manually remove the files pertaining to your application.
Setting this to a boolean expression can be useful if you want to offer the user a 'portable mode' option.
major.minor6.1 or higher6.1sp1 (Windows 7 with Service Pack 1 or Windows Server 2008 R2 with Service Pack 1)
This directive lets you specify a minimum version of Windows that your software runs on. Build numbers and/or service pack levels may be included.
If the user's system does not meet the minimum version requirement, Setup will give an error message and exit.
major.minor0 or higher than 6.10
This directive lets you specify a minimum version of Windows that your software will not run on. Specifying 0 means there is no upper version limit. Build numbers and/or service pack levels may be included.
This directive is essentially the opposite of MinVersion.
yes or noyes
This directive lets you disable warnings about messages missing for a language.
See also:
NotRecognizedMessagesWarning
yes or noyes
This directive lets you disable the missing RunOnceIds warning. See RunOnceId for more information.
yes or noyes
This directive lets you disable warnings about messages not recognized for a language.
See also:
MissingMessagesWarning
yes or noyes
This directive lets you disable the used user areas warning. See Non Administrative Install Mode for more information.
admin, or lowestadmin
This directive affects whether elevated rights are requested (via a User Account Control dialog) when the installation is started.
When set to admin (the default), Setup will always run with administrative privileges and in administrative install mode. If Setup was started by an unprivileged user, Windows will ask for the password to an account that has administrative privileges, and Setup will then run under that account.
When set to lowest, Setup will not request to be run with administrative privileges even if it was started by a member of the Administrators group and will always run in non administrative install mode. Do not use this setting unless you are sure your installation will run successfully on unprivileged accounts.
See also:
PrivilegesRequiredOverridesAllowed
One or more of the following, separated by spaces: commandline dialog(blank)
Can be set to one or more overrides which allow the end user to override the script's default PrivilegesRequired setting.
If override commandline is allowed then Setup will support two additional command line parameters to override the script's default PrivilegesRequired setting: /ALLUSERS and /CURRENTUSER. See Setup Command Line Parameters for more details.
If override dialog is allowed then Setup will ask the user to choose the install mode based on the script's default PrivilegesRequired setting using a suppressible dialog. Allowing dialog automatically allows commandline and when one of the command line parameters is used then Setup will not ask the user.
See also:
UsePreviousPrivileges
yes or noyes
Controls whether Setup attempts to enable Windows' RedirectionGuard mitigation on its own process. Uninstall also enables RedirectionGuard for its process if it was successfully enabled during the most recent installation of the application.
The RedirectionGuard mitigation, available on Windows 11 and Windows 10 22H2, blocks traversal of NTFS junctions and symbolic links created by unprivileged users (or any non-elevated processes).
RedirectionGuard is particularly of benefit to installers that read or write files in locations that are writable by unprivileged users, such as {commonappdata}. For example, if an installer is known to access {commonappdata}\YourApp, an unprivileged user could create a junction at that location to redirect all traversals of {commonappdata}\YourApp to some other arbitrarily-chosen path. If the installer doesn't enable RedirectionGuard, then the junction could trick the installer into creating or modifying files in a directory that the unprivileged user cannot access themselves. This constitutes privilege escalation, and could potentially allow the unprivileged user to gain full control over the system.
Best practice, however, is to avoid accessing publicly-writable locations like {commonappdata} whenever possible. Configuration files and data files that are only meant to be written by the installer or administrators should be placed under {app} (i.e., Program Files), not {commonappdata}.
Note that this setting only affects Setup/Uninstall's own process. It is not inherited by any child processes, nor does it enable RedirectionGuard for the application that is installed. Applications that access files in publicly-writable locations should consider enabling RedirectionGuard on their own process, or checking for the reparse point attribute (FILE_ATTRIBUTE_REPARSE_POINT) on each directory and file that is accessed.
When RedirectionGuard blocks access to a path, any error message shown or logged will typically include the error code 448. If it turns out that a blocked junction was actually created for some non-malicious purpose, then the recommended course of action is to delete and recreate the junction with administrative privileges (by running MKLINK from an elevated Command Prompt). Disabling RedirectionGuard shouldn't be necessary.
Setup and Uninstall both support /NOREDIRECTIONGUARD and /REDIRECTIONGUARD parameters to override this setting from the command line.
RedirectionGuard status is logged, so you can verify whether the mitigation was active during installation/uninstallation.
See also:
Setup Command Line Parameters
Uninstaller Command Line Parameters
One or more of the following, separated by spaces: setup setupcustomstyle setupldr is7z isbunzip isunzlib islzma(blank)
The compiler verifies precompiled files before using them. For certain files, you can disable verification if necessary. Use this directive to specify the list of files that should not be verified.
setupldr applies to both setupldr.e32 and setupldr.e64. is7z applies not only to isz7.dll, but also to both is7zxr.dll and is7zxa.dll. islzma applies to both islzma32.exe and islzma64.exe.
yes or nono
Obsolete in 4.1.2. Pre-4.1.2 versions of Inno Setup had a different directory selection interface, and the DisableAppendDir directive was used to control its behaviour.
yes or nono
When set to yes, Setup will display a message box if the directory the user selects doesn't exist. Usually you will also set DirExistsWarning=no when this is yes.
Obsolete in 3.0. This directive is no longer supported. If you wish to create an Uninstall icon, use the new {uninstallexe} constant in the Filename parameter of an [Icons] section entry.
0
Normally, the disk space requirement displayed on the wizard is calculated by adding up the size of all the files in the [Files] section. If you want to increase the disk space display for whatever reason, set ExtraDiskSpaceRequired to the amount of bytes you wish to add to this figure. (1048576 bytes = 1 megabyte)
Supports digit separators and set in bytes. (1048576 bytes = 1 megabyte)
[Setup]
ExtraDiskSpaceRequired=1_048_576
basic enhanced/nopassword enhanced fullbasic
This specifies the method of archive extraction used by [Files] section flag extractarchive and support functions ExtractArchive and CreateExtractionPage.
basic uses an embedded version of the "7z ANSI-C Decoder" from the LZMA SDK by Igor Pavlov, as-is, except that Unicode support and error messages were improved and that it outputs memory requirements. It only supports .7z archives that are not password-protected.
enhanced/nopassword internally uses 7zxr.dll from the 7-Zip source code by Igor Pavlov, as-is, except that it was recompiled, code-signed, and renamed to is7zxr.dll. Compared to basic, it has lower memory requirements for archives that contain large files but increases the size of the Setup file(s). It still only supports .7z archives that are not password-protected.
enhanced uses 7zxa.dll instead of 7zxr.dll, recompiled, code-signed, and renamed to is7zxa.dll. It still only supports .7z archives, but they may be password-protected.
full uses 7z.dll instead of 7zxa.dll, recompiled, code-signed, and renamed to is7z.dll. It supports multiple archive formats, although not as many as the original 7z.dll, to reduce its size. Additionally, it supports multi-volume archives.
The following table summarizes the differences between these methods.
* = When using a 32-bit installer.
** = When extracting a file, at least enough memory will always be allocated to hold the entire file, regardless of the block size. For example, extracting a 1 GB file using the basic method requires at least 1 GB of RAM. Consider using a different method for .7z archives that contain large files: their memory requirements depend on the dictionary size only.
All methods overwrite read-only files which already exist in the destination directory without prompting the user.
All methods restore the following file properties from the archive, if available: creation time, last modified time, attributes.
When using the full method to extract a compressed archive, such as archive.tar.gz, the output will be the archive file itself (e.g., archive.tar) rather than the individual files contained within it.
The basic method has the following additional limitations, as written by Igor Pavlov in the LZMA SDK:
It does not support PPMd and BZip2 methods.
It converts original UTF-16 Unicode file names to UTF-8 Unicode file names.
It decodes whole solid block from 7z archive to RAM. The RAM consumption can be high.
See also:
ExtractArchive
MapArchiveExtensions
CreateExtractionPage
zip zip/1 through zip/9 bzip bzip/1 through bzip/9 lzma lzma/fast lzma/normal lzma/max lzma/ultra (review memory requirements below before using) lzma/ultra64 (review memory requirements below before using) lzma2 lzma2/fast lzma2/normal lzma2/max lzma2/ultra (review memory requirements below before using) lzma2/ultra64 (review memory requirements below before using) nonelzma2/max
This specifies the method of compression to use on the files, and optionally the level of compression. Higher levels compress better but take longer doing so, and may also require more memory while compressing/decompressing.
zip is the method of compression employed by .zip files ("deflate"). It is fast in both compression and decompression, and has very low memory requirements (less than 1 MB for both compression and decompression at level 9), but generally does not compress nearly as well as the other supported methods. zip, like lzma2, has one special property, though: it will not expand incompressible data (e.g., files that are already compressed). If a compression level isn't specified, it defaults to 7.
bzip is the method of compression employed by the bzip2 compressor. It almost always compresses better than zip but is usually slower in both compression and decompression. Up to 4 MB of memory is required during decompression, and up to 8 MB during compression. If a compression level isn't specified, it defaults to 9.
lzma is the method of compression employed by the 7-Zip LZMA compressor. It typically compresses significantly better than the zip and bzip methods. However, depending on the compression level used, it can be significantly slower at compressing, and consume a lot more memory. The following table summarizes the approximate memory requirements for each of the supported lzma compression levels. If a compression level isn't specified, it defaults to max.
Decompression (dictionary size)
Compression (6 MB + 11.5 * dictionary size)
fast (worst)
32 KB
6 MB
normal
2 MB
29 MB
max (default)
8 MB
98 MB
ultra
32 MB
374 MB
ultra64
64 MB
742 MB
128 MB
1.44 GB
256 MB
2.88 GB
512 MB
5.76 GB
1 GB
11.51 GB
2 GB
23.01 GB
3 GB
34.51 GB
3.8 GB
43.13 GB
Dictionary sizes larger than 1 GB are only supported by 64-bit Setup.
The compression memory requirements are approximately 60% of the above when LZMAMatchFinder is set to HC at the expense of compression ratio.
lzma2 is the method of compression employed by the 7-Zip LZMA2 compressor. LZMA2 is a modified version of LZMA that offers a better compression ratio for incompressible data (random data expands about 0.005%, compared to 1.35% with original LZMA), and optionally can compress multiple parts of large files in parallel, greatly increasing compression speed but with a possible reduction in compression ratio (see LZMANumBlockThreads). If a compression level isn't specified, it defaults to max. Like LZMA, LZMA2 can consume a lot of memory; see the above table. Do note: LZMA2 only supports a limited number of dictionary sizes and other sizes will be rounded up to the next supported size. Supported sizes are powers of two starting at 4 (4, 8, 16, 32, etc.) and the midway points between them (6, 12, 24, etc.). For instance, a dictionary size of 524289 (512 MB + 1 byte) has the same memory requirements as one of 786432 (768 MB).
none specifies that no compression be used.
See also:
SolidCompression
LZMAAlgorithm
LZMABlockSize
LZMADictionarySize
LZMAMatchFinder
LZMANumBlockThreads
LZMANumFastBytes
LZMAUseSeparateProcess
auto 1 2 (or higher)auto
Controls whether the multi-threaded match finder is enabled on the LZMA and LZMA2 compressors. Enabling the multi-threaded match finder can speed up the compression process by 50% or more on systems with multiple processor cores, and 20% or more on systems with Intel processors featuring Hyper-Threading Technology.
A value of auto (the default) enables the multi-threaded match finder for all compression levels except fast, which doesn't support it.
A value of 1 always disables the multi-threaded match finder.
Values of 2 or higher are currently equivalent to auto.
Note that for the LZMA2 compressor, this directive only controls whether the multi-threaded match finder is used. To enable support for compressing multiple parts of large files in parallel, set LZMANumBlockThreads.
See also:
LZMANumBlockThreads
yes or nono
If yes, solid compression will be enabled. This causes all files to be compressed at once instead of separately. This can result in a much greater overall compression ratio if your installation contains many files with common content, such as text files, especially if such common content files are grouped together within the [Files] section.
The disadvantage to using solid compression is that because all files are compressed into a single compressed stream, Setup can no longer randomly access the files. This can decrease performance. If a certain file isn't going to be extracted on the user's system, it has to decompress the data for that file anyway (into memory) before it can decompress the next file. And if, for example, there was an error while extracting a particular file and the user clicks Retry, it can't just seek to the beginning of that file's compressed data; since all files are stored in one stream, it has seek to the very beginning. If disk spanning was enabled, the user would have to re-insert disk 1.
none, or one of the LZMA compression levelsnormal
This specifies the level of LZMA compression to use on Setup's internal structures. Generally, there is little reason to change this from the default setting of normal.
yes or noyes
If this is set to no, no directory for the application will be created, the Select Destination Location wizard page will not be displayed, and the {app} directory constant is equivalent to the {win} directory constant. If the uninstall feature is enabled when CreateAppDir is no, the uninstall data files are created in the system's Windows directory.
yes or no, or a scripted boolean expressionyes
If this is set to no or to a scripted boolean expression evaluating to False, Setup won't create an entry in the Add/Remove Programs Control Panel applet.
Setting this to no can be useful if your installation is merely an update to an existing application and you don't want another entry created, but don't want to the disable the uninstall features entirely (via Uninstallable=no). In this case, UpdateUninstallLogAppName is usually set to no as well.
See also:
Uninstallable
auto, yes, or noauto
When set to auto, the default setting, Setup will show a "The directory ... already exists. Would you like to install to that directory anyway?" message if the user selects a directory that already exists on the Select Destination Location wizard page, except when another version of the same application is already installed and the selected directory is the same as the previous one (only if UsePreviousAppDir is yes, the default setting).
When set to yes, Setup will always display the "Directory Exists" message when the user selects an existing directory.
When set to no, Setup will never display the "Directory Exists" message.
auto, yes, or noauto
If this is set to yes, Setup will not show the Select Destination Location wizard page.
If this is set to auto, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will not show the Select Destination Location wizard page.
If the Select Destination Location wizard page is not shown, it will always use the default directory name.
Also see AlwaysShowDirOnReadyPage.
yes or nono
If this is set to yes, Setup will not show the Setup Completed wizard page, and instead will immediately close the Setup program once the installation process finishes. This may be useful if you execute a program in the [Run] section using the nowait flag, and don't want the Setup Completed window to remain in the background after the other program has started.
Note that the DisableFinishedPage directive is ignored if a restart of the computer is deemed necessary, or if a file is assigned to the InfoAfterFile[Setup] section directive. In those cases, the Setup Completed wizard page will still be displayed.
auto, yes, or noauto
If this is set to yes, Setup will not show the Select Start Menu Folder wizard page.
If this is set to auto, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will not show the Select Start Menu Folder wizard page.
If the Select Start Menu Folder wizard page is not shown, it will always use the default Start Menu folder name.
Also see AlwaysShowGroupOnReadyPage.
yes or nono
If this is set to yes, Setup will not show a list of settings on the Ready to Install wizard page. Otherwise the list is shown and contains information like the chosen setup type and the chosen components.
yes or nono
If this is set to yes, Setup will not show the Ready to Install wizard page.
When Setup is not running silently, this directive is ignored if no other wizard page before the Ready to Install wizard page has been shown yet.
Setting this to yes does not automatically change the caption of the Next button on the new last pre-installation wizard page to Install. You must do so manually instead. For example, if the new last pre-installation wizard page is the Select Program Group page:
[Setup]
DisableReadyPage=yes
[Code]
procedure CurPageChanged(CurPageID: Integer);
begin
if CurPageID in [wpSelectProgramGroup, wpReady] then
WizardForm.NextButton.Caption := SetupMessage(msgButtonInstall)
else if CurPageID = wpFinished then
WizardForm.NextButton.Caption := SetupMessage(msgButtonFinish)
else
WizardForm.NextButton.Caption := SetupMessage(msgButtonNext);
end;
yes or noyes
If this is set to yes, Setup will not show the Welcome wizard page.
yes or nono
If this is set to yes, Setup will show a User Information wizard page which asks for the user's name, organization and possibly a serial number. The values the user enters are stored in the {userinfoname}, {userinfoorg} and {userinfoserial} constants. You can use these constants in [Registry] or [INI] entries to save their values for later use.
For the serial number field to appear, a CheckSerial event function must be present.
The DefaultUserInfoName, DefaultUserInfoOrg and DefaultUserInfoSerial directives determine the default name, organization and serial number shown. If UsePreviousUserInfo is yes (the default) and Setup finds that a previous version of the same application is already installed, it will use the name, organization and serial number entered previously instead.
On silent installs, the default user name, organization, and serial number values will be assumed. Setup will not check whether the user name is blank (since the user has no way of correcting it), however it will still check the serial number.
{sysuserinfoname}
Specifies the default name shown on the User Information wizard page. This can include constants.
{sysuserinfoorg}
Specifies the default organization shown on the User Information wizard page. This can include constants.
Specifies the default serial number shown on the User Information wizard page. This can include constants.
yes or nono
Normally, Inno Setup's {group} constant points to the All Users start menu if the user has administrative privileges. If this directive is set to yes, it always uses current user's profile.
You should be careful about using this option: it may not achieve what you are intending. The compiler will warn you about this, which can be disabled using UsedUserAreasWarning.
yes or noyes
If set to no the compiler will only check the script for errors and skip creating setup files. Note: it will still clean the output directory and delete the manifest file, unless OutputDir and OutputManifestFile are set to an empty string.
mysetup
This directive allows you to assign a different name for the resulting Setup file(s), so you don't have to manually rename them after running the compiler.
Setting this to setup is not recommended: all executables named "setup.exe" are shimmed by Windows application compatibility to load additional DLLs, such as version.dll. These DLLs are loaded unsafely by Windows and can be hijacked.
OutputBaseFilename=MyProg100
{app}
Specifies the directory where the "unins*.*" files for the uninstaller are stored.
Note: You should not assign a different value here on a new version of an application, or else Setup won't find the uninstall logs from the previous versions and therefore won't be able to append to them.
UninstallFilesDir={app}\uninst
This lets you specify a particular icon file (either an executable or an .ico file) to display for the Uninstall entry in the Add/Remove Programs Control Panel applet. The filename will normally begin with a directory constant.
If the file you specify contains multiple icons, you may append the suffix ",n" to specify an icon index, where n is the zero-based numeric index.
If this directive is not specified or is blank, Windows will select an icon itself, which may not be the one you prefer.
This lets you specify a custom name for the program's entry in the Add/Remove Programs Control Panel applet. The value may include constants. If this directive is not specified or is blank, Setup will use the value of [Setup] section directive AppVerName for the name.
UninstallDisplayName=My Program
See also:
Side-by-side installation
On Windows 7 and later, Setup uses this directive to set the EstimatedSize value in the Uninstall registry key when possible since the Windows 7 Add/Remove Programs Control Panel (called Program and Features) no longer automatically calculates it. If an UninstallDisplaySize is not set, Setup estimates the size itself by taking the size of all files installed and adding any ExtraDiskSpaceRequired values set. Note: Windows 7 without any service pack only supports the display of values smaller than 4 GB.
Supports digit separators and set in bytes. (1048576 bytes = 1 megabyte)
UninstallDisplaySize=1_073_741_824
Obsolete in 3.0. This directive is no longer supported. If you wish to create an Uninstall icon, use the new {uninstallexe} constant in the Filename parameter of an [Icons] section entry.
yes or nono
If set to yes, the uninstaller will always create a log file if it is launched from the Add/Remove Programs Control Panel applet. Equivalent to passing /LOG on the command line.
This directive has no effect if CreateUninstallRegKey is not set to yes.
See also:
SetupLogging
append, new, or overwriteappend
append, the default setting, instructs Setup to append to an existing uninstall log when possible.
new, which corresponds to the behavior in pre-1.3 versions of Inno Setup, instructs Setup to always create a new uninstall log.
overwrite instructs Setup to overwrite any existing uninstall logs from the same application instead of appending to them (this is not recommended). The same rules for appending to existing logs apply to overwriting existing logs.
UninstallLogMode=append
yes or nono
When set to yes, the uninstaller will always prompt the user to restart the system at the end of a successful uninstallation, regardless of whether it is necessary (e.g., because of [Files] section entries with the uninsrestartdelete flag).
yes or noyes
If yes, when appending to an existing uninstall log, Setup will replace the AppName field in the log with the current installation's AppName. The AppName field of the uninstall log determines the title displayed in the uninstaller. You may want to set this to no if your installation is merely an upgrade or add-on to an existing program, and you don't want the title of the uninstaller changed.
The value of this directive is used for the default Start Menu folder name on the Select Start Menu Folder page of the wizard. If this directive is blank or isn't specified, it will use "(Default)" for the name.
Keep in mind that Start Menu folders are stored as literal directories so any characters not allowed in normal directory names can't be used in Start Menu folder names.
DefaultGroupName=My Program
yes or noyes
When this is set to yes, Setup will not show the This will install... Do you wish to continue? prompt.
This setting has no effect if UseSetupLdr is set to no.
yes or nono
If set to yes, the disk spanning feature will be enabled. Instead of storing all the compressed file data inside Setup.exe, the compiler will split it into multiple Setup-*.bin files -- known as "slices" -- suitable for copying onto separate CD-ROMs or DVD-ROMs. Each generated slice contains a number in its name which indicates the disk onto which it should be copied. (For example, Setup-2.bin should be placed on disk 2.) The generated Setup.exe always goes on disk 1 along with the Setup-1*.bin file.
The size of each slice and the number of slices to create for each disk are determined by the values of the DiskSliceSize and SlicesPerDisk [Setup] section directives, respectively. Other disk spanning-related directives that you may want to tweak include DiskClusterSize and ReserveBytes.
Note that it is required that you set this directive to yes if the compressed size of your installation exceeds 4,200,000,000 bytes, even if you don't intend to place the installation onto multiple disks. (The installation will still function correctly if all the Setup-*.bin files are placed on the same disk.)
262144 through 9223372036800000000, or max2100000000
This specifies the maximum number of bytes per disk slice (Setup-*.bin file). Normally, this should be set to the total number of bytes available on the disk media divided by the value of the SlicesPerDisk[Setup] section directive, which defaults to 1.
This directive is ignored if disk spanning is not enabled using the DiskSpanning[Setup] section directive.
To optimally fill 4.7 GB recordable DVDs, use:
SlicesPerDisk=3
DiskSliceSize=1566000000
To optimally fill 8.5 GB (dual-layer) recordable DVDs, use:
SlicesPerDisk=5
DiskSliceSize=1708200000
To optimally fill 700 MB (80-minute) recordable CDs, use:
SlicesPerDisk=1
DiskSliceSize=736000000
512
This specifies the cluster size of the disk media. The compiler needs to know this in order to properly fill each disk to capacity.
This directive is ignored if disk spanning is not enabled using the DiskSpanning[Setup] section directive.
1 through 261
The number of Setup-*.bin files to create for each disk. If this is 1 (the default setting), the files will be named Setup-x.bin, where x is the disk number. If this is greater than 1, the files will be named Setup-xy.bin, where x is the disk number and y is a unique letter.
One reason why you may need to increase this from the default value of 1 is if the size of your disk media exceeds 2,100,000,000 bytes -- the upper limit of the DiskSliceSize[Setup] section directive. If, for example, your disk media has a capacity of 3,000,000,000 bytes, you can avoid the 2,100,000,000-byte disk slice size limit by setting SlicesPerDisk to 2 and DiskSliceSize to 1500000000 (or perhaps slightly less, due to file system overhead).
0
This specifies the minimum number of free bytes to reserve on the first disk. This is useful if you have to copy other files onto the first disk that aren't part of the setup program, such as a Readme file.
The compiler rounds this number up to the nearest cluster.
This directive is ignored if disk spanning is not enabled using the DiskSpanning[Setup] section directive.
yes or noyes
Normally two file entries referring to the same source file will be compressed and stored only once. If you have a bunch of identical files in your installation, make them point to the same source file in the script, and the size of your installation can drop significantly. If you wish to disable this feature for some reason, set this directive to no.
yes or no
Obsolete in 4.2.5. Use MergeDuplicateFiles instead.
MergeDuplicateFiles=no is equivalent to DontMergeDuplicateFiles=yes.
yes or noyes
Setting this to no prevents the user from cancelling during the actual installation process, by disabling the Cancel button and ignoring clicks on the close button. This has the same effect as passing /NOCANCEL to Setup on the command line.
yes or nono
When set to yes, Setup will display a Don't create a Start Menu folder check box on the Select Start Menu Folder wizard page, which allows the user to skip creation of program shortcuts on the Start Menu.
Only [Icons] entries that have a Name parameter starting with {group}\ and no Tasks parameter are affected by default. To force the check box to have an effect on a particular [Icons] entry, add a Check: not WizardNoIcons parameter.
yes or nono
When set to no, the default, the user will not be allowed to enter a root directory (such as "C:\") on the Select Destination Location page of the wizard.
yes or noyes
If set to no, the user will not be allowed to enter a UNC path (such as "\\server\share") on the Select Destination Location page of the wizard.
To fully disallow installation to network locations, you must also set AllowNetworkDrive to no.
yes or noyes
If set to no, the user will not be allowed to enter a network drive on the Select Destination Location page of the wizard.
To fully disallow installation to network locations, you must also set AllowUNCPath to no.
yes or nono
When set to yes, Setup will always prompt the user to restart the system at the end of a successful installation, regardless of whether this is necessary (for example, because of [Files] section entries with the restartreplace flag).
yes or noyes
When set to yes, and a program executed in the [Run] section queues files to be replaced on the next reboot (by calling MoveFileEx or by modifying wininit.ini), Setup will detect this and prompt the user to restart the computer at the end of installation.
Obsolete in 4.0. This directive is no longer supported. Use the new [Languages] section to specify a custom messages file.
Specifies the name of an optional license agreement file, in .txt or .rtf (rich text) format, which is displayed before the user selects the destination directory for the program. This file must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
If the user selects a language for which the LicenseFile parameter is set, this directive is effectively ignored. See the [Languages] section documentation for more information.
If an Unicode .txt file is used, it must be UTF-8 (with or without a BOM) or UTF-16LE encoded.
If using a .rtf file with custom colors, be mindful of contrast ratios, especially if supporting a dark style. Aim for at least an AA pass for normal text, using a contrast checker. Example colors that pass on both light and dark backgrounds include: red #eb0000, green #008a00, and blue #6161ff.
LicenseFile=license.txt
See also:
InfoBeforeFile
InfoAfterFile
Specifies the name of an optional "readme" file, in .txt or .rtf (rich text) format, which is displayed before the user selects the destination directory for the program. This file must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
If the user selects a language for which the InfoBeforeFile parameter is set, this directive is effectively ignored. See the [Languages] section documentation for more information.
If an Unicode .txt file is used, it must be UTF-8 (with or without a BOM) or UTF-16LE encoded.
If using a .rtf file with custom colors, see LicenseFile for special considerations.
InfoBeforeFile=infobefore.txt
See also:
InfoAfterFile
LicenseFile
Specifies the name of an optional "readme" file, in .txt or .rtf (rich text) format, which is displayed after a successful install. This file must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
This differs from isreadme files in that this text is displayed as a page of the wizard, instead of in a separate Notepad window.
If the user selects a language for which the InfoAfterFile parameter is set, this directive is effectively ignored. See the [Languages] section documentation for more information.
If an Unicode .txt file is used, it must be UTF-8 (with or without a BOM) or UTF-16LE encoded.
If using a .rtf file with custom colors, see LicenseFile for special considerations.
InfoAfterFile=infoafter.txt
See also:
InfoBeforeFile
LicenseFile
yes or no, or a scripted boolean expressionno
When set to yes or to a scripted boolean expression evaluating to True, Setup will tell Explorer to refresh its file associations information at the end of the installation, and Uninstall will do the same at the end of uninstallation.
If your installation creates a file association but doesn't have ChangesAssociations set to yes, the correct icon for the file type likely won't be displayed until the user logs off or restarts the computer.
yes or no, or a scripted boolean expressionno
When set to yes or to a scripted boolean expression evaluating to True, at the end of the installation Setup will notify other running applications (notably Windows Explorer) that they should reload their environment variables from the registry.
If your installation creates or changes an environment variable but doesn't have ChangesEnvironment set to yes, the new/changed environment variable will not be seen by applications launched from Explorer until the user logs off or restarts the computer.
yes or no, or a scripted boolean expressionyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will use the directory of the previous installation as the default directory presented to the user in the wizard.
Note that Setup cannot re-use settings from a previous installation that had Uninstallable set to no, since the registry entries it looks for are not created when Uninstallable is no.
yes or no, or a scripted boolean expressionyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will use the Start Menu folder name of the previous installation as the default Start Menu folder name presented to the user in the wizard. Additionally, if AllowNoIcons is set to yes, the Don't create a Start Menu folder setting from the previous installation will be restored.
Note that Setup cannot re-use settings from a previous installation that had Uninstallable set to no, since the registry entries it looks for are not created when Uninstallable is no.
yes or noyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will use the language of the previous installation as the default language presented to the user in the wizard.
Note that this directive does not change the language used by the Select Language dialog itself. See the [Languages] section help topic for details on which language the Select Language dialog uses by default.
Also note that Setup cannot re-use settings from a previous installation that had Uninstallable set to no, since the registry entries it looks for are not created when Uninstallable is no.
UsePreviousLanguage must be set to no when AppId includes constants.
yes or noyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed in one of the two install modes, and if so, it will use that install mode and not ask the user.
If PrivilegesRequiredOverridesAllowed does not allow dialog, this directive is effectively ignored.
UsePreviousPrivileges must be set to no when AppId includes constants and PrivilegesRequiredOverridesAllowed allows dialog.
See also:
PrivilegesRequiredOverridesAllowed
yes or no, or a scripted boolean expressionyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will use the setup type and component settings of the previous installation as the default settings presented to the user in the wizard.
Note that Setup cannot re-use settings from a previous installation that had Uninstallable set to no, since the registry entries it looks for are not created when Uninstallable is no.
yes or no, or a scripted boolean expressionyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will use the task settings of the previous installation as the default settings presented to the user in the wizard.
Note that Setup cannot re-use settings from a previous installation that had Uninstallable set to no, since the registry entries it looks for are not created when Uninstallable is no.
yes or no, or a scripted boolean expressionyes
When this directive is yes, the default, at startup Setup will look in the registry to see if the same application is already installed, and if so, it will use the name, organization and serial number entered previously as the default settings presented to the user on the User Information wizard page.
Note that Setup cannot re-use settings from a previous installation that had Uninstallable set to no, since the registry entries it looks for are not created when Uninstallable is no.
Specifies a password you want to prompt the user for at the beginning of the installation.
When using a password, you might consider setting Encryption to yes as well, otherwise files will be stored as plain text and it would not be exceedingly difficult for someone to gain access to them through reverse engineering.
The password itself is not stored (neither as clear text nor as a hash) but you should still use a strong password.
(see below)
Specifies the name(s) of the image file(s) to display on the left side of the Welcome and Setup Completed wizard pages. Wildcards are supported and the files(s) must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
Supports .bmp and .png images, including those with transparency. Use WizardImageBackColor to customize the background color. Even transparent .bmp files are supported, see WizardImageAlphaFormat for more information. Use WizardImageOpacity to increase transparency.
The size of the area in which the image is displayed depends on the system's DPI setting and whether the default font, WizardSizePercent, and WizardKeepAspectRatio settings are being used. In all cases, an aspect ratio of 164:314 is maintained. The specified image should have the same aspect ratio.
Any size of image may be used; by default, images that are too small or too large to fit in the image area will be stretched or shrunk. Specifying an image larger than 202x386 is recommended to avoid the image looking blurry on higher-DPI systems. The size of the default built-in image is 240x459.
If a single larger-sized image does not produce a satisfactory result across different DPI settings, multiple files may be specified, separated by commas. In that case, Setup will automatically select the one that best matches the size of the image area. Assuming the default font, WizardSizePercent, and WizardKeepAspectRatio settings are being used, the size of the image area at various DPI settings is:
100%
202x386
125%
269x515
150%
336x643
175%
403x772
200%
430x824
225%
498x953
250%
534x1022
(You may notice that the size at 200% is not exactly double the 100% size. This is because the scaling factor is based on the dimensions of the font that a DPI setting uses, not the DPI itself.)
If this directive is not specified, a single built-in 240x459 wizard image will be used, by default stretched or shrunk if the image is larger or smaller than required.
If this directive is set to a blank value, no wizard image will be used. This does not change the layout of the wizard.
If the default settings from before Inno Setup 6.6.0 are being used, the size of the image area at various DPI settings is:
100%
164x314
125%
202x386
150%
240x459
175%
290x556
200%
315x604
225%
366x700
250%
416x797
To use the old default wizard images set this directive to compiler:WizClassicImage.bmp.
WizardImageFile=myimage.bmp,myimage2.bmp
See also:
WizardBackImageFile
WizardSmallImageFile
WizardImageAlphaFormat
WizardImageBackColor
WizardImageOpacity
WizardImageStretch
(blank)
Overrides WizardImageFile when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
For all details see WizardImageFile.
(see below)
Specifies the name(s) of the image file(s) to display in the upper right corner of the wizard. Wildcards are supported and the file(s) must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
Supports .bmp and .png images, including those with transparency. Use WizardSmallImageBackColor to customize the background color. Even transparent .bmp files are supported, see WizardImageAlphaFormat for more information. Use WizardImageOpacity to increase transparency.
The size of the area in which the image is displayed depends on the system's DPI setting and whether the default font settings are being used. In all cases, the area is square; thus, the specified image should be square as well.
Any size of image may be used; by default, images that are too small or too large to fit in the image area will be stretched or shrunk. Specifying an image larger than 58x58 is recommended to avoid the image looking blurry on higher-DPI systems. The size of the default built-in image is 147x147.
If a single larger-sized image does not produce a satisfactory result across different DPI settings, multiple files may be specified, separated by commas. In that case, Setup will automatically select the one that best matches the size of the image area. Assuming the default font settings are being used, the size of the image area at various DPI settings is:
100%
58x58
125%
77x77
150%
97x97
175%
116x116
200%
124x124
225%
143x143
250%
159x159
(You may notice that the size at 200% is not exactly double the 100% size. This is because the scaling factor is based on the dimensions of the font that a DPI setting uses, not the DPI itself.)
Backward compatibility note: If a single image smaller than 58x58 is specified, the image will not be stretched to fill the entire image area; instead, it will be centered.
If this directive is not specified, a single built-in 147x147 wizard image will be used, by default stretched or shrunk if the image is larger or smaller than required.
If this directive is set to a blank value, no wizard image will be used. This does not change the layout of the wizard.
If the default settings from before Inno Setup 6.6.0 are being used, the size of the image area at various DPI settings is:
100%
58x58
125%
71x71
150%
85x85
175%
103x103
200%
112x112
225%
129x129
250%
147x147
To use the old default wizard images set this directive to compiler:WizClassicSmallImage.bmp.
See also:
WizardBackImageFile
WizardImageFile
WizardImageAlphaFormat
WizardSmallImageBackColor
WizardImageOpacity
WizardImageStretch
(blank)
Overrides WizardSmallImageFile when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
For all details see WizardSmallImageFile.
(blank)
Specifies the name(s) of the image file(s) to display as the background of wizard pages in Setup, but not in Uninstall. Wildcards are supported and the files(s) must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
Supports .bmp and .png images, including those with transparency. Use WizardImageBackColor to customize the background color. Even transparent .bmp files are supported, see WizardImageAlphaFormat for more information. Use WizardBackImageOpacity to increase transparency.
The size of the area in which the image is displayed depends on the system's DPI setting and whether the default font, WizardSizePercent, and WizardKeepAspectRatio settings are being used. If WizardKeepAspectRatio is set to yes, which is the default, an aspect ratio of 497:360 is maintained. The specified image should have the same aspect ratio.
Any size of image may be used; by default, images that are too small or too large to fit in the image area will be stretched or shrunk. Specifying an image larger than 596x432 is recommended to avoid the image looking blurry on higher-DPI systems.
If a single larger-sized image does not produce a satisfactory result across different DPI settings, multiple files may be specified, separated by commas. In that case, Setup will automatically select the one that best matches the size of the image area. Assuming the default font, WizardSizePercent, and WizardKeepAspectRatio settings are being used, the size of the image area at various DPI settings is:
100%
596x432
125%
796x576
150%
994x720
175%
1193x864
200%
1272x922
225%
1471x1066
250%
1630x1148
(You may notice that the size at 200% is not exactly double the 100% size. This is because the scaling factor is based on the dimensions of the font that a DPI setting uses, not the DPI itself.)
If this directive is set to a blank value, no background image will be used.
Otherwise, if a custom style is not specified by WizardStyle or WizardStyleFile, it will automatically activate custom style windows11 with modifiers excludelightcontrols and hidebevels. Note that in light mode, the windows11 custom style uses an off-white background color. To revert this, set WizardBackColor to white.
To show only the background image and no other wizard images, set both WizardImageFile and WizardSmallImageFile to blank values. Alternatively set WizardImageOpacity to for example 150 to make both those images partially transparent.
Use support function WizardSetBackImage to set, update, or remove the background image at runtime.
; Use separate background images for light and dark appearances
WizardBackImageFile=MyBackImage.png
WizardBackImageFileDynamicDark=MyBackImage_Dark.png
; Hide the large and small wizard images
WizardImageFile=
WizardSmallImageFile=
; Use the same background image for both light and dark appearances
WizardBackImageFile=MyBackImage.png
WizardBackImageFileDynamicDark=MyBackImage.png
; Apply transparency to the background image so it works well in
; both light and dark appearances
WizardBackImageOpacity=150
; Keep large and small wizard images, applying transparency so they
; blend with the background image
WizardImageOpacity=150
; Use a background image in the wizard, and also use custom
; background colors on other windows, and in Uninstall
WizardBackImageFile=MyBackImage.png
WizardBackImageFileDynamicDark=MyBackImage.png
WizardBackColor=#ffc0cb
WizardBackColorDynamicDark=#570c22
; On wizard pages blend the background image and color together
WizardBackImageOpacity=150
See also:
WizardImageFile
WizardSmallImageFile
WizardBackColor
WizardBackImageOpacity
WizardImageAlphaFormat
WizardImageStretch
(blank)
Overrides WizardBackImageFile when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
For all details see WizardBackImageFile.
Feature removed in 6.4. These directives are no longer supported. In past versions, they were used to configure a 1990s-style blue gradient background behind the wizard window.
none, defined, premultipliednone
If set to none, the default, any wizard image (including the background image) which is a 32-bit .bmp file should not have an alpha channel.
If set to premultiplied, any wizard image (including the background image) which is a 32-bit .bmp file should have its red, green and blue channel values premultiplied with the alpha channel value.
If set to defined, any wizard image (including the background image) which is a 32-bit .bmp file should not have its red, green and blue channel values premultiplied with the alpha channel value.
This directive has no effect for a wizard image which is not a 32-bit .bmp file.
To create transparent .bmp files compatible with Inno Setup, you can use Paint.NET, a free image editor. Open your transparent image in Paint.NET, save it as a 32-bit .bmp file, and then set this directive to defined. These files may appear large, but Inno Setup compresses them using LZMA, which typically achieves better compression ratios than, for example, PNG compression.
See also:
WizardBackImageFile
WizardImageFile
WizardSmallImageFile
A value in the form of #rrggbb or $bbggrr, where bb, gg, and rr specify the two-digit intensities (in hexadecimal) for blue, green, and red respectively. Or it may be one of the following predefined color names: black, maroon, green, olive, navy, purple, teal, gray, silver, red, lime, yellow, blue, fuchsia, aqua, white, none, window.(see below)
This directive specifies the background color used to fill any unused or transparent space around the wizard image, which is specified by WizardImageFile. Using none as the fill color keeps transparency.
If a custom background image is specified by WizardBackImageFile, then this directive defaults to none.
Otherwise, if WizardImageFile specifies a blank value, then this directive also defaults to none.
Otherwise, if a custom wizard image is used, then this directive defaults to window.
Otherwise, if custom style slate is used then this directive defaults to #bcd2e2 (light grayish blue).
Otherwise, if custom style zircon is used then this directive defaults to #d0eaee (light grayish cyan).
Otherwise, if forced dark mode is used then this directive defaults to #2e3a3f (very dark grayish blue).
Otherwise, it defaults to #e8f3f9 (light grayish blue).
See also:
WizardImageFile
WizardStyle
#314853 (bluish dark gray)
Overrides WizardImageBackColor when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
For all details see WizardImageBackColor.
A value in the form of #rrggbb or $bbggrr, where bb, gg, and rr specify the two-digit intensities (in hexadecimal) for blue, green, and red respectively. Or it may be one of the following predefined color names: black, maroon, green, olive, navy, purple, teal, gray, silver, red, lime, yellow, blue, fuchsia, aqua, white, none, window.(see below)
This directive specifies the background color used to fill any unused or transparent space around the small wizard image, which is specified by WizardSmallImageFile. Using none as the fill color keeps transparency.
If a custom background image is used via WizardBackImageFile, then this directive defaults to none.
Otherwise, if WizardSmallImageFile specifies a blank value, then this directive also defaults to none.
Otherwise, if a custom wizard image is used, then this directive defaults to window.
Otherwise, it defaults to none.
none
Overrides WizardSmallImageBackColor when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
For all details see WizardSmallImageBackColor.
A value in the form of #rrggbb or $bbggrr, where bb, gg, and rr specify the two-digit intensities (in hexadecimal) for blue, green, and red respectively. Or it may be one of the following predefined color names: black, maroon, green, olive, navy, purple, teal, gray, silver, red, lime, yellow, blue, fuchsia, aqua, white, none, window.(see below)
This directive specifies the background color to use for wizard pages and all other windows such as the Select Language dialog, in both Setup and Uninstall.
If a custom background image is specified by WizardBackImageFile, then this directive defaults to window and setting it to none is not allowed.
Otherwise, it defaults to none.
Using window without also specifying a custom background image has no effect.
Using none disables this feature, so native background colors will be used, as determined by the system or the custom style.
If this feature is enabled, and the color is set to another value than window, then all panels will become transparent. To also hide all bevels (horizontal lines) in Setup and Uninstall, enable WizardStyle modifier hidebevels.
Additionally, if this feature is enabled but a custom style is not specified by WizardStyle, it will automatically activate custom style windows11 with modifier excludelightcontrols.
See also:
WizardBackImageFile
WizardStyle
Overrides WizardBackColor when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
For all details see WizardBackColor.
0 through 255255
If set to 0, the wizard images set via WizardImageFile and WizardSmallImageFile will be fully transparent. If set to 255, the wizard images will be fully opaque (non-transparent).
This is useful if you want to use identical regular and DynamicDark wizard images, or if you want to use them in combination with a custom background image set via WizardBackImageFile. For example, you can set WizardImageOpacity to 150 to achieve partial transparency.
If set to 0, the background wizard image set via WizardBackImageFile will be fully transparent. If set to 255, the wizard images will be fully opaque (non-transparent).
This is useful if you want to use an identical regular and DynamicDark background image. For example, you can set WizardBackImageOpacity to 150 to achieve partial transparency.
If set to yes, the default, the wizard images (including the background image) will be stretched or shrunk if the images are larger or smaller than required.
If set to no, the wizard images (including the background image) will be centered in their respective areas if the images are smaller than required, and clipped if the images are larger than required.
See also:
WizardBackImageFile
WizardImageFile
WizardSmallImageFile
Obsolete in 6.6.0.
yes or noyes
If set to yes, the default, Setup and Uninstall keep the original aspect ratio of their windows when scaling for DPI.
If set to no, the aspect ratio may be changed when scaling for DPI. As a result, your Setup and Uninstall windows will by default be 14% narrower at 125% DPI or higher.
See also:
WizardSizePercent
a,b, where a is the horizontal size, and b is the vertical size.each size: 100 through 150120,120
Lets you increase the default size of all Setup and Uninstall windows without increasing the font size. A size of for example 120 means a 20% size increase.
If you specify only one size it will be used as both the horizontal and the vertical size.
WizardSizePercent=130
Note: Some windows such as the Select Language dialog will only increase in size horizontally.
See also:
WizardKeepAspectRatio
DialogFontSize
Specifies a new source directory for the script.
SourceDir=c:\files
Output
Specifies the "output" directory for the script, which is where the compiler will place the resulting Setup.* files. By default, it creates a directory named "Output" under the directory containing the script for this.
If OutputDir is not a fully-qualified pathname, it will be treated as being relative to SourceDir, unless the pathname is prefixed by "userdocs:", in which case it will be treated as being relative to the My Documents folder of the currently logged-in user. Setting OutputDir to . will result in the files being placed in the source directory.
OutputDir=c:\output
One or more of the following, separated by spaces: classicmodern lightdarkdynamic polarslatewindows11zircon excludelightbuttonsexcludelightcontrols hidebevels includetitlebarclassic
This directive controls the visual style and appearance of Setup and Uninstall.
The base styles are:
classic: Uses a gray background for the page content (default behavior if no base style is specified).
modern: Uses a white background for the page content, matching the top panel, and hides the bevel (horizontal line) between the top panel and the page content.
Also supported are additional appearance modes:
light: Forces a light appearance (default behavior if no mode is specified).
dark: Forces a dark appearance.
dynamic: Automatically switches between light and dark appearance based on the user's Windows system settings.
Also supported are built-in additional custom styles:
polar: Uses light blue instead of gray or white for the light appearance, and dark blue instead of black for the dark appearance.
slate: Uses medium gray for both the light and dark appearances.
windows11: Enables a light counterpart of the built-in dark style.
zircon: Alternative light-only style with cyan accents.
Also supported are the following modifiers:
excludelightbuttons: Disables custom styling of all buttons (including command link buttons, as used in task dialogs) when a light style is active.
excludelightcontrols: Disables custom styling of all controls (including buttons) when a light style is active, except when styling is required to achieve transparency.
hidebevels: Hides all bevels (horizontal lines) across Setup and Uninstall, except those in native system dialogs.
includetitlebar: Enables custom styling of both title bars and borders when a custom style (including the built-in custom dark style) is active. By default, the system's native light or dark title bar is used instead.
Examples:
WizardStyle=modern dynamic will use the modern look and automatically adapt to the system's light or dark mode setting. WizardStyle=modern dark polar includetitlebar will use the modern look, and the dark appearance of the built-in polar style, and also style both title bars and borders.
Dark Mode Behavior
When forced dark (dark) or dynamic dark (dynamic with Windows in dark mode) is active, the following changes occur:
The main icon of Setup and Uninstall is replaced by its dark mode version, if not overridden by a custom one using SetupIconFile.
Note: Windows may temporarily display a different icon due to its icon cache, this is normal.
Other icons in Setup and Uninstall are also replaced by dark mode versions. These are not affected by Windows' icon cache.
The wizard images are replaced by dark mode versions, if not overridden by custom ones using WizardImageFile.
The wizard image background color is adjusted for dark mode if not overridden by custom values using WizardImageBackColor.
The small wizard images are replaced by dark mode versions, if not overridden by custom ones using WizardSmallImageFile.
Any colors in RTF files are removed and replaced by the dark style colors.
If includetitlebar is not used: the title bar is made dark to match the system appearance, if the system allows this.
Dynamic Mode Special Considerations
When using dynamic mode, the following additional considerations apply:
The main icon as displayed by Windows will always be the light version.
The system's light or dark mode setting is checked only once, at startup.
Separate directives are available to specify images and colors used specifically for dynamic dark mode:
WizardBackImageFileDynamicDark and WizardBackColorDynamicDark.
WizardImageFileDynamicDark and WizardImageBackColorDynamicDark.
WizardSmallImageFileDynamicDark and WizardSmallImageBackColorDynamicDark.
WizardStyleFileDynamicDark
The standard WizardBackImageFile, WizardBackColor, WizardImageFile, WizardImageBackColor, WizardSmallImageFile, WizardSmallImageBackColor, and WizardStyleFile settings are used for dynamic light mode.
Note: Forced dark mode (dark) does not use the DynamicDark settings; it uses the standard settings.
Other Considerations
The default style can be customized by specifying a VCL Styles file using the WizardStyleFile directive. When forced light (light) or dynamic dark (dynamic with Windows in light mode) is active, the default style is the system's native light style. Otherwise, the default style is a built-in custom dark style.
Custom styles (including the built-in custom dark style) are not activated when the user's system is set to a high-contrast theme or when command line parameter '/NOSTYLE' is used.
When a custom style (including the built-in custom dark style) is active, three additional things occur. First, all text labels, except for the label associated with the BeveledLabel message, are transparent instead of opaque. Second, Setup and Uninstall use a custom implementation of Windows message boxes and task dialogs. Third, color properties set through Pascal Scripting are usually ignored, with the style's colors taking precedence.
Enabling forced dark (dark) increases the size of Setup by approximately 220 KB. Enabling dynamic dark (dynamic) adds approximately 75 KB more. Enabling dynamic dark and including a custom light style as well (for example, dynamic windows11) adds approximately 110 KB more.
Messages displayed by the so-called "setup loader" will never be styled. Normally no such messages are displayed, unless you enabled the startup prompt using DisableStartupPrompt.
Example screenshots
classic
classic dark
modern
modern windows11
modern windows11 excludelightbuttons
modern dark (same as modern dark windows11)
modern polar
modern polar includetitlebar
modern dark polar
modern slate
modern slate includetitlebar
modern zircon
modern zircon includetitlebar
See also:
WizardSizePercent
WizardStyleFile
IsDarkInstallMode
HighContrastActive
(blank)
This directive specifies a custom VCL Styles file (.vsf) to be used. It is recommended to use only styles that support high DPI.
When using WizardStyle with light or dynamic mode, the specified style should always use a light color theme (such as predominantly white or in other light colors). When using dark, use a dark color theme (such as predominantly black or in other dark colors).
Using a custom style file increases the size of Setup, except when using dark mode and a style file that is smaller than the built-in one, which is 199 KB before compression.
Can also be set to builtin:polar, builtin:slate, or builtin:zircon to use one of the built-in custom styles. See WizardStyle for more information.
VCL Styles files can be downloaded from sources such as GetIt (free if 'Subscription' says 'Not Required', requires a Delphi installation to download, which may be a Community Edition for the free styles), and from DelphiStyles (not free).
FireMonkey (FMX) Styles files are not supported.
See also:
WizardStyle
WizardStyleFileDynamicDark
(blank)
Overrides WizardStyleFile when using WizardStyle with dynamic mode and Windows is in dark mode. Ignored otherwise.
The specified style should always use a dark color theme (such as predominantly black or in other dark colors).
For all other details see WizardStyleFile.
Obsolete in 5.0.0.
yes or noyes
If this directive is set to yes, Setup will always show the components list for customizable setups. If this is set to no Setup will only show the components list if the user selected a custom type from the type list.
yes or nono
If this directive is set to yes, Setup will always show the selected directory in the list of settings on the Ready to Install wizard page. If this is set to no, Setup will not show the selected directory if DisableDirPage is yes.
yes or nono
If this directive is set to yes, Setup will always show the selected Start Menu folder name in the list of settings on the Ready to Install wizard page. If this is set to no, Setup will not show the selected Start Menu folder name if DisableProgramGroupPage is yes.
If no Start Menu folder is going to be created by Setup, this directive is effectively ignored.
yes or noyes
When this directive is set to yes, Setup will use 'flat' checkboxes for the components list. Otherwise Setup will use '3D' checkboxes.
yes or noyes
When this directive is set to yes, Setup will show the size of a component in the components list. Depending on the largest component, Setup will display sizes in kilobytes or in megabytes.
yes or nono
When this directive is set to yes, Setup will show 'tree lines' between parent and sub tasks.
Segoe UI
Specifies the name of the font that should be used in dialogs on languages that do not set DialogFontName in their [LangOptions] section.
If the specified font name does not exist on the user's system or is an empty string, 9-point Segoe UI will be substituted.
yes, no, or autoyes
When set to yes and there are multiple [Languages] section entries, a Select Language dialog will be displayed to give the user an opportunity to override the language Setup chose by default. See the [Languages] section documentation for more information.
When set to no, the dialog will never be displayed.
When set to auto, the dialog will only be displayed if Setup does not find a language identifier match.
See also:
UsePreviousLanguage
uilanguage, locale, noneuilanguage
When set to uilanguage, Setup will determine the default language to use by checking the user's "UI language" (by calling GetUserDefaultUILanguage(), or on Windows versions where that function is unsupported, by reading the registry). This is the method that Microsoft recommends. The "UI language" is the language used in Windows' own dialogs. Thus, on an English edition of Windows, English will be the default, while on a Dutch edition of Windows, Dutch will be the default. On the MUI edition of Windows, the default will be the currently selected UI language.
When set to locale, Setup will determine the default language to use by calling GetUserDefaultLangID(). This function returns the setting of "Your locale" in Control Panel's Regional Options. It should however be noted that the "Your locale" option is not intended to affect languages; it is only documented to affect "numbers, currencies, times, and dates".
When set to none, Setup will use the first language specified in the [Languages] section as the default language.
0 through 602
By default, time stamps on files referenced by non external [Files] section entries are rounded down to the nearest 2-second boundary. FAT partitions have only a 2-second time stamp resolution, so this ensures that time stamps are set the same way on both FAT and NTFS partitions.
The rounding can be altered or disabled by setting the TimeStampRounding directive. Setting it to 0 will disable the rounding. Setting it to a number between 1 and 60 will cause time stamps to be rounded down to the nearest TimeStampRounding-second boundary.
yes or nono
By default, time stamps on files referenced by non external [Files] section entries are saved and restored as local times. This means that if a particular file has a time stamp of 01:00 local time at compile time, Setup will extract the file with a time stamp of 01:00 local time, regardless of the user's time zone setting or whether DST is in effect.
If TimeStampsInUTC is set to yes, time stamps will be saved and restored in UTC -- the native time format of Win32 and NTFS. In this mode, a file with a time stamp of 01:00 local time in New York will have a time stamp of 06:00 local time when installed in London.
(blank)
Specifies a custom program icon to use for Setup/Uninstall. The file must be located in your installation's source directory when running the compiler, unless a fully qualified pathname is specified or the pathname is prefixed by "compiler:", in which case it looks for the file in the compiler directory.
It is recommended to include at least the following sizes in your icon: 16x16, 32x32, 48x48, 64x64, and 256x256.
If this directive is not specified or is blank, a built-in icon supporting the above sizes will be used.
To use the old default icon set this directive to compiler:SetupClassicIcon.ico.
SetupIconFile=MyProgSetup.ico
AppPublisher if AppPublisher doesn't include constants, an empty string otherwise
Specifies the company name value for the Setup version info.
AppCopyright if AppCopyright doesn't include constants, an empty string otherwise
Specifies the copyright value for the Setup version info.
"AppName Setup" if AppName doesn't include constants, an empty string otherwise
Specifies the file description value for the Setup version info.
This setting has no effect if UseSetupLdr is set to no.
Specifies the original file name value for the Setup version info.
AppName if AppName doesn't include constants, an empty string otherwise
Specifies the product name value for the Setup version info.
VersionInfoProductVersion if set, else AppVersion if set and does not include constants, else VersionInfoTextVersion
Specifies the textual product version value for the Setup version info.
A value in the form of up to 4 numbers separated by dotsVersionInfoVersion
Specifies the binary product version value for the Setup version info.
Partial version numbers are allowed. Missing numbers will be appended as zero's.
Note that this value is only known to be displayed by Explorer on Windows Vista SP2. Other versions display the textual product version value (VersionInfoProductTextVersion) instead.
VersionInfoVersion
Specifies the textual file version value for the Setup version info.
Note that this value was only displayed on Explorer's Version tab on Windows 98 and earlier. Later versions display the binary version value (VersionInfoVersion) instead.
This setting has no effect if UseSetupLdr is set to no.
A value in the form of up to 4 numbers separated by dots0.0.0.0
Specifies the binary file version value for the Setup version info.
Partial version numbers are allowed. Missing numbers will be appended as zero's.
This setting has no effect if UseSetupLdr is set to no.
Obsolete in 5.0.0. As Setup and Uninstall have been merged into a single executable, setting a custom icon for Uninstall is no longer possible.
yes or noyes
By default, when a folder in the dialog displayed by the Browse... button on the Select Destination Location wizard page is clicked, Setup automatically appends the last component of DefaultDirName onto the new path. For example, if DefaultDirName is {autopf}\My Program and "Z:\" is clicked, the new path will become "Z:\My Program".
Setting this directive to no disables the aforementioned behavior. In addition, it causes a Make New Folder button to appear on the dialog.
yes or noyes
By default, when a folder in the dialog displayed by the Browse... button on the Select Start Menu Folder wizard page is clicked, Setup automatically appends the last component of DefaultGroupName onto the new path. For example, if DefaultGroupName is My Program and "Accessories" is clicked, the new path will become "Accessories\My Program".
Setting this directive to no disables the aforementioned behavior. In addition, it causes a Make New Folder button to appear on the dialog.
current, none, or YYYY-MM-DDcurrent
The date used in the time/date stamp of files referenced by [Files] section entries that include the touch flag.
A value of current causes the current system date (at compile time) to be used. A value of none leaves the date as-is. Otherwise, TouchDate is interpreted as an explicit date in YYYY-MM-DD (ISO 8601) format. If TimeStampsInUTC is set to yes, the date is assumed to be a UTC date.
TouchDate=2004-01-31
current, none, HH:MM, or HH:MM:SScurrent
The time used in the time/date stamp of files referenced by [Files] section entries that include the touch flag.
A value of current causes the current system time (at compile time) to be used. A value of none leaves the time as-is. Otherwise, TouchTime is interpreted as an explicit time in HH:MM or HH:MM:SS format. If TimeStampsInUTC is set to yes, the time is assumed to be a UTC time.
TouchTime=13:00
yes or no or fullno
If set to yes, files that are compiled into the installation (via [Files] section entries) will be encrypted using XChaCha20 encryption.
If set to full, the entire installation will be encrypted, and the password must be specified using the /PASSWORD= command line parameter.
If set to yes or full and you call the ExtractTemporaryFile function from the [Code] section prior to the user entering the correct password, the function will fail unless the noencryption flag is used on the [Files] section entry for the file.
If set to yes or full the 256-bit XChaCha20 encryption key is derived from the value of Password using the function specified by EncryptionKeyDerivation
The 192-bit XChaCha20 encryption nonce is a random base nonce, appending the index of the first file in the chunk for unique encryption nonces.
See also:
Password
EncryptionKeyDerivation
pbkdf2 pbkdf2/1 through pbkdf2/2147483647pbkdf2/220000
This specifies the key derivation function to use to derive the encryption key from the value of Password, and optionally its parameters.
pbkdf2 is the PBKDF2-HMAC-SHA256 function with a 128-bit random salt, and optionally allows to increase its number of iterations for extra security. If the number of iterations isn't specified, it defaults to 220000.
See also:
Encryption
When this directive is set, a separate "Modify" button in the Add/Remove Programs Control Panel applet will be displayed. Setting it is optional. The value may include constants.
AppModifyPath="{app}\Setup.exe" /modify=1
When this directive is set, the compiler will create a manifest file detailing information about the files compiled into Setup. The file will be created in the output directory unless a path is included.
OutputManifestFile=Setup-Manifest.txt
x86, x64x86
When using x86 (the default), a 32-bit version of Setup is used which runs on systems capable of running 32-bit x86 binaries. This includes systems running x86 Windows, x64 Windows, and also Arm64 Windows 10 and 11 systems, which have the ability to run x86 binaries via emulation.
Otherwise, when using x64, a 64-bit version of Setup is used which runs on systems capable of running x64 binaries. This includes systems running x64 Windows, and also Arm64-based Windows 11 systems, which have the ability to run x64 binaries via emulation.
For more information, see 64-bit Inno Setup.
These are used in the values of ArchitecturesAllowed and ArchitecturesInstallIn64BitMode.
arm32compatible
Matches systems capable of running 32-bit Arm binaries. Arm64 Windows previously included such support, but Microsoft removed it in Windows 11 24H2.
arm64
Matches systems running Arm64 Windows.
win64
Matches systems running 64-bit Windows, regardless of OS architecture.
This may be useful in an installer that doesn't ship any architecture-specific binaries, but requires access to something 64-bit, like HKLM64 in the [Registry] section, or the native 64-bit Program Files directory.
x64compatible
Matches systems capable of running x64 binaries. This includes systems running x64 Windows, and also Arm64-based Windows 11 systems, which have the ability to run x64 binaries via emulation and also support Arm64EC.
Always matches if Setup itself is built as a 64-bit x64 binary, see SetupArchitecture.
x64os
Matches systems running x64 Windows only — not any other systems that have the ability to run x64 binaries via emulation.
In most cases, x64compatible should be used instead of x64os, because x64compatible allows x64 apps to be installed on Arm64 Windows 11 systems as well.
However, x64os is appropriate in unusual cases where an x64 app/binary is known to require true x64 Windows and cannot function under emulation. x64 device drivers are one example; x64 emulation isn't supported in kernel mode.
Before Inno Setup 6.3, x64os was named x64. The compiler still accepts x64 as an alias for x64os, but will emit a deprecation warning when used.
x86compatible
Matches systems capable of running 32-bit x86 binaries. This includes systems running x86 Windows, x64 Windows, and also Arm64 Windows 10 and 11 systems, which have the ability to run x86 binaries via emulation.
Always matches if Setup itself is built as a 32-bit x86 binary, see SetupArchitecture.
x86os
Matches systems running 32-bit x86 Windows only.
x86os usually only makes sense when installing 32-bit x86 device drivers. When installing a regular 32-bit app, x86compatible should be used instead (or just leave ArchitecturesAllowed unset).
Before Inno Setup 6.3, x86os was named x86. The compiler still accepts x86 as an alias for x86os.
See also:
Architecture Identifier Matchers like IsX64Compatible
ProcessorArchitecture
A space separated list of architecture identifiers.
Or, a boolean expression containing architecture identifiers. See Components and Tasks parameters for examples of boolean expressions.32-bit Setup: x86compatible
64-bit Setup: x64compatible
Specifies which architectures Setup is allowed to run on. If none of the specified architecture identifiers match the current system, Setup will display an error message (WindowsVersionNotSupported) and exit.
If your application's binaries are all 32-bit and you're using 32-bit Setup, then there is normally no need to set this directive; the default value of x86compatible is correct. If your application's binaries are built for the x64 or Arm64 architectures, you should set this directive to either x64compatible or arm64 respectively.
If you are installing device drivers, then the proper setting is x86os, x64os, or arm64, depending on the architecture of the drivers.
; Require two architecture identifier matches at the same time.
; - An x64 app installer that includes some 32-bit x86 binaries:
ArchitecturesAllowed=x64compatible and x86compatible
; - An Arm64 app installer that includes some x64 or Arm64EC binaries:
ArchitecturesAllowed=arm64 and x64compatible
; Only allow installation on systems that aren't x64-compatible.
; Useful in a situation where you have separate x86 & x64 installers,
; and don't want users of x64-compatible OSes (x64 + Arm64 Win11)
; erroneously running the x86 installer.
ArchitecturesAllowed=x86compatible and not x64compatible
; Allow installation on x64-compatible systems, but deny Arm64.
; Useful if you provide a separate installer for Arm64 systems.
ArchitecturesAllowed=x64compatible and not arm64
; The "os" variant is appropriate when installing something that
; cannot operate in an emulated environment, such as a device driver.
ArchitecturesAllowed=x64os
; Allow installation only on 64-bit Windows, but don't check the
; architecture.
; (Don't use this if installing any architecture-specific binaries.)
ArchitecturesAllowed=win64
See also:
ArchitecturesInstallIn64BitMode
A space separated list of architecture identifiers.
Or, a boolean expression containing architecture identifiers. See Components and Tasks parameters for examples of boolean expressions.32-bit Setup: (blank)
64-bit Setup: x64compatible
Specifies the architectures on which Setup should enable 64-bit install mode. If this directive is set to a blank value, Setup will always use 32-bit install mode.
Generally, 64-bit install mode should only be enabled on installers that ship 64-bit binaries (x64 or Arm64).
Since 64-bit install mode is only supported on systems running 64-bit Windows, the specified expression must never match systems running 32-bit Windows. So, for example, don't set this directive to a value like x86compatible, since that will match systems running 32-bit Windows. If the expression does indeed match a system running 32-bit Windows, Setup will display an error message and exit.
Be sure you have read the 64-bit Installation Limitations topic before setting this directive.
If your application runs only on 64-bit architectures and you're using 32-bit Setup, you should set ArchitecturesAllowed to the same value as this directive to prevent Setup from running on 32-bit Windows.
; Only allow the installer to run on x64-compatible systems,
; and enable 64-bit install mode.
ArchitecturesAllowed=x64compatible
ArchitecturesInstallIn64BitMode=x64compatible
See also:
ArchitecturesAllowed
yes or noyes
Specifies whether the compiler should set the "Terminal Services aware" flag in the headers of the Setup and Uninstall programs.
Most importantly, the "Terminal Services aware" flag affects the behavior of the {win} constant (and GetWinDir support function) on servers with Terminal Services installed in application mode.
When the flag is set, {win} will consistently return the system's real Windows directory, typically "C:\WINDOWS", just as on systems that do not have Terminal Services installed.
When the flag is not set, Windows runs the program in compatibility mode, where {win} may return either the real Windows directory or a user-specific Windows directory, such as "C:\Documents and Settings\<user name>\WINDOWS". Which one you get depends on the name of the program's EXE file and how it is launched. If the program is named setup.exe or install.exe, or if it is launched from the Add/Remove Programs Control Panel applet, then Windows will put the system in "install mode", which effectively makes the program (and all other programs running in the session) behave as if the "Terminal Services aware" flag were set. Otherwise, the program is treated as a legacy application and is given a private Windows directory. (This is true even if the user running the program has full administrative privileges.)
Because the behavior that results from setting TerminalServicesAware to no is inconsistent and hard to predict, it is recommended that you use the default setting of yes. Only use no as a temporary fix if you encounter troubles on systems with Terminal Services after upgrading from a previous Inno Setup version.
yes or noyes
Specifies whether the compiler should set the "NX Compatible" flag in the headers of the Setup and Uninstall programs to mark them compatible with data execution prevention (DEP).
Setting this to no might be needed if you're using a buggy third-party DLL from [Code].
yes or noyes
Specifies whether the compiler should set the "Dynamic Base" flag in the headers of the Setup and Uninstall programs.
yes or nono
If set to yes, Setup will always create a log file. Equivalent to passing /LOG on the command line.
See also:
UninstallLogging
yes or noyes if a SignTool is set, no otherwise
Specifies whether the uninstaller program (unins???.exe) should be deployed with a digital signature attached. When the uninstaller has a valid digital signature, users will not see an "unknown publisher" warning when launching it.
When set to yes, any temporary self-copies used by Setup are digitally signed too.
If the SignTool directive is set, the file will be signed automatically on the fly. Otherwise:
The first time you compile a script with SignedUninstaller set to yes, a uniquely-named non-temporary copy of the uninstaller EXE file will be created in the directory specified by the SignedUninstallerDir directive (which defaults to the output directory).
You will then be prompted to attach a digital signature to this file using an external code-signing tool (such as Microsoft's signtool.exe).
On subsequent compiles, the signature from the file will be embedded into the compiled installations' uninstallers, without prompting you.
If you delete the file, you will be prompted again if necessary on the next compile.
Upgrading to a newer version of Inno Setup, or changing certain [Setup] section directives that affect the contents of the uninstaller EXE file (such as SetupIconFile, WizardStyle and VersionInfo directives), will cause a new file to be created under a different name.
When the uninstaller has a digital signature, Setup will write the messages from the active language into a separate file (unins???.msg). It cannot embed the messages into the EXE file because doing so would invalidate the digital signature.
Details on obtaining signing certificates and using code-signing tools are beyond the scope of this documentation.
OutputDir
Specifies the directory in which signed uninstaller files should be stored. By default, such files are stored in the output directory.
Separate script files may share the same SignedUninstallerDir setting. By setting up a common directory to hold signed uninstaller files, you won't have to re-sign the uninstaller each time you compile a new script file with a distinct OutputDir setting.
If SignedUninstallerDir is not a fully-qualified pathname, it will be treated as being relative to SourceDir. Setting SignedUninstallerDir to . will result in the files being placed in the source directory.
SignedUninstallerDir=c:\signeduninstallers
A name followed by zero or more parameters, space separated
Specifies the name and parameters of the Sign Tool to be used to digitally sign:
Setup
Uninstall if SignedUninstaller is set to yes
Original source files if the [Files] section's sign or signonce flag is used
When Setup has a valid digital signature, users will not see an "unidentified program" warning when launching it.
The specified Sign Tool name and its command have to be defined in the Compiler IDE (via the Tools | Configure Sign Tools... menu) or on the compiler command line (via the "/S" parameter), else an error will occur.
The following special sequences may be used in Sign Tool parameters and commands:
$f, replaced by the quoted file name of the file to be signed. (required)
$p, replaced by the Sign Tool parameters.
$q, replaced by a quote, useful for defining a Sign Tool which contains quotes from the command line.
$$, replaced by a single $ character.
Assume the following Sign Tools have been defined in the Compiler IDE:
The Setup section may also list multiple SignTool directives which will be executed in order of appearance. This can be used to dual sign (SHA1 & SHA256) Setup and Uninstall:
[Setup]
SignTool=mycustom sign /a /n $qMy Common Name$q /fd sha1 /t http://timestamp.comodoca.com/authenticode /d $qMy Program$q $f
;the /as parameter in the following SignTool requires a recent signtool.exe version and a SHA256 (SHA-2) certificate
SignTool=mycustom sign /a /n $qMy Common Name$q /as /fd sha256 /td sha256 /tr http://timestamp.comodoca.com/rfc3161 /d $qMy Program$q $f
Note: for security reasons you should give a unique name to any Sign Tool set to $p, and not use a byparam name copied from this example. Consider what happens if you #include a third-party file that says:
[Setup]
SignTool=byparam format c:
Further details on obtaining signing certificates and using code-signing tools are beyond the scope of this documentation.
Note: If you use a Sign Tool and your Setup contains a large amount of data, it is recommended that you enable Disk spanning with DiskSliceSize set to max. If you don't do this, the user might experience a long delay after starting Setup caused by Windows verifying the digital signature against all your data. There should be no security reduction from using disk spanning in practice: all files extracted from the unsigned .bin files undergo SHA-256 verification (provided dontverifychecksum isn't used). The SHA-256 hashes for this (along with all other metadata) are kept inside Setup's EXE, which is protected by the digital signature.
See also:
SignToolMinimumTimeBetween
SignToolRetryCount
SignToolRunMinimized
0
If not set to 0, specifies the minimum number of milliseconds that should have elapsed between consecutive digital signing actions by the compiler. For example, if set to 5000 then the compiler will perform 1 digital signing per 5 seconds at most. Can be used to avoid being rejected by rate limiting timestamp services.
See also:
SignTool
2
Specifies the number of times the compiler should automatically retry digital signing on any errors.
See also:
SignTool
SignToolRetryDelay
500
Specifies the number of milliseconds the compiler should wait before any automatic digital signing retries specified by SignToolRetryCount.
See also:
SignTool
SignToolRetryCount
yes or nono
When set to yes, the compiler will run Sign Tools in a minimized window. Has no effect if the sign tool is a console program.
See also:
SignTool
0 or 10 if the LZMA compression level is set to fast 1 otherwise
Controls the algorithm used by the LZMA and LZMA2 compressors.
A value of 0 enables the fast algorithm.
A value of 1 enables the normal algorithm.
1024 through 2621444 * LZMADictionarySize with a minimum of 1024 and a maximum of 262144
Controls the block size used by the LZMA2 compressor, in kilobytes, when LZMANumBlockThreads is set to 2 or higher.
Note that setting this too high can negate the benefits of using multiple block threads. Typically, the block size should be no more than the total size of your data divided by the number of block threads.
See also:
LZMADictionarySize
LZMANumBlockThreads
32-bit compiler: 4 through 131072 (by default) 4 through 1048576 if LZMAUseSeparateProcess is set to yes and running on 64-bit Windows (x64)
64-bit compiler: 4 through 393216032 if the LZMA compression level is set to fast 2048 if the LZMA compression level is set to normal 8192 if the LZMA compression level is set to max 32768 if the LZMA compression level is set to ultra 65536 if the LZMA compression level is set to ultra64
Controls the dictionary size used by the LZMA and LZMA2 compressors, in kilobytes. A larger dictionary size can provide a better compression ratio at the expense of compression speed and memory requirements.
Review the memory requirements listed in the Compression topic before using.
32-bit compiler: If an "Out of memory" error is seen after increasing the dictionary size, LZMAUseSeparateProcess may need to be set.
See also:
LZMABlockSize
HC or BTHC if the LZMA compression level is set to fast BT otherwise
Controls the match finder method used by the LZMA and LZMA2 compressors.
A value of HC enables the Hash Chain method with 5 hash bytes.
A value of BT enables the Binary Tree method with 4 hash bytes.
The Binary Tree method can provide a better compression ratio at the expense of compression speed.
1 through 2561
When compressing a large file, the LZMA2 compressor has the ability to divide its data into "blocks" and compress two or more of these blocks in parallel through the use of additional threads (provided sufficient processor power is available). This directive specifies the maximum number of threads to use -- that is, the maximum number of blocks that the LZMA2 compressor may compress in parallel. Using a high maximum requires a very large file before this maximum is fully utilized.
The memory required during compression when multiple block threads are used is roughly:
Since LZMA2 (and LZMA) uses two threads for match-finding by default (see CompressionThreads), there ideally should be two processor cores available for each block thread. Thus, to see the maximum benefit from a value of 2, four cores are needed.
Dividing the data into multiple blocks can reduce the compression ratio, as the compressor cannot find matches across blocks. Using a large block size can help to mitigate this.
32-bit compiler: If an "Out of memory" error is seen when multiple block threads are enabled in combination with a compression level that uses a large dictionary size (such as ultra64), LZMAUseSeparateProcess may need to be set.
See also:
LZMABlockSize
5 through 27364 if the LZMA compression level is set to max, ultra, or ultra64 32 otherwise
Controls number of fast bytes used by the LZMA and LZMA2 compressors. A larger number of fast bytes can provide a better compression ratio at the expense of compression speed.
force, yes, or noyes
If set to yes or force and Setup is not running silently, Setup will pause on the Preparing to Install wizard page if it detects applications using files that need to be updated by the [Files] or [InstallDelete] section, showing the applications and asking the user if Setup should automatically close the applications and restart them after the installation has completed.
If set to yes or force and Setup is running silently, Setup will always close and restart such applications, unless told not to via the command line.
If set to force Setup will force close when closing applications, unless told not to via the command line. Use with care since this may cause the user to lose unsaved work.
Note: Setup uses Windows Restart Manager to detect, close, and restart applications.
See also:
CloseApplicationsFilter
RegisterExtraCloseApplicationsResources
RestartApplications
AppMutex
A list of file name wildcards, separated by commas*.exe,*.dll,*.chm
Limits which [Files] and [InstallDelete] entries Setup will check for being in use. Only files matching one of the wildcards will be checked.
Setting this to *.* can provide better checking at the expense of speed.
See also:
CloseApplications
CloseApplicationsFilterExcludes
RestartApplications
A list of file name wildcards, separated by commas
Limits which [Files] and [InstallDelete] entries Setup will check for being in use. Files matching one of the wildcards will not be checked even if they match CloseApplicationsFilter.
For example, to check all files except MyProg.exe:
See also:
CloseApplications
CloseApplicationsFilter
RestartApplications
yes or noyes
When set to yes and CloseApplications is also set to yes, Setup restarts the closed applications after the installation has completed.
Note: For Setup to be able to restart an application after the installation has completed, the application needs to be using the Windows RegisterApplicationRestart API function.
See also:
CloseApplications
CloseApplicationsFilter
For compatibility with previous Inno Setup versions, 1 and 0 may be used in place of yes and no, respectively.
Additionally, it allows true and false to be used in place of yes and no.
yes, no, or x86no
Controls whether LZMA compression is performed inside the main compiler process or in a separate process.
This directive is ignored if the 64-bit compiler is being used. Otherwise:
Using a separate process for LZMA compression allows the compressor to allocate larger amounts of memory, which makes it possible for higher LZMADictionarySize and LZMANumBlockThreads settings to be used. Additionally, on 64-bit Windows (x64), a small increase in compression speed may be observed.
On 64-bit Windows (x64), there are no limitations on the amount of memory the compressor may use, as it runs inside a native 64-bit process. On 32-bit Windows, however, due to address space constraints, typically only about 1.5 GB is available for use by the compressor.
A value of yes enables the use of a 64-bit process on 64-bit Windows (x64), and a 32-bit process on 32-bit Windows.
A value of x86 enables the use of a 32-bit process only (normally only useful for debugging purposes).
A value of no disables the use of a separate process for LZMA compression.
Note that this directive only affects the compression of files specified in the [Files] section; compression of Setup's internal structures is always performed inside the main compiler process.
When a new version of an application is installed over an existing version, instead of creating a new uninstall log file (unins???.dat), Setup will by default look for and append to an existing uninstall log file that belongs to the same application and is in the same directory. This way, when the application is uninstalled, changes made by all the different installations will be undone (starting with the most recent installation).
The uninstaller will use the messages from the most recent installation of the application. However, there is an exception: if an installation was built with an older version of Inno Setup that included an older version of the uninstaller than the existing one on the user's system, neither the existing uninstaller nor its messages will be replaced. In this case the uninstall log will still be appended to, though, since the file format is backward compatible.
The application name displayed in the uninstaller will be the same as the value of the [Setup] section directive AppName from the most recent installation, unless UpdateUninstallLogAppName is set to no.
To disable the uninstall log-appending feature set the [Setup] section directive UninstallLogMode.
"Same application" refers to two separate installation runs that share the same AppId setting (or if AppId is not set, the same AppName setting), and the same administrative or non administrative install mode, and the same 32-bit or 64-bit install mode*. Two of such installation runs will usually lead to only one actual installation of the files.
(* = This requirement does not apply to any same application information retrieved from the registry in non administrative install mode since the HKEY_CURRENT_USER key is shared between the 32-bit and 64-bit registry. It does however always apply to the uninstall log since the 32-bit and 64-bit uninstall logs are kept separate, even in non administrative install mode. In practice this means you should avoid offering both a 32-bit and a 64-bit non administrative installer to your users without giving these installers different AppId, DefaultDirName, DefaultGroupName, and UninstallDisplayName settings.)
See also:
Side-by-side installation
"Side-by-side installation" refers to two separate installation runs that share the same AppId setting (or if AppId is not set, the same AppName setting) but not the other "Same application" requirements. Two of such installation runs will usually lead to two actual installations of the files. To avoid entries with identical names in the Add/Remove Programs Control Panel applet Setup will automatically mark the new entry with a text like "Current user" or "64-bit" when necessary during a side-by-side installation.
By default, the compiler expects to find files referenced in the script's [Files] section Source parameters, and files referenced in the [Setup] section, under the same directory the script file is located if they do not contain fully qualified pathnames. To specify a different source directory, create a SourceDir directive in the script's [Setup] section.
The versions specified in MinVersion and OnlyBelowVersion can optionally include build numbers and/or service pack levels.
6.1sp1
10.0.22000
If a build number is not specified or is zero, Setup will not check the system's build number.
If a service pack level is not specified or is zero, Setup will not check the system's service pack level.
When a service pack level is specified, Setup will only compare it against the system's service pack level if the specified major and minor versions match the system's version. For example, if MinVersion specifies 6.1sp1, Setup will only check for SP1 on Windows 7 and Windows Server 2008 R2 (6.1) systems.
In an OnlyBelowVersion parameter, if the specified version matches the system's version, then Setup will normally consider the system's version to be too high. However, when a service pack level is specified, the specified version is allowed to match the system's version.
6.1.7600
Windows 7 or Windows Server 2008 R2
6.1.7601
Windows 7 with Service Pack 1 or Windows Server 2008 R2 with Service Pack 1
6.2.9200
Windows 8 or Windows Server 2012
6.3.9200
Windows 8.1 or Windows Server 2012 R2
6.3.9600
Windows 8.1 with Update 1
10.0.10240
Windows 10 Version 1507
10.0.10586
Windows 10 Version 1511 (November Update)
10.0.14393
Windows 10 Version 1607 (Anniversary Update) or Windows Server 2016
10.0.15063
Windows 10 Version 1703 (Creators Update)
10.0.16299
Windows 10 Version 1709 (Fall Creators Update)
10.0.17134
Windows 10 Version 1803 (April 2018 Update)
10.0.17763
Windows 10 Version 1809 (October 2018 Update) or Windows Server 2019
10.0.18362
Windows 10 Version 1903 (May 2019 Update)
10.0.18363
Windows 10 Version 1909 (November 2019 Update)
10.0.19041
Windows 10 Version 2004 (May 2020 Update)
10.0.19042
Windows 10 Version 20H2 (October 2020 Update)
10.0.19043
Windows 10 Version 21H1 (May 2021 Update)
10.0.19044
Windows 10 Version 21H2 (November 2021 Update)
10.0.19045
Windows 10 Version 22H2 (2022 Update)
10.0.20348
Windows Server 2022 Version 21H2
10.0.22000
Windows 11 Version 21H2 (original release)
10.0.22621
Windows 11 Version 22H2 (2022 Update)
10.0.22631
Windows 11 Version 23H2 (2023 Update)
10.0.26100
Windows 11 Version 24H2 (2024 Update)
10.0.26200
Windows 11 Version 25H2 (2025 Update)
Note that except for Windows 11 there is normally no need to specify the build numbers (i.e., you may simply use "6.2" for Windows 8).
