Alexandre, could you back this patch out?
This patch broke shell ParseDisplayName (created call loop) from IShellFolder_ParseDisplayName to SHELL32_ParseNextElement back to IShellFolder_ParseDisplayName
Vitaliy Margolen
Tuesday, June 14, 2005, 14:08:31, Vitaliy Margolen wrote:
Changelog: Implement SHGetPathFromIDList based on GetDisplayNameOf
Bye,
Hi Vitaliy,
On Thursday 23 June 2005 20:57, Vitaliy Margolen wrote:
This patch broke shell ParseDisplayName (created call loop) from IShellFolder_ParseDisplayName to SHELL32_ParseNextElement back to IShellFolder_ParseDisplayName
SHELL32_ParseNextElement consumes one path component each time it's called. So this loop should consume the path while it's looping until it eventually hits the tail, in which case IShellFolder_ParseDisplayName won't call SHELL32_ParseNextElement any more.
Do you have a piece of code, or an application which crashes because of this loop? I didn't have any problems with it up to now. Would be cool if I could have a look at the code to find the problem.
Bye,
Thursday, June 23, 2005, 1:57:27 PM, you wrote:
Hi Vitaliy,
On Thursday 23 June 2005 20:57, Vitaliy Margolen wrote:
This patch broke shell ParseDisplayName (created call loop) from IShellFolder_ParseDisplayName to SHELL32_ParseNextElement back to IShellFolder_ParseDisplayName
SHELL32_ParseNextElement consumes one path component each time it's called. So this loop should consume the path while it's looping until it eventually hits the tail, in which case IShellFolder_ParseDisplayName won't call SHELL32_ParseNextElement any more.
What I seen is that IShellFolder_ParseDisplayName being called with some path. It starts from top "Desktop" and calls SHELL32_ParseNextElement. Which in turn calls IShellFolder_ParseDisplayName with "Desktop". There is nothing that brakes this circle and wine runs out of stack.
Do you have a piece of code, or an application which crashes because of this loop? I didn't have any problems with it up to now. Would be cool if I could have a look at the code to find the problem.
shlfolder test will do it right from the start. One more is winecfg: click on "Add application" button.
I didn't research this problem - don't have time for. Don't know if this is because I have more drives/more directories then you or something else. My tree is not modified except not relevant things (GetAttributesOf & shell exec).
I have shell and relay log if you need it.
Vitaliy.
On Friday 24 June 2005 04:15, Vitaliy Margolen wrote:
Do you have a piece of code, or an application which crashes because of this loop? I didn't have any problems with it up to now. Would be cool if I could have a look at the code to find the problem.
shlfolder test will do it right from the start. One more is winecfg: click on "Add application" button.
Both work fine on my setup. I've also renamed my .wine directory to .wine.bkp, and both cases still have no problem. Would you mind trying this (renaming .wine to .wine.bkp and run the shlfolder test).
I didn't research this problem - don't have time for. Don't know if this is because I have more drives/more directories then you or something else. My tree is not modified except not relevant things (GetAttributesOf & shell exec).
I have shell and relay log if you need it.
If you still have the problem with a clean .wine directory, would you mind sending me a diff of your tree?
What I've realized just now is that the patch you are mentioning doesn't touch ParseDisplayName at all. It's related to SHGetPathFromIDList and GetDisplayNameOf. Are you sure this patch is what gives you the problems?
Bye,
-
Michael Jung -
Vitaliy Margolen