Is it possible to run Thinapp Scripts inside the VM

[JohnFx]

I've written a thinApp script to dynamically create some registry keys when the package starts up and it seems to be working okay. However, it is writing the registry keys to the host system and not the virtual environment. Is there any way to make the script run within the virtual environment, or alternately write to the virtual registry explicitly in a script?

Folling is the code I am using to write the keys.

Sub SetStringKey_HKLM(strKeyPath,KeyName,strValue)

c

onst HEY_LOOCAL_MACHINE = &H80000002

strComputr = "." Set oReg=GetOect(twinmgmts:s:mpersonanaonLevel=impersonatate}!
" & strComput & "\root\d\default:StdRegPro)

oReg

eg.SetSngVague HKEY_LOCAL_AL_MACHINE,strKeyPateyName,strsalue

End Su

Sub

[Squidly_Man · Accepted solution]

JohnFx, You'll need to modify your ThinApp project registry hive text files (one or both depending upon the registry keys you're modifying in your script) to add the settings' parent key(s) with ISOLATION_WRITECOPY or ISOLATION_FULL to the header of the registry key line.

For example, if I'm writing mods to the HKLM\SOFTWARE\VMWARE key with a script, and I want these values to be stored in my ThinApp package's Sandbox vs. the native system's registry, I need to modify the HKEY_LOCAL_MACHINE.TXT file and ensure the parent key (HKEY_LOCAL_MACHINE\SOFTWARE\VMWARE) is present in the registry hive file with a value of ISOLATION_WRITECOPY (in case I wish to see what's on the native as well as what I write to the virtual registry hive) or ISOLATION_FULL (in the event I only want my app to pull settings from the virtual registry and not see what's in the native system).

Alternatively, you can also try the following in your PACKAGE.INI:

Read the online docs for more information on the above (see the link below).

-Dean F.

[JohnFx]

I think I might need to clarify my question based on your answer. I am talking about the .VBS scripts that are built into the package and run at startup of the package. I was under the impression that those run outside the context of the virtual environment, so I don't see how modifying the virtual registry keys would help.

[Squidly_Man]

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.

[JohnFx]

Are you absolutely sure about this. I isolated (with write_copy isolation) the exact key my script was modifying and it still affected the registry on the host system. I am writing to the key in the OnFirstSandboxOwner callback, perhaps this callback behaves differently?

[JohnFx]

Okay, I think I have discovered the issue and it appears that not all objects were being treated the same with respect to whether it affected the host system or not.

This Approach will write to the host system registry regardless of the isolation

Sub SetStringKey_HKLM(KeyPath,KeyName,Value)

const HKEY_LOCAL_MACHINE = &H80000002

Computer = "."

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!
" & Computer & "\root\default:StdRegProv")

oReg.SetStringValue HKEY_LOCAL_MACHINE,KeyPath,KeyName,Value

End Sub

This approach seems to operate inside the context of the virtual bubble

Sub SetStringKey_HKLM(KeyPath,KeyName,Value)

Set WSHShell = CreateObject("Wscript.Shell")

WSHShell.RegWrite "HKEY_LOCAL_MACHINE\" & KeyPath & "\" & KeyName, Value,"REG_SZ"

End Sub

[Squidly_Man]

Ahhh! Good catch John. I didn't even think to see how you were making your calls to modify the registry. That does make sense... :smileycool:

-Dean F.