On Wednesday 23 July 2003 12:03 pm, Mike Hearn wrote:
One dependency that isn't simple is that it embeds Internet Explorer and uses it as an HTML enabled word processor. The app uses a Java<->COM bridge to do that, and as such gives OLE quite a work out. Originally, not having much time, I just used microsofts OLE, which worked pretty well but unfortunately there was a problem with it deadlocking on thread detach, which blocked the loader section and so everything died. After trying to divine what was going wrong there for about a week, I decided that it was fruitless and I'd be better bringing Wines DCOM/OLE up to scratch.
Tell me abou it... both avenues are pretty darn thorny! My hope is that if I implement the LPC 'ports' api, NT rpcrt4/ole32/oleaut32 combo's will show more promise... but of course there is no guarantee until I try, which is going to take a while... you are probably on the right course imo, and certainly the course most likely to be helpful to wine.
Because this app does many horrid things, like marshalling IDispatch between threads in order to make calls from Java to IE (C++), I needed Oves patch to add these features, which he kindly sent. I've been hacking on that ever since, trying to make it able to do all the things said app needs. Cue wild learning spree as I try to cram the entirety of COM into my head in a few days :)
Sounds like you are doing a great job, BTW! I know this stuff gets kinda frustrating & tedious, but remember that you are in territory that has been a problem for wine since time immemorial.
The issue that plagued me before (which i've now hacked around) was that the call was segfaulting inside IE, because riid == NULL, not IID_NULL. Clearly this field is used, even though it's marked as reserved by Microsoft, as if it's wrong IE dereferences it and dies.
great find.
The reason NULL was being passed in instead of IID_NULL was because in the MIDL generated stubs, the Ndr call which demarshalls the iid was passed a pointer to a local variable (&riid), initialized on the stack as "RIID riid = NULL", it set *ppMemory = demarshaled iid, and trace statements confirmed that just before it returned *ppMemory was indeed pointing at the right thing. Unfortunately, for some reason riid stayed at NULL.
Changing the way riid was declared fixed that. I don't know why, and although I'm curious to find out, I'm running out of time before my year at QinetiQ is up and I drop the project and go back home, so I'm not that curious :(
10-4. It just caught my eye as a red-flag for some deeper problem that may deserve longer-term attention...
The problem I face now is that the property get request returns the HTML DOM IDispatch in a variant of type VT_DISPATCH, which the Ndr variant marshalling code doesn't seem able to handle.
unfortunately, this oleaut stuff is largely unknown to me... is this using CoMarshallInterface?
I poked about, saw that it couldn't handle that, and thought "I have a cunning plan - why not use NdrInterfacePointerMarshall to implement this code?", but unfortunately that function needs information that has been lost (ie not passed through the function calls) by the time we find out that the variant is a VT_DISPATCH.
Now I'm stuck :( I don't know how to get the information NdrInterfacePointerMarshall needs, namely the MIDL_STUB_BUFFER and format string, and I can't extend the function prototypes to contain it because they are invoked from some kind of table. Obviously hacks like global variables are wrong. That's where I left off todays adventures....
any insights welcome -mike
If it's in CoMarshallInterface, I think you will just create an infinite loop. It appears that CoMarshallInterface is called by NdrInterfacePointerMarshall to do all the dirty work.
Sorry, I wish I was a little more up on this stuff, but a lot of code has gone into rpcrt4 marshalling that I haven't even taken the time to audit and properly understand yet, and once we leave the domain of pure RPC and start mixing in with OLE & OLE automation I'm pretty ignorant... I've been meaning to correct that, but so far other things have occupied my time.