Using an Environmental Variable shortcut in Windows 8 disables it in Windows XP

Here's an interesting one.

Environmental Variable %APPDATA% takes you to this location
• under Windows XP: C:\Documents and Settings\{username}\Application Data
• under Windows Vista/7/8: C:\Users\{username}\AppData\Roaming

If you create a folder shortcut to %APPDATA%\WinRAR

The same shortcut will take you to
C:\Documents and Settings\{username}\Application Data\WinRAR under Windows XP
or
C:\Users\{username}\AppData\Roaming\WinRAR under Windows Vista/7/8


Here's the kicker:
If I simply click on this shortcut under Windows Vista/7/8 and use it, after rebooting into Windows XP , the shortcut can no longer be used.
If I set a Read-only attribute to the shortcut, it CAN be used under Windows XP even after using it under Windows Vista/7/8.
Therefore simply using the shortcut under Windows Vista/7/8 modifies the shortcut in a way that it is not possible to use it under Windows XP.
But setting a Read-only attribute prevents Windows 8 from modifying it, resolving this problem.

Why would this happen?!

This... makes no sense.


What would Win 8 modify for a shortcut to disappear?
Does the shortcut re-appear in Win 8 after it disappears??

Another bizzare aspect of Windows...

First thing I need is someone with a dual boot do try to replicate this.
Simple create a shortcut to anything inside %APPDATA% and execute the shortcut inside Vista/7/8 then reboot into Windows XP and see if the shortcut can be used inside Windows XP.

The shortcut does not disappear, it is still there, just not functional.

Oh I read that wrong then...

Perhaps it's the "Start in" directory? maybe that gets changed?
Still makes no sense.

I don't have a dual boot to test this though..

All right, like I said, step 1 is to determine if anyone else can replicate this.
Until then, here's what happens on my system.

I created two identical shortcuts and gave them descriptive names:
Click on in Win8
and
DO NOT CLICK ON in win8.


If I go to either Windows Vista or 7 or 8 and click on shortcut 'Click on in Win8' - here's how it is modified in comparison to a test shortcut.
'Click on in Win8' shortcut ONLY UNDER WINDOWS XP goes white and no longer works under Windows XP, and here are its properties, the size has been modified:

Strange...

Well, let's see if someone else can confirm this
Wonder what changed in the shortcut to make it smaller...

I'm guessing that when you click on the shortcut, the OS evaluates the environment variable and stores the shortcut behind the scenes on the filesystem as the absolute path to where you want to go. When you reboot into XP, that location is still true (ie, a non-existent place in your XP environment), so the shortcut is broken. If the shortcut wasn't broken, you could properly click it, which would re-evaluate your environment variable and take you to where you want to go.

Try creating C:\Users\{username}\AppData\Roaming on your XP environment and see if the shortcut is still broken. My guess is that the shortcut wouldn't be broken, but when you click it, it will properly evaluate the environment variable in your XP environment and take you to the correct location (C:\Documents and Settings\{username}\Application Data).

Alternatively, try creating a new environment variable (ie, %WINRAR_PATH%=%APPDATA%\WINRAR or something), and use that as your shortcut variable. It would get updated upon boot rather than upon clicking the shortcut, so your shortcut would probably never break.

If that doesn't work, just accept that it's a fault in a 12 year old OS. Guess you could ask MS for help.. Oh, wait..

I have already discovered a solution to this and it is to simply set a Read-only attribute to the shortcut.

Without the Read-only attribute, the moment that shortcut is executed on any other OS that came after Windows XP - that shortcut gets broken for use under Windows XP... unless it has a Read-only attribute which prevents this problem...


The first thing you said about creation of the shortcut - it doesn't matter - the shortcut will get modified no matter where it was created.
The second thing about %WINRAR_PATH%=%APPDATA%\WINRAR , please clarify what you mean, how would a shortcut exactly be created differently using what you said?

pcgamer4life said:

...just accept that it's a fault in a 12 year old OS. Guess you could ask MS for help.. Oh, wait..

Click to expand...

I may be in the Navy.
Here's a screenshot from the news, today, June 29, 2015:

