Non-English System Folders.
A German customer is having difficulty in getting our program to launch. As it happens, Windows is installed on his E:\ drive instead of the more common C:\ drive. This seems to be remarkably common in non-English speaking countries for some reason. However, it doesn't cause any problems for our program.
It's a 32-bit program running on Win7 64-bit, so normally we'd expect it to be installed in C:\Program Files (x86)\Mixbus. But in our client's case, Explorer shows the install folder as E:\Programme (x86)\Mixbus
For some reason, he can't launch the program and I've spent nearly 2 days trying to figure out why. Eventually I asked him to open a Command Prompt and type these lines:-
Quote:
E:
cd "\Programme (x86)\Mixbus"
but each time he attempts the 2nd line he sees this error:-
Quote:
Das System kann den angegebenen Pfad nicht finden
or, roughly translated, "folder not found".
After 2 days we've finally realised that if he types this at his Command Prompt:-
Quote:
E:
cd "\Program Files (x86)\Mixbus"
he can access the correct folder!! So although Explorer displays his Program Files folder as E:\Programme (x86), under the hood it still seems to be called E:\Program Files (x86) !!!!
This seems totally weird to me. I had no idea that foreign locales simply translate the system folder names! Can anyone tell me if this is commonplace in non-English locales or is there something peculiar about our client's setup?
Re: Non-English System Folders.
Windows 7 now officially supports something called "Junction Points" or in other terms, aliased directories. So maybe you are seeing the alias name in Explorer, and the real name is Program Files (X86).
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
http://blog.korteksolutions.com/junc...indows-vista7/
Junction points also existed under XP, but were not well-known or supported. Under Vista and 7, they now have a bigger role.
Regards,
Paul McKenzie
Re: Non-English System Folders.
I must admit, I've noticed these on my own system without realising what they were. For example in my user folder there's a subfolder called "My Documents" which is owned by me and which I can enter. There's also a Junction Point called "My Documents". It has a different owner (SYSTEM) but appears to have the same access permissions as the original subfolder. I assume that it points to the same place - and yet it always gives Access is denied if I try to enter it (which begs the question - what is it for?)
Microsoft comes up with some very strange concepts at times....
Re: Non-English System Folders.
Quote:
Originally Posted by
John E
...
Microsoft comes up with some very strange concepts at times....
Yeah! Because they think it is coooool!!!! :eek:
Re: Non-English System Folders.
Quote:
Originally Posted by
John E
Microsoft comes up with some very strange concepts at times....
Nope. This concept has existed in *NIX for a long time. Except, they call it a "link".
Quote:
NAME
ln - make links between files
SYNOPSIS
ln [OPTION]... TARGET [LINK_NAME]
ln [OPTION]... TARGET... DIRECTORY
ln [OPTION]... --target-directory=DIRECTORY TARGET...
DESCRIPTION
Create a link to the specified TARGET with optional LINK_NAME. If LINK_NAME is omitted, a link with the same basename as the TARGET is created in the current directory. When using the second form
with more than one TARGET, the last argument must be a directory; create links in DIRECTORY to each TARGET. Create hard links by default, symbolic links with --symbolic. When creating hard
links, each TARGET must exist.
Viggy
Re: Non-English System Folders.
The strange thing is the way that they work (on Windows). For example, in my Windows personal folder I've probably got around 6 Junction Points (including the "My Documents" one that I mentioned earlier). All of them tell me Access is denied if I try to double-click them from within Explorer. That's in spite of the fact that I apparently have the correct access privileges for the target locations.
OTOH if I open a Command Prompt and access them via the command line, I can enter them all without any problems - but once in the relevant location, if I type dir they all appear to be empty... :confused:
I'm sure this must make sense to someone - but it doesn't make a lot of sense to me :(
Re: Non-English System Folders.
Quote:
Originally Posted by
MrViggy
Nope. This concept has existed in *NIX for a long time. Except, they call it a "link".
Viggy
In Unix, links are part of the culture, unlike Junction Points in Windows. You say "Junction Points" to a semi-advanced Windows user (even advanced ones), and you'll get a blank stare more often than not.
Regards,
Paul McKenzie
Re: Non-English System Folders.
Re: Non-English System Folders.
Yeah, in particular it explained the 'Access denied" problem. AFAICT this is so that backup software etc won't keep backing up the same files multiple times. The files can be modified, deleted etc but not listed. Oh well, makes some kind of sense I suppose....
Re: Non-English System Folders.
Quote:
Originally Posted by
John E
A German customer is having difficulty in getting our program to launch. As it happens, Windows is installed on his E:\ drive instead of the more common C:\ drive. This seems to be remarkably common in non-English speaking countries for some reason. However, it doesn't cause any problems for our program.
John,
Is your application using hard coded location of the installed program?
You should use SHGetFolderPath to retrieve program files.
There is more to take under consideration:
32-bit program will be installed in Program Files (x86) on 64-bit machine and Program Files on 32 bit machine.
You would want to determine if program is running in Wow64 and call SHGetFolderPath passing CSIDL_PROGRAM_FILESX86 or CSIDL_PROGRAM_FILES depending on the system to retrieve proper program files path.
I do not know why for the sake of sanity and consistency, MS did not keep Program Files for 32-bit applications and add Program Files (x64) for 64-bit systems. I think the amount of changes would have been the same.
Re: Non-English System Folders.
No, that's all okay John. We use SHGetSpecialFolderLocation() to find the various paths we need and we check the WOW64 situation too. In fact, we already have several non-English users but this was the first one who flagged up a problem. It did turn out to be the Junction Points issue as far as I could tell. On a non-English system, the Program Files folder is still called either [drive letter]:\Program Files or [drive letter]:\Program Files (x86). But Windows seems to create a Junction Point to it, in the relevant language. This makes it impossible for anyone to launch an app from the command line since Junction Points don't have the same access rights as the folder they're pointing to. It also seems to screw up spawn() and similar functions. :cry:
