Windows installers are declarative and data-driven. An installer script does not simply use the file copy operations a usual app would use during runtime. Inst

Windows installers are declarative and data-driven. An installer script does not simply use the file copy operations a usual app would use during runtime. Instead an installer is driven by a number of "database" tables that specify the installer actions in a declarative way. There are several benefits to this approach. The declarative actions are reversible and the uninstall actions can thus be inferred automatically. This removes the burden on install authors to create a script to reverse the install operations. This includes registering services/daemons (will unregister on uninstall), registering protocol handlers, filetype/program associations, desktop shortcuts etc. The declarative approach also allows the installer to roll back in case of an error during installation. This even includes "undeleting" files that were deleted. (https://docs.microsoft.com/en-us/windows/win32/msi/rollback-installation https://docs.microsoft.com/en-us/windows/win32/msi/rollback-...) The author of the install script can (non-Store installers) escape and execute a specific program during the install process. This is rarely needed, though. So the default is that the uninstaller will uninstall by completely reversing the install actions. https://docs.microsoft.com/en-us/windows/win32/msi/windows-installer-portal https://docs.microsoft.com/en-us/windows/win32/msi/windows-i...