[PATCH 1/1] Fix Bug 44570

[Tom Watson]

https://bugs.winehq.org/show_bug.cgi?id=44570

Signed-off-by: Tom Watson

[Fabian Maurer]

On Sonntag, 4. März 2018 22:53:31 CET Tom Watson wrote:
> https://bugs.winehq.org/show_bug.cgi?id=44570
>
> Signed-off-by: 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.

Regards,
Fabian Maurer

[Tom Watson]

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

[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

[Fabian Maurer]

Hello Tom,

AFAIK the Z:\ symlink is not be hardcoded and can be changed via winecfg, so this doesn't 
look right to me.
Just try to remove the symlink and open wine cmd in a folder outside your wineprefix, it 
looks something like "unix\home\fabian\Programming\Wine"

Also, "wine-dev explorer ." does not work when cmd is open in drive_c, it opens Z: instead.
> I'm not much of a Windows user so was unaware of the possibility to
> use a "window path", how are they formatted?

That's the paths with backslashes in them, like ".\windows/system32". Or alternatively 
something like "\?\C:" (Which doesn't seem to work either, but not related to this issue)

You probably want to create a few tests if possible, and then work from there. That's what 
I'd try, at least.

Regards,
Fabian Maurer