User Accounts & Fast User Switching Tutorial

Introduction

Windows XP represents Microsoft's big push to get the largely Windows 9X-based user community to an operating system family based on the Windows NT-kernel. In Windows XP, new client services not only blend the ease of use of familiar Windows 9X profiles with the robustness of Windows NT (and Windows 2000) user management, but significantly improve on the combination. While the majority of these advancements will be appreciated most by home users, enterprise customers that share assets-for instance, with shift workers and telecommuters or with users who access e-mail from multiple machines while roaming-will also see improvements.

Many computers are shared between multiple users, particularly in the home environment where studies have shown that 80% of computers are used routinely by multiple people. In previous versions of Windows NT, user account management-which could be strictly enforced across the enterprise by administrators-was a somewhat tricky process that was beyond the abilities of most non-computing professionals. Simple-to-use Windows 9X profiles, however, were not enabled by default and were largely ignored: The cost of actually using the profiles, which required that users log off before allowing other users to access the system, meant that the vast majority of machines made do with a single shared profile, with all of the corresponding security, configuration, and data-loss risks.

In Windows XP, user profiles are always enabled and even non-enterprise users are encouraged to create accounts during the Setup process. These accounts are based on Windows NT profiles and allow Windows XP to provide strong isolation and protection of users' data and settings. If multiple user accounts are configured on a machine, then users are presented with a Welcome screen that appears featuring separate-and customizable-graphics for each user. Users of Windows XP machines that are members of an NT-style domain do not see this screen, since presenting a list of machine users could be considered a security violation. A new control panel applet replaces the familiar Windows NT User Manager and Windows 2000 Computers and Users snap-in, providing a simple interface that allows almost anyone to set up a new user and give them appropriate rights and privileges.

Fast User Switching

Windows XP introduces fast user switching. Undoubtedly, fast user switching is the single most important feature that makes sharing Windows-based computers workable. Using fast user switching, it is not necessary for a user to log off the computer before allowing a second user to access their own account. Instead, the first user's account is "disconnected," which leaves all the programs running; the second user can then log on, and then the users can switch quickly between logged-on accounts. Many accounts can be open simultaneously on one computer, though only one account at a time will be able to interact with the keyboard, screen, and input devices.

In the home environment, for instance, fast user switching allows a parent working on a personal finance program to yield the computer to a child to work on homework by browsing the Internet, without requiring the parent to shut down and restart the finance program and without exposing the child to the parent's financial information. In the business environment, fast user switching can allow multiple users in a common environment, such as a research lab, to share a single machine.

Fast user switching is just one of two mechanisms that allow multiple users to work with a single system. Remote desktop, another built-in Windows XP feature, allows users to interact with machines remotely across a network and to access data and applications on those remote machines. While fast user switching is aimed principally at the home market, remote desktop enables business users to access their corporate desktops from remote computers-and vice versa, enabling them to operate home machines while at work.

Programming Issues

Both fast user switching and remote desktop use Windows XP's updated terminal services technology. Improvements have been made to both the server and client components of terminal services. Windows XP now features support for both local and remote sound, 24-bit video, performance optimizations, and the mapping of the local drives and printers.

Fortunately, most applications don't have to be rewritten to work with terminal services and, thus, fast user switching and remote desktop. Rather, they need to respect basic user settings management guidelines. These guidelines are not new: Most are covered in the Windows 2000 Certified for Windows Application Specification, which has been available on Microsoft's Web site for some time. The Data and Settings Management section of this specification includes several topics that are particularly important when supporting multiple users on a single machine:

· Default to the My Documents folder for storage of user-created data;
· Classify and store application data correctly;
· Degrade gracefully on "Access denied" messages. 

Mostly, this means isolating data and settings for each user. And an important step in this direction is to ensure that you are using the HKEY_CURRENT_USER registry key rather than HKEY_LOCAL_MACHINE for storing settings in the system registry. You should also be careful to install programs correctly and to classify and store data correctly. You can use the ShGetFolderPath API to obtain the path of a specific named folder-such as "My Documents" or even "Program Files"-as well as the appropriate directories for storing Roaming, Non-Roaming, and Shared application data. 

The following are some general guidelines for locating data:
· Profiles\username\Application Data\appname
  - Roaming, auto-created user files (e-mail DB, custom dictionaries…)
· Profiles\username\Application Data\Local Settings\appname
  - Discardable/local-only user data files (e.g., offline stores)
· Profiles\All Users\Application Data\appname
  - Last-resort for local-only, common dynamic data (e.g., log files)

A notable exception to the isolation rule is that you should support "All Users" installations: It is extremely frustrating for users to install the same application repeatedly for multiple user accounts.

By carefully locating user data, user settings, and computer settings, applications can make it easier for users to backup individual documents and settings, share a computer among multiple users, and even to work with the same documents and settings on multiple computers. By handling data and settings properly, you can enable your application to run in both the home (fast user switching) and business enterprise (remote desktop) marketplaces.

Controlling Running Instances

It is common for applications to control their startup so that only a single instance may be running on a machine at any given time. There are many valid reasons for doing this: licensing restrictions, required dedicated access to specific hardware resources, and perhaps even enforcing data integrity. However, with multiple users on the same machine, it might be desirable to allow multiple users-each with their own instance-to work with (for example) a personal finance program as long as their data remains isolated. At this point, the commonly used mechanisms for controlling running instances may exhibit some unwanted side effects when operating under Windows XP's fast user switching or remote desktop.

The most common method for discovering whether another instance is running is to use the FindWindow or FindWindowEx APIs to search for a window that, if your application is running, you know to be open. Somewhat unexpectedly, both of these APIs work in a single user session only. So using this method won't prevent another instance of your application from being started by another user.

A more robust method for controlling multiple instances is to use one of the NT kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects can all be used with Global\ or Local\ prefixes on Windows 2000 and Windows XP. By default, each user (terminal service) session will have its own namespace for kernel objects. By creating a Global\ object-for instance, a mutex or semaphore-when your application is started (and closing it upon exit), your application can detect running instances across multiple user (terminal service) sessions. Of course, you can't just switch to the previous instance: It may be in another session! What typically happens in that case is the user clicks on an icon and then nothing appears to happen (since the app thinks it's located another running instance). At a minimum, you should warn the user that there's another instance running.

What about sound? Well, the terminal services in Windows XP have been designed to configure sound to both the interactive and disconnected sessions. While it may be difficult to imagine at first, there may be valid scenarios where it would desirable to output multiple audio streams. For instance, what if you used a sound card in one user session to output audio to the home stereo system and at the same time the active user wanted to hold an interactive meeting with sound? In this case, you certainly would not want to blend the two streams. And neither would you want to suspend the audio stream in the disconnected session. Getting this right can be particularly important when working with shared media devices like DVD players.

One general guideline is to do "as little as possible, as much as necessary" when you are the disconnected session. To do this, it can be helpful to know when a session switch occurs. While most applications won't need to be notified, if your application accesses a shared resource-such as a serial port or other hardware device-you may want to know when the machine switches between user sessions. To be notified when a session switch occurs, you must register to receive the WM_WTSSESSION_CHANGE message by calling the WTSRegisterConsoleNotification API. Using this function, you can choose to be notified for a single session or for all sessions, and when either local or remote sessions connect or disconnect. When you no longer require notification, you should unregister using the WTSUnRegisterConsoleNotification API.

Summary

If you isolate access to your application's data and settings and take care not to tie up shared resources, your application should work well with Windows XP's terminal services. By developing your application to assume it's not the only thing running on the machine, your users are likely to have a much better experience when they start using it with Windows XP's new fast user switching and remote desktop features.