Windows does not change it after you use the icon, it saves the hard-coded path in the LNK file. Using a hex editor, I created two %appdata% shortcuts, opened one in explorer, then compared them in a hex editor; they were identical. I copied both shortcuts to an XP virtual machine and neither shortcut worked. I created a %appdata% shortcut in XP and checked the contents, it also had the path hard coded in the shortcut.

Windows XP shorcut:



Windows 8 shortcut:


You can see both have "%appdata%" as the location (bottom), but both have their hard-coded paths above. Copying it to another system, even if the OS stayed the same, would product the same result.




If you want a "shortcut", I'll create you a very small .net application that will always open the appropriate path, if you want. I just need to know what is the highest version of .net both systems have.

I realize you already have a solution, I just mean that to test my theory of why is happening, try each of the things I suggested.

1) If you create the physical path (C:\Users\{username}\AppData\Roaming) on your XP machine, does your shortcut still break? My theory is that it will not break, and will work as you intend it to.

2) If you add an environment variable that references %APPDATA%, (ie, create a new env var called %WINRAR% and set it to %APPDATA%/winrar, or wherever) and use this new variable in your shortcut, my theory is that your shortcut will not break when switching between OS's.

If either of these works, it validates my thought as to why you have these issues. If neither works, then it beats the heck out of me.

pcgamer4life, the physical path does not break the shortcut. Only if Environmental Variable is used and then only if the link is executed outside of Windows XP.
Quickest solution is to set a Read-only attribute and be done with it.

thideras, thanks for the idea. Hex editor absolutely shows that the lnk file gets modified inside Windows Vista/7/8 so that the actual path CHANGES.
Windows Vista/7/8 can read Windows XP created shortcuts but Windows XP cannot read the CHANGED shortcut.

I'm not sure why Vista/7/8 have to mess with it and instead just don't read it and get you to it - instead of hardcoding CHANGES in it?

Thanks you for the offer on the app. I was puzzled as to why this was happening, but now I know why.
I think the easiest by far, solution, is to simply set a Read-only attribute, making the lnk file permanently readable, everywhere always.

c627627 said:

pcgamer4life, the physical path does not break the shortcut. Only if Environmental Variable is used and then only if the link is executed outside of Windows XP.
Quickest solution is to set a Read-only attribute and be done with it.

Click to expand...

I think you're misunderstanding what I'm saying regarding why I think this is happening. The shortcut breaks because merely switching OS's does not update the shortcut's reference to %appdata%. When you swap to XP, your shortcut is still pointing to the absolute path of %APPDATA% on your Vista+ install. When you click the shortcut, it will (I think) re-evaluate %APPDATA%, update its shortcut path appropriately, and take you to where you want to go. The problem is that before it has a chance to do this, it first verifies the path of the shortcut as it currently exists, and halts because it doesn't exist in XP.. it never gets a chance to evaluate your environment variable. I'm suggesting that you merely create that path on XP so that the shortcut on XP doesn't break immediately before it has a chance to re-evaluate the value of %APPDATA% for your current OS. I don't have an XP VM installed, else I'd test this theory for you.

Creating extra steps/apps would be cumbersome, and it would be necessary on *every* system the shortcuts are taken to.
The big picture is creation of a shortcut that can be take to EVERY system, without doing anything else.

The *only* way that can be done is to CHECK Read-only in shortcut properties. I was puzzled as to why this was happening and we found out why - Vista/7/8 physically modify the shortcut by hardcoding the new location.

You've suggested ways to resolve that on one single system. But only one solution works on every system: CHECKing the Read-only attribute.

I wasn't suggesting a resolution, just an explanation (or rather, my best guess) as to why it's happening.

I realize you already have a solution, I just mean that to test my theory of why is happening, try each of the things I suggested.

Click to expand...

If you want a very quick and easy option, without using two different shortcuts, I created this program for you. It is small and all it does is run %appdata%. You could even right click "Run as administrator" to get an admin-level Explorer window.

The source is the "Application Shortcut Source" (there isn't really anything to the program), and the compiled application is in the other file. It is targeted to .net 3.5, which most systems should have.