If you can set a system variable (something like %MyGameFolder%), then you can use that in your paths and shortcuts, and Windows will fill in rest of the path for you (that is, %MyGameFolder%\data\MyGame.exe).
Here is a small primer. You can either set this value via a batch file, or you can probably set it programmatically if you share how you're planning to create your shortcut.
Make sure Start in is blank. That causes it to start in the current directory.
Click OK. On Windows 7, the shortcut icon will change to the cmd.exe icon.
That's probably acceptable in the case of shortcutting to a .bat but if you want to change the icon, open the shortcut's properties again and click Change Icon... (again, under the Shortcut tab on Windows 7). At this point you can Browse... for an icon or bring up a list of default system icons by entering
%SystemRoot%\system32\SHELL32.dll
to the left of the Browse... button and hitting Enter. This works on Windows 7 and Windows XP but the icons are different due to style updates (but are recognizably similar). Depending on the version of Windows the shortcut resides, the icon willwill sometimes change accordingly.
I like leoj3n's solution. It can also be used to set a relative "start in" directory, which is what I needed by using start's /D parameter. Without /c or /k in as an argument to cmd, the subsequent start command doesn't run. /c will close the shell immediately after running the command and /k will keep it open (even after the command is done). So if whatever you're running spits to standard out and you need to see it, use /k.
Unfortunately, according to the lnk file specification, the icon is not saved in the shortcut, but rather "encoded using environment variables, which makes it possible to find the icon across machines where the locations vary but are expressed using environment variables." So it's likely that if paths are changing and you're trying to take the icon from the executable you're pointing to, it won't transfer correctly.
If the other person is to install/uncompress whatever to wherever on their respective system drive (usualy c:).
For demonstration purposes call our app "test.exe" (could be any executable/file doesn't have to be exe) and it is to be installed/uncompressed to folder MYCOMPANY\MYAPP\
Then just make a shortcut that uses %SystemDrive%\MYCOMPANY\MYAPP\test.exe as target and
%SystemDrive%\MYCOMPANY\MYAPP\ as start in.
So now you would like to deploy it.
Using an app like "WinRAR".
Easy way is using self-extraction zip file, neatly packaged as an ".exe"
I would use one for my shortcut and another for the app. There is ways to make one self-extraction zip file that extracts different files to different directories, but i haven't played with it yet.
Another way is to make a selfextract for the shorcut, embed it inside the selfextract for the app and then apply a run once script,being that you know where the file is going to be.
etc.
If you want to enable the installer to use custom installation/uncompress directories, then rather have a look at NSIS a scriptable install system.
According to Microsoft, if you leave the 'Start In' box empty, the script will run in the current working directory. I've tried this in Windows 7 and it appears to work just fine.
You can make a relative shortcut manually by changing the file path.
First in the usual context-menu you create a new shortcut of Windows for your file and in the properties -> location of your file:
Just a small improvement to leoj3n's solution (to make the console window disappear): instead of putting %windir%\system32\cmd.exe /c start "" "%CD%\bat\bat\run.bat" to the Target: field of your Windows shortcut, you can also try adding only the following: %windir%\system32\cmd.exe /c "%CD%\bat\bat\run.bat" AND then also adding start in front of your commands in run.bat. That will make the console window disappear, but everything else remains the same.
After reading several answers, I decided to do it with a simple solution:
Instead of a shortcut, I made a .bat with only one line to call the main .bat and it works like I wanted.
I'm not sure if I'm right, or I'm missing something, but as for now (2016-07-11, running Win7 Enterprise SP1) a LNK file adapts itself on moving or even changing the drive letter after it is run at a new place!
I created a new shortcut on my USB drive and tried moving the shortcut and its target in a way that the relative position stayed unchanged, then I changed the drive letter. The shortcut worked in both cases and the target field was adapted after I double-clicked it.
It looks like Microsoft has addressed this issue in one of the past updates.
The link with a relative path can be created using the mklink command on windows command line.
mklink /d \MyDocs \Users\User1\Documents
This might be the best way to create link because apparently, the behaviour of shortcut can be different perhaps based on the way they are created (UI vs mklink command). I observed some strange behavior with how the shortcuts behave when I change the root folder.
There is a weird behaviour on Windows 7 that I tested. Sometimes the the link still just works when the root folder of target is changed (the shortcut properties automatically update to reflect the changed path!). The "start in" field updates automatically as well if it was there.
I also noticed that one link doesn't work the first time I change the root path (properties shows old) but it works after the 2nd and everytime after that. The link properties get updated as result of the first run!
I also noticed at least for two link, it doesn't update the path and no longer works.
From link properties, there is no difference in format of any fields yet the behaviour is different.