SEPTEMBER 2003 TIP OF THE MONTH

This month’s tip will discuss migrating applications. There are a few differing philosophies on what the migration should and should not move due to safety reasons and software piracy. This tip will discuss the dangers in migrating applications and file types that may or may not be appropriate to bring to an XP™ system because of the interaction between the application and Operating System. We hope this will clarify what the dangers can be so you can make an informed decision.

XP has proven to be a popular version of the Windows® O/S, yet some of the technology advancements in this operating system have accelerated old versions to be retired due to functions and features. This information is provided as a resource from Microsoft®’s technical documentation. We have listed the web address below with content produced by Microsoft to explain how these standards are important and can make a difference in the migration experience.

<http://www.microsoft.com/winlogo/software/windowsxp-sw.mspx>


“Designed for Windows XP” for Applications


"Designed for Microsoft Windows XP" Application Specification defines the technical requirements for applications to earn the "Designed for Microsoft Windows XP" logo.

The following summarizes the key requirements for the "Designed for Windows XP" logo program for applications.

Contents:
1.0 Windows Fundamentals: Requirements Summary
2.0 Install/Remove: Requirements Summary <http://www.microsoft.com/winlogo/software/>
3.0 Data and Settings Management: Requirements Summary

See also:
Supplemental Guidelines in Recommendations and Future Requirements <http://www.microsoft.com/winlogo/software/swfuture.mspx>
Download: "Designed for Microsoft Windows XP" Application Specification <http://www.microsoft.com/winlogo/software/downloads.mspx>


1.0 Windows Fundamentals: Requirements Summary
Customers can be confident that a compliant product will execute on Microsoft® Windows® XP and will not adversely affect the reliability of the operating system.

1.1 Perform primary functionality and maintain stability
The application must perform its primary functions without compromising the stability of the operating system or the application.

1.2 Any kernel-mode drivers that the application installs must pass verification testing on Windows XP
Poorly written kernel-mode drivers have the potential to crash the system. Therefore, it is critical that any application that includes kernel-mode drivers, such as backup, copy protection and compact disc (CD) burning products, be thoroughly tested to minimize this risk.

If the application includes any kernel-mode drivers, each of these drivers must pass validation triggered by the Windows Driver Verifier Manager tool (Verifier.exe). That is, running Driver Verifier must not report any stop error messages, or otherwise cause system instability.

You are responsible for ensuring that all components provided with your application meet this requirement.

1.3 Any device or filter drivers included with the application must pass Windows HCT testing
If the product includes drivers for hardware devices and filter drivers, these drivers must pass the related tests provided in Windows Hardware Compatibility Test (HCT) 10.0 or later.

For certain categories of drivers, Windows XP will present a warning to end users if they attempt to install a driver that does not have a digital signature from Microsoft. For any driver categories that require a digital signature, the component must be digitally signed by Microsoft.

You are responsible for ensuring that all components provided with your application meet this requirement.

1.4 Perform Windows version checking correctly
The application must verify that the operating system meets the minimum version requirements for the application. The application must also install and run on all later versions of Windows.

In certain cases, it is acceptable to block installation of the application on later versions of Windows. If you choose to do this, you must display a message to the user when blocking installation or execution that the application is not designed for the later Windows version.



1.5 Support Fast User Switching
In Windows XP, the Fast User Switching feature allows multiple users sharing the same computer to have individual profiles and to swap their current work spaces without logging off. The application must not crash or lose data or settings when customers use Fast User Switching.

For example, if the first user has an editor application open and a subsequent user launches the same editor application, the first instance of the application must not shut down and must not lose any of the first user's edits.

By meeting the requirements for Data and Settings Management, your application is unlikely to have problems with Fast User Switching, except for possible conflicts with shared resources such as CD drives, printers, modems, and sound cards.

If additional instances of the application run by separate users can result in failure of primary functionality, you must redesign so that the failure cannot occur. When blocking any feature to prevent failure under Fast User Switching, the application must inform the user why it did so.

1.6 Support new visual styles
If the application loses functionality or usability when a user selects one of the new visual styles, you must disable the style for the application. Applications that are full-screen graphics typically do not need do anything to meet this requirement, because changing the visual styles in Windows would be unlikely to have an adverse affect on the functionality or usability of the application.

1.7 Support switching between tasks
The application must not block ALT+TAB, CTRL+ALT+DEL and other task-switching scenarios. The application must not try to defeat these mechanisms in any way.

2.0 Install/Remove: Requirements Summary
Customers can be confident that your product will install onto Windows XP without degrading the operating system or other applications.

2.1 Do not attempt to replace files that are protected by Windows File Protection
The application must not attempt to replace any files that are protected by Windows File Protection (WFP). To ensure that the application does not invoke WFP, it should call SfcIsFileProtected when installing any file that it did not create. The Windows Installer service does this automatically.

Windows File Protection is a feature of Windows XP that prevents the unauthorized replacement of essential system files. WFP runs as a background process on Windows XP and monitors certain files. When WFP detects that a protected file has been changed, it restores the original.

Protected files include the following files that ship on the Windows XP product CD:

  • Most .SYS, .DLL, .EXE and .OCX files.

  • The following fonts: Micross.ttf, Tahoma.ttf, Tahomabd.ttf, Dosapp.fon, Fixedsys.fon, Modern.fon, Script.fon, and Vgaoem.fon.
If the application requires newer versions of these components, it must update these components by using a Microsoft Service Pack that installs the required versions.

2.2 Migrate from earlier versions of Windows
The application must continue to function correctly when the operating system is upgraded to Windows XP from Windows 98, Windows Me, Microsoft Windows NT®, or Windows 2000. It is strongly recommended that the application do this without requiring un-installation and reinstallation.

If your application requires Windows version specific code (kernel mode drivers, VxDs, etc.), you must ensure that a solution is available to the user for download or retrieval when they upgrade to a later version of Windows.
  • The application must not crash or lose data if run after the system is upgraded to a new version.

  • The solution must be freely available.

  • The solution must not require any technical actions. It must be easy to use and targeted at end-users. For example, it must not require the user to modify registry entries or change INI settings.

To achieve this, the application may need to be able to react to operating system changes dynamically at runtime. Many applications detect the Windows version during installation and decide what to install based on that. This usually means that the installed application is operating system-specific, and when Windows is upgraded to a newer version it will not function properly.

Applications only need to migrate from versions of Windows that they support. For example, if the application does not install onto Windows 98 or Windows Me, it does not need to migrate from those versions.



2.3 Do not overwrite non-proprietary files with older versions
The application's installation program must properly check to ensure that the latest file versions are installed. Installing an application must never regress any files that you do not produce or that are shared by applications that you do not produce.

Do not prompt the user to update a component unless a version update is actually required. Correct file version information has several benefits, including making it easier to meet the requirement of not overwriting files with older versions. Accordingly, all executable images that you distribute must contain valid file version information. When you display or get the properties of an executable (EXE, DLL, OCX, CPL, and so on), they must contain an accurate Product Name, Company Name, and File Version.

2.4 Do not require a reboot inappropriately
In Windows XP, very few installation situations require a reboot. Reboots are unwelcome by customers and, in some situations, can make deploying applications difficult. The application must not require or suggest an unnecessary reboot during or after installation.

Some situations that require a reboot:

  • Installing a Windows Service Pack or authorized system redistributable may require a reboot.

  • Installing a Graphical Identification and Authentication dynamic link library (GINA) requires a reboot. The GINA is a replaceable DLL component that is loaded by Winlogon. The GINA implements the authentication policy of the interactive logon model, and it is expected to perform all identification and authentication user interactions. For example, replacement GINA DLLs can implement smart card, retinal scan, or other authentication mechanisms in place of the standard Windows XP user name and password authentication.
Situations that do not require a reboot:
  • DLL registration.

  • Updating a service component. If necessary, you must warn the user that certain services will be stopped while they are updated.

  • Replacing an existing file that is in use by an application. You must give the user information about any open applications that have loaded the resource files you are updating so that the user can shut down those files and allow file replacement to occur without a reboot.

  • Also, for many components, you should install the components side-by-side or use MoveFileEx with the delay until reboot option to avoid this situation.
If you do require a reboot, you must prompt users and allow them the option of deferring the reboot.

2.5 Install to Program Files by default
By default, the application must install into an appropriate sub-directory where the current user's program files are stored.
  • If you are using the Windows Installer, this folder is represented by the ProgramFilesFolder property in a Windows Installer-based package. (The ProgramFilesFolder property is a variable that exposes the path to the Program Files folder, and the Windows Installer sets that variable appropriately on all Windows platforms.)

  • If you are not using the Windows Installer, the recommended method is to use SHGetFolderPath API to retrieve the string represented by the CSIDL_PROGRAM_FILES value. On English-language systems, this folder is often C:\Program Files. However, do not hard-code that path, even for use on English systems, because it is not universal.

If you are upgrading a previously installed version of the application, it is acceptable to default to the directory on which that version exists. If your application does not require installation (it executes without any files being installed onto the system), then this requirement is not applicable.



2.6 Install any shared files that are not side-by-side to the correct locations
Windows-based applications can share code, application, and component state in the registry, application-specific data in the file system, and Windows APIs that expose global namespaces. Sharing allows for the efficient leverage of limited hardware resources and reduces the exposed front that Quality Assurance groups must test.

However, there are costs to sharing. Sharing causes applications to become interdependent upon one other, which introduces an element of fragility. In the extreme, applications that previously worked might mysteriously start functioning oddly, or even fail. Typically, an application is dependent on a particular version or implementation of a shared component. If that shared component is upgraded (or downgraded) as a result of installing another application, the former application may break. Windows XP, Windows 2000, Windows 98 Second Edition, and Windows Me enable side-by-side sharing, which minimizes this application fragility. Side-by-side sharing enables multiple versions of the same Win32® component to run at the same time in memory.

This means that applications can use the specific components that they were designed for and tested with, even if another application requires a different version of the same component. This allows developers to build more reliable applications, because developers can choose the version of the component that they will use for their application, independent of the other applications on the system.

The proper location for shared components that are not shared side by side depends on whether these components are shared across companies or by a single company:

  • Shared components that are private to a single software vendor must be installed in one of two places: the common files directory, or the publisher's directory under the Program Files folder. Do not store these files in the System directory.

  • New control panel applets must be installed in the application directory on Windows XP.

  • Services and device drivers must be placed in the System directory.

  • OCXs and DLLs that are not side-by-side and are shared by multiple software vendors can be placed in the System directory to ensure backward compatibility with those applications.

2.7 Support Add or Remove Programs properly
The application must supply your product's name, the location of your application's uninstaller, and so on, so that the Add or Remove Programs applet in the Control Panel can obtain information about the application as needed. You can write this information directly to the registry during install or, if you are using an installation system based on the Windows Installer service, you can set these values by using properties in the Windows Installer-based package.

This requirement is not applicable for an application that does not install - that is, if it executes without installing any components, writing to the registry, modifying the system, or leaving any files on the system other than user created files.

The application's uninstaller must correctly and fully remove the application.

2.8 Support "All Users" installs
Applications are often used by more than one user on the machine. Your installer must default to "all users" or provide "all users" installation as an option. For example, an installer might default to the option of installing the application only for the current user but the application must provide an option to install for all users.

An unprivileged user may attempt to install the application. If a limited user cannot install the application or cannot install for "all users," the installation must degrade gracefully.

2.9 Support Autorun for CDs and DVDs
For applications distributed on CD, DVD, or other removable media that support Autorun, the first time the disc is inserted, the application must use Autorun to run the application or prompt the user to install. In the case of applications distributed on multiple discs, subsequent discs must either use the Autorun feature or continue installation without prompting the user to press a key or take other action when the CD has been inserted.

It is not acceptable to require the user to use Start/Run to launch the installation from the CD or DVD.

After the application has been successfully installed, re-inserting the CD or DVD in the drive must not cause installation to automatically begin again. It is acceptable to ask.

3.0 Data and Settings Management: Requirements Summary
Windows XP provides an infrastructure that supports state separation of user data, user settings, and computer settings. Applications that use this infrastructure correctly offer the following benefits:

  • Applications do not fail when run by Limited Users (non-Administrator), allowing family or friends to share a computer safely and easily.

  • Parents can allow children to use the computer without giving them administrative privileges, which would give the child unrestricted access to modify the computer.

  • Users can back up their individual documents and settings easily without needing to back up application and operating system files.

  • Multiple users can share a single computer, each with his or her own preferences and settings.

  • Applications are less likely to prevent Fast User Switching from operating correctly and efficiently.
3.1 Default to the correct location for storing user-created data
User-created files must be stored in the user's My Documents (or descendant) folder. For imaging files, it is recommended to use My Pictures in place of My Documents. Similarly, use My Music for audio files.

The first time a user runs an application, the application's File Open and Save dialogs must default to the user's My Documents (or descendant) folder the first time these dialogs are called. On subsequent calls to these dialogs, it is recommended to default to the previously selected path. Application data, such as user preferences, application state, temporary files, and so on, must not be stored within My Documents.

The benefits of using the My Documents folder as the default for data storage are:
  • All users (including those with restricted account types) have write access to this location.

  • Users have one familiar place to organize and store all their data.

  • Data sharing is facilitated between applications because all applications using Common File Open can easily access the My Documents folder.

  • My Documents is an abstracted location and can be redirected to the network transparently by an administrator.

  • My Documents is available on the Start menu

3.2 Classify and store application data correctly Classifying and storing application data according to the guidelines in this requirement provides these benefits:
  • It enables multiple family members to share a machine and helps enable Fast User Switching.

  • It enables business-related operations such as roaming, off-line storage, and allowing the operating system and its applications to be secured.

  • It ensures a consistent and abstracted location for user data, enforces per-user separation of application data.

  • It is one of the key factors in enabling remote use of the application.
3.3 Deal gracefully with access-denied scenarios
By default on Windows XP, restricted user accounts (for example, Limited Users on Home Edition) cannot write to per-machine locations such as HKLM and the Windows directory. Only applications that classify and store data correctly, as described earlier, will be able to avoid access-denied errors and run successfully in this secure environment.

There are, however, legitimate scenarios in which access-denied errors are encountered by applications that classify and store data correctly.

3.4 Support running as a Limited User
Applications must not require users to have unrestricted access (for example, Administrator privileges) to make changes to system or other files and settings. In other words, the application must function properly in a secure Windows environment. Complying with the previous requirements in this section will help to ensure that the application meets this requirement.

An application that does not install (executes without installing any components) must still support use by a Limited User.

A secure Windows environment is defined as the environment exposed to a Limited (non-Administrator) user by default on a clean-installed NTFS system. In this environment, users can only write to these specific locations on a local machine:
  • Their own portions of the registry (HKEY_CURRENT_USER)

  • Their own user profile directories (CSIDL_PROFILE)

  • A Shared Documents location (CSIDL_COMMON_DOCUMENTS)

  • A folder that the user creates from the system drive root

  • However, applications defaulting to use of these folders do not comply with the other requirements of this section.
Users can also write to subkeys and subdirectories of these locations. For example, users can write to CSIDL_PERSONAL (My Documents) because it is a subdirectory of CSIDL_PROFILE. Users have read-only access to the rest of the system.

When the major features of the application can be successfully run by a non-privileged user, minor features are allowed to fail gracefully. These minor features must not be installed by any default mechanism (for example, a minimal or typical install) other than a complete install and must not be considered important for the operation of the program. Examples of such minor features include components necessary to support legacy file formats.

Limited Users cannot perform several system administration functions such as disk defragmentation, backup/restore, changing system time, and so on. When most of the primary functionality of an application is system administration, the application must still run from a Limited User account and inform the user why none of the features can be used.

Windows and XP are registered trademarks of Microsoft Corporation. ©2003 Microsoft Corporation. All rights reserved.