On 08/10/2017 01:01 PM, Jacek Caban wrote:
On 10.08.2017 18:47, Zebediah Figura wrote:
On 08/10/2017 09:33 AM, Jacek Caban wrote:
On 09.08.2017 20:12, Zebediah Figura wrote:
On 08/09/2017 06:07 AM, Jacek Caban wrote:
Are you sure that's how it's supposed to work? I didn't test it myself, but given how it's registered and documented, I'd expect that CLSID_InternetExplorerManager should live in a different process from CLSID_InternetExplorer. It should be easy to distinguish those processes with -startmanager command line argument.
I'm sorry, I don't understand what you mean. Isn't CoRegisterClassObject process-agnostic?
It is in a sense that created proxy/stub abstract where the object lives, yes. But note that the actual instance of IE object must live in one process or another. There is a lot of different aspects like pluggable protocols, script engines, ActiveX objects, document objects that live in its process and it's quite important for them which process it is. I did a bit of testing and it seems to be a separated process on Windows, so we should follow that.
Jacek
Isn't the IEM object already created in a different process with this patch (namely, iexplore.exe -startmanager), since it has to be created with CLSCTX_LOCAL_SERVER?
Not really, see how CoRegisterClassObject is used. With your patches a single process (both with -embeding and -startmanager arguments) registers both CLSID_InternetExplorer and CLSID_InternetExplorerManager with REGCLS_MULTIPLEUSE. It means that all instances of both objects will live in this single process. I think that -embeding should register CLSID_InternetExplorer and -startmanager should register CLSID_InternetExplorerManager (probably with REGCLS_SINGLEUSE).
Ah, I see. I'm not sure that's quite right, though, since creating a IEM instance will pass both options. It seems like it would be correct to register IEM when -startmanager is passed and IE otherwise.