Application Compatibility: Default Programs
Default Programs
Brief Description
Default Programs has a new infrastructure to manage per-user file and protocol associations designed with contentious applications in mind. Applications need to register in order to use the functionality of Default Programs. Be aware that Default Programs will receive high visibility in Windows Vista® and Windows Server® 2008 and beyond and make certain tasks much easier for applications to code and maintain.
Remedies
Windows Vista and Windows Server 2008 provide a new set of functionality for applications to take advantage of: Default Programs. Default Programs was designed to help users make choices about their default behaviors. A large part of this design is that defaults in Windows Vista and Windows Server 2008 and beyond will be primarily controlled at the per-user level instead of the per-machine level. This control allows much more flexibility for the multi-user computer environment that is expected to become the standard. Part of the change is adding a new centralized UI for the user, but the other part is giving ISVs the tools they need to help a user express choice. Default Programs gives an application:
A simplified process for taking defaults.
Per-user file and protocol associations.
A programmatic way to check for defaults.
Common Windows UI to reuse.
Advertising area within Windows.
This functionality was primarily designed for contentious applications, which are applications that want to be the default for file types such as MP3 and JPEG or protocols such as HTTP and MAILTO. Applications that primarily deal in their own protocols and file associations will not typically need to use this new functionality since they do not have to worry about other applications overriding them. Applications that are not contentious will behave and install as they do in Windows XP®. However, any application can take advantage of the new Default Programs.
The functionality of Default Programs functionality is built into the Operating System as a series of Control Panels and open APIs. For an application to use the control panels or APIs, it needs to register at installation time to be part of Default Programs by writing a specific schema. This registration will allow the application to show up in the Default Programs control panels so a user can restore the applications default file associations and protocols at any given time.
Once an application has registered with Default Programs, the application can take advantage of new functionality provided through APIs. Default Programs provides APIs to:
Restore all registered defaults.
Restore single registered default.
Query for the owner of a specific default file association/protocol/start menu canonical.
Launch Defaults UI for a specific application.
Clear all per-user associations.
The Default Programs work is intended to make it very easy to express user choice post install and provide applications a simple framework to contend for defaults and claim them.
Why Use Default Programs?
High-level points:
Default Programs helps applications get discovered.
The underlying architecture that allowed all administrators to write to HKEY_Local_Machine (HKLM) is changing for Windows Vista and Windows Server 2008.
Default Programs allows applications to maintain Windows XP parity process flows while changing very little code.
Claiming only machine-level defaults will not always give the desired results.
There is an obvious consumer gain for contentious applications using the Default Programs framework, but there is also a significant gain for the application to use Default Programs.
Default Programs provides a rich UI experience for registered applications to advertise its features to the user. In addition, applications that are digitally signed with a URL will be able to display that URL and allow users to easily navigate back to its home Web site and see what other applications and enhancements the company offers.
Using the new API set also significantly reduces the development cost for new applications. Almost all contentious applications monitor or check to see if they are the default. With the new API set, this check can be done in a single API call instead of crawling the registry, which was the method in previous versions of the OS.
Using the new API set also helps applications to function correctly in the new world with UAC (User Account Control). UAC is implemented by making an administrator look like a standard user to the system, which means that an administrator cannot normally write to HKLM in Windows Vista and Windows Server 2008 and beyond. This change is done so processes cannot act on the administrator’s behalf without knowledge. Installation will typically always be elevated because there is an experience for that, but for applications that want to be able to claim defaults after installation, they need to claim the defaults on the per-user level instead of the per-machine level. Switching to the new API set implements this behavior automatically. Applications that try to claim per-machine defaults after installation will fail.
The other strong reason to update an application to use Default Programs is to consistently achieve the desired results. File and protocol associations are derived from a hierarchical structure in the registry. Part of this structure dictates that per-user defaults will always be chosen over per-machine defaults. This precedence means that if an application decided to build elevation points in its code to claim defaults by writing to HKLM as in Windows XP, it would not always achieve the desired result. As soon as another similar application is installed and uses the Default Programs APIs that take per-user file and protocol associations, the previous application would no longer be the default because per-user defaults have a higher precedence.
Default User Checklist
Registers correctly for Set Program Access and Defaults (SPAD)
Registers correctly for Program Defaults
Registers correctly file associations, protocol handling, Open With, Start menu, and Quick Launch
Follows guidelines during installation (sets per-machine registration, does not take defaults)
Follows guidelines during first run (asks user for settings, file associations, and so on)
Does not take defaults during installation or upgrade
Correctly self-checks for default user permission before taking default
Never triggers virtualization
Has no application-compatibility warnings or blocks (from Program Compatibility Assistant)
Continues to work correctly in Windows XP
Uses the OS UI for file associations, protocol handling, and so on
Uses signed code (URL in Program Defaults)
Links to Other Resources
Default Programs (watch video)