Guidelines for Managing Default Applications in Windows Vista

The Set Program Access and Defaults (SPAD) feature was provided in service packs for Microsoft Windows XP and Windows 2000 to manage per-computer defaults. In addition to SPAD, Windows Vista introduces the concept of per-user default applications and the Default Programs item in Control Panel.

Per-user default settings are specific to an individual user account on the system. If per-user default settings are present for a specific user, they take precedence over corresponding per-computer defaults. For any defaults that are not set per-user, the system falls back to the per-computer defaults. Therefore, a newly created user account gets the per-computer defaults until per-user defaults are established for that user. Users can use the Windows Vista Default Programs item in Control Panel to set or change their per-user defaults. In addition, when a user runs an application for the first time, per-user defaults can be set for that user using the guidelines that follow in the Application First Run and Defaults section.

An application must register with both SPAD and the Default Programs feature to be offered as the default program in Windows Vista.

This topic provides independent software vendors (ISVs) with a quick guide to the steps necessary to register and manage application defaults in Windows Vista. Links are provided to more in-depth articles about each section's topic.

  • Default Programs Item in Control Panel
  • Set Program Access and Computer Defaults
  • Registering for Application Entry Points
  • Application Installation and Defaults
  • Application Upgrades and Defaults
  • Application First Run and Defaults
  • Verifying Defaults and Asking for User Consent
  • Application Compatibility Tips
  • Related Topics

Default Programs Item in Control Panel

Default Programs is a feature introduced in Windows Vista, accessible directly from the Start menu as well as Control Panel. It provides a new infrastructure that works with standard user privilege (not elevated) and is designed to enable users and applications to manage per-user defaults. For users, Default Programs provides a unified and easily accessible way to manage defaults, file associations, and Autoplay settings across all applications on the system. For applications, using the per-user scope provided by the Default Programs APIs offers several advantages.

  • No Elevation

    An application does not have to elevate its privileges to claim defaults.

  • Good Citizenship

    On a multiple-user machine, each user can select different default applications.

  • Default Management

    Default Programs APIs offer a reliable and consistent mechanism for self-checking the default status and reclaiming lost settings without resorting to writing directly to the Registry.

To enable your application to manage defaults in Windows Vista effectively, you must register your application as a potential default program. See Default Programs for details on registering and using the Default Programs APIs.

Default Programs also provides these two features:

  • Reusable Defaults UI

    Both the program defaults (Set your default programs) and file associations (Associate a file type or protocol with a program) user interface (UI) can be reused and called from within an application. This enables applications to provide a standard user experience for managing defaults and saves ISVs from having to develop a custom or equivalent UI.

  • Inclusion of URL and Marketing Information

    As part of the Set your default programs page of the Default Programs item in Control Panel, an application can provide marketing information and a link to the vendor's Web site. This URL is derived from the Authenticode certificate that the application has been signed with. This prevents misuse and unauthorized replacement of this link. If an application has an Authenticode certificate for the application, and that certificate includes an embedded URL, Windows UI displays that embedded URL. ISVs should take advantage of this feature to direct users to the vendor's Web site for updates and other downloads.

Set Program Access and Computer Defaults

Set Program Access and Computer Defaults (SPAD)—called simply Set Program Access and Defaults in earlier versions of Windows— is included in Windows Vista and works as it did in earlier versions of Windows. SPAD enables administrators to manage computer-wide defaults that are inherited by all new users of that computer. It also provides a way for administrators to repair file associations that can be broken when programs are removed from the system.

The process of registering an application in SPAD has not fundamentally changed from previous versions of the OS. See Working with Set Program Access and Computer Defaults (SPAD) and Registering Programs with Client Types for specific information. Specific changes and new recommendations are discussed in the sections that follow.

Setting Defaults in SPAD

In Windows Vista, per-user defaults override per-computer defaults. Therefore, defaults set in SPAD will not be seen by users if corresponding per-user defaults are set. However, if a user has not previously set a per-user default, the system falls back to the corresponding machine default. New user accounts on a computer inherit the machine defaults initially. That user should be prompted by an application to assign the user's per-user defaults on a per-application basis the first time that application is run by that user. See Application First Run and Defaults.

When an application implements Set as Default in SPAD, these guidelines should be followed:

  • Applications should claim only machine-level defaults through SPAD.
  • Applications should not claim per-user defaults through SPAD.

Hide Access in SPAD

The hide access option for each possible default in SPAD is accessed in one of two ways:

  • Choose the Non-Microsoft category of defaults, which removes access to all Microsoft defaults.
  • Choose the Custom category and clear the Enable access to this program box.

