> First, it' kinda hard to test for me since my compiled wine for some reason doesn't 
> exhibit this crash - it instead shows an empty window.
> However, your patch doesn't lead to wine explorer opening the right path - it 
> always opens the Desktop folder. Does that work on your machine?
> Also, I'm not sure if treating a relative path as unix path is right, it could also be a 
> window path.

Hi Fabian,
  thanks for the feedback, for some reason your email didn't come through the list, not sure where it went/what happend. Anyway, you are correct, the original patch didn't work, I was having issues with my fonts and it hid some of the results, I went down the rabbit hole again and came up with a different aproach;  https://bugs.winehq.org/attachment.cgi?id=60665&action=diff
 This sounds like it may not be correct either based on your last sentence there. I'm not much of a Windows user so was unaware of the possibility to use a "window path", how are they formatted? 

To answer your question, yes explorer from git head crashes if run with '.' as a path;
$ ./wine programs/explorer/explorer.exe.so .
wine: Unhandled page fault on read access to 0x00000008 at address 0x7ec842e2 (thread 002f),

This is due to the use of an unitialised variable here;
https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/explorer.c#l255
This sends garbage information in the CBEM_SETITEMW message and causes the crash, it appears to me that the code path in this if statement is never run if a relative path is used, thus never sets main_item;
https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/explorer.c#l202

I believe that this is because a relative path, ie ../wine, is not a child of ${HOME}/.wine/dosdevices, by forcing it to z:../wine it figures it all out, stops the crash, and shows the correct directory information.

I'm open to suggestions here for a path forward, I don't know much about the project only that I use it every now and then as was looking to give a little back.

Cheers.


On Sun, Mar 4, 2018 at 8:56 PM, Tom Watson <coder@tommywatson.com> wrote:
Signed-off-by: Tom Watson <coder@tommywatson.com>
---
v2
Simpler fix, stays out of dll's, assumes that 'z:' is the unix path on all systems? Seems like it as it's hard coded in ntdll?

dlls/ntdll/server.c:    symlink( "/", "dosdevices/z:" );


On Sun, Mar 4, 2018 at 3:53 PM, Tom Watson <coder@tommywatson.com> wrote: