Or, you know, you could just uncompress the application in a newly-created subfolder of C:\WINDOWS\TEMP\ and launch the binary that is to be run afterwards (which of course is conveniently named SETUP.EXE). The way it's always been done.
The problems with this approach are:
- It can take a long time to extract the package, especially if you are looking at gigabyte applications. We are able to launch huge applications instantly because we avoid the extraction step.
- Windows applications are typically hard-coded to read files from global locations like c:\windows\system32, side-by-side DLL locations, HKEY_LOCAL_MACHINE registry, font folders, services, etc. If you try to copy most applications to a single folder, they won't run. Some apps can be designed to run from a single folder, but this is the exception rather than the rule.
- Ideally you don't want the application writing to other parts of the filesystem or registry because it might screw up other apps. We solved this by doing copy on write access to other parts of the PC and redirecting the writes to a local folder.
How do you stop the app from permanently writing stuff to the registry or filesystem?
Thinapp solved this by presenting a synthetic view of the filesystem and registry to the app. This view merged the contents of the real system with the contents of the package, so the app thought everything was were it expected when it runs. In addition, we provided a copy-on-write sandbox of this view, so any writes would be redirected to a local folder without the app knowing about it. If you delete the sandbox, the app goes back to it's "first run" state.
It sounds a lot like how Flatpak and friends work. Would be interested if there were a few detailed blog posts about it?