John Haller wrote, on 2012-09-27:
virtualization in a stable, reliable form is something I'd like to look into including at some point.
Does this mean that the PortableApps.com platform only migrates changes upon app termination?
For those unfamiliar with these terms, there are two common methods of portablizing an app that isn't already portable: one is by virtualizing its system access (intercepting registry and file changes and redirecting them to a portable folder); the other is by allowing changes on the host and then migrating them into the portable folder when the app terminates, according to a pre-packaged knowledge base about what regions that particular app is known to change or by monitoring it while it runs.
I would prefer to use PortableApps instead of JauntePE ("JPE"), to gain the benefits of its launcher menu, update frequency, and broad community support. But I'm very timid about losing the protections I've enjoyed with JPE for many years. It truly leaves no trace* on the host system, even during app operation, nor even if power is lost or the whole machine crashes. Furthermore, registry conflicts are impossible between apps with JPE, which allows me to run them all concurrently without "fighting" over ownership of file types, DLL handlers, etc.
Does PortableApps already offer the protections I crave, perhaps using methods I'm not aware of? If not, consider this another +1 vote for adopting virtualization tech, someday sooner rather than later.
*No trace specific to that app, anyway. I'm not bothered by changes Windows itself makes in response to an app, such as recording exe signatures or tracking usage of hardware peripherals.
Programs from ProtableApps only migrate changes upon termination, you are correct.
As far as I know, though I'm not a developer here, virtualization like that is not being developed by PA at this moment.
My posts are old and likely no longer relevant.
Currently, there is still no viable component that we could use. As I mentioned before, we'd be happy to explore one if there was one. I personally don't have the technical expertise or time to code one.
JPE seems like it is abandoned and never got proper 64-bit support, even to beta level, just in a few nightly builds. Is that still the case? Also, did JPE work out its licensing issues? It was using a closed-source component that could only be distributed for personal/educational use, which is a big hinderance for our needs.
All our apps here have no issues with registry or DLL handler conflicts and work fine with each other. None of them do file type handling internally but all have their file type association information included in their config files to advertise to the platform (including extensions handled, icons to use for those extensions, mime types handled, specific command line parameters to use for each file/mime type, etc). These will be used by the platform shortly to automatically manage file associations for all apps.
Sometimes, the impossible can become possible, if you're awesome!
JPE did get clear of licensing tangles; as of version 0.6.0 it began using its own code instead of the MadCodeHook libraries. Citation: https://sites.google.com/site/jauntepe/latestnews/open-sourceclosed-sour...
Unfortunately, JPE does seem abandoned, without having finished 64-bit support, and I confess I've had trouble building it from the sourceforge repository. It compiles ok, but does not seem to function properly as-is. So its viability may be rather poor for your expertise and time.
Thanks for the conversation, and for the good news about conflicts and file associations!