Suppose, some process has initialized BoxedApp (see the function BoxedAppSDK_Init). When initializing the shared memory (uses MMF - memory mapped files), BoxedApp creates a virtual registry and a virtual file system. Now, other process can also use the virtual file system and the virtual registry. We say that these two processes share a virtual environment. Each of these processes is attached to the virtual environment. The initialization of BoxedApp, when an "attachment" to a virtual environment takes place, is called attaching to virtual environment.
The primary way of attaching a process to a virtual environment is running it in the context of an already attached process.
Such inheritance is regulated by the BoxedApp SDK options: DEF_BOXEDAPPSDK_OPTION__EMBED_BOXEDAPP_IN_CHILD_PROCESSES and DEF_BOXEDAPPSDK_OPTION__EMULATE_OUT_OF_PROC_COM_SERVERS.
If the option DEF_BOXEDAPPSDK_OPTION__EMBED_BOXEDAPP_IN_CHILD_PROCESSES is set, all the child processes inherit the link to the virtual environment; i.e. use the same virtual file system and registry as the parent process.
The option DEF_BOXEDAPPSDK_OPTION__EMULATE_OUT_OF_PROC_COM_SERVERS matters when dealing with non-hosted COM servers. If the COM object is implemented as an EXE file that is virtual, BoxedApp will run the virtual EXE file to create the COM object.
If the COM object is implemented as an EXE file that does not exist in the virtual file system, by default the process based on the EXE file will be created by the system. And even if the option DEF_BOXEDAPPSDK_OPTION__EMBED_is set, the new process will not be attached to the virtual environment, and hence will not have access, for example, to the virtual files. To attach such processes, set the option DEF_BOXEDAPPSDK_OPTION__EMULATE_OUT_OF_PROC_COM_SERVERS.