Discussion:
ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
Robert Shearman
2007-12-20 19:16:27 UTC
Permalink
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?
--
Rob Shearman
Huang, Zhangrong
2007-12-22 15:46:05 UTC
Permalink
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.
Post by Robert Shearman
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.
Post by Robert Shearman
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.
Post by Robert Shearman
--
Rob Shearman
--
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
James Hawkins
2007-12-22 17:06:58 UTC
Permalink
Post by 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
$ ../../../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.
$ ../../../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.
Post by Robert Shearman
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.
Post by Robert Shearman
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?
--
James Hawkins
Huang, Zhangrong
2007-12-22 18:25:36 UTC
Permalink
Post by James Hawkins
Post by 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
$ ../../../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.
$ ../../../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.
Post by Robert Shearman
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.
Post by Robert Shearman
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.
Post by James Hawkins
--
James Hawkins
--
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
James Hawkins
2007-12-22 20:55:39 UTC
Permalink
Post by Huang, Zhangrong
Post by James Hawkins
Post by 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
$ ../../../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.
$ ../../../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.
Post by Robert Shearman
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.
Post by Robert Shearman
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.
--
James Hawkins
Maarten Lankhorst
2007-12-23 00:57:00 UTC
Permalink
Post by James Hawkins
Post by Huang, Zhangrong
Post by James Hawkins
Post by 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
$ ../../../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.
$ ../../../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.
Post by Robert Shearman
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.
Post by Robert Shearman
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
James Hawkins
2007-12-23 03:12:18 UTC
Permalink
Post by Maarten Lankhorst
Post by James Hawkins
Post by Huang, Zhangrong
Post by James Hawkins
Post by 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
$ ../../../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.
$ ../../../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.
Post by Robert Shearman
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.
Post by Robert Shearman
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
Huang, Zhangrong
2007-12-23 04:37:05 UTC
Permalink
hi,
Post by James Hawkins
Post by Maarten Lankhorst
Post by James Hawkins
Post by Huang, Zhangrong
Post by 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?
Post by James Hawkins
Post by Maarten Lankhorst
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.
Post by James Hawkins
--
James Hawkins
--
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
James Hawkins
2007-12-23 09:43:18 UTC
Permalink
Post by Huang, Zhangrong
hi,
Post by Maarten Lankhorst
Post by James Hawkins
Post by Huang, Zhangrong
Post by 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.
Post by Huang, Zhangrong
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.
--
James Hawkins
Huang, Zhangrong
2007-12-23 10:49:04 UTC
Permalink
Post by James Hawkins
Post by Huang, Zhangrong
hi,
Post by Maarten Lankhorst
Post by James Hawkins
Post by Huang, Zhangrong
Post by 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.
Post by James Hawkins
Post by Huang, Zhangrong
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.
Post by James Hawkins
--
James Hawkins
--
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
Steven Edwards
2008-06-17 17:46:26 UTC
Permalink
Post by James Hawkins
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.
--
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Robert Shearman
2008-01-06 16:21:57 UTC
Permalink
Post by 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
$ ../../../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.
$ ../../../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
Huang, Zhangrong
2008-06-17 14:53:59 UTC
Permalink
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
Post by Huang, Zhangrong
$ ../../../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.
$ ../../../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
--
$ apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
Loading...