|
|
| |
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.
User Accounts and Fast User Switching
| |
|
