I had an idea a while back and have been surprised not to find anyone else having the same. The quick summary:
Run a program in a "sandbox", similar to the Linux fakeroot tool, intercepting all accesses and changes to files, registry, etc., redirecting them to a different location.
It should be clear how this approach could make almost any application portable: simply run its installer in the sandbox, redirecting to your USB key.
There are bunches of other uses for this too, though: keep an easy archive of a clean, already set-up copy of an app; prevent two apps from possibly conflicting with each other; quickly sharing complex setups (e.g. to show the existance of a certain bug); easily moving infrequently-used apps off of the main disk... and finally, if locked down enough... run a questionable app (or web browser) in a sandbox where it couldn't mess with anything else. (chroot for Windows.)
So-- does this interest anybody? I have very little low-level programming experience on Windows, so I can't lead this project. (I may do it on Linux, since it's much easier there, though.) But if someone else does have the interest and know-how to make this possible, I could possibly help out; just let me know.
I've collected a few technical thoughts on how to do this below:
This is quite straightforward to implement on Linux, where we have LD_PRELOAD to be able to inject a dynamic library into almost any program. On Windows it's significantly more difficult. We have DLL_PRELOAD (http://fy.chalmers.se/~appro/nt/DLL_PRELOAD/), but that clearly requires admin privs and a reboot. The best alternative I can come up with is using the debugger interfaces to inject a library load right after the CreateProcess.
Then the question is: intercepting the Win32 API or the NT Native API? Patching the Native API allows more things to be caught, and might be easier because there are much fewer native API calls to worry about. But some things would be much more complex that way, like intercepting DDE or other stuff like that. Either way, one needs to be careful of infinite intercept loops and of intercepting all child processes.
Regards,
-Ken
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
maybe someone could compile wine... for windows :S
A quick look around shows a few commercial apps that do this. Thinstall VOS and AppOnkey (who it appears rather cheekily tried to advertise on here!).
I thought about this quite a while ago, but never really got around to trying it.
The way that I feel would be easiest is if you run the install for programs in a sandboxed environment.
So have a wrapper program which calls the installer, this will allow it to know the Process ID for the installer which makes it much easier to track file and registry access' as you can seperate them from other applications (the problem comes if it launches another process to do the installation, but we may be able to hook that as well).
We track and redirect registry and file access' using the same techniques that regmon and fileman use (available at www.sysinternals.com)
Once the app is installed we then have a record of all the files it accessed and all it's registry access's.
If we then only ever launch the application through our sandbox utility then, once again we have it's process ID and can capture and redirect it's file and registry access's.
Difficulties:
What happens if the application relies on shared/system dll's which may not exist on another system.
What happens if the application checks for other applications/libraries during install.
I think this technique could work quite well and easily on simple applications, but larger suites of applications would be a lot more problematic.
CC
Would Paraglider's RunScanner be useful to help redirect programs to a different set of registry hives (ie: registry on your USB/external drive?
You need to be able to dynamically patch registry entries.
I.e. if the registry points to a file that was in the install directory then you need to modify that to point to whatever the ESB drives path is.
CC
If a virtual registry feature is combined with a virtual file system feature, you approach what Thinstall and CEEDO have.
If the both the regisry and file system modules allowed pass through read only access to host machine based elements that aren't captured in their virtual proxies with all other creation, modify, and delete operations constrained to the virtual proxies, it is possible to create a shared space feature. Imagine that all my apps running on my USB drive could share a common virtual registry and file system. There would have to be some tools to prepare the apps for this as mentioned but if the tools themselves ran in the same environment, the results should be compatible to run anywhere the same virtual feature set existed.
There may be some practical issues that would force support for OSs to be limited to NT and up or even more severe to Win2K and up. Also, there are some suport tools that would be necessary to facilitate application profiling in order to deterine what registry and file system elements need to be setup when the app is istalled on the portable media.
The techniques for injecting dlls into processes to capture registry and file system calls are available and published. This is really not that far from being something for which at least a registry prototype couldn't be knocked off in a month or so. As for the development environment, I wouldn't be much help outside of C++ and Visual Studio and wonder if it would really make sense in proceed in any other environment for reasons other than prinicple.
Anyway - just trying to see if this will morph into a real project - I think that it's a great idea but some heavy lifting will be required.
I was considering making up an application that would run a Lua script that would have functionality to copy files, register DLLs, access the registry, execute files, and do all other things required to make an application portable. Having it use Lua would also mean it could be easily ported to Linux and Mac. The problem is my time schedule and my huge list of things to do. Once I get the time, I'll do some work on it.
Rob Loach [Website] [Projects]
What about modifying the interrupt table (there was an interrupt table in (at?) MS-DOS, but there should be a similar table of basic funktions in windows, too) so that any registry- and filerequests of the portable application are redirected to a fake registry or file table stoed on the thumb drive?