The first one is extremely easy to use and does a lot of work behind the scenes. For example, Symantec use it for running legacy applications such as Internet Explorer 6 in Windows 7.
They are not focused on the kind of security isolation of Vx32 but they work in low privilege Windows processes.
It's an older work worth reading. Other methods have appeared since. BASS and TxBox were interesting. Most have potential issues, though, as there's too much risk in the mechanism. The strongest method is still to run the untrusted code in a partition in a separation kernel with comms between trusted and untrusted component using carefully-validated, easily-parsed messages. Compromise gets the attacker stuck in the partition trying to feed attacks to other components via malicious messages that good validation will catch. And might be detected depending on how it's setup.
Open-source attempts for these constructions include KeyKOS, EROS, OKL4, Fiasco.OC, seL4, JX w/ type safety, INTEGRITY-178B, and recently Muen sep kernel. The model, implementation, and middleware levels vary with OKL4 having a decent component framework. In case anyone asks, the advantage of these over some extremely-clever, hypervisor stuff is (a) you don't need hypervisor capabilities and (b) more clever = more problems found over time in most cases.
- https://github.com/nektra/deviare2
- https://github.com/nektra/Deviare-InProc/
The first one is extremely easy to use and does a lot of work behind the scenes. For example, Symantec use it for running legacy applications such as Internet Explorer 6 in Windows 7.
They are not focused on the kind of security isolation of Vx32 but they work in low privilege Windows processes.