Typelib marshalling BSTRs

[Ove Kaaven]

man, 21.07.2003 kl. 17.31 skrev Mike Hearn:
> On Mon, 2003-07-21 at 12:55, Ove Kaaven wrote:
> > > fixme:ole:PointerUnmarshall unhandled ptr type=12
> > 
> > This means that null pointers may not be handled properly (but non-null
> > pointers will still work). However, I have yet to see a situation where
> > I needed to handle it, but then again I've only worked on InstallShield.
> > I suppose it's possible that you need to if you're working on something
> > else (but I don't think IDispatch is an interface where you need to
> > worry about it). 
> 
> IDispatch::Invoke has an riid parameter, that the docs say is reserved
> and must be IID_NULL. In the current custom marshallers, trace
> statements reveal that the stub receives this as NULL, not IID_NULL. Are
> they equivalent in this context, or is that being marshalled
> incorrectly?

Not exactly equivalent here. The ptr type is not 0x12 here, I think;
supplying NULL here is completely invalid and the MIDL code in oaidl_p.c
will raise an exception, completely refusing to marshal the call at all.

If supplying NULL is supposed to be valid at the API level, it must be
handled by the IDispatch_Invoke_Proxy wrapper in usrmarshal.c,
converting the NULL to IID_NULL, before passing it off to the
MIDL-generated marshaller. (This Invoke wrapper already treats some
other can-be-NULL arguments in this manner, so this would just be yet
another case of this.)

> > You probably just need to marshal an extra flag saying
> > whether the pointer is null or not, but since I haven't seen the DCE RPC
> > spec I don't know what the flag should look like.
> 
> Is that just a case of adding another IStream::Write call, and having
> the equivalent read in the custom demarshaller?

That would probably work, except that MIDL-based marshallers and rpcrt4
don't use IStream...

> > Hmm. It could still be in Wine code, since NdrComplexArrayUnmarshall
> > might be trying to unmarshal an array of variants, which is a custom
> > type. The custom-marshalling code for variants is in
> > dlls/oleaut32/usrmarshal.c, and there is a VariantInit in the
> > VARIANT_UserUnmarshal function in there (though it probably shouldn't
> > have shown up in a relay trace).
> 
> I found that it's in IDispatch_Invoke_Stub - it calls IDispatch::Invoke
> on the actual object and crashes, in native shdocvw code. So, I guess
> the inputs its given there are incorrect somehow. I'll look into it some
> more.

OK.