Moving to Vista-- Part Three-Oh |
We have been looking at Windows Vista (TM Microsoft) for a few weeks, seeing how it will affect Sagebrush products. View earlier articles Part1 and Part2 .
Some of the restrictions discussed below may have existed under WinXP, but most home users ran as administrator and never noticed any problem. Now, unless User Account Control is disabled, programs will tend to start with "Standard User" priveleges, and restrictions will be noticed. Some home users might be tempted to always run with "Admin Priveleges", but we, as programmers, must run under low priveleges to find any problems.
Standard user programs can read anything in the registry, but write access is limited to the HKEY_CURRENT_USER branch. Here is where WinChime nornally stores its user settings, so we didn't need to change anything:
We used to use the HKEY_LOCAL_MACHINE branch to store a setting to enable WinChime to start up during system boot. Under Vista, WinChime no longer has registry write access to that branch, so we now write to a similar location in HKEY_CURRENT_USER (HKCU), but this will not work under all circumstances.
The registry settings saved under HKCU change, depending on who is logged in. If "Jim" is logged in and runs VCRadio, changes a scheduled timer event, and then logs out and logs in as "Adam", the HKCU settings are completely different! For this reason, some programs, such as the latest VCRadio version, started storing settings under HKEY_LOCAL_MACHINE (HKLM) as well as HKEY_CURRENT_USER. This allowed the radio tuner program to record scheduled shows no matter who was currently logged in.
This will no longer be possible under Vista. In fact, I currently know of no place in the registry that can be written by a program with standard user priveleges that can be read by the program running under a different user. This is a big problem for VCRadio and TVactive, which naturally wants a common registry location for all users. (Perhaps a smarter programmer knows a better answer; I am still learning Vista changes.)
Users have asked us to store registration code information in a common location as well. Suppose a Vista machine is configured with different User Accounts for each member of a family or workgroup. Further imagine a user license for RecAll-PRO was purchased for this computer. (Thank you!) The software license allows any user of that computer to run RecAll-PRO (as long as two users are not running at the same time). However, user "Jim" enters the registration code, logs out, and user "Adam" logs in, and will have to enter the same registration code! The registration code will have to be installed for any of the users that wish to use the program, which hardly seems friendly.
Perhaps these programs need to abandon the registry and save their current state to disk. Ahhhhh, one might think so, but problems exist...
Programs may no longer make assumptions about which directories have write-access for standard user program priveleges. Most locations on the disk will have read access, but write access may fail. Here are pre-defined locations whose priveleges are known for "standard user":
CSIDL |
Typical Path |
Standard User Rights |
Scope |
CSIDL_PERSONAL |
C:\Users\user name\Documents |
Read/Write |
per-user |
CSIDL_LOCAL_APPDATA |
C:\Users\user name\AppData\Local |
Read/Write |
per-user |
CSIDL_PROGRAM_FILES |
C:\Program Files |
Read |
all users |
CSIDL_COMMON_APPDATA |
C:\ProgramData |
Read/Write |
all users |
From the table, the most likely place to store program state information is in "C:\ProgramData", BUT when a file is created by one user, another user may not have privelege to modify/delete the file. We are not sure how to get around this problem to have a single file which saves the preferences of a program, and can be written and read from all users on a computer.
User Account Control for Game Developers
A Programmer's Exploration of Vista's User Account Control
In the final part of this series, we will consider various miscellaneous discoveries.