On Dec 22, 2007 6:57 PM, Maarten Lankhorst maarten@codeweavers.com wrote:
James Hawkins schreef:
On Dec 22, 2007 12:25 PM, Huang, Zhangrong hzhrong@gmail.com wrote:
2007/12/23, James Hawkins truiken@gmail.com
On Dec 22, 2007 9:46 AM, Huang, Zhangrong hzhrong@gmail.com 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 rob@codeweavers.com:
Huang, Zhangrong wrote:
> See dlls/ole32/compobj.c, > > static HRESULT apartment_getclassobject(struct apartment *apt, LPCWSTR dllpath, > BOOL apartment_threaded, > REFCLSID rclsid, REFIID riid, > void **ppv) > { > ................... > if (SUCCEEDED(hr)) > { > .................. > TRACE("calling DllGetClassObject %p\n", > apartment_loaded_dll->dll->DllGetClassObject); > /* OK: get the ClassObject */ > hr = apartment_loaded_dll->dll->DllGetClassObject(rclsid, riid, ppv); > ^^^^ > if (hr != S_OK) > ERR("DllGetClassObject returned error 0x%08x\n", hr); > } > .............. > } > > Reference to http://msdn2.microsoft.com/en-us/library/ms680760.aspx, > > riid > > [in] Reference to the identifier of the interface that the caller > is to use to communicate with the class object. Usually, this is > IID_IClassFactory (defined in the OLE headers as the interface > identifier for IClassFactory). > > This doesn't mean anything other than CoCreateInstance is usually used instead of CoGetClassObject (and CoCreateInstance always passes in IID_IClassFactory for the IID).
It's failed when calling MkParseDisplayName.
> We can't pass riid to DllGetClassObject directly sometimes, causes some dlls' > DllGetClassObject (like native adsldp.dll) can only return reference-counted > pointer to class factory via IID_IClassFactory, for retrieving the > pointer to the > class object interface requested in riid, we must try another way. > > Thank you for your patch, but this behaviour seems a little strange and needs a little more investigation before I am happy that it is correct. What parameters are being passed in to CoGetClassObject to cause the call to fail for you?
That's how MS does, I see this strange behaviour happening through assembly debugging. First time calling DllGetClassObject using riid, and it's failed, then trying IID_IClassFactory.
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.