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-...)
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-i...