PDA

View Full Version : Windows Vista & programdata directory


Robin
1st August 2007, 09:29 PM
Does anybody know of a site that gives the lowdown about programming applications that store files in the "c:\program files" directory. I am told they need to have shadow copies in the c:\programdata directory if they are to be available to all users. Anybody got any idea about this?

rockoon
1st August 2007, 11:58 PM
I am not exactly sure because I dont have Vista yet, but I have been involved in many discussions about becoming a vista-ready developer..

From what I understand, a normal user does not have write access to the /program files/ directory but does have read access to it. If this is the case, then all users should (unless permissions are explicitely set otherwise) be able to read from it.

The vista compatability engine (forget the real name) takes steps to redirect write-attempts to \programdata\. There is some sort of detection-phase (the first time the program is run?) where vista will move files to /programdata/ and then replace the originals with hotlinks to the new location if it is determined that the program is not "vista compliant" and requires a compatability mode.

All new programs should not use \program files\ for a general data dump .. infact, Microsoft has been telling people this since WindowsXP but nobody was really listening.

Robin
2nd August 2007, 11:48 PM
I am not exactly sure because I dont have Vista yet, but I have been involved in many discussions about becoming a vista-ready developer..

From what I understand, a normal user does not have write access to the /program files/ directory but does have read access to it. If this is the case, then all users should (unless permissions are explicitely set otherwise) be able to read from it.

The vista compatability engine (forget the real name) takes steps to redirect write-attempts to \programdata\. There is some sort of detection-phase (the first time the program is run?) where vista will move files to /programdata/ and then replace the originals with hotlinks to the new location if it is determined that the program is not "vista compliant" and requires a compatability mode.

All new programs should not use \program files\ for a general data dump .. infact, Microsoft has been telling people this since WindowsXP but nobody was really listening.
Hmmm... the app I am using has been widely distributed since well before XP and as it works with various other apps it is a bit difficult to suddenly change the location of config files.

Guess we should have been using the registry all along for config information. But that makes it a bit difficult to make the application portable across different platforms.

Wait a minute, I just think I realised the reasons for this change.

alock
3rd August 2007, 08:49 AM
You should ALWAYS use the API call SHGetSpecialFolderPath for obtain your path (some environments like .NET will provide an easy way to access this without the API).

Don't assume there is a folder called "C:\ProgramData". It might have a different name in other languages. It might get changed in the next version of Windows.

rockoon
5th August 2007, 02:04 AM
Hmmm... the app I am using has been widely distributed since well before XP and as it works with various other apps it is a bit difficult to suddenly change the location of config files.


I understand the issues of future shock here. But ...


Guess we should have been using the registry all along for config information. But that makes it a bit difficult to make the application portable across different platforms.

Wait a minute, I just think I realised the reasons for this change.

Microsoft has also been recommending that you do NOT store most config information in the registry since Windows XP.

A decade ago using an INI file meant that your program wouldnt pass Microsoft logo testing .. they advocated the registry.

Today it is the opposite. Using the registry for more than a few window settings will surely cause problems getting a program through Microsofts logo testing.

(of course, most developers realy dont care about submitting to or passing logo testing .. and probably rightly so)


What exactly is going on with your setup? Is it that Program Installation A is trying to nose around with the data of Program Installation B?

Robin
5th August 2007, 04:29 PM
I understand the issues of future shock here. But ...
The issue is not really future shock, but the problem of upgrading about 2,000 end users in 2,000 different companies most of whom are not particularly computer literate and the fact that the program shares data directories with other applications written by a number of vendors. We would really like to keep the directory structure the same.
What exactly is going on with your setup? Is it that Program Installation A is trying to nose around with the data of Program Installation B?
It is a Java application that I inherited the maintenance of. The config and data directories and executables are all under the same base folder, which by default is installed under "C:\Program Files"

When I install a fresh copy and run it under a particular user it downloads the files as expected (via the internet) and stores them in a particular directory.

When I use Windows explorer as the same user I cannot see the files it has downloaded. Searching for them I find them stored in a hidden directory under the user's directory.

Someone at the customer's site has found the instruction about the programdata folder that I alluded to in the OP. But I have my doubts about whether this will be the full answer.

Robin
5th August 2007, 04:32 PM
You should ALWAYS use the API call SHGetSpecialFolderPath for obtain your path (some environments like .NET will provide an easy way to access this without the API).

Don't assume there is a folder called "C:\ProgramData". It might have a different name in other languages. It might get changed in the next version of Windows.
Thanks, I will look into this one. It is a Java app, but I am more and more using calls to native routines, so I can get this path on startup, or even on installation.