By David Perkovich

Introduction

As Microsoft^® prepares to roll out their latest OS platform, Windows^® XP, a new feature called fast user switching should interest developers. Fast user switching differs from the Remote Desktop feature built into Windows XP. With Remote Desktop, you can connect to one or more remote computers via terminal services. But fast user switching allows the locally logged in user the ability to run multiple login sessions at the same time.

Using the terminal services technology, developers can finally configure an environment that allows them to quickly and easily test their software, while simulating different users with their own unique permissions, on the same computer. We will introduce you to the fast user switching feature for developmental testing, and provide examples of how this new capability will revolutionize how you develop applications on the Windows platform.

User Benefits

Let's first take a closer look at fast user switching from the user's perspective. Fast user switching creates independent sessions based on user accounts. You can create multiple sessions at the same time on the system, but only one session can have access to the screen, keyboard, and mouse at a given time.

From an end-user standpoint, this solution allows multiple employees, for example, to use the same computer. While previous Windows operations systems allowed this through user profiles, a user would need to close their applications and log out from the computer before the next user could log into the computer.

In contrast, fast user switching maintains the state of a session even when another user is accessing the computer. This means that the first user does not need to close their applications and log off. Instead, through the new welcome screen in Windows XP, users simply click their name to log into the computer, leaving the original user's session running in memory. Most importantly, the previous user's session is completely secure and totally isolated from other users accessing the computer. Fast user switching allows you to have multiple connections on the same, local, computer.

Live Session Application Testing

From a developer's standpoint, you can now test applications you develop using sample accounts that represent your actual client base.

For example, you may develop a customer management system for use by the sales department. Let's assume that depending on the user, such as a sales representative or a sales manager, your application will allow different levels of access to the underlying data. For instance, sales managers may have the capacity to run detailed reports on all customer orders, such as their order history and credit limits. Individual sales representatives should have the capacity to run a similar report, but only on their own assigned customers. Your application will expose this data based on the authentication of the user accessing the application.

To test this program, you will need to log into the computer as a sales manager and then as a sales representative. In the meantime, you'll want to remain logged in as your primary developer's account so that you can work on the code to fix any bugs you may encounter.

So for example, you could create the following live sessions via fast user switching:

• Your developer session - to interactively debug code, etc.
• A sales rep session - to test your application using a sales rep account
• A sales manager session - to test your application using a sales manager account

Now, as you find bugs or other issues with your code, you can quickly switch to the developer session, recompile your code, and switch back to one of the end-user sessions to test your changes. You can do all this without logging in and out of your computer, or configuring multiple physical computers to play the role of different users.

Planning Considerations for Both

When developing an application for this manner of use, there are a few specifics that you must take into account because you will have two or more users running the application at the same time, at least while you are testing. (It will also be true if, after deploying your solution into production, your clients will use the application in their own fast user switching environment.) Fortunately, most applications, if properly designed and developed in the first place, will typically address the following considerations without any additional coding. Let's review them.

• Install the program for All Users:
  You really need to consider this only if any user that has access to the computer in a fast user switching environment will access the application. From a development standpoint, you probably won't need to actually install the application—just compile it and run it from the appropriate session.
• Save user-specific data in the My Documents folder:
  Properly organizing data that is generated by your application on a per-user basis is critical in the fast user switching environment. Remember, multiple users (through their unique sessions) will run your application concurrently. This creates a possibility of data corruption if you save user-specific data, for example, in App.Path. Saving data in the user's My Documents folder is a good idea anyway when developing a Windows application. However, fast user switching simply raises the need to segment and isolate user data.
• Saving data to the registry:
  You'll probably want to use HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE to store application-specific data in the registry. Again, since multiple user sessions will be accessing your application in a fast user switching development environment, there is a distinct possibility that they could overwrite one another's data. Using the HKEY_CURRENT_USER key will assure that any data specific to the user will be isolated and protected from possible corruption.
• Plan for "access denied" errors:
  Whether you deploy your application to support fast user switching, or just use fast user switching for development purposes, you should prepare your application for the operating system to potentially deny access to resources based on the current user session. As you switch between sessions, say as the developer and as a normal end-user sales representative, it is very likely that the level of permissions will be different between these users. As a result, access denied errors can easily occur and you will need to plan to add the appropriate error handlers as a result.

Multimedia Considerations for Testing

Fast user switching has the ability to support multimedia output devices independently from each user session. This can be useful, but it can also be tricky if, for example, one user session is playing music through the speakers and another user session wants to use the speakers.

For testing purposes, the easiest thing to do is simply to disable an application's access to multimedia devices when it is switched to the background. Windows XP provides the WTSRegisterConsoleNotification API call that will notify your application if the session it is running in changes — such as being relegated to a background session—or has been selected as the current, foreground session. Through this API, you can then run the appropriate code to configure your application to run appropriately if it is not in the foreground session, such as temporarily disabling multimedia output.

Of course, if you want to ensure that only one copy of your application is running, you can use the FindWindow or FindWindowEx API call when your application starts. Obviously you'll only need this when you deploy your application to your client's desktop since, from a development standpoint, you'll want to run multiple copies for testing purposes.

Juggling multiple-session simultaneous access to multimedia output devices for end-user deployment is a deeper issue. A companion article in the DevX Windows XP Developer Center, "User Accounts and Fast User Switching," by Keith Pleas, discusses these issues in more detail.

Overall

Overall, fast user switching provides a great way to create controlled user sessions, with all the appropriate permissions, to allow you to interactively test and debug new applications all from the same computer. Since fast user switching isolates each user session from the other, you can confidently recreate the desktops of your various end-user clients. Then by switching between these sessions, you can quickly and easily test your application against various user account types, such as sales representatives and sales managers. As a result, multiple copies of your application can potentially run concurrently on your development computer.

This means you will need to take additional care in how you manage user-created and application-specific data.

The considerations for multiple users listed in this article are all typically included in a properly developed solution. Depending on whether your clients will be using fast user switching on their actual production desktop computers, you may just want to leave any additional code added as a result of considerations in your application. Fast user switching provides a great new tool for developing and testing applications for use on any of the Windows operation systems.