Read the title to this article and think to yourself what you expect it to be about. I believe most people will have a definite idea, and while most of them are correct they are incomplete. Such is the nature of this problem, many applications deal with one aspect of the problem well while ignoring the others.
I'm going to talk about Windows with multiple users from three angles:
- As of the Windows NT line of products (which includes Windows 2000 and the current version as of this writing, Windows XP) you log into the computer with an account, and different users (should) log in with different accounts.
- Windows XP has a feature called 'Fast User Switching' which allows more than one person to be logged in at the same time. You can switch from account to account without logging the other ones out.
- On a Terminal Server, many users can all be logged on remotely using Remote Desktop to a single computer simultaneously.
User Accounts
DOS, Windows 95, Windows 98, etc. all were based on the single user model. There was only one user of the computer (at a time, anyway) and they owned everything and could do pretty much whatever they wanted. This evolved from the nature of the PC in the formative years and made sense for a while.
So why should different people using the same computer use different user accounts?
- Settings, options, and preferences: For well-behaved applications these are all stored on a per-user basis, by logging onto my account the application can load my settings rather than someone else's. This includes the Desktop, My Documents folder, etc.
- Ownership: When I create a file my account 'owns' it, which means it is either impossible or at least more difficult for someone else (from their account) to modify or delete it on purpose or by accident.
- Privacy: Different users' private data can be made inaccessible to other users, protecting their privacy.
- Security: Each user has their own password and/or other authentication mechanisms, preventing others from impersonating them and allowing administrators to deny access to only the required people when necessary.
- Stability: By having different users access the computer with different accounts and specifying access rights for those accounts properly, the chances of users accidentally destroying data, installing bad software, corrupting the system with a virus, etc. are all substantially reduced.
Let's dig into what makes an application play nicely in this environment.
User Settings
If you store information about settings or preferences, it should almost always be done at the user level. For the registry, this means HKCU (HKEY CURRENT USER). HKLM (HKEY LOCAL MACHINE) should only store information that is universally true for the entire computer regardless of who is using it. Even in those cases it is often best to use HKCU, because...
Running As a Non-Administrator
The number one thing a user on a Windows system can do to avoid getting viruses, worms, and other nasty problems is to have their user account not have Administrator rights to the computer. There are a few issues in the OS that get in the way of this happening, but there are tons of problems with some non-Microsoft products that behave really badly in this case.
These issues get even more extreme when someone uses an application while logged on with minimum rights such as the 'Guest' account. It is reasonable for an application to have features that don't work given non-administrator rights (although this is usually just laziness), and even more reasonable when they have only Guest rights, but the important this is to have graceful degradation of functionality based on the resources and rights available.
Run As
When you're running as a non-Administrator there will be times where you need more access in order to get something done. That may be accessing some data, it may be installing a new program (this is the normal case in my experience), or it may be running some application that boneheadedly requires Administrator access. No need to log out and log back in (or even use Fast User Switching which I'll cover below but can be handy in these cases from time to time), instead use the Run As command.
In Windows XP it is available as a right-click option on programs as well as being a command line utility (type 'runas /?').
Files
Another common mistake (besides HKLM instead of HKCU) is where files are kept. If you store them based on the user account it is very unlikely there will be permissions issues. Create your files in the right location with the correct ACLs, and never allow other users to access your customer's data unless they want them to. If they're stored in a hard coded location (especially in Program Files) it takes elevated (read: Administrator) privileges to create files often.
I'm sure there are a number of old applications (especially games) that require the user is an Administrator for no other reason than they save information in their Program Files folder instead of the user's profile or My Documents folders. Which leads to...
PIDLs
Hard-coded paths suck, especially when trying to get the location of special folders from the OS. Use functions in the SDK like SHGetFolderLocation(), where you pass in value for the special folder you're looking for and it will give you back the location that is always correct. Special folders include the Desktop, the My Documents folder, My Pictures, and so on.
Privacy and Security
For particularly sensitive information there are security and encryption APIs to help developers help their users keep it hidden and safe. The amount of information you can store is limited, so use it wisely, but it makes a lot of sense for things like encryption keys. If you wanted to encrypt a file with sensitive data, for instance, you don't want to just write the key for the encryption into another file right next to it. Instead, hide that key using the OS's mechanism.
Fast User Switching
Fast User Switching (FUS) and Terminal Server (TS) are very similar, the only real difference being that with FUS only one user can be interacting with the computer at a time even though they're all logged in to the system, while TS allows the users to all be active.
The big gotcha for most programs is to realize that more than one user may be running the program at the same time, with different access rights, operating with a different set of preferences, etc. For most programs this isn't a big deal, but if you require exclusive rights to a resource (maybe the sound card, or the DVD drive) you need to check for the conflict, avoid major problems, and thoroughly inform the user.
Terminal Server
An issue that is more important for TS than FUS is idle time processing. Most developers think that taking up 5% of the CPU (as an example) every X many seconds is not a big deal. It may not be in the case where only a single user is interacting with the system (although it can be very annoying even in this case), but if you're on a TS machine with 20 people logged in, every X many seconds 100% of the CPU is being used if they're all running such an application.
Comments