Comment by jclarkcom | Hacker News Reader

Comment by jclarkcom | Hacker News Reader

Parent Full thread

I worked on something similar for Windows for nearly 10 years, called Thinstall (acquired by vmware and renamed to Thinapp). I love the idea of something like that for linux.

We put a lot of effort into being able to run an application directly from a compressed single-file binary, you have a small executable with a big payload attached to the end of it. The payload essentially contains a mountable filesystem, however because windows doesn't support doing anything like that from an unprivileged account we had to emulate many things Windows normally does, including execution of binary images.

We did some tricks where executable data was stored on disk in a format it can be directly memory mapped and run without reading anything - this allowed us to launch most applications over a network without extracting anything to disk locally and achieve millisecond launch times. Pages would get pulled into local memory by the OS as needed while the application was running.

The end result was that you can create a single EXE file could contain things like python + script, or more complex like photoshop & Word. Just go to a new computer from a guest account, launch the EXE and you instantly start using that app.

I haven't been involved with it for the last 6 years, but I believe vmware still offers it.

Wow, hello! I worked in the UK on a short-lived product called SoftInstall.net which did something similar for .NET applications. We had our own file system and registry emulation layers, all inspired by Microsoft Research’s “Detours” paper. I remember being impressed with Thinstall at the time.

My email is in my profile - fee free to say hi!

You gotta emulate CreateProcessEx? How did you approach that?

I've seen people do it by running something like calc.exe suspended then remapping all the memory. The trouble is, this approach certainly wouldn't work for situations involving 64 bit Windows and 32 bit binaries, and well, it's ugly and confusing ("why is Photoshop running under calc.exe?") Surely, the solution had to be nicer than that?

Didn’t you use Lisp to develop it? It would be great if you could share your experiences with that.

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?

Reply on news.ycombinator.com