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

[James Hawkins]

On Dec 22, 2007 6:57 PM, Maarten Lankhorst <maarten at codeweavers.com> wrote:
> 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
>

You could paste it all over winehq.org and the docs and it'll still happen.

-- 
James Hawkins