SetOutPath on non-English OS
 

Hey folks, I ran into an issue with an installer I created for a plugin of another software package. I read the other application's installation directory from its corresponding registry hive, then assign it as the destination for SetOutPath. In a non-English OS, the registry lists this path in its English equivalent, so if you're on a German OS, C:\Programme (x86) is listed as C:\Program Files (x86).

The problem I see is that none of the files that were intended to be copied actually get written to C:\Programme (x86). This might seem like an obvious open and shut scenario, but Microsoft supports the interchangeable use of English version in such situations. For example, in command prompt, the folder "C:\Programme (x86)" can be identified as follows:

code:


C:\>cd Program Files (x86)

C:\Program Files(x86)>

So is this a known limitation for SetOutPath that it does not treat the English version as a sort of alias path for the default install folder? Should I use the following steps as a workaround or is there a better way?

1. Detect OS language. If not English, do the following:
2. Determine if "Program Files" or "Program Files (x86)" is in the path. If so, replace with $PROGRAMFILES or $PROGRAMFILES32 and see if the expected directory is present.

Actually please disregard. I found that the registry entry I read included a trailing backslash. In SetOutPath, I was adding another backslash. On an English OS, this was not a problem, but on a non-English OS, the second backslash was not ignored. Once I resolved this, the output path validated as desired and the output files were copied.

Allow me to clarify something. Before Vista the %programfiles% folder path/name comes from the language of Windows you have (Document and Settings might be localized as well). In Vista and later it is always "x:\Program Files" but Explorer might display it as a different name but that is just the shell lying to you, the name at the filesystem level is always in English on these systems.

There might be some compatibility symlinks/junctions in the drive root that also redirects to the correct folder but you should not count on this.

See also: https://web.archive.org/web/20120208...8/1487464.aspx