Bug: shortcut fails in XYplorer, works in File Explorer

[JPL]

Hi,

I am trying to use a Windows shortcut to display a video stream via VLC. The same shortcut (.lnk) file works correctly with a shortcut on the desktop or within a folder using Windows File Explorer, but fails in XYplorer.

Here is the target of an example shortcut that displays this behaviour:
"C:\Program Files\VideoLAN\VLC\vlc.exe" http://carnyxlive.co.uk:1935/live/abern ... ylist.m3u8

Screenshot of error message on attempting to run the shortcut from within XYplorer:

ScreenShot_20160322_164557.jpg

Note that the path shown does indeed not exist - it is the x86 version of the actual pathname of the program, as shown in the shortcut target above.

This strange behaviour appears to be a bug in XYplorer.

Xyplorer Free v16.40 on Windows 10 Pro 64-bit Version 1511 Build 10586.164

JPL

[TheQwerty]

The shortcut is most likely making use of the wrong environment variable.

%ProgramFiles% is resolved differently depending on the bitness of the running process.Thus for 32-bit programs (like XY) it typically resolves to 'C:\Program Files (x86)' while in 64-bit one (like File Explorer) it might be 'C:\Program Files'.

The shortcut should be created with the environment variable corresponding to its actual install location:
%ProgramFiles(x86)% = 'C:\Program Files (x86)'
or
%ProgramW6432% = 'C:\Program Files'

[JPL]

Hi,

Thanks for your response.

Yes, I wondered about that, but since both Target and Start In contain a valid, direct path ("C:\Program Files\VideoLAN\VLC\"), why is the environmental variable being used at all? Presumably Windows File Explorer does not make this substitution.

Anyway, I changed the shortcut, replacing "C:\Program Files" with "%ProgramFiles%" and it worked correctly.

Surely XYplorer should not replace the root of a valid pathname with the environment variable for a different root.

JPL

[JPL]

P.S. Vlc.exe is a 64-bit program according to Process Explorer. Why does XYplorer consider it to be 32-bit?

JPL

[TheQwerty]

Yes, I wondered about that, but since both Target and Start In contain a valid, direct path ("C:\Program Files\VideoLAN\VLC\"), why is the environmental variable being used at all? Presumably Windows File Explorer does not make this substitution.

The property dialog does not necessarily show the unresolved target. In some cases it can, and does, show the resolved target.

Surely XYplorer should not replace the root of a valid pathname with the environment variable for a different root.

XYplorer is not the cause of this annoying behavior. Windows itself is returning the resolved target and not providing a way to get the unresolved version.

More details: http://www.xyplorer.com/xyfc/viewtopic. ... 45#p115245

P.S. Vlc.exe is a 64-bit program according to Process Explorer. Why does XYplorer consider it to be 32-bit?

XY does not care about VLC's bitness at all. It is XYplorer that is 32-bit, so when it asks Windows to resolve %ProgramFiles% it gets back C:\Program Files (x86). If XY was a 64-bit program it would get back C:\Program Files.

Unless the application exists under both C:\Program Files and C:\Program Files (x86) then it is a mistake to ever reference it using the variable %ProgramFiles%. This variable will only ever resolve to one of those two paths but which one depends on the bitness of the program performing the resolution and not the program being referenced.

[highend]

Vlc.exe is a 64-bit program according to Process Explorer

Em, really? My process explorer states it's a 32-bit application...

[TheQwerty]

Vlc.exe is a 64-bit program according to Process Explorer

Em, really? My process explorer states it's a 32-bit application...

Here too, but if you click the arrow on the download button they offer an "Installer for 64bit version": http://www.videolan.org/vlc/download-windows.html

[JPL]

The installer I used was vlc-2.2.2-win64.exe chosen as Installer for 64bit version via the down-arrow on the Download VLC button. (And I can't really see Process Explorer getting this wrong!)

Also I notice that a newly created shortcut (right-click/drag from the vlc .exe file in XYplorer) works OK. The problem arises if you edit the shortcut via its Properties window to add a URL to the command line. The paths displayed in the Properties window for the shortcut remain unchanged; presumably the path that is actually being used - and must have been changed - is stored behind the scenes.

I think it is bad practice for the working data and their display not to match. If the resolved target is changed the display should be changed to show the result.

when it asks Windows to resolve %ProgramFiles% it gets back C:\Program Files (x86).

Why? On this PC %ProgramFiles% resolves to C:\Program Files.

I have used other 32-bit file managers, e.g. xplorer2 lite, in 64-bit Windows but did not observe this behaviour.

JPL

[highend]

The installer I used was vlc-2.2.2-win64.exe chosen as Installer for 64bit version via the down-arrow on the Download VLC button

Okidoki, I was just wondering^^

[TheQwerty]

I've already explained twice that %ProgramFiles% does not resolve to any one path on 64-bit systems.

What happens in the Properties window or in the Windows' APIs that resolve environment variables is controlled by Microsoft and outside the hands of XYplorer.

[JPL]

Environment variable %ProgramFiles% always has the value "C:\Program Files". I have edited the shortcut properties, replacing "C:\Program Files" with %ProgramFiles% in all paths, and all is working fine now.

Thanks for your help.

JPL

[bdeshi]

Environment variable %ProgramFiles% always has the value "C:\Program Files".

Really?
Run (Windows Key + R) "%WINDIR%\system32\cmd.exe" and "%WINDIR%\syswow64\cmd.exe". In both cmd windows, type

Code: Select all

echo %programfiles%