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

[James Hawkins]

On Dec 22, 2007 12:25 PM, Huang, Zhangrong  wrote:
> 2007/12/23, James Hawkins :
> > On Dec 22, 2007 9:46 AM, Huang, Zhangrong  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 :
> > > > 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.