Scripts embedded within the root of a ThinApp package will always run within the context of the virtual environment (i.e. inside the virtual bubble). Modifying the ThinApp project t...
See more...
Scripts embedded within the root of a ThinApp package will always run within the context of the virtual environment (i.e. inside the virtual bubble). Modifying the ThinApp project to add those registry keys as previously stated will, in this scenario, properly set the isolation levels upon those keys so that any changes made to them (whether by the app or by the embedded script) will remain within the virtual environment. Some things to remember (for anyone reading this); A ThinApp packaged application can be configured to keep all runtime modifications within the virtual bubble or allow any number or type of runtime modifications be made out on the native environment if that is desired. This is in part because ThinApp packaged applications can be configured to isolate all or some (or, if you want, even none) of the application's utilized files or registry entries by setting isolation levels upon individual registry keys and folders in the file system. Isolation levels essentially define what the packaged application can see and do on the native system (i.e. outside the virtual bubble). An anology I like to use is; think of yourself as the application and you're standing inside a bubble. You don't see the bubble but you see the effects of the bubble - the bubble being created by the ThinApp Virtual Operating System. If FULL ISOLATION is set, that means you, the app, cannot see or modify anything outside the bubble (on the native system). If MERGED isolation is set, you, the app, can not only see, but affect changes to the native system. With WRITECOPY isolation, ThinApp basically tricks the app to thinking it has complete access to the native system but actually takes a copy of that file/registry setting and writes it to the ThinApp Sandbox (which is also part of the virtual bubble) for the app to modify as necessary. So, in a sense, WRITECOPY is a read only state on the native system. Following this logic process a step further, one can also deduce that ThinApp has an order of precedence in that if a registry setting/file exists both in the virtual bubble and on the native system, the one within the virtual bubble will take precedence over that of the native setting or file. Lastly, isolation levels are set per registry key or per folder on the file system and are inheritable. Hope this helps! -Dean F.