Typelib marshalling BSTRs

Gregory M. Turner gmturner007 at ameritech.net
Wed Jul 23 14:35:09 CDT 2003


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




More information about the wine-devel mailing list