[2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).

[Dmitry Timoshkov]

Jacek Caban <jacek at codeweavers.com> wrote:


> >> On 09/02/15 07:44, Dmitry Timoshkov wrote:
> >>> +    if (member == DISPID_HTTPREQUEST_OPTION)
> >> Why can't we use standard, ITypeInfo-based implementation here?
> > The tests (1/2 and existing ones) show that ITypeInfo->Invoke doesn't work
> > for a lot of cases when native IWinHttpRequest::Invoke succeeds. In fact,
> > after a lot of attempts I failed to force ITypeInfo->Invoke work at all
> > under Windows using same code that winhttp request (and many other places
> > in Wine) uses to load a typelib from winhttp.dll and forward Invoke to
> > ITypeInfo implementation.
> 
> It seems to me that it's a typelib problem. I think that Invoke
> implementation can't find how to handle enum arguments. Did you try if
> building the typelib with midl helps? My guess is that the typelib
> produced by widl is somehow broken.

I tried almost all things that can think of like extracting a binary
typelib from an XP's winhttp.dll and replacing by it a Wine generated
one in the Wine built-in winhttp.dll, extracting with oleview.exe typelib
from XP's winhttp.dll and compiling it with widl and idl and using the
result again in the Wine built-in dll. After that I've written a test under
Windows that does the same as Wine's winhttp's IDispatch implementation:
loads a typelib from winhttp.dll, and uses the resulting ITypeInfo for
experimenting with ITypeInfo_Invoke: noone of the Invoke calls succeed.
So I went to a conclusion that winhttp.dll in Windows most likely uses
custom Invoke implementation, especially taking into account that it
can successfully handle some invalid flags/args usage demonstrated by
the tests.

-- 
Dmitry.