XYplorer Beta Club

Currently, #LinkTarget resolves environment variables.
Will you please add #LinkTargetPure or #UnresolvedLinkTarget to return the unresolved targets? Plus, #ShortcutTarget versions.

Reasoning: Many installers create shortcuts using %ProgramFiles% out of habit, laziness, or ignorance which is fine until WOW64 redirection applies and suddenly all of those shortcuts point to non-existing paths within 32-bit applications on a 64-bit OS.
It also seems tweak WOW64DisableRedirection doesn't come into play here.


Given the age and lack of noise, I'm fine with this being limited to only adding those new properties, but it might be better if XY had some smartness to handle this better. Such as if target contains %ProgramFiles% and the resolved (with redirection) path does not exist but the resolved (without redirection) path does - use the latter.


Interestingly this also proves problematic when viewing the System Properties of those shortcuts because Windows itself won't show you the unresolved target and falls victim of the redirection when opened from XY's 32-bit context menu.

Many installers create shortcuts using %ProgramFiles% ...

Really? Did not even know this was possible.

#LinkTarget resolves environment variables.

Uh, no, not that I know of. There is no such thing in my code.

admin wrote:

Many installers create shortcuts using %ProgramFiles% ...

Really? Did not even know this was possible.

#LinkTarget resolves environment variables.

Uh, no, not that I know of. There is no such thing in my code.

They are both definitely happening, unfortunately.

If I look at the raw view of one of these shortcuts I can see it referencing %ProgramFiles%.
A column using #LinkTarget reports it as C:\Program Files (x86)\...
Opening the properties from XY's 32-bit context menu shows the x86 path; the 64-bit menu shows native path.

Opening the shortcut in XY gives a location not found error.
Opening it in WE works correctly.

Maybe your code doesn't resolve them but the method you call does - can you tell it to not perform the resolving or at least ignore WOW64 redirection?

I'll try to get you more details on Monday (though I'm not sure what else I can do to prove this is true).

See for yourself Don: The columns in XY show what the normal "Link Target" shell property returns and XY's own #ShortcutTarget, and WE shows the shell property as it sees it.

The Raw View shows that the file itself definitely references the environment variable, and the extracted text below shows no mention of the x86 prog files.

The Properties dialog on the left is from XY's 64-bit context menu helper - the one on the right from its standard 32-bit context menu.


Extracted text of Bins.lnk:

PàOÐ ê:i
PROGRA~1
1UPIND~1
WCz&
BINSLA~1.EXE
C:\Program Files\1UPIndustries\Bins\BinsLauncher.exe
%ProgramFiles%\1UPIndustries\Bins\BinsLauncher.exe
1SPSâ
1SPSU(L
ÐáÔ-áÕó=
[redacted: My Computer Name]
(Cò÷F
#ÙÞöK|
ãkcuî"ä
|éÓþ)
(Cò÷F
#ÙÞöK|
ãkcuî"ä
|éÓþ)

Running the shortcut within XY:

Not Found: Link Target
-----
Could not find:

C:\Program Files (x86)\1UPIndustries\Bins\BinsLauncher.exe

I don't think I should do anything here. This is Windows behavior and Windows responsibility. It would be too smart to start fixing something like this.

That's a bit problematic since that means these shortcuts will only work from XY if the program is in fact installed to both the x86 and native program files directories - but fine onto my next wish.