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

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

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?

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

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

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

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

Post by James Hawkins
--
James Hawkins

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

[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

[James Hawkins]

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.

[Huang, Zhangrong]

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

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

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.

[Huang, Zhangrong]

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

[Steven Edwards]

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.

[Robert Shearman]

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.

[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

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

...