views:

256

answers:

3

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.

+2  A: 

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.

Dour High Arch
Actually, the recommended approach in Vista certification guide for the case when you need writable shared data, is for the application installer to create a folder under CommonApplicationData and set its permissions accordingly (i.e. world writable).
Pavel Minaev
... which is to say that there is no ban on shared writable data or anything like that. It's deliberately not trivial to do, but it's not impossible, and there are valid use cases.
Pavel Minaev
Good comment Pavel; it's not impossible but I stand by the suggestion that you should not do this.
Dour High Arch
My need is akin to that involved in licensing software; you seem to be saying that if members of my family needs some licensed software, I should tell them to buy their own copy and install it in their private environment!
Mike D
Mike D
@Dour High Arch: Reference your paragraph 3. Does this mean that some ADMIN could run my app which without any special code could create and update data in the Windows 7 equivalent of CSIDL_COMMON_APPDATA and that other non ADMIN users could read that data? My first reaction is that this would satisfy my needs.
Mike D
@Mike, decide whether you want to license the software for a machine or for a user. If a machine, check for a machine identifier like MAC address, and let as many users as want to install the software on the same machine. Users will not be able to run on another machine even if they use the same account. If you want to license users, attach it to their domain account and they will be able to run it on any machine they log on to from the same account, but different users would need separate licenses to run on the same machine.
Dour High Arch
@Mike, an Admin can install software into CommonApplicationData and set all other users to be able to read, or copy, write, or have no access to the data as desired. It is not necessary to do this, you can let every user install the software for themselves with their own data without Admin access.
Dour High Arch
@Dour High Arch: Thanks very much, I'm beginning to see the light. Much like my old experiences with Vax VMS. One further thread I'd like to pursue. I'd like to avoid as much as possible special code for different OS (XP/Vista/Windows 7). From experience, I've seen that my program does get installed in the real, not virtual Program files if installed by an ADMIN. Now my questions are 1) if an ADMIN runs the program can it create (_mkdir) a directory in CommonApplicationData and create files therein 2) Are those file world readable by all user by default or do I need to anything special?
Mike D
System.Environment.SpecialFolder is supported by XP, Vista, and Win7. It will return different paths depending on the OS and machine policy. Admin accounts can install software for themselves alone or for all users. Admins can create shared files in CommonApplicationData and set access to whatever they want, by default they are world-readable.
Dour High Arch
Please avoid running anything as Admin, I do not believe your situation requires it. Users running as Admin is the #1 cause of security problems in Windows. Standard user accounts can install applications; if multiple users want to install an app, let each user install it for themselves.
Dour High Arch
Ok, I now know how to do what I want to do, I.e. having some common data readable by all user and writable by my code running as ADMIN thus breaking your guidelines. How do we reconcile this? I suppose we could let admin establish the sub-folder and grant write access to one user who gets the to do the updates but that means the install is going to require a complex dance by the ADMIN.
Mike D
I can give advice if you explain why you think you need common data readable by all users and why you think you need to run as Admin. What are you trying to do? What use case requires this? I can think of no user application that needs this... web browsers, office apps, graphics apps, personal productivity, line of business, ... everything works fine if you let each user install the apps they need. If two users need the same app, let each user install it.
Dour High Arch
I have system wide defaults for parameters. I note that their are dozens of directories in my common app data folder for all kinds of standard software. How did they get there? And How do the programs get at them?
Mike D
A: 

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.

Mike D
A: 

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

paul smietan

related questions