Re: [PATCH 1/1] Fix Bug 44570

[Tom Watson]

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

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  wrote:
> Signed-off-by: Tom Watson
>
> 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  wrote:
> > https://bugs.winehq.org/show_bug.cgi?id=44570
> >
> > Signed-off-by: Tom Watson