Previously, taking either of those actions removed all entry points to those applications on the system. The specific guidelines are to remove shortcuts and icons from the following locations:

  • Desktop
  • Start menu
  • Quick Launch bar
  • Notification area
  • Shortcut menus
  • Folder task band

Vendors are encouraged to implement these guidelines in the application's Hide Access callback.

Alternate Hide Access Method in SPAD

For some legacy applications, a full implementation of Hide Access may not be practical. An alternative method that achieves the same effect, but is not easily reversible by the user, is to uninstall the application. The following shows sample behavior and example code to implement this alternative.

The recommended user experience for this alternative is as follows:

  • When the user clears the Enable access to this program box in SPAD, the following UI is presented:

    Vista dialog box. To hide access to this program, you need to uninstall it by using Programs and Features in Control Panel.

  • When the user clicks OK, the Programs and Features item in Control Panel displays so that the user can uninstall the application.

  • Windows XP users should be presented with this dialog box:

    Windows XP dialog box. To hide access to this program, you need to uninstall it by using Add/Remove Programs in Control Panel.

  • When the Windows XP user clicks OK, the Add or Remove Programs item in Control Panel displays so that the user can uninstall the application.

The following code provides a reusable implementation for the Hide Access feature as outlined previously. It can be used for both Windows XP and Windows Vista.

#include <windows.h>
#include <shlwapi.h>
#include <strsafe.h>

PCWSTR c_pszMessage1 = L"To hide access to this program, you need to uninstall it by ";
PCWSTR c_pszMessage2 = L"using\n%s in Control Panel.\n\nWould you like to start %s?";
PCWSTR c_pszApplicationName  = L"Sample App";

int _tmain(int argc, WCHAR* argv[])
{
    OSVERSIONINFO version;
    version.dwOSVersionInfoSize = sizeof(version);

    if (GetVersionEx(&version))
    {
        PCWSTR pszCPLName = NULL;

        if (version.dwMajorVersion >= 6)
        {
            // Windows Vista and later
            pszCPLName = L"Programs and Features";
        }
        else if (version.dwMajorVersion == 5 &&
                 version.dwMinorVersion == 1)
        {
            // XP
            pszCPLName = L"Add/Remove Programs";
        }

        if (pszCPLName != NULL)
        {
            WCHAR szMessage[256], szScratch[256];
            if (SUCCEEDED(StringCchPrintf(szScratch, 
                                          ARRAYSIZE(szScratch), 
                                          c_pszMessage2, 
                                          pszCPLName, 
                                          pszCPLName)))
            {
                if (SUCCEEDED(StringCchCopy(szMessage, 
                                            ARRAYSIZE(szMessage), 
                                            c_pszMessage1)))
                {
                    if (SUCCEEDED(StringCchCat(szMessage, 
                                               ARRAYSIZE(szMessage), 
                                               szScratch)))
                    {
                        if (IDOK == MessageBox(NULL, 
                                               szMessage, 
                                               c_pszApplicationName, 
                                               MB_OKCANCEL))
                        {
                            ShellExecute(NULL, 
                                         NULL, 
                                         L"appwiz.cpl", 
                                         NULL, 
                                         NULL, 
                                         SW_SHOWNORMAL);
                        }
                    }
                }
            }
        }
    }
    return 0;
}

Registering for Application Entry Points

There can be many application entry points within the operating system. The following are the recommended locations where an application may put entry points.

  • Desktop
  • Start menu
  • Quick Launch bar
  • Notification area
  • Shortcut menus
  • Folder task band

This section focuses on these specific areas:

  • Open With
  • Start Menu and Quick Launch Bar

Open With

The Open With shortcut menu enables the user to select an application that can handle a specific file type. While Open With can be used simply to open a file with that application on that occasion, it can also be used to set the default for that file name extension. Therefore, an application should always register for Open With so that users are presented with that application as a choice. Applications can register both file types and protocols for Open With. Applications that register protocols in the Default Programs framework are automatically added to the Open With options for protocols.

For information on registering for Open With, see Introduction to File Associations.

Start Menu and Quick Launch Bar

To become more discoverable to the user, applications can add shortcuts to various places in Windows. The most common place to add a shortcut is the Start menu. To appear in the list of programs in the Start menu for all users in Windows Vista, an application creates a shortcut in the hidden folder %ProgramData%\Microsoft\Windows\Start Menu\Programs. Commonly, an application adds a subfolder that contains the shortcut.

