Jacek Caban jacek@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.