Hi all,
I was wondering whether anybody with experience working with microsofts ole implementation (win98 version) could answer these questions:
Firstly, does anybody know what it does during thread detach? Its behaviour seems to vary according to, i dunno, the alignment of Mars and Jupiter or something. With a test app it destroys the hidden windows it seems to use for IPC, and terminates cleanly. With my IE-in-java app, it goes into a message loop, processes some messages then blocks waiting. It never drops out of the message loop.
Secondly, does anybody know what is missing from Wines built in OLE implementation for it to be used for IE embedded? I've tried using it, and other than a couple of bugs in the GIT (which I will try and send a patch for soon), it seems to get stuck in ITypeInfo::Dispatch() and ends up with an E_NOTIMPL exception.
Thirdly, why does MSOLE use hidden windows for communication? I've come across lots of gnashing of teeth in OLE/DCOM forums about this, people wondering why their app (and sometimes the whole system!) deadlocks if they don't service the message queue in threads that use OLE. Windows has had other forms of IPC for years, I can't see the logic behind using the limited and broken message passing scheme for it.
Wierdly enough, wines built in OLE seems to work OK for iexplore.exe itself, which iirc simply embeds the ActiveX control like any other program. So, maybe it's just a strange little bug that is stopping it from working.
anybody got some insight? thanks -mike
tir, 08.07.2003 kl. 12.23 skrev Mike Hearn:
Hi all,
I was wondering whether anybody with experience working with microsofts ole implementation (win98 version) could answer these questions:
Firstly, does anybody know what it does during thread detach? Its behaviour seems to vary according to, i dunno, the alignment of Mars and Jupiter or something. With a test app it destroys the hidden windows it seems to use for IPC, and terminates cleanly. With my IE-in-java app, it goes into a message loop, processes some messages then blocks waiting. It never drops out of the message loop.
I think it will also try to disconnect any proxies and stubs that were created in the apartment about to be destroyed, but I don't remember exactly. But I know it's mentioned somewhere, perhaps in the book I've read.
Thirdly, why does MSOLE use hidden windows for communication? I've come across lots of gnashing of teeth in OLE/DCOM forums about this, people wondering why their app (and sometimes the whole system!) deadlocks if they don't service the message queue in threads that use OLE. Windows has had other forms of IPC for years, I can't see the logic behind using the limited and broken message passing scheme for it.
Perhaps the "limited" nature of them is exactly the point. What other communication mechanisms in the Windows kernel have thread affinity, i.e. can run anything reliably (and quickly, message passing is probably among the most heavily-optimized stuff in the Windows kernel) in the context of a specific thread (when the OLE apartment type requires it)? Perhaps APCs to some degree, but they're even more limited, and possibly not as reliable, flexible, or predictable regarding reentrancy and in "not interrupting anything important". They probably *could* change over to it and implement their reliability-workarounds in terms of it instead of messages, but it would be a lot of pain for pretty much no gain - APCs have no advantages in this respect that I can see (people would just have to use alertable waits instead of message loops). And Microsoft did have backwards compatibility to think of...
-
Mike Hearn -
Ove Kaaven