8.18 IsolatedMemoryObjects
IsolatedMemoryObjects - List specific shared memory objects to isolate from other applications
Shared memory objects are created by applications using CreateFileMapping and OpenFileMapping.
Shared memory objects can be named or anonymous; when the objects are named, they will be
visible to other applications running in the same user account. Sometimes, it is desirable to isolate
shared memory objects so that virtual applications cannot see system objects and vice-versa. By
default, Thinstall will only isolate shared memory objects used by embedded Internet Explorer
instances, because there is a known conflict with between explorer.exe and iexplore.exe when they
map sandboxed files. You can use this option to isolate additional named shared memory objects so
they are visible only to other virtual applications using the same sandbox.
IsoaltedMemoryObjects accepts a list of entries that are separated using the ';' character. Each entry
can have wildcard characters '*' and '?' to match variable patterns.
Example
Isolate two shared memory objects, matching anything with "outlook" in the name and one matching
exactly "My Shared Object"
[BuildOptions]
IsolatedMemoryObjects=*outlook*;My Shared Object
8.19 IsolatedSynchronizatio...
IsolatedSynchronizationObjects - List specific synchronization objects to isolation from other
applications
Windows has several different named Synchronization objects :
- Mutex, accessed using OpenMutex & CreateMutex
- Semaphore, accessed using OpenSemaphore & CreateSemaphore
- Events, accessed using OpenEvent & CreateEvent
By default Thinstall will not isolate Synchronization objects. You can specify a list of sychronization
objects to isolate from other applications not running in the same virtual namespace. A namespace is
defined by the location of the application's sandbox. If two applications share the same sandbox
path, they will have the same namespace for isolated SynchronizationObjects. If two applications
have the same sandbox name, but the path to the sandbox is different, the applications will have
separate namespaces.
IsolatedSychronizationObjects accepts a list of entries that are separated using the ';' character. Each
entry can have wildcards characters '*' and '?' to match variable patterns.
Example
Isolate two synchronization objects, matching anything with "outlook" in the name and one matching
exactly "My Shared Object"
[BuildOptions]
IsolatedSychronizationObjects=*outlook*;My Shared Object
8.14 ExternalCOMObjects
ExternalCOMObjects - Controls whether a specific COM object CLSID will be created by
Thinstall or by Windows.
By default, Thinstall creates all COM objects inside of the virtual environment instead of Windows.
COM supports out-of-process (EXE) servers as well as service-based COM objects. If an application
can create such COM objects on the host PC and cause these COM objects to modify the host PC,
then the integrity of the host PC cannot be assured. However, if Thinstall executes out-of-process and
services-based COM objects inside of the virtual environment, all changes made by the COM objects
will be stored in the sandbox.
Example usage:
This instructs Thinstall to execute 2 COM objects outside of the virtual environment if they are
created by the application
[BuildOptions]
ExternalCOMObjects={8BC3F05E-D86B-11D0-A075-00C04FB68820};{7D096C5F-AC08-4F1FBEB7-
5C22C517CE39}
8.44 VirtualizeExternalOut...
VirtualizeExternalOutOfProcessCOM - Controls whether external Out-of-process COM
objects are run in the virtual environment
Thinstalled applications can create COM objects that are registered in the virtual environment, as well
as COM objects from the host system.
This option determines how to treat Out-of-process COM objects that are not part of a Thinstall
package and not registered in the virtual registry. By default, Thinstall will execute external out-ofprocess
COM objects in the virtual environment, so such COM objects cannot modify the host PC. If
you run into a compatability issue with an external COM object running in the virtual environment, this
option can be used to allow such objects to be created by and run on the host system. If you want to
run only specific COM objects outside of the virtual environment, you can list each COM object's
CLSID explicity using ExternalCOMObjects.
Examples:
This instructs Thinstall to execute all external out-of-process COM objects in the system context,
not in the virtual environment
[BuildOptions]
VirtualizeExternalOutOfProcessCOM=0
This instructs Thinstall to execute all external out-of-process COM objects in the virtual environment
(default)
[BuildOptions]
VirtualizeExternalOutOfProcessCOM=1
根据上面的解释
按照我现在的理解是：
设置成
VirtualizeExternalOutOfProcessCOM=0
不设置ExternalCOMObjects=
那程序就会直接调用系统环境的所有COM对象，如果设置了ExternalCOMObjects=只调用指定的com对象。
对吗？
关于 IsolatedMemoryObjects 和 IsolatedSynchronizatio...
我现在的理解是
如果不设置这两个内容，系统可以从这个程序中获取所有的内容，而如果不想让系统获取相关内容或者要隔离保护这个程序才需要设置这两个项目。
这样理解对吗？
另外com对象，MemoryObjects，SynchronizationObjects
各起什么作用？
请各位前辈指教，谢谢！