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

[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).
> 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?

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

[Huang, Zhangrong]

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.

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

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

[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?

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

[Huang, Zhangrong]

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.
> --
> James Hawkins

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.

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  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

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

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

[James Hawkins]

On Dec 22, 2007 6:57 PM, Maarten Lankhorst  wrote:
> James Hawkins schreef:
> > 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
>
> 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.

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

[Huang, Zhangrong]

hi,

2007/12/23, James Hawkins :
> On Dec 22, 2007 6:57 PM, Maarten Lankhorst  wrote:
> > James Hawkins schreef:
> > > On Dec 22, 2007 12:25 PM, Huang, Zhangrong  wrote:
> > > > 2007/12/23, James Hawkins
> > > > > > >
> > > > > >
> > > > >
> > > > > 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.

Thank you for mentioning that. But, I think that's kind of mixing up.
I didn't do anything like disassembly code to source code translation.
I just saw how native binaries work when debugging my app in Windows.

I didn't have much knowledge about COM, so I searched MSDN and found
some useful info about DllGetClassObject, then I wrote the patch, it's
quite clean.

Why I mentioning disassembly is just giving a sample that how to call
DllGetClassObject,
it doesn't mean I have done anything illegal to wine.

Anyway, have you tried my testcase? Then how can we fix the problem?
> > 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.

That could be useful.
> --
> James Hawkins

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

[James Hawkins]

On Dec 22, 2007 10:37 PM, Huang, Zhangrong  wrote:
> hi,
>
> 2007/12/23, James Hawkins :
> > On Dec 22, 2007 6:57 PM, Maarten Lankhorst  wrote:
> > > James Hawkins schreef:
> > > > On Dec 22, 2007 12:25 PM, Huang, Zhangrong  wrote:
> > > > > 2007/12/23, James Hawkins
> > > > > > >>
> > > > > > >
> > > > > > 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.
>
> Thank you for mentioning that. But, I think that's kind of mixing up.
> I didn't do anything like disassembly code to source code translation.
> I just saw how native binaries work when debugging my app in Windows.

Disassembling of any kind is prohibited.  You don't have to convert
the disassembly to source code first to disqualify.
> I didn't have much knowledge about COM, so I searched MSDN and found
> some useful info about DllGetClassObject, then I wrote the patch, it's
> quite clean.

You just said you disassembled native ole32.dll.

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

[Huang, Zhangrong]

2007/12/23, James Hawkins :
> On Dec 22, 2007 10:37 PM, Huang, Zhangrong  wrote:
> > hi,
> >
> > 2007/12/23, James Hawkins :
> > > On Dec 22, 2007 6:57 PM, Maarten Lankhorst  wrote:
> > > > James Hawkins schreef:
> > > > > On Dec 22, 2007 12:25 PM, Huang, Zhangrong  wrote:
> > > > > > 2007/12/23, James Hawkins 
> > > > > > >>>
> > > > > > >>
> > > > > > > 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.
> >
> > Thank you for mentioning that. But, I think that's kind of mixing up.
> > I didn't do anything like disassembly code to source code translation.
> > I just saw how native binaries work when debugging my app in Windows.
>
> Disassembling of any kind is prohibited.  You don't have to convert
> the disassembly to source code first to disqualify.

Actually, I did say "assembly debugging" at first, because when I was debugging
my private app, what I saw in native ole32.dll was assembly code, so I called
"assembly debugging".  All I got that was native ole32.dll called
DllGetClassObject
twice, that's it, I didn't know how it done and still don't understand
that assembly code well.
> > I didn't have much knowledge about COM, so I searched MSDN and found
> > some useful info about DllGetClassObject, then I wrote the patch, it's
> > quite clean.
>
> You just said you disassembled native ole32.dll.

Maybe I missed what your said and what you mean, but you said
"disassembly"  first,
I did mean I saw native ole32.dll in assembly code mode, not mean I
did disassembly
or any cracking stuff.
> --
> James Hawkins

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

[Steven Edwards]

On Sat, Dec 22, 2007 at 11:12 PM, James Hawkins  wrote:
> You could paste it all over winehq.org and the docs and it'll still happen.

I think this argument is totally bogus. Whats viewed as illegal
reverse engineering in Canada is not the same as in the United States.
Having this unwritten standard just means people end up wasting more
time. Lets just codify the standard practices and be done with it,
then when someone violates it, send them the URL so we don't have to
keep having this discussion every three months.

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

[Robert Shearman]

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.

I've just sent a patch for this. Thanks for reporting it and going to 
the trouble of describing how to reproduce it and proposing a patch.

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

[Huang, Zhangrong]

Hi,
> ole32: get_moniker_for_progid_display_name should fallback to using IClassFactory to get IParseDisplayName if getting it directly fails.

This fix looks OK, but still gets lots of error messages:

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

2008/1/7 Robert Shearman :
> > 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.
>
> I've just sent a patch for this. Thanks for reporting it and going to the
> trouble of describing how to reproduce it and proposing a patch.
>
> --
> Rob Shearman