This took a really long time, but it’s finally here: The new NSIS script - written completely from scratch, and has also undergone several major refactors. It has many new features and improvements, and the code is much more mature. There are still a few small things that need to be decided - I’ll sum them up at the end.

Major features

• Allow per-machine and per-user installations to coexist: This is done primary because the opposite cannot really be enforced on multi-user systems, but also because it might be something that could be useful in some cases. Now, their shortcuts have different names (per-user includes (current user)), and they are registered as distinct application, so both can be selected as default app.
• Better detection of previous installers: Maybe not as useful anymore, but on upgrades, the version number and install path of installations from previous installers, are detected and seemingly integrated.
• Improved workaround of Windows force-elevation of uninstallers: There is the /user command line option, which restarts the uninstaller unelevated, and is used when called from the system settings. This takes care of the bug on older versions of Windows that elevate per-user uninstalls, and also makes sure that on per-machine uninstalls, the Clear Cache and Clear Config options are for the user that run the uninstall (in case a different account was used for elevation - something that happens before the uninstaller is executed). This option is also available for the installer, and can be used for example, when it is started from an elevated prompt, but needs to install for the current (standard) user.
• Tweaked single instance: Now, the window of an already running instance of the installer/uninstaller is brought to front when the user runs the program a second time (instead of displaying the Retry/Cancel dialog box).
• Detection of qutebrowser running: The detection happens only if qutebrowser is running form within the install path, or in case of an upgrade to a different directory, also the uninstall path. Running from anywhere else shouldn't bother the install (and using only the process name for detection is weak).
• Command line options for fully configurable unattended setups: Components are set with /{DesktopIcon, StartMenuIcon, RegisterBrowser, ClearCache, ClearConfig}[=off]. There is also /InstallDir as a /D alternative that doesn’t have to be the last parameter and accepts quotes as usual, and /Silent as a more descriptive /S alternative which is also not case sensitive.
• Enhanced Components page: On upgrades, unless set from the command line, the shortcut and registry selections are based on the existing setup. The uninstaller displays which components are installed and are going to be removed. The Clear Cache and Clear Config components are only available if the directories exist, and are also available for the installer. A confirmation is requested if Clear Config is selected.
• Enhanced Install Directory page: The installation path typed by the user is processed on the fly: rejects illegal characters, navigates \.\ and \..\, converts / to \ while allowing only one, converts short names to long names, and also disallows the selection of some paths (the root of the drive, directly into Program Files, anywhere inside Windows). On fresh installs (or upgrade to new directory), if the selected directory exists and contains files, a message box informs the user and asks for confirmation (unless it only contains the default cache directory, which is the case with the default path for per-user installations).
• Clean up before extraction / after failure: If the installation directory contains files, any existing files that belong to the installation are removed (failure to remove a file will abort the install before the extraction begins), and if an existing subdirectory that belongs to the installation still contains files, the user is asked if the extra files should be removed or not (same with the uninstaller). If an installation fails to complete, the installer removes any written files/folders/registry. On upgrades, if the uninstaller is missing or fails to execute, the uninstall is performed by the installer.
• Ability for the user to interrupt and abort/resume an ongoing installation: The cancel button is enabled and available for the user to abort an active install, in which case the incomplete installation is removed.
• Verification of extracted files using SHA-256: After the extraction of each file, its hash is calculated and is compared with its original value stored at compile time. On a mismatch the user is informed and is given the option to retry the extraction or abort (and remove the incomplete install).
• Validation of registry operations: If the installer fails to make a registry change, the user is informed and is given the option to retry, abort, or continue without adding registry settings (in which case, attempts to remove any written key/value). If the uninstaller fails to remove a key/value, the user can retry, abort or continue ignoring the specific item.
• Log file support: Install/uninstall operations can be logged to a file by using the command line /Log option. It can accept as parameter the path of the log file, or an existing directory where the log will be saved with the default name (installer name + .log). If no parameter is provided, the log is created with the default name at the same directory as the .exe. On upgrades, both the installer and uninstaller write at the same log file.
• (Optional) MSI wrapper for deployment using MSCCM or Active Directory: This is similar to what Crome and Firefox provide with their "Enterprise" installers. It requires the WiX3 toolset, which can be downloaded by the script at compile time.
• (Early) Dark theme support: The setup window uses dark colors when dark mode for apps is set. There is no proper dark mode support for win32 apps from Windows yet (most existing methods are undocumented - more info: Discussion: Dark mode for applications microsoft/WindowsAppSDK#41). Currently, the detection is done through registry, and the colors are hardcoded. Some things, like message boxes and the "Browse Folder" dialog, don't have dark colors.

Building the installer

The script uses PowerShell to generate a .nsh file containing macros that can pass every file, its calculated hash, and every folder of the release, to any other macro or instruction. It also downloads the plugins (NsisMultiUser, UAC, StdUtils), and (if required) downloads and extracts the WiX binaries. The installer can also be built under Linux (with the POSIX build of makensis) if there is PowerShell Core installed (for the MSI package it also requires wine, but I haven’t test that).

Passing the script form its default location without setting any defines, builds both x86 and x64 for the version that gets from __init__.py. The most important configuration defines are the following:

• ARCH: Set the targeted CPU architecture. Can be either 'x86' or 'x64'. If left undefined, both architectures are built.
• VERSION: Set the release version number.
• MSI: Enable the creation of MSI wrappers. If defined empty, the WiX binaries are expected in $path. If the value is an http(s) link, it treats it as a link to the binaries .zip file - if only the protocol is defined, it uses a predefined link for the .zip download. Any other value is treated as the local path to the WiX binaries.
• SIGN: If defined it signs the installer and uninstaller executables, and (if created) the .msi package. It accepts the command string as its value, with %1 being replaced by the target file. If defined empty, it uses the predefined string signtool.exe sign /a /tr http://timestamp.digicert.com /td sha256 /fd sha256 "%1". Might come useful for Code signing on Windows #7249.
• DEBUG: If defined, a debug build of the setup will be created. Running the installer/uninstaller creates a debug log file in the same directory that the installer was created, or in a directory that is set as a value to the define.

Running the installer

Command line options for install:

qutebrowser-setup.exe [</AllUsers | /CurrentUser> [/Silent]] [/User]
                      [/RegisterBrowser[=off]] [/DesktopIcon[=off]] [/StartMenuIcon[=off]]
                      [/ClearCache] [/ClearConfig]
                      [/InstallDir=<{install_path}>] [/Log[={log_path}]]

Command line options for uninstall using the installer:

qutebrowser-setup.exe </Uninstall> </AllUsers | /CurrentUser> [/Silent] [/User]
                      [/ClearCache] [/ClearConfig] [/Log[={log_path}]]

Command line options for uninstaller:

uninstall.exe [</AllUsers | /CurrentUser> [/Silent]] [/User]
              [/ClearCache] [/ClearConfig] [/Log[={log_path}]]

Using the MSI:
The .msi is intended for system administrators and use with deployment tools like Active Directory or Microsoft System Center Configuration Manager. They run unattended and the installation is performed for all users. An MSI database editor like Orca can be used to create transforms (or make direct changes). These public properties are provided for configuration:

• INSTALL_PATH: Set the installation directory. Must be an absolute path.
• DESKTOP_ICON: Create Desktop shortcut icon. Can be on or off, default in on.
• START_MENU_ICON: Create Start Menu shortcut icon. Can be on or off, default in on.
• REGISTER_BROWSER: Register the browser with Windows. Can be on or off, default in on.
• LOG: The path of the log file or the log directory, default is \\.\nul.

They can also be set from command line, for example:

msiexec /package qutebrowser-setup.msi REGISTER_BROWSER=off DESKTOP_ICON=off INSTALL_PATH="C:\qb"

Reviewing the code

The code is structured in the following way:

• qutebrowser.nsi: The main script. It configures the plugins, has the installer and uninstaller Sections, and sources the rest of the files.
• config.nsh: Configures the setup build and provides a macro with the compile time commands.
• commands.nsh: Contains commands with operations that are repeated at different parts of the code, or are shared between the installer and uninstaller. The code of the functions is defined by macros, and imported for both installer and uninstaller for shared commands.
• callbacks.nsh: Contains the callback functions. Some functions are shared by the installer and uninstaller, that's why it is sourced twice, with a different function prefix each time.
• language-english.nsh: The English language strings. Where possible, it reuses strings from NSIS MUI. To add a new language, copy this file, change the language name and translate the strings. Then include the new file from the main script. Keep in mind though, that although MUI supports many languages, there are also a few strings from MultiUser plugin, which are only translated to Bulgarian and German (for other languages, they are displayed in English).

Things that might need changes

• The script is designed to download the 3rd party files to a temporary directory, build both architectures if needed, and remove the directory. But now build_release.py builds each installer separately, so it downloads the files twice. This could be overcomed without actual code changes, by setting KEEP_SCRATCHDIR for the first build and NO_DOWNLOADS for the second, while setting for both a temporary path in SCRATCHDIR. Or maybe it's not so important since the 32-bit build is going to be dropped?
• If the required versions of Win10/11 are going to be from a specific build number and above, a new detection method must be written.
• Maybe the message when the installer is started under 32-bit should be different, if it's not going to be a 32-bit version.
• The dark theme colors are set to match the Windows 11 dark theme, which is not completely black. Setting DARK_BGCOLOR_0=0, DARK_BGCOLOR_1=0 makes it look more like what Windows 10 uses.
• For the Welcome/Finish pages, I used a more modern looking image which is included with latest NSIS, and applied a small modification (color and logo). I think it looks ok, but maybe something different is preferred.