Question

I have an app (32 bit c++) running under XP that I need to adapt to run under Windows 7 and Vista. It needs to store a few dozen bytes of data someplace independent of User. Under XP, I stored the data in the registry under HKEY_LOCAL_MACHINE\Software. When I run the app on Windows 7 the registry entries are virtual-ized and each user gets a separate copy of the data.

The non-virtual-ized registry seems like a logical place for the data but I have no idea how to go about doing so. I note that there are a multitude of applications that actually store data there; how do they go about doing so?

I'm also willing to store the data else where, is there is some well know global repository for it? A single small file is all I need.

I'm more or less ignorant of the whole rights/privileges business so any hints, pointers, etc much appreciated.

Was it helpful?

Solution

One of the design goals of Windows 7 is to isolate user data and applications. This is to improve privacy, security, and customization. In fact, standard users in Win 7 cannot change data of other users.

The standard places to store application data is returned by the System.Environment.SpecialFolder enumeration. Note that not all folders are readable or writable by all users. For example, CommonApplicationData is readable by all users, but only writable by those with an appropriate policy, like Admins.

If you absolutely must have data that is shared among users, an Admin or one with permission must install it to a shared location. If users need to update this data, they should copy it to a location they can write to, such as ApplicationData, and update their own private copies. This private copy cannot be changed by other users. You should not install data to shared locations unless your application won't work otherwise.

In fact, in Win7 you should install all applications and data to the logged-on user's application and data folders, not to shared locations. If multiple users install the application, each user will get their own copy of the application and data. This is almost always what you want. If multiple users are running an application or game, you do not want one user changing everyone else. If multiple users really do need the same change, let each user update their private copy when they need it. If one user's account is hacked or turns evil, you do not want it destroying everyone else's applications and data.

Also be aware that in Win7, users can log on to a machine remotely, so it is not a good idea to store machine-specific data, like screen resolutions or IP addresses, by user. Instead, check this every time your app runs.

OTHER TIPS

IMHO, it's unreasonable to think that many people are going have individual users install their own copies of a software package. In fact many packages will not install unless they are done under ADMIN (ALLUSERS=1). If reasonable means for facilitating system wide installs at some protection level less than ADMIN are not provided, ADMIN level installs will remain the norm.

For example, why couldn't some non-ADMIN User (with intermediate privileges) installs be allowed to create registry keys in some restricted part of the registry (HKLM\SOFTWARE\package) and directories in ALL USERS\APPLICATION DATA\package?

I have decided to make a ADMIN required (ALLUSERS=1) .msi and create registry keys with modified protection.

So, in a situation where my customer has a dedicated workstation our application (which derives data from a good old INI file which we'll r+w to) our message to their IT staff is that they'll need to install it on the same machine for every user they have?

We need to read/write to (under Windows 7/Vista): Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + @"\GoScan\GoScan.ini"

but like other's have found out the permissions for a typical user is not enough to r+w. Is it an "acceptable" practice to change the directory/file permissions after the installer is done or perhaps during the install (not sure where to do this in VS 2008 Setup project).

-Paul

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top