User Accounts and Fast User Switching

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.