Hi

> Seems to work now. Nearly everything had to do with the empty space

between "Program" and "Files" in "C:\Program Files" - I'm not used to that
(here in Germany, it reads "C:\Programme").

Note, that there is a lot of virtualization going on in windows 7.

Earlier versions of Windows (prior to vista) had language dependent folder
names. Current versions have the English folder names everywhere. However,
these folders are shown in explorer in a language dependent way, such that
they read "Programme" in German. But note, that this very folder still is
"Program files".
Aditionally there is a file system link really called "Programme", which
points to "Program files", that is system and hidden.

Things are even more fancy for things like "Users", which is the real folder
name and is displayed as "Benutzer" in the German Explorer and there are
links "Dokumente und Einstellungen" and "Documents and Settings" linking
there.

Most especially you need to worry in x64 Systems.
There are folders "Program files" (shown as "Programme" in German) and
"Program files (x86)" (shown as "Programme (x86)" in German) and there is a
file system link "Programme" pointing to "Program files".

Now, if you run a 32 bit setup application, that tries to access "Programme"
or "Program files", it is actually redirected to "Program files (x86)" and
not "Program files"!
However, if you run a 64 bit setup application, that tries to access
"Programme" or "Program files", it is actually redirect to "Program files"
and not "Program files (x86)"!

That all makes sense to a certain degree. It is a transition way of moving
from language and system dependent folder names without breaking most
applications. Still it results in somewhat surprising effects if you want to
access files in paths that are virtualized and if you don't expect to reach
the very same file on two different paths.

Last, but not least, remember that there is an runtime user-dependent
virtualization since vista, that allows older software to write application
data to its program folder or to the windows folder, which is actually
redirected to special folders of the currently logged in user. This allows
badly written software to be used by different users independently. However
two processes running in two different user contexts (real user and system
for example) see these files in different locations...

So be warned about different folder virtualizations during installation and
not to put any data (including database files) in the program files folder.

We got hit by these problems when we deployed and visual studio default
installer (an 32 bit application) together with an .net application (32/64
bit independent) ona windows 7 x64 system. Even though the installer
reported to install to "Program files", the files ended up in "Program files
(x86)". However a custom module during installation set up some registry
entries that a) ended up in the wrong registry path (Wow64Node) and
contained the wrong folder name ("Program files\....").

Regards,
Steffen



[Non-text portions of this message have been removed]