Inno Setup is a compiler for building Windows installation packages from a written setup script. The script names the files to copy, folders to create, registry entries to write, shortcuts to add, optional tasks to show, and actions to take during installation or removal. Compiling turns those instructions and payload files into a distributable Setup executable. Inno Setup does not inspect an application and discover its deployment rules automatically; the author must define where every item belongs and which system changes are safe.
Sections define work
A script has a Setup section for global choices and separate sections for files, icons, registry entries, tasks, components, languages, and run actions. Conditions can include or skip an entry according to the selected component, operating environment, or scripted check.
The order of entries can matter when one action depends on a file or folder created earlier. A successful compile proves that the script follows the language rules. It does not prove that the installed application starts, that every dependency exists, or that an upgrade preserves user data. Test the built installer on a clean system as well as over an earlier release.
Scope changes paths
PrivilegesRequired determines whether Setup asks for administrative elevation. The default administrative scope suits machine-wide locations and protected system changes. The lowest setting avoids elevation and requires locations that the current user can write.
Changing this directive affects more than the consent prompt. A per-user install should not write to machine-wide protected areas simply because an old file entry still names them. Inno Setup can let the user override the default scope when the script supports both modes, but every destination and registry entry must behave correctly under either choice.
Architecture redirects entries
Inno Setup uses 32-bit installation mode by default, even on 64-bit Windows. Architecture directives can select 64-bit mode on compatible systems. That decision changes which Program Files directory, System directory, and registry view certain constants and entries reach.
A 64-bit application installed through the wrong mode may land in the 32-bit program directory or write registration data to the wrong registry view. The installer can still finish without an obvious error. Match the mode to the payload and test shell integration, file associations, services, and any component that reads machine registration data.
AppId joins upgrades
AppId is the installation identity used for the uninstall registry key and uninstall log. Releases that retain the same AppId normally append their changes to that existing log. This lets a later uninstaller understand files recorded by earlier installs.
Changing AppId makes Windows see a different installed product for removal. Reusing one AppId for unrelated editions can create the opposite problem: their uninstall records overlap. Decide whether a release is an upgrade, a side-by-side edition, or a separate product before distributing it.
Silent still needs answers
Silent and very silent command-line modes hide different amounts of the wizard. Other switches can choose components and tasks, load saved choices, write a log, prevent restart, or supply installation details. Automation still depends on a script that has safe defaults.
Some critical messages can appear when Setup cannot continue, and custom script code can introduce prompts that silent mode does not answer automatically. A deployment job can therefore wait unseen for input. Run the exact unattended command in a clean virtual machine and check its exit result, log, installed files, and restart state.
Removal follows the log
Inno Setup creates an uninstaller when Uninstallable is enabled. Setting it to no removes that automatic path, so another updater, package manager, or manual procedure must own removal. Omitting an uninstaller does not make installed files temporary.
The uninstall log records what Setup placed and changed. Files created later by the application may need explicit cleanup rules, while user documents often need deliberate preservation. Shared files and overlapping installations require care because removing one product must not break another product that still uses the same object.
Custom Pascal Script can extend installation and removal with checks, forms, and event handlers. When several releases share one uninstall log, only one stored uninstall script runs. A change to removal logic in a newer release therefore needs testing against machines that passed through older scripts, not only fresh installations.
