Typelib marshalling BSTRs

Mike Hearn mike at theoretic.com
Wed Jul 23 15:01:31 CDT 2003


On Wed, 2003-07-23 at 20:35, Gregory M. Turner wrote:
> 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.

The win98 versions are still available and work pretty well, the only
big problem being that obviously it's not free software, with all the
debugging and redistribution nastyness that implies.

> 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.

Thanks. I'm hoping that when I've got a grip on all this and settled
into uni I'll be able to write some more docs so in future people don't
have to spam the list to learn Wine OLE hacking.

> 10-4.  It just caught my eye as a red-flag for some deeper problem that may 
> deserve longer-term attention...

Yes, it's definately worth remembering. A friend suggested compiler bug,
which is possible, but then isn't gcc invincible? ;)

> > 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 assume I'd need to call that in order to marshal it, yes.

> 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.

I don't think I'll create an infinite loop, AFAIK the interface
marshalling code doesn't use the NDR engine, it just writes to an
IStream. In fact the ndr_ole code wraps the NDR buffer in a simple
IStream implementation so that API can be used. It's just a case of
having the right data at hand.

> 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.

Thanks for the encouragement anyway :) I'll think of something..... by
the end of it I'm going to have a pretty good overview of most areas of
OLE.

thanks -mike




More information about the wine-devel mailing list