ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
Huang, Zhangrong
hzhrong at gmail.com
Sat Dec 22 09:46:05 CST 2007
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.
Anyway, what's DllGetClassObject return depends on its implementation,
it can be a pointer to
ClassFactory or a pointer to class object, we should try both.
>
> --
> Rob Shearman
>
>
--
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LDAP.reg
Type: application/octet-stream
Size: 476 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20071222/0441f2da/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests_moniker.diff
Type: text/x-patch
Size: 1854 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20071222/0441f2da/attachment.bin
More information about the wine-devel
mailing list