ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.

[Maarten Lankhorst]

James Hawkins schreef:
> On Dec 22, 2007 12:25 PM, Huang, Zhangrong <hzhrong at gmail.com> wrote:
>   
>> 2007/12/23, James Hawkins <truiken at gmail.com>
>>> On Dec 22, 2007 9:46 AM, Huang, Zhangrong <hzhrong at gmail.com> wrote:
>>>       
>>>> Hi,
>>>> Sorry for the delay.
>>>> Here is a test, pls import the attached registry files, and copy
>>>> native activeds.dll, adsldpc.dll,
>>>> adsldp.dll to your windows system32 dir, and patch
>>>> wine/dlls/ole32/tests/moniker.c
>>>>
>>>> Then run the test:
>>>> $ ../../../wine ole32_test.exe.so moniker
>>>> err:ole:apartment_getclassobject DllGetClassObject returned error 0x80004002
>>>> err:ole:create_server class {228d9a81-c302-11cf-9aa4-00aa004a5691} not
>>>> registered
>>>> fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
>>>> err:ole:CoGetClassObject no class object
>>>> {228d9a81-c302-11cf-9aa4-00aa004a5691} could be created for context
>>>> 0x15
>>>> moniker.c:783: Test failed: ****************LDAP**************
>>>> moniker: 2 tests executed (0 marked as todo, 1 failure), 0 skipped.
>>>>
>>>> after my patch:
>>>> $ ../../../wine ole32_test.exe.so moniker
>>>> moniker.c:783: Test failed: ****************LDAP**************
>>>> moniker: 2 tests executed (0 marked as todo, 1 failure), 0 skipped.
>>>>
>>>> Although the test failed, but loading class
>>>> {228d9a81-c302-11cf-9aa4-00aa004a5691} success.
>>>>
>>>>
>>>> 2007/12/21, Robert Shearman <rob at codeweavers.com>:
>>>>         
>>>>> Huang, Zhangrong wrote:
>>>>>           
>>>>>> See dlls/ole32/compobj.c,
>>>>>>
>>>>>> static HRESULT apartment_getclassobject(struct apartment *apt, LPCWSTR dllpath,
>>>>>>                                         BOOL apartment_threaded,
>>>>>>                                         REFCLSID rclsid, REFIID riid,
>>>>>> void **ppv)
>>>>>> {
>>>>>> ...................
>>>>>>     if (SUCCEEDED(hr))
>>>>>>     {
>>>>>> ..................
>>>>>>         TRACE("calling DllGetClassObject %p\n",
>>>>>> apartment_loaded_dll->dll->DllGetClassObject);
>>>>>>         /* OK: get the ClassObject */
>>>>>>         hr = apartment_loaded_dll->dll->DllGetClassObject(rclsid, riid, ppv);
>>>>>>                                                                   ^^^^
>>>>>>         if (hr != S_OK)
>>>>>>             ERR("DllGetClassObject returned error 0x%08x\n", hr);
>>>>>>     }
>>>>>> ..............
>>>>>> }
>>>>>>
>>>>>> Reference to http://msdn2.microsoft.com/en-us/library/ms680760.aspx,
>>>>>>
>>>>>> riid
>>>>>>
>>>>>>     [in] Reference to the identifier of the interface that the caller
>>>>>>     is to use to communicate with the class object. Usually, this is
>>>>>>     IID_IClassFactory (defined in the OLE headers as the interface
>>>>>>     identifier for IClassFactory).
>>>>>>
>>>>>>             
>>>>> This doesn't mean anything other than CoCreateInstance is usually used
>>>>> instead of CoGetClassObject (and CoCreateInstance always passes in
>>>>> IID_IClassFactory for the IID).
>>>>>           
>>>> It's failed when calling MkParseDisplayName.
>>>>
>>>>         
>>>>>> We can't pass riid to DllGetClassObject directly sometimes, causes some dlls'
>>>>>> DllGetClassObject (like native adsldp.dll) can only return reference-counted
>>>>>> pointer to class factory via IID_IClassFactory, for retrieving the
>>>>>> pointer to the
>>>>>> class object interface requested in riid, we must try another way.
>>>>>>
>>>>>>             
>>>>> Thank you for your patch, but this behaviour seems a little strange and
>>>>> needs a little more investigation before I am happy that it is correct.
>>>>> What parameters are being passed in to CoGetClassObject to cause the
>>>>> call to fail for you?
>>>>>           
>>>> That's how MS does, I see this strange behaviour happening through
>>>> assembly debugging.
>>>> First time calling DllGetClassObject using riid, and it's failed, then
>>>> trying IID_IClassFactory.
>>>>
>>>>         
>>> Disassembling what?
>>>       
>> Native ole32.dll, MkParseDisplayName calls adsldp.dll's
>> DllGetClassObject twice,
>> frist using IID_IParseDisplayName, second using IID_IClassFactory.
>>
>>
>>     
>
> Disassembling native Windows binaries is not allowed in this project,
> so I'm afraid none of your patches can be accepted
This is not the first time such disassemble occurs, I think it should be
made more clear that disassembly is not allowed in the wine project.

After looking at the wine faq, I only see disassembling mentioned once
in "Who can't contribute to Wine?", not even in a full sentence. Perhaps
it should be made prominent in the documentation about 'sending patches'
and debugging parts, and also give it a seperate mentioning in the wiki?

-Maarten