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. -- "...he that hath no sword, let him sell his garment, and buy one." - Jesus Christ, Luke 22:36 gmt
