4 ms·

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 (whi

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.

fooker 8y ago
How do you stop the app from permanently writing stuff to the registry or filesystem?
- jclarkcom 8y ago
  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.
  - hashhar 8y ago
    It sounds a lot like how Flatpak and friends work. Would be interested if there were a few detailed blog posts about it?
jclarkcom 8y ago
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.

fooker 8y ago

How do you stop the app from permanently writing stuff to the registry or filesystem?

jclarkcom 8y ago
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.
- hashhar 8y ago
  It sounds a lot like how Flatpak and friends work. Would be interested if there were a few detailed blog posts about it?

jclarkcom 8y ago

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.