For browser and e-mail programs, the Start menu also presents two dedicated links outside of the program list canonically titled Internet and E-mail. After an application registers for those categories, the Default Programs framework can manage what is launched through those links.

To further increase discoverability, applications can also add shortcuts to the desktop and the Quick Launch bar. Applications should ask the user for permission during installation or on first run before adding an icon to the Start menu, desktop, or Quick Launch bar.

For more information, see these topics:

Application Installation and Defaults

Application installation procedures did not fundamentally change from Windows XP to Windows Vista, with the exception of a new guideline to take per-computer defaults at installation time, but not to set any per-user defaults until that user first runs the application. (See Application First Run and Defaults later in this document.) Applications should not take per-user defaults during installation because there are many situations where the person installing the application is not the intended user of that application.

During installation, an application should copy its binaries to the hard disk and write its ProgIDs to the registry. The application should also register for Default Programs and Open With at this time for every file association it should be a candidate to handle. The application can use the OpenWithProgIds subkey to register with Open With.

For more information, see these topics:

Application Upgrades and Defaults

Many applications have the ability to upgrade themselves over time. This upgrade procedure should not change the state of per-user defaults because that change would be unexpected to the user. However, it is acceptable for an application to check machine-level file associations and repair them if they have been corrupted.

Application First Run and Defaults

With the introduction of per-user defaults in Windows Vista, it is important that applications that contest for popular file extensions all provide a common user experience to claim these file extensions. Because these defaults are now set in the context of the user, they should present themselves as a default possibility only when the user runs the program after installation.

The guideline for establishing per-user defaults is this: When an application is first run for a specific user, that application should request user preferences for defaults and file associations for itself.

The recommended UI should provide two clear choices to the user:

  1. Accept all defaults the application would like to claim. This option might also set other default properties of the application such as privacy or automatic update settings. This option allows the application to claim all of its registered defaults.
  2. Customize by accepting or not accepting default selections and program settings individually. This option presents further UI that enables the user to make granular choices for their default options.

For more information, see Default Programs.

After an application registers with Default Programs, certain Windows Vista APIs become available to the application. For instance, it is reasonable for an application to check whether it is the default program when it is started. The IApplicationAssociationRegistration interface provides methods specifically to do this.

Any application that wants to claim defaults must first ask the user and should never claim defaults without permission. The user should be asked whether they want to make the application the default or leave things the way they are. There should also be an option not to be asked this question again.

For more information, see Default Programs.

Application Compatibility Tips

This section provides some application compatibility tips related to the Default Programs experience in Windows. For full references on Windows Vista application compatibility, please refer to Application Compatibility Cookbook World Wide Web link.

Avoid Triggering Per-User Virtualization

With the new user account control (UAC) environment, applications should always run with only standard user rights for the best customer experience. For security reasons, applications with a standard user privilege level are blocked from writing to certain parts of the registry and to certain system files. Windows Vista provides a temporary application compatibility (AppCompat) layer to help applications make the transition. Blocked write actions to the registry or system files are "virtualized" so that the application continues to run, but the sensitive areas of the system are not altered. However, applications should not rely on the AppCompat technology as a long-term solution. Instead, applications should use the many available tools to verify that they can run successfully under standard user rights. Some reprogramming of the application might be required to accomplish this, but it should be done in the interest of long-term compatibility.

For more information, see Windows Vista Application Development Requirements for User Account Control (UAC) World Wide Web link.

Avoid AppCompat Warnings or Blocks from the Program Compatibility Assistant)

The Program Compatibility Assistant (PCA) is introduced in Windows Vista. Its purpose is to make older programs with compatibility problems work better, in an automated manner. The PCA monitors programs for known issues. If an issue is detected, it notifies the user of the problem and offers to apply solutions that will be effective before the user runs the program the next time. To avoid seeing these warnings or blocks, ISVs should use the many available tools to ensure that their applications are compatible with Windows Vista.

For more information, see Application Compatibility Cookbook World Wide Web link.

Support for Previous Windows OS Versions

The Default Programs infrastructure is not available on any Windows operating system before Windows Vista. Therefore, when applications move to the new Default Programs infrastructure, they should retain their older code for application defaults to maintain compatibility with older versions of Windows. An application should run an OS version check as part of its installation to determine which code to run.

To support an upgrade from Windows XP to Windows Vista, applications should add all the registry entries required for Default Programs on Windows Vista even when they are installing on a computer running Windows XP. The registration will have no effect on a computer running Windows XP, but if the computer is later upgraded to Windows Vista the application will be already registered and able to take advantage of the framework.

For more information, see OSVERSIONINFO.