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 .
User Account Control
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” privileges, and restrictions will be noticed. Some home users might be tempted to always run with “Admin Privileges”, but we, as programmers, must run under low privileges to find any problems.
Restricted Registry Access
Standard user programs can read anything in the registry, but write access is limited to the HKEY_CURRENT_USER branch. Here is where WinChime normally 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 privileges 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 work-group. 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…
Restricted Write Access
Programs may no longer make assumptions about which directories have write-access for standard user program privileges. Most locations on the disk will have read access, but write access may fail. Here are pre-defined locations whose privileges are known for “standard user”:
Standard folders
CSIDL
Typical Path
Standard User Rights
Scope
CSIDL_PERSONAL
C:Usersuser nameDocuments
Read/Write
per-user
CSIDL_LOCAL_APPDATA
C:Usersuser nameAppDataLocal
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 privilege 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.
Further Reading
Next:
In the final part of this series, we will consider various miscellaneous discoveries.