Microsoft Windows XP: What's in It for Developers?

Kyle Marsh, Dave Massy, and John Boylan
Microsoft Corporation

February 2001

Summary: This article explores some of the features of Microsoft Windows XP and looks at the effect these changes have on software developed for Windows. The discussion focuses on the new Windows XP visuals and ComCtl32, side-by-side component sharing, and fast user switching. (10 printed pages)

Introduction

The good news about Microsoft® Windows® XP is that it has all sorts of cool new features and capabilities. The other good news is that despite the changes, if you've been writing successful applications for Windows, you can write even better applications for the new Windows XP.

In a nutshell, Windows XP (code-named "Whistler" in beta form) is Microsoft's long-awaited operating system that builds on the strengths of Microsoft Windows 2000, while incorporating and expanding the consumer-friendly potential of Windows Millennium Edition (Me).

Writing applications for Windows XP requires a few new tricks, but they're not difficult. More important is the message we've been repeating over and over, especially since the introduction of Windows 2000: the more your applications behave like good citizens, the more successfully they'll run on Windows XP. Windows XP applications should follow the rules you learned in kindergarten: share your resources, play well with others, and follow the rules. It's all about cooperation.

Windows XP Explained

Windows XP is the version of the Microsoft Windows operating system that follows Microsoft Windows 2000 and Microsoft Windows Me and replaces both. Windows XP is based on the Windows 2000 code base and inherits that operating system's reliability and performance. Windows XP also inherits and enhances the new features of the Windows Me operating system: system restore, Windows Media Player, Windows image acquisition, and so forth.

For client machines, Windows XP has two editions, Professional and Home. Professional is for use in businesses and supercedes Windows 2000 Professional, offering the functionality needed for corporations and other businesses. The Home Edition is for consumer use and supercedes Windows Me. Both Windows XP editions include such features as enhanced support for digital media and the new computer sharing capabilities of fast user switching.

On the server side, the three editions match the current Windows 2000 server configurations: Server; Advanced Server for departmental servers, line-of-business, and Web-enabled applications; and Datacenter Server, for high-availability, mission-critical applications. This article focuses on the client editions; the server editions will have their own similar feature set, which will be addressed in future articles.

In order to live up to the promise of a system that works equally well for business and consumer use, Windows XP is loaded with new features. Perhaps the most readily apparent is a whole new look, with completely new visuals and larger, high-quality icons that provide a stronger user experience with minimal development cost. Task bar improvements, such as the grouping together of windows of the same application, make it easier to organize information. And there's more underneath, with enhanced power management, side-by-side component sharing, fast user switching, support for high-density displays, Passport integration, easier-to-use balloon notification, and GDI+. The list goes on.

In this article, we'll briefly look at some of the most important areas you need to cover: writing for the new UI with the new ComCtl32 version 6, writing for side-by-side sharing, and writing applications that take advantage of Windows XP's fast user switching and remote desktop features. In the coming months, MSDN will explore these and other topics in greater depth. The PSDK has information about these features. The Windows XP beta 2 SDK release will have a lot more, and that will go out to all MSDN subscribers with their copy of beta 2. If you're not a subscriber, it will be available later in the year.

A New Look

The visual style of Microsoft Windows has been pretty much unchanged since Windows 95. The gray three-dimensional chiseled dialog box controls have become synonymous with Windows. With the release of Windows XP, we see a whole new visual style. Windows XP builds on the desktop themes first introduced in the Windows 95 Plus Pack to provide multiple themes that determine the visual style of the system. While the original desktop themes would change a user's color scheme, fonts and font sizes, and wallpaper settings, Windows XP themes change the way controls, window borders, and menus are drawn.

The task bar has undergone a complete overhaul. We wanted to address the problem of finite space on the task bar, with buttons getting smaller and smaller as more windows are open. We've all faced the problem of task bar buttons that are so small as to be next to useless. If you have many windows open at one time, so that the buttons are too small, Windows XP will begin to group the buttons. For example, say the user has five Microsoft® Word documents currently open; rather than having five buttons, you have one. Click it and a menu opens, listing all of the open windows.

The notification area has also been cleaned up. Over time it has lost its original purpose as a place for notifying the user of current issues, instead becoming a place for launching applications. Windows XP reduces clutter by hiding icons that are not actively notifying the user. The user exposes hidden icons with chevrons and can decide to override this behavior, choosing which icons to always show and always hide.

The way Windows opens has changed. To reduce desktop clutter, all icons except the Recycle bin are moved to the new larger start menu, where system-supplied functions appear in a separate blue section, alongside a display of the user's most frequently used applications. To further help reduce desktop clutter, Windows XP will periodically search the desktop for unused application icons, and a desktop wizard will then help the user remove them from the desktop. Any data kept on the desktop will stay as it is.

Windows XP itself provides two visual styles: the classic Windows style and the new style that we're calling the Whistler style. On top of that, Windows XP has mechanisms for ISVs to synch with new styles, and as Microsoft adds styles over time that allow for individual preference, the applications you write for Windows XP will have the ability to automatically receive those refinements.

At first glance, the potential for multiple Windows XP styles may look like the skin functionality in such applications as Window Media Player, but there are differences. Themes change the visual style of the operating system, but still provide a consistent UI with earlier versions of Windows. This is important since themes are applied system-wide. The changes applicable to an application skin, such as removal of buttons, are not appropriate at the operating system level. The theme file formats are not public; Microsoft retains the design control for themes, to allow a consistent user interface and ensure design continuity. A theme developer's kit will not be available with Windows XP.

You're familiar with the classic style, with windows and dialog boxes appearing in the familiar gray, chiseled look. This Windows XP option allows users to keep a familiar interface. The Windows XP Whistler style provides a whole new set of visuals. As much as the new visual style varies from classic windows, however, the overall look and feel is still similar. New to the Windows XP are buttons and tabs that change color when the pointer rolls over them in much the same way as hot spots on a Web page.

Figure 1. Windows XP Start menu

Themes and Controls

With Windows XP, Microsoft has coalesced the User Win32 controls with the common shell controls in ComCtl32 version 6. These new controls use the new theme manager to render the appropriate visuals.

In earlier 32-bit versions of Windows, some controls are implemented in User32.dll, others in ComCtl32. The rendering of nonclient areas of a window (the border and menus, for example) is done with User32.dll. User32.dll is a core component of the operating system, and thus it is tied to a particular version of that operating system. For Windows 2000 and Windows Me, ComCtl32 is under Windows File Protection, so it can also only be changed with a system update or service pack. For previous versions of Windows, ComCtl32 actually shipped with many system components and applications, and it was often a cause of applications failing after another application or system component was installed. Windows XP ships with the same ComCtl32 as the most recent service pack for Windows 2000.

Windows XP introduces the next direction for Windows component development, based on side-by-side component sharing. Remember that the new themes specify the appearance of controls. To allow for the new look in Windows and to give designers the ability to innovate the visual style of the UI without requiring changes to the core functionality, Microsoft is introducing the theme manager, uxtheme.dll. This new DLL provides rendering support for the new controls and provides information APIs to assist controls in positioning parts. It also renders the new Windows XP visual style for the nonclient areas in all applications, unless they are custom-drawn, including scroll bars and title bars. That means that the theme manager is involved with every application. Together with ComCtl32, the theme manager allows us to theme the majority of Windows applications, with a visual flexibility that allows ISV designers to get the new Windows XP look into their application.

We fully realize that the new ComCtl32 has the potential to break some applications. To prevent this, ComCtl32 version 6 is installed as a shared assembly, side-by-side with ComCtl32 version 5, which is installed in the System32 directory. The new DLL is only available to applications that provide a manifest telling the operating system that they work with the new DLL. If they do not provide a manifest, existing applications continue to use ComCtl32 version 5. Versions 5 and 6 both ship with Windows XP and are installed side-by-side. We'll talk more about manifests in the next section.

Note ComCtl32 version 6 will not ship for previous versions of Windows, where you'll continue to use ComCtl32 version 5. Version 5 does not have such features as the new visuals, hyperlink control, or the group view. If you use these features, you should test your application on Windows 95, Windows 98, and Windows 2000.

To make sure that your application uses the new visual styles in Windows XP, you need to make sure to link to ComCtl32 and use a manifest to specify the dependency on ComCtl32 version 6. If you have any owner-drawn controls, start asking the uxtheme.dll to draw them, rather than drawing them yourself. You'll need to do this if you want them to feel like the rest of the UI.

Here is the code that draws a theme-aware button:

rtButton.top = 100;
rtButton.left = 10;
rtButton.bottom = 130;
rtButton.right = 200;
hTheme = OpenThemeData(hWnd, L"Button");
DrawThemeBackground(hTheme, hdc, BP_PUSHBUTTON,  PBS_NORMAL, &rtButton, NULL);
DrawThemeText(hTheme, hdc, BP_PUSHBUTTON, PBS_NORMAL, wzTMB, wcslen(wzTMB),
DT_CENTER | DT_VCENTER | DT_WORD_ELLIPSIS | DT_SINGLELINE, 0, &rtButton);

One common reason for creating owner-drawn buttons has been the need to add a bitmap. Now the ComCtl32 version 6 buttons can incorporate developer-supplied bitmaps by associating an image list with the button. Be sure to test your application with a ComCtl32 version 6 manifest and with version 5—whether you are updating your application or writing a new one—to see how your windows and dialog boxes look with the new visuals.

Here is code that draws a button with a bitmap:

Button_ImageList.himl = himl;
Button_ImageList.uAlign = BUTTON_IMAGELIST_ALIGN_LEFT;
Button_ImageList.margin.top = 3;
Button_ImageList.margin.bottom = 3;
Button_ImageList.margin.left = 3;
Button_ImageList.margin.right = 3;

hwndImageBtn = CreateWindow(L"Button",wzText,WS_CHILD | 
      BS_PUSHBUTTON,0,0,0,0,hWndParent,NULL,hInst,NULL);
Button_SetImageList(hwndImageBtn, &Button_ImageList);
Button_GetIdealSize(hwndImageBtn, &sizeBtn);
SetWindowPos(hwndImageBtn, hWndParent, 10, 10, sizeBtn.cx, sizeBtn.cy, 
      SWP_SHOWWINDOW | SWP_NOZORDER | SWP_NOACTIVATE);

Note If you're using HTML to render a UI using Microsoft Internet Explorer technologies, you can place a metatag in the HTML file to ensure that the theme is adopted by the HTML controls.

Note A word of caution: don't theme third-party extensions until you have tested all of them. If you host a third-party application, we'll be looking at a way to deal with other applications in your process in an MSDN article scheduled to appear in March 2001.

Icons

Windows XP allows for icons that not only look great, but also include enough detail to present a much more complex and sophisticated message than traditional icons. The new icons support up to 24-bit color depth, and they support an 8-bit mask in the alpha channel. Used in icon, tile, and thumbnail views, these images can be as large as 48 by 48 pixels. By the way, the tile view icons are a great new way of presenting information; the icon comes with two or three lines of annotation, so you can present key information alongside the icon.

The icon format has not changed, but Microsoft has added support in our imagelist APIs to display these 32-bit icons. In order to correctly author these icons so that they work well in previous versions of Windows, you will need to author multiple images for each icon, as shown in Figure 2.

Figure 2. Multiple icon images

In this example, the first three images are used in 16-color mode for safe mode. The next three icons are used in Windows XP 256-color modes. The final three icons have the alpha channel and should only be used in Windows XP or later operating systems when running in 24-bit color or higher.

Note that the order of these images in the icon format does matter. If the order is wrong, the icons will cause older version of Windows to function poorly when extracting the icons. This poor performance manifests itself in memory corruption and improper rendering. Also note that previous version of Windows had a 10-icon resource limit, whereas Whistler supports thousands of icon resources in the icon file.

One way to think about the new icons: Before, you used a relatively simple tool like Microsoft Paint to create your icons; now you'll find yourself using Photoshop.

Note

   

The gamani productions tool, GIF Movie Gear for Icons, can write full 24-bit color, eight-bit alpha channel Windows icons (ICO) files. See https://www.gamani.com/foricons/.

Side-by-Side Sharing

The workings of the new UI rely on a side-by-side sharing requirements structure. As a solution for versioning problems and DLL Hell, Microsoft strongly suggests that applications adopt a side-by-side versioning strategy. As seen in the implementation of ComCtl version 6, side-by-side components are the future of Windows development. This section gives you an overview about what's new for side-by-side sharing for Windows XP. For an in-depth look into this topic, see How To Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP. For background on side-by-side component sharing issues and DLL redirection, see Implementing Side-by-Side Component Sharing in Applications (Expanded).

With side-by-side components, multiple versions of a component are installed simultaneously. An application is bound to the version of the component with which it was designed and tested.

With Windows XP, there's an infrastructure to support assemblies and isolated applications (both COM+ and Win32). A code change should not be required to get at side-by-side assemblies from Win32 applications. Applications can use the latest system assemblies without global impact.

In short, isolated applications are valuable because they are more reliable. They are built and shipped with all needed components and are not affected by changes that other applications make. Isolated applications use a manifest, which is an XML file containing information that self-describes an assembly or an application. All binding and activation metadata, such as COM classes, interfaces, and type libraries, is now stored in the manifest, rather than the registry. There are two types of manifest files: applications manifests, which describe isolated applications, and assembly manifests, which describe individual assemblies.

An isolated application may use side-by-side assemblies. Assemblies are the fundamental units of naming, binding, versioning, deployment, and configuration. They come in two varieties, shared and private. A shared assembly is available for use by multiple applications on the computer, installed in the WinSxS folder in the Windows directory. A private assembly is only visible to that application and is deployed within the directory structure of the application.

There's another benefit for application developers in using side-by-side sharing; your schedule can be much clearer. Your development schedules are not affected by the release schedules of the components you use.

Fast User Switching

Windows XP brings a new feature called fast user switching. Based on the computer sharing functionality of Windows 2000 and the multiple sessions of Windows 2000 Terminal Server, fast user switching allows several users to easily and efficiently share the same computer.

Surveys indicate that 80 percent of consumer Windows users share a computer with other household members. While Windows 98 has the ability to create sharing called profiles, the feature is rarely used. With Windows 2000, a feature that allows separate accounts but it is difficult to use in a home environment.

Windows XP changes all that. Based on the Windows 2000 profiles, user accounts are created for all users during installation. As the default, passwords are not required, although users can create them if desired. A friendly new welcome screen featuring user names and pictures or icons rather than code names or aliases replaces the logon dialog box. Further, a new control panel applet makes it easy to add and edit user accounts. Each user has their own settings, including wallpaper, music, pictures, favorites, and so forth.

In fast user switching, multiple users do not have to not log off when using a single computer. Instead, their accounts are always logged on, and they can switch quickly between all open accounts.

For example, Dad comes home and starts using his machine. He opens PowerPoint and starts working on a document. Son Billy then asks to use the computer. He goes back to the Welcome screen, clicks "Billy," and logs on and starts playing a game. However, Dad is still logged on at this point, and if he wants to, he can quickly switch to his open account without logging off. His PowerPoint presentation will still be open; his Internet connection will be preserved.

An accompanying feature is remote desktop, which allows users to access their data and applications, still with their own settings, from a remote machine. This can happen within a network, but it also can happen when the user locks their workstation at the office, goes home, and remotely controls the workstation applications from a home computer.

Windows XP does all this with terminal server. For developers, supporting fast user switching is largely the same as developing for computer sharing in business environments, with roaming users, users on several shifts, telecommuters, and for working well for hosted servers in a terminal server environment.

MSDN will explore switching details in the Windows XP environment in an article that will appear in March 2001. Also see the article Optimizing Applications for Microsoft Windows 2000 Terminal Services and Windows NT Server 4.0, Terminal Server Edition. For now, keep in mind that to work well with fast user switching, applications should follow the Certified for Windows specification for data and setting management.

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

In addition, here are some other things to consider. Applications should:

• Support "All Users" installs
• Check for other instances correctly.
• Communicate with services.

Further, consider these when your application is not on the current desktop:

• Minimize processor usage.
• Don't play sounds.
• Don't update the display.
• Be sensible with system resources.

Other Features

The full range of Windows XP features is beyond the scope of this article, although we can look at a few of them from a development standpoint.

Power management. Windows XP employs Windows 2000 power management features; for a good overview see Robert Di Benedetto's article, Tips for Supporting OnNow (Power Management) in Windows 2000 Applications.

GDI+. Graphics Device Interface Plus (GDI+) is the portion of Microsoft Windows.NET that provides two-dimensional vector graphics, imaging, and typography. GDI+ improves on GDI (the graphics device interface included with earlier versions of Windows) by adding new features and by optimizing existing features. More information is available in the Beta 2 SDK.

64-bit Windows. Microsoft is building Windows XP from one source tree for both 32-bit and 64-bit Windows. Your application will be 64-bit someday, and we strongly recommend that you start getting your applications ready for 64-bit now. See the section of the Platform SDK in the MSDN Library entitled, "Getting Ready for 64-bit Windows."

Support for high-density displays. New 133-DPI monitors are available now, and 200-DPI monitors are on the way. You'll want to test your applications with 140-DPI fonts and large icons. The Windows XP dialog boxes, buttons, title bars, and speech input are all large font aware. Look for an MSDN article on writing applications for high-density displays in March 2001.