knahrvorn
18th February 2011 07:08 UTC
$INSTDIR confusing on localized Win7
I have a script which uses
InstallDir "$PROGRAMFILES\MyProgramName"
and
Page instfiles
and is thereafter refers to $INSTDIR for installation and creating a start menu shortcut. So far no problems; my program (in Java) is packed into an installer and is being installed and runs with no problems.
However, today I tried the installer on a Windows 7 system, which was originally installed in English, but now has been set to Danish. This means that "C:\Program Files" is now "C:\Programmer" instead, and apparently that confuses the installer made by my script.
During the install, the installer suggests installation to "C:\Program Files\MyProgramName", and if I just select Next, my program is installed without errors. However, the installed shortcut in the start menu refers to "C:\Program Files\MyProgramName", which makes Java complain that the path is not found.
If, in the installer, I choose to "Browse" my way into "C:\Programmer" (which IS shown in the directory list), I still get "C:\Program Files" as the destination folder in the main install window. If I manually type in "C:\Programmer\MyProgramName", the program is (again) installed without errors, and this time it starts.
What is REALLY weird, I think, is that if I open a command prompt in Win7, it reports that only "C:\Program Files" exists, and the Win7 GUI detects only "C:\Programmer".
So, since I'm not very used to the Windows environment, my question is: Is this normal behaviour from Windows? If so, how do I refer to "C:\Programmer" from an NSIS script?
jiake
18th February 2011 08:25 UTC
C:\Programmer is a diaplay name but not the folder name. You would understand it clearly if you are using a Chinese, Japanese or Korean Windows OS. On Windows XP, some folder names has translated to system's language. The desktop folder path is "C:\Documents and Settings\Adminstrator\桌面" on Simplified Chinese Edition and "C:\Documents and Settings\Adminstrator\Desktop" on English one. But on Windows 7, the desktop folder names of all languanges are the same one: C:\Users\Adminstrator\Desktop, you can only see different display names among OSes of different languages. For example, the Favorites folder of Winows XP is shown as "收藏夹" but the folder name is Favorites, and the Desktop folder on Windows 7 is shown as "桌面" and the folder name is still Desktop, etc. The value of $PROGRAMFILES in NSIS is get from Windows API such as SHGetSpecialFolderPath, so on the same system, the path is always the same. I thought that the problem is not the path being incorrect, maybe other reasons.
knahrvorn
18th February 2011 09:22 UTC
jiake, thank you for the explanation. So it IS expected behaviour from Windows, and as "Program Files" is still the actual directory name, I am indeed receiving the correct path through $INSTDIR. So far, so good.
The strange thing, for me, is now why a shortcut that I create with the following command:
CreateShortCut "$SMPROGRAMS\${PROGRAMNAME}.lnk" "java" "main.MyProgramName" "" "" SW_SHOWNORMAL "" "Program description"
which results in a shortcut like the one on the attached screenshot, is triggering a file not found exception in Java (though the file does exist)...
java.io.FileNotFoundException: C:\Program%20Files\MyProgramName\filename.ext (Den angivne sti blev ikke fundet)
Perhaps because Windows seems to translate "Program Files" into "Program%20Files"? Nah, that shouldn't matter, should it? Besides, I had this working on an English language system where both actual directory name and display name was "Program Files", with no changes.
MSG
18th February 2011 12:36 UTC
Things like %20 do not work for folder names, they're only used for internet URLs.
Your problem isn't very clear, but it seems to be related to java, not NSIS. You may have to supply a proper path to java, with quote marks. Otherwise, ask java support?
knahrvorn
18th February 2011 15:09 UTC
MSG, thank you for your reply. I am trying to figure out if this *is* related to Java or to NSIS (or to Windows, for what I knew).
It does indeed seem as if this is an issue with Java instead of NSIS. As far as I understand NSIS, I am already supplying properly quoted path to the java executable. But perhaps I don't understand it correctly? So in order to rule out NSIS, here's what I do when I create the start menu item:
SetOutPath "$INSTDIR"
in order to set a "current path" from which to run the java executable.
(I even tried with SetOutPath "$\"$INSTDIR$\"" which didn't seem to make any difference)
then:
CreateShortCut "$SMPROGRAMS\${PROGRAMNAME}.lnk" "java" "main.MyProgramName" "" "" SW_SHOWNORMAL "" "Program description"
where the first argument is, of course, the name of the shortcut. The next one is the name of the java executable. The next one, the arguments sent to the java exec, is the name of my program with a path relative to the current path as set by SetOutPath.
So, in other words, if I'm not making anything wrong here(?), I know the issue is with Java instead.
Afrow UK
18th February 2011 15:17 UTC
How about:
CreateShortCut "$SMPROGRAMS\${PROGRAMNAME}.lnk" "java" `"$INSTDIR\main.MyProgramName"` "" "" SW_SHOWNORMAL "" "Program description"
Stu