@Loverock Davidson
The JavaScript engine was communicating with trident through COM. However, COM supports both in-process and out-of-process "servers".
In-process is significantly faster as parameters/results from method/function calls do not need to be marshalled under this model. Out-of-process has a considerable overhead on each invocation.
The JavaScript engine was always "in-process" and thus exploits from memory corruption vulnerabilities etc. would have no process barrier to scale before being able to compromise the main process. Windows still lays out several other barriers to stop exploits in their tracts; nothing has changes there.
Thus, moving the JavaScript engine in with the rendering engine is merely a refactoring. In terms of security boundaries, nothing has changed. The speed improvements from this is probably not from more effective calls (being a binary model, in-proc COM has *very* low overhead), but rather because the rendering engine and the scripting engine now work against the same DOM with no need for adapter objects.
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
