Developing a Metro style-enabled desktop browser
August 16, 2012
Abstract
Windows 8 introduces a new programming paradigm called Metro style. Metro style apps offer a clean, polished user experience that push app experiences to the forefront, and immerse the user in a full screen environment that’s tailored to the user’s hardware and context. Windows 8 also continues to offer desktop app experiences as found in previous versions of Windows. In Windows 8, the browser that the user sets as the default for handling web pages and associated protocols may be designed to access both the Metro style experience as well as the traditional desktop experience. This type of browser is called a Metro style enabled desktop browser. This guide describes how to create such a browser. The information in this document applies specifically to browsers that will be made available to end-users as the default viewer for the http:// protocol and associated web pages and protocols on the x86/64 architecture.
This information applies to the following operating systems: Windows 8

Disclaimer: This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet website references, may change without notice. Some information relates to pre-released product which may be substantially modified before it’s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. You bear the risk of using it.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
© 2012 Microsoft. All rights reserved.

Contents
Presentations of browsers 3
User experience framing 3
Implementation 4
Installation 4
Sample “VisualElementsManifest.xml” file 6
Manifest schema 6
Register an Application User Model ID (AppUserModelID) 8
Declare a square tile for the Start screen 8
Declare a splash screen logo 9
Becoming the default browser 9
Tiles 9
Pinning secondary tiles 10
Activation (launch) 10
Contextual launch 11
Launching vs. switching 12
Activating the Metro style enabled desktop browser for file and protocol contracts 13
Invocation into desktop presentation 13
Launching other Apps via protocols 14
In-proc vs. Out-of-proc Activation Handling 15
Handling system activation on background session close 15
Windowing 15
UI Framework Guidance 17
Guidance for multi-process browsers 17
Touch Keyboard 17
App contracts 18
Search contract 18
Share contract 18
Play To contract 18
Print contract 19
Process Lifetime Management 19
Close gesture 19
Closing background sessions and cleaning up private browsing data 20
Completing downloads and uploads prior to suspend 20
Roaming browser application data 20
Register for roaming 21
Sync behavior 21
Syncing favorites / Internet shortcuts 21
Syncing typed URLs 22
Syncing browser history 23
Roaming other registry settings 25
Windows Runtime API Reference 25

Presentations of browsers
The desktop browser ecosystem is well established. Users expect that popular Windows 7 desktop browsers will continue to work on Windows 8, and that is the case. Beyond the desktop, Windows 8 introduces a new app programming model which enables development of apps that are touch optimized, behave in the manner customers expect (maximize battery life, emphasize reliability, adhere to customer preferences for privacy and potentially sensitive devices like GPS, handle system start-up and shutdown without changing the state or impacting other apps, etc.), take on the enhanced new look and feel of Windows 8, and integrate with the richness of the PC via contracts. Apps that do these things are said to participate in the Metro style user experience.
In Windows, a web browser may be built as a Metro style app, a desktop app, or a Metro style enabled desktop browser.
• Metro style app. A Metro style app adheres to the principles of the new app model– it runs in an App Container, uses APIs found in the Windows Software Development Kit (SDK) for Metro style apps, is packaged as an .appx file, and is made available via the Windows Store.
• Desktop browsers. Same model as Windows 7.
• Metro style enabled desktop browser. A desktop browser that chooses to participate in the new Metro style experience when the user has expressed preference for the browser to do so. Such a browser can provide HTML5 rendering for webpages and service HTTP / HTTPS requests. By definition, such a browser has full access to Win32 APIs for rendering HTML5, including the ability to use multiple background processes, JIT compiling, and other distinctly browser-related functionality (like background downloading of files). Desktop browsers typically run at medium or low integrity level.

This guide focuses on developing a Metro style enabled desktop browser.
User experience framing
The following design and user experience principles provide framing for how to think about web browsers in Windows 8:
• The user is in control of browser preference. Browser choice is one of personal preference, and Windows 8 continues to honor user selection. Users can select the default via a “new app installed” system notification, and they can also configure via other means, such as Set User Defaults (SUD).
• There is only one default browser on the system. Any and all browsers can register their intent to be considered as the default (http:// protocol and the other consolidated attributes which define a browser in SUD), and the user can select one browser as the default. This is the same model as Windows 7.
• A Metro style enabled desktop browser may participate in the Metro style user experience only if it is the default browser. Desktop apps (typically packaged as .MSI, medium integrity level) run in the desktop. Metro style apps (.appx packaged, run in App Containers, API set restricted to the Windows SDK for Metro style apps, acquired via the Windows Store) run in the Metro style experience. A Metro style enabled desktop browser can be thought of as a desktop browser that can also participate in the new Metro style experience. The restriction to limit Metro style user experience participation to the user’s default browser is rooted in preserving the Metro style user experience. Note that this limitation applies to all browsers, including Internet Explorer.

Implementation
The following sections detail the design and code required to build a Metro style enabled desktop browser.
Technology Description
Installation Update installation code to create correctly formatted tiles, splash screen, and other associated content which indicate to the system that the browser is a Metro style enabled desktop browser.
Becoming the Default Browser Understand the changes to how users select file and protocol handlers for apps in Windows.
Tiles Provide a square tile for the Start screen and implement execute commands for secondary tile invocation.
Activation (Launch) Implement the app activation contract to launch the browser in the Metro style user experience.
Windowing Understand the rules governing window creation in the Metro style user experience.
App Contracts Implement and participate in app contracts: Search, Share, Play To, and Print.
Process Lifetime Management Save and restore state in the Metro style user experience.
Roaming Browser Application Data Keep browser application data (e.g. settings) synchronized between multiple Windows 8 devices.
Windows Runtime API Reference A subset of Windows Runtime APIs are available for use by Metro style-enabled desktop browsers.

Note: For some of the Metro style-enabled desktop browser integration points you might need to write browser code that calls into Windows Runtime objects. This is particularly true for the Metro style presentation of the browser and App Contract integration. For the Metro style portions of the browser, you need a developer tool with C++11 support to provide support for the async pattern, which is prevalent in Windows Runtime use. Microsoft Visual Studio 11 Express has this level of support. You can download it from the Metro style apps Dev Center.

Installation
No change is required to browser discovery and acquisition mechanisms:
• Metro style enabled desktop browsers may be distributed via existing channels, for example, web download, network share, OEM pre-install, or systems management software.
• Metro style enabled desktop browsers may be deployed via existing desktop app deployment methods, for example, MSI packaged, Click-Once installer, or .ZIP archive extraction with file copy.

Note: We strongly recommend that you digitally sign all the installation executables, including those that might be used as “bootstrap files” during a Click-Once installation, with an Authenticode Certificate issued by a Certificate Authority (CA) that is a member of the Windows Root Certificate Program. For more information on this best practice and the role of Windows SmartScreen in Windows 8, see Protecting you from malware.
However, Windows must be able to identify that a browser is a Metro style enabled desktop browser, otherwise the operating system will assume that the browser is desktop-capable only and will treat it accordingly. This means no interaction with the Metro style user experience. A Metro style enabled desktop browser must perform the following:
• Author a “VisualElementsManifest.xml” file that adheres to the schema and example included in this document.
• Include the .xml file as part of the Metro style enabled desktop browser’s installation contents.
• Include the supporting files as referenced by the .xml file (e.g. tile logo, splash screen images, Resources.PRI file) as part of the Metro style enabled desktop browser’s installation contents.
• During installation, copy the .xml file to the same directory as the browser executable.
C:\Program Files\YourBrowser\browser.exe
C:\Program Files\YourBrowser\VisualElementsManifest.xml
• During installation, copy the supporting files to the same directory as the browser executable (or relative to it).
C:\Program Files\YourBrowser\browser.exe
C:\Program Files\YourBrowser\VisualElementsManifest.xml
C:\Program Files\YourBrowser\logo.jpg
C:\Program Files\YourBrowser\logosmall.jpg
C:\Program Files\YourBrowser\imagefile.jpg
C:\Program Files\YourBrowser\Resources.PRI
Note: Should you wish to update the resources associated with the browser after the initial install (for example: during an update), you must also update the app’s shortcut timestamp. Doing so signals Windows to reread and reload the visual elements.
• During installation, create a Start shortcut to your app populated with the following properties:
PKEY_AppUserModel_IsDualMode set as TRUE (VT_BOOL)
PKEY_AppUserModel_ID set as the browser’s AppUserModelID (VT_LPWSTR). For additional information relevant to this specific property, see Register an Application User Model ID (AppUserModelID), in this document.

Sample “VisualElementsManifest.xml” file

Note: Windows uses the DisplayName attribute under /Application/VisualElements for the tile and splash screen. The BackgroundColor value under /Application/VisualElements will also be used as the background color of the SplashScreen.
For more information about the property values, see Default Tile.
Manifest schema
The following XSD is used to validate your VisualElementsManifest.xml file:

Register an application user model ID (AppUserModelID)
A Metro style enabled desktop browser must register an explicit Application User Model ID (AppUserModelID) for itself. This ID must be provided under the progID registered with SUD. The AppUserModelID may not be longer than 64 characters. When running in the Metro style experience, this AppUserModelID is immutable by the running browser process.
The AppUserModelID should be specified in the shortcut properties for the app as created during installation. For more information about assigning an AppUserModeID, see http://msdn.microsoft.com/en-us/library/dd378459%28VS.85%29.aspx#where.
Note: Metro style enabled desktop browsers should not set an AppUserModelID at runtime when participating in the Metro style user experience (browsers may continue to do so when activating in the desktop). This is not supported in the new experience and can lead to unpredictable behavior.
Declare a square tile for the Start screen
During installation, a Metro style enabled desktop browser must communicate the details of its app tile. The tile assets that must be included are:
• Square tile logo
• At 1x (.75x and 1.4x plateaus are optional but highly recommended)
• Small Logo
• Background Color
• Foreground Text Value
• Short Name (optional – use only if the display name is too long to fit on a the tile on the Start screen)

For more information, see Creating and managing tiles, toast, and Windows push notifications.
Declare a splash screen logo
During installation, a Metro style enabled desktop browser must communicate the details of its splash screen logo. This is a png, jpg, or jpeg and must be specified at .75x, 1x, and 1.4x plateaus. These images must occur within a Package Resource Index (PRI). The PRI may be created using free tools included with the Windows Software Development Kit (SDK) for Metro style apps.
For more information about PRI, review the documentation for the ResourceManager Class.
Becoming the default browser
Browser registration must follow the best practices outlined on MSDN. For more information, see Default Programs. Upon installation, Windows presents the user with a system notification that enables selection of the browser as the system default. This notification appears when these conditions are met:
• At the end of browser installation, the browser installer calls SHChangeNotify with the SHCNE_ASSOCCHANGED flag to indicate to Windows that new protocol handlers have been registered.
• Windows detects that one or more new apps have registered to handle both http:// and https:// protocols and the user has not been notified yet. In other words, none of the following have been shown to the user: system notification advertising the app, OpenWith flyout containing the app, Set User Defaults (SUD) Control Panel page for the app.
Dismissing or ignoring the notification and/or dismissing the flyout without making a selection results in the default browser remaining unchanged. The user may also change the default browser via other operating system mechanisms, including SUD.
Tiles
In Windows, the start menu has been replaced by a Start screen of tiles.
If the default browser supports the Metro style user experience, the browser’s app tile (and secondary tiles, if they exist) will display in Start in a manner similar to Metro style apps (as defined by properties that were specified in the .XML manifest that was copied during browser installation). Otherwise, the tile will appear as a desktop app. Verbs appropriate to the Metro style user experience and desktop mode of the app will appear on the tile. The tile will appear in search results like any other tile. Other tile actions (re-arrange, pin/unpin, etc.) are no different for browsers than they are for other app tiles.
The default Metro style enabled desktop browser always appears as a square tile. Any secondary tiles belonging to the default Metro style enabled desktop browser also appear with Metro style user experience tile visuals.
Pinning secondary tiles
Secondary tiles enable users to promote interesting content and deep links – for example, a reference to a specific location inside of the pinning app – from Metro style apps onto the Start screen. A typical use of secondary tiles by a Metro style enabled desktop browser might involve surfacing the ability to create a tile that represents a link to a particular website important to the user, e.g. a “favorite”. For more information about using secondary tiles, see Creating and managing secondary tiles.
A Metro style enabled desktop browser may pin secondary tiles while running in the Metro style user experience. These tiles will be associated with the app that created them (the Metro style enabled desktop browser), the same as any other secondary tile.
While the secondary tiles’ parent Metro style enabled desktop browser app is the current default browser, those secondary tiles launch in the Metro style user experience and have Metro style visuals. If their parent app is no longer the default browser, those secondary tiles are treated the same as any desktop tile.
• The system examines the Application User Model ID of the app to verify the calling app is the current default browser.
• The app supplied arguments will be stored in the shortcut and supplied in the Arguments field of the LaunchActivatedEvent.

Attempts to call the secondary tiles APIs from any browser running in desktop mode will fail.
Activation (launch)
Metro style enabled desktop browsers are capable of activating in both the desktop and the Metro style user experience (the latter only when configured as the default browser). To support desktop activation, no changes are necessary. To support Metro style user experience activation, changes are required.
The following rules govern app activation:
• Desktop shortcuts, pinned taskbar icons, and other “desktop artifacts” activate the Metro style enabled desktop browser in the desktop.
• Tiles in the Start screen activate the browser in the Metro style user experience when the browser is the default. When the browser is not the default, tiles activate the browser in the desktop. This same behavior also applies to a browser’s secondary tiles.
• Browsers that wish to activate in the Metro style user experience for file and protocol contracts must call IApplicationActivationManager::ActivateForFile or IApplicationActivationManager::ActivateForProtocol in the implementation of their verb handler. Verb handlers must be implemented as a DelegateExecute handler. For more information about verb handling, see the FileActivatedEventArgs.Verb property.
• It is strongly recommended that browsers implement “contextual launching”. This means taking the calling app’s presentation (desktop or Metro style user experience) into account when determining the browser’s presentation (desktop or Metro style user experience) for activations originating from other apps,such as when a user clicks an http:// link in their mail app.
• Search contract activations always activate in the Metro style user experience. These activations can only occur if the browser is the user’s default. For more information, please reference the Search contract section of this document.

Contextual launch
Users expect a seamless experience when activating a browser via a link; for example, launching a browser by clicking on an http:// link in a mail or messaging app. When following a link within a Metro style app, most users expect a Metro style presentation of the linked content. Conversely, when following a link from a desktop app, most users expect a desktop style presentation of the linked content.
When the browser is activated, use the IExecuteCommandHost::GetUIMode() method to obtain the current UI context of the app or system component where the browser’s activation originated. In other words, this indicates the UI context of the caller of the launching API. The context is provided by the site chain, service ID SID_ExecuteCommandHost and IExecuteCommandHost::GetUIMode(). Use this information to provide the best browser presentation.

// site is the site pointer provided to the shell verb implementation
// via IObjectWithSite::SetSite(). bool IsImmersiveLauncher(IUnknown *site)
{
ComPtr commandHost; EC_HOST_UI_MODE hostUIMode; return SUCCEEDED(IUnknown_QueryService(site, SID_ExecuteCommandHost, IID_PPV_ARGS(&commandHost))) && SUCCEEDED(commandHost->GetUIMode(&hostUIMode)) && (hostUIMode != ECHUIM_DESKTOP);
}

The enumeration has three values:
• ECHUIM_DESKTOP – Desktop application launch
• ECHUIM_IMMERSIVE – Metro style application launch
• ECHUIM_SYSTEM_LAUNCHER – Start menu launch (includes Tile activation, typing a URL into the search box in Start, etc.)

We recommend that browsers provide a configurable setting to give users control over their preferred presentation experience. For example, a setting named “Choose how you open links”, with options a) Always launch Metro style, b) Always launch in the desktop, c) Let the browser decide, aka contextual (suggested default).
Follow these steps to implement contextual launch:
• Author a DelegateExecute verb handler that implements IExecuteCommand, IObjectWithSite, IInitializeCommand, IObjectWithSelection, and IExecuteCommandApplicationHostEnvironment.
• Register the handler in the registry under HKCR\{browser desktop AppID}\.exe
• Any shortcut that contains a PKEY_AppUserModel_ID value will cause Windows to first look for a verb handler registered for the shortcut’s target’s type registered under the AppUserModelID. Browser shortcuts will point at the browser’s executable file and thus must be registered for the ‘.exe’ type under the AppUserModelID. When the verb is invoked, it will be provided with the shortcut’s target and any arguments stored in the link (this includes arguments specified in secondary tiles).
• During launch, the implementation of IExecuteCommandApplicationHostEnvironment::GetValue is called. The browser should return which presentation to launch in, but it will likely need more information in order to make this determination.
• Use IUnknown_QueryService(_pSite, SID_ExecuteCommandHost, …) to obtain the IExecuteCommandHost implementation.
• Call IExecuteCommandHost::GetUIMode to discover the launch context. Use this information, along with the user configurable preference and information such as that provided to IInitializeCommand and IObjectWithSelection, to determine the presentation, either desktop or Metro-style. Return the value from the IExecuteCommandApplicationHostEnvironment::GetValue call.
• Return AHE_IMMERSIVE from the implementation of GetValue only if the browser is configured as the user’s default.

In all launch cases except launch via the browser’s tile(s) on the Start screen, the browser’s IExecuteCommand::Execute handler will get called and the browser must fully handle activation. In the case of the tile on the Start screen, if IExecuteCommandApplicationHostEnvironment::GetValue returns AHE_IMMERSIVE, Windows finishes activation of the browser in order to provide a consistent launch animation. IExecuteCommand::Execute will not be called in this case.
Register the DelegateExecute handler.
The following is an example of the registry entry:
HKCR\Example.Browser\.exe\shell\
(Default) = “open” open\command (Default) = “”
DelegateExecute = “{1e1946d6-5e51-4548-b7e8-033c60abffaf}”

In this example, “{1e1946d6-5e51-4548-b7e8-033c60abffaf}” is a handler CLSID that the browser provided.
Launching vs. switching
In the desktop case, it’s a common occurrence for the browser to already be running when a user attempts to activate it via the Start menu tile or file / protocol activation. Rather than creating a separate new instance of the browser for each activation, you should use the DelegateExecute handler to communicate with a running instance of the browser.
It’s recommended that browsers support, at a minimum, the “open” verb. Also, when a user chooses “Open new window”, the browser should open a new tab rather than a new instance of the browser. Browsers are suggested to implement a verb, e.g. “open new window”, corresponding to that common user action.
For more information about setting a state or parameter related to a verb or invoking the verb, see IExecuteCommand interface.
Activating the Metro style enabled desktop browser for file and protocol contracts
Browsers should implement their file and protocol associations as Execute Command verbs (see the Execute Command Verb Sample for an example) in a manner similar to tile launch. When directing the verb invocation into the Metro style user experience, browsers call a method on IApplicationActivationManager to activate in the Metro style user experience for the File or Protocol contract. The Application Activation Manager is a COM component identified by CLSID_ApplicationActivationManager. interface IApplicationActivationManager : IUnknown
{
…

HRESULT ActivateForFile( [in] LPCWSTR appUserModelId, [in] IShellItemArray *itemArray, [in, unique] LPCWSTR verb, [out] DWORD *processId);

HRESULT ActivateForProtocol( [in] LPCWSTR appUserModelId, [in] IShellItemArray *itemArray, [out] DWORD *processId); }

The ActivateApplicationForFile and ActivateApplicationForProtocol methods accept an IShellItemArray, which is the input to DelegateExecute verb implementations via IObjectWithSelection::SetSelection.
Note that IAplicationActivationManager API only works from medium integrity level processes (High IL will not work). Therefore, it is recommended that this object is CoCreated with CLSCTX_LOCAL_SERVER as this object is registered to run in the DLLHOST surrogate at Medium IL.
Invocation into desktop presentation
Metro style enabled desktop browsers must set an AppUserModelID at runtime when running in desktop mode by calling SetCurrentProcessExplicitAppUserModelId and providing the value specified under PKEY_AppUserModel_ID in the browser’s primary tile. This ensures that the AppUserModelID “link” between tiles and the Metro style enabled desktop browser is preserved.
Additionally, it should be noted that since secondary tiles are associated with the AppUserModelID of the browser’s primary tile, the browser must have the same runtime AppUserModelID as its primary tile.
When activating into the Metro style presentation, SetCurrentProcessExplicitAppUserModelId has no effect and therefore should not be called.
Note: If the Metro style enabled desktop browser is not currently selected as the user’s default browser, it can only launch in the desktop.
Launching other apps via protocols
It is common for web browsers to support launching apps through the windows file and URI scheme (sometimes referred to as protocols) association system using the ShellExecuteEx() API. It is strongly recommended that browsers use the AssocIsDangerous() API to safely handle activation of other apps on the system. It is also strongly recommended that browsers provide a consistent, predictable user experience when users select protocol links that cause the activation of a different Windows app.
The AssocIsDangerous() API identifies file types that have potentially dangerous content, including the ability to execute code. Browsers should discourage users from launching programs that are identified as dangerous by this API or mitigate the threats using the attachment execution services (AES) API.
The following steps are best practices:
• Use ShellExecuteEx() to launch the file types and URI schemes that are not natively handled by the browser
• Verify the source and integrity of files using digital signatures
• Verify the reputation of the particular file
• Inform the user about what app will be launched to handle the file or URI
• Require the user to confirm that the source of the launch is allowed to perform the action

ShellExecuteEx() has been extended to report information to the caller about the identity of the app that will be activated. The API provides the name of the process or CLSID of the handler that will be launched, the name of the app, and the publisher name and icon. This information should be used when constructing a user consent dialog, or when evaluating per application policy as managed by browser-specific settings.
Consistent with the guidance in the Contextual Launch section of this document, it’s recommended that browsers provide a configurable setting to give users greater awareness of the presentation experience of the to-be-invoked app. For example, use the information gathered by the extended ShellExecuteEx() API to populate a contextually appropriate dialog. In that dialog, indicate to the user what app will be launched and whether that app uses Metro style or desktop presentation. The CLSID can be used to distinguish Metro style apps from desktop apps. Metro style apps use CLSID_AppShellVerbHandler.
Lastly, for ShellExecuteEx() error cases, browsers must ensure that any resulting error dialogs remain visible to the user. For example, if the browser is participating in the Metro style experience and tries a file launch of a 64-bit executable on a 32-bit capable machine (an error condition), it’s possible that the error dialog from the ShellExecuteEx() call is displayed on the desktop. This is a problem because the browser cannot automatically switch focus to the desktop, which means the error dialog is hidden from the user’s view. Metro style-enabled desktop browsers must either disable the error UI by specifying SEE_MASK_FLAG_NO_UI (and handle the failure themselves) or specify SHELLEXECUTEINFO.lpClass = “Unknown” and lpVerb = “InvokeDefaultVerbInOtherProcess” in calls to ShellExecuteEx()In-proc vs. Out-of-proc Activation Handling.
You can implement the COM components that handle browser launch (the previous sections) either in-proc or out-of-proc.
In the in-proc case, a process provided by the system loads the browser’s COM components. In Windows 8, this process is openwith.exe. (In the future, the system provided process may change.) This process isn’t likely to be already running; therefore, the time it takes for openwith.exe itself to launch adds to the activation time of the browser.
NOTE: To debug your code that executes in-proc to this system-provided process, attach a debugger to openwith.exe.
In the out-of-proc case, the COM components that handle browser launch are implemented and hosted in the browser’s own binary, most likely the browser’s frame process. In most cases, starting the system-provided process is faster than starting the browser’s binary. But a browser could potentially see a performance benefit with an out-of-proc implementation in launch cases where the browser happens to already be running. For example, if the user opens a desktop window with the browser configured as the default, switches to a Metro style app, and then selects a link from within that app that redirects to an http:// address, the browser’s binary hosting the COM components is already running (the desktop browser window instance). In this example, choosing an out-of-proc implementation would likely result in a slightly slower initial browser launch case, but the subsequent re-activation would likely be faster than similar in-proc implementations because the small additional overhead is needed to start the system-provided process.
Handling system activation on background session close
As detailed in the section Closing background sessions and cleaning up private browsing data, there are circumstances where the system will activate the browser. Browsers must handle this activation mechanism.
NOTE: In this activation case, the browser’s executable is directly invoked as a desktop process with –BackgroundSessionClosed added as a command line parameter. As such, handling of this parameter must happen in the browser executable’s startup sequence and not in the IExecuteCommand verb handler.
Windowing
The Windows 8 Metro style user experience is designed around a number of principles related to immersion and consumption:
• Metro style apps run only in the Metro style user experience. Using the new windowing APIs, they cannot create windows in the desktop experience.
• The Metro style user experience is focused on a single app at a time, with multitasking, app switching, and notifications provided by the Metro style experience.
• Metro style apps are sized to fill available space in the Metro style user experience environment, with a static number of supported “views” (e.g. portrait, landscape, full screen).
• Ongoing activities in the desktop remain in the desktop environment.

A Metro style enabled desktop browser, configured as the user’s default, can choose to participate either in the Metro style user experience or the desktop, but not both from the same running process.
• The browser must first activate itself as a Metro style app; once this has been done and it is the user’s default browser, it will be identified as such by the system:
• A Metro style enabled desktop browser, when identified and activated as a Metro style enabled desktop browser, can create and manage windows in the Metro style user experience.
• Attempting to create a window in the Metro style user experience when not identified as a Metro style enabled desktop browser will fail.
• Attempting to create a desktop window when identified as a Metro style enabled desktop browser will succeed, but the Metro style enabled desktop browser will not be able to change focus (bring to foreground) nor manage any desktop windows. Any calls to SetForegroundWindow() or SetActiveWindow() will fail under these conditions. There is no automatic switching between the Metro style experience and the desktop.
• A Metro style enabled desktop browser may not call LockSetForegroundWindow(); any calls to the API will fail.
• Any calls to AllowSetForegroundWindow() may succeed if the Metro style enabled desktop browser is in the foreground, however this call will not facilitate any attempt to allow a desktop app or another Metro style app to move to the foreground.
• Any calls to EnableWindow() from a Metro style enabled desktop browser will fail if the target hWnd is not a Metro style user experience window.
• A Metro style enabled desktop browser may not attach input threads with any desktop app and vice-versa. Any calls to AttachThreadInput(idAttach, idAttachTo) where the idAttach and IdAttachTo parameters are neither both viewable in the Metro style user experience nor both desktop will fail.
• A Metro style enabled desktop browser may not change the foreground (even to a Metro style user experience window) when a desktop app, accessibility app or system component is in the foreground. Any calls to SetForegroundWindow() or SetActiveWindow() will fail under these conditions.
• Before activating as a Metro style app, it is advised that the browser destroy any visible desktop windows as these will be unmanageable once identified as a Metro style enabled desktop browser.
• Should a Metro style enabled desktop browser wish to launch a desktop app and have that app come to the foreground (for example, downloading and launching a file such as a PDF reader), it may do so by using ShellExecuteEx() and specifying the SEE_MASK_FLAG_LOG_USAGE flag in the fMask field. If this flag is not specified the desktop app will launch, but will not be able to come to the foreground. There is no automatic switching between the Metro style experience and the desktop.

UI framework guidance
Metro style-enabled desktop browsers may use the primary UI technology of their choosing for both the Metro style experience and the desktop, provided that technology is defined in the Windows 8 Platform (Desktop) SDK. More specifically, we recommend that browsers use DirectX as their primary rendering technology and framework. Metro style-enabled desktop browsers can’t use UI technologies intended for Metro style app use as defined in the Metro style app SDK (for example, the new XAML and HTML5 / JavaScript UI frameworks introduced in Windows 8).
Guidance for multi-process browsers
For browsers that have adopted a multi-process architecture – typically, a separation of the frame process from the tabs that display webpage content – create a single ICoreWindow managed by the frame process. We don’t recommend that you host each tab in its own separate top level ICoreWindow. Adopting such an architecture may lead to flickering of windows on tab switches, brief display of the Start background on tab creation / switching, and incompatibility with Narrator and other accessibility tools.

Touch keyboard
The touch keyboard is a system component that enables users of touch devices to input text. The touch keyboard is displayed when users need to input text, and it is out of the way when they don’t. The touch keyboard reacts to UI accessibility properties to determine whether a focused UI element is meant to receive text input. This approach allows the touch keyboard to define a specific set of rules for invocation and dismissal that are rooted in the UI elements that users interacts with.
Metro style-enabled desktop browsers must ensure text controls are marked with the correct accessibility properties (e.g. UI Automation TextPattern) to receive the correct touch keyboard behavior. This accessibility property requirement applies both to UI that displays in the Metro style experience and to UI that displays on the desktop. Additionally, for desktop UI (such as the address bar when the browser is displaying on the desktop), you must also call the EnableFocusTracking method.
For more info, see Input Hosting Manager and the Touch Keyboard.
NOTE: Don’t use the Windows 7 model of keyboard invocation, which relied on conventional APIs (e.g. ITextInputPanel) to display / hide the keyboard. That model is not compatible with Metro style presentations of browsers.
App contracts
Contracts are like agreements between Windows and Metro style apps, including Metro style enabled desktop browsers. They support some kind of user interaction and help users complete scenarios. Metro style enabled desktop browsers are encouraged to participate in app contracts, particularly Search, Sharing, PlayTo, and Print. Some browser-specific examples of the utility of contracts include playing music originating from a website on a connected (to the PC) stereo and/or sharing article content as viewed on a website with another Metro style app.
For more information, see Windows application contracts.
Search contract
Search is unchanged from Windows 7 in terms of defaults. Metro style enabled desktop browsers that are set as the user’s default may choose to (and are encouraged to) participate in the Search contract of the Metro style user experience. When a Metro style enabled desktop browser is not set as the user’s default browser, a tile entry for the browser will not appear in the search pane.
For more information, see Quickstart: Adding Search.
Share contract
Metro style enabled desktop browsers are encouraged to help users share website content with other Metro style apps on the system. A typical flow starts with the user selecting some content displayed in the browser – a video, a block of text, an image – and choosing the share charm to share the content with another app. When the user has selected an object and chosen to share, the browser should share that selection. In the absence of a currently selected object, the browser should share the URL to the webpage along with metadata such as the page title and description. Browsers should also consider implementing and sharing custom formats. For example, a differentiating feature (that would also enhance the user experience) might be to add extra entities to a user selection, such as a movie, and share that data as a custom format.
For more information, see Quickstart: Sharing Content.
Play To contract
The Play To contract provides the ability to stream HTML audio, video and images from websites to certified Play To devices. The typical scenarios are streaming a single video from a website, or streaming a playlist of audio/video elements. It’s up to the browser to identify and specify/update the media element that should be set as the Play To source.
The algorithm to set the Play To source is up to the browser and could rely on a combination of user input/selection, site developer specifying the source using a media element attribute, and/or other disambiguation heuristic when multiple media elements are present on the same page. For example, Internet Explorer 10 enables webpage developers to use the x-ms-xPlayToPrimary attribute to indicate an audio, video, or image is the default media source. Also, because Play To is enabled by default in Internet Explorer 10, the x-ms-xPlayToDisabled attribute can be used by a webpage developer to disable the functionality on the page. Other browser vendors may choose to provide similar vendor-specific attributes.
The typical flow starts with the user swiping the charms and selecting Devices. At this point the browser is asked to provide a Play To source. If a source is specified, available Play To target devices are shown in the Device charm. To synchronize device events with the media elements, the browser must register for device events from the Play To Manager.
For more information, see Streaming Media to Devices using Play To and the related Quickstart: Using Play To in apps.
Print contract
Browsers are encouraged to implement the print contract, to support simple and predictable printing experiences within the Metro style user experience. For more information, see: Quickstart: Adding simple print capability.
Process lifetime management
Metro style enabled desktop browsers are subject to the same Process Lifetime Management (PLM) rules as other Metro style apps. When drawing desktop windows and managing background downloads, browsers are subject to the process lifetime standards of desktop apps.
Close gesture
Users may choose to close a Metro style enabled desktop browser via operating system features such as the keyboard combination ALT+F4 or by using the close gesture. Users invoke the close gesture by “dragging” a representation of the window from the top of the app to the bottom of the screen. When the Metro style enabled desktop browser is active (not suspended, not in the background), painting via ICoreWindow, it will be sent a registered window message with the string “DefaultBrowserClosing” as it moves off screen during window close. The browser should use this message as a signal to prepare for termination after suspension is complete.
For example, a browser may send events to the active webpage, such as BeforeUnload and Unload when the DefaultBrowserClosing message is received. Some websites rely on events such as these to trigger specific behaviors, such as sending data back to a server to mark the end of a user session.
Note: Open browser dialogs, such as those originating from webpages, should not prevent the user from closing the browser. For instance, confirmation dialogs that sometimes show when a page handles the BeforeUnload event should be suppressed and not allowed to interfere with closing the browser. For more information, see Managing the Application Lifecycle.
Closing background sessions and cleaning up private browsing data
There are a few user affordances that allow for a user to close a Metro style browsing session without first bringing the browser window to the foreground.
• Pulling the thumbnail of the browser from the switch list to the bottom of the screen.
• Right-clicking the thumbnail of the browser from the switch list and choosing ‘close’.
• Pulling the browser from the back stack using the left edge and dragging the window to the bottom of the screen.
In such instances, the browser can’t run code before the app is closed. The browser’s window isn’t sent a “DefaultBrowserClosing” message.
Instead, Process Lifetime Management closes the browser and immediately reactivates it as a desktop process with the -BackgroundSessionClosed command-line argument, e.g. “examplebrowser.exe -BackgroundSessionClosed”. Use this opportunity to clean up data from the previous browsing session, particularly sensitive user data that may have been persisted to disk during a private browsing session. Don’t present a window or run other tasks. Exit as soon as the cleanup is complete. If no data cleanup tasks are required (for instance, if the browser doesn’t offer the private browsing feature), handle the activation argument and exit.
Completing downloads and uploads prior to suspend
Metro style enabled desktop browsers suspend when the user switches away from the browser and resume when the user switches back to it. There are a limited number of cases where the browser may postpone the act of suspension in order to complete a long running user task:
• Completing file uploads, such as an active upload via POST with a file attached or via XMLHttpRequest
• Completing file downloads

Browsers are strongly encouraged to leverage the background APIs in a manner consistent with Metro style apps. Doing so improves battery life by more efficiently consuming system resources. For more information, see Quickstart: Downloading and uploading files. Alternatively, Metro style enabled desktop browsers may use the PowerCreateRequest, PowerSetRequest, and PowerClearRequest functions as documented in the Power Availability Requests whitepaper. Note that these APIs are only callable from medium integrity level (or higher) processes. For more information, see Guidelines for managing app lifecycle.
Roaming browser application data
Users can easily keep their browser’s application data in sync across multiple devices when you support roaming. Doing so benefits the user by:
• Reducing the amount of setup work that the user needs to do for your browser on their second device.
• Enabling users to continue a task, such as composing a list, right where they left off, even on a different device. Windows replicates roaming data to the cloud and synchronizes the data to other devices where the user has installed the browser.

Windows limits the size of the application data that each app may roam. For this reason, it is a best practice to use roaming data only for user preferences such as favorites and browser history. For more information, see Guidelines for roaming app data.
Metro style enabled desktop browsers can sync the following:
• Favorites / Shortcuts
• Typed URLs
• History
• Up to 5 other registry based settings

Register for roaming
The following registrations are required in order to roam data:
• HTTP and HTTPS protocol registration.
• A registry key HKLM\Software\RegisteredApplications with the browser name and the path to Capabilities Registry Key (of type REG_SZ For example: Software\Example Company\Example Browser\Capabilities).
• A Start shortcut with PKEY_AppUserModel_IsDualMode set to TRUE (VT_BOOL).
• A registry key under HKLM\Software\Microsoft\Windows\CurrentVersion\SettingsSync\BrowserSettings. The key name should be the same as the browser name. No sub keys and values are needed under this.
• The Capabilities Registry Key should contain a subkey named “Roaming”. This is the location where data stores are registered.

Sync behavior
Under normal circumstances, application data will be uploaded within a few minutes of receiving a change notification. For performance reasons, however, the sync framework may delay upload of new history entries, in some cases up to 24 hours. When a sync causes a conflict the “last writer wins”.
Syncing favorites / Internet shortcuts
In order to roam favorites, create a registry key with the name “FavoriteUrls” under the browser’s roaming capabilities registry key. For example: HKLM\Software\Example Company\Example Browser\Capabilities\Roaming\FavoriteUrls. Then, create a registry value with name “KnownFolderID” of type REG_SZ that specifies the GUID for the known folder where the user’s favorites are stored. Internet shortcuts within this folder and subfolder are roamed. The shortcuts must be created using the APIs as explained in Internet Shortcuts.
Optionally, you can register to roam the order of shortcuts. To accomplish this, create a registry value under “FavoriteUrls” capabilities with name “OrderRegPath” that specifies the root registry key under HKCU containing the order information for the top level “Favorites” folder and all sub folders. For example: Software\Example Company\Example Browser\FavoritesOrder.
For the order of shortcuts in the top level “Favorites” folder, the above registry key can contain a registry value with the name “Order” and type REG_BINARY with a value of the browser’s choosing. For the order of shortcuts in any subfolders, this registry key must contain corresponding sub keys mirroring the folder hierarchy (again, with the name “Order” and type REG_BINARY).
For example, if the favorites folder is %LOCALAPPDATA%\Example Company\Example Browser\Favorites\Sub Folder1\Sub Folder2, then the order information for the root favorites folder must be in a registry value under HKCU\Software\Example Company\Example Browser\FavoritesOrder, the order information for the first sub-folder (…\Favorites\Sub Folder1) must be in a registry value under HKCU\Software\Example Company\Example Browser\FavoritesOrder\Sub Folder1, and so on.
Watch for changes to the favorite’s folder before refreshing the browser UI representation of the user’s favorites. When a shortcut is roamed for the first time, an additional property {FMTID_Intshcut, PID_IS_ROAMED } of type VT_BOOL and value VARIANT_TRUE is added. Set the value to VARIANT_FALSE once the browser has processed the update.
Additionally, Windows sends an extended shell change notification SHCNE_EXTENDED_EVENT of type SHCNEE_ORDERCHANGED and the PIDL of the folder in which the shortcut was changed. Browsers can listen for this notification to refresh the favorites order following roaming.
Syncing typed URLs
In order to sync typed URLs, create a registry key with the name “TypedURLs” under the browser’s roaming capabilities registry key. For example: HKLM\Software\Example Company\Example Browser\Capabilities\Roaming\TypedURLs. Then, create a registry value with the name “URLsRegPath” of type REG_SZ that specifies the path (within HKCU) that contains the URLs in key value format. For example:
HKCU\Software\Example Company\Example Browser\TypedURLs
Name Type Value url1 REG_SZ http://www.microsoft.com

url2 REG_SZ http://msdn.microsoft.com

…

Windows roams 50 of the user’s most recently accessed URLs. If a user has more recent entries, browsers may choose to store the time when each of the URLs was typed; Windows uses this information to ensure that the most recently typed URLs sync first. To do this, create a registry value with the name “URLsTimeRegPath” of type REG_SZ that specifies the path (within HKCU) that contains the URL’s typed time. For example:
HKCU\Software\Example Company\Example Browser\TypedURLsTime
Name Type Value url1 REG_BINARY FILETIME, in UTC, of the time when the URL was typed in the browser url2 REG_BINARY FILETIME, in UTC, of the time when the URL was typed in the browser
…

Running instances of the browser receive a window message “WM_SETTINGCHANGE” with a wParam value of “0” and an lParam value of “TypedUrlsRoamed”. Specify the window class Windows should send the message to by creating a registry value of name “WindowClassesToNotify” of type REG_SZ and value equal to the name of the window classes, separated by comma.
Syncing browser history
The following registrations are required in order to sync browser history:
• Implement a shell folder and register it as a KNOWNFOLDER. When the user’s browsing history changes, call SHChangeNotify to indicate that the folder contents have changed.
• Store URL history in a WinInet cache using a browser-specific prefix ending with a colon. For example, the Contoso browser might use the prefix “Contoso:” when storing URLs in a WinInet cache.

In order to sync browser history, create a registry key with the name “WinInet” under the browser’s roaming capabilities registry key. For example: HKLM\Software\Example Company\Example Browser\Capabilities\Roaming\WinInet. Then, create a registry value with the name “KnownFolderID” of type REG_SZ that specifies the shell folder GUID. Also, create a registry key value with the name “WinInetPrefix” of type REG_SZ and value equal to the name of the browser-specific prefix, ending with a colon (:).
For more information about using WinInet caching APIs, see Caching.
Store the URL in the format “Prefix: username@URL” where “username” is the value returned by the GetUserName() function. For example, Contoso: user@http://www.microsoft.com/en-us/default.aspx
The CommitUrlCacheEntry function allows a browser to store a list of URLs that have been accessed and associate each with a local copy of the data that was last received. It also allows the browser to store header information (in the lpHeaderInfo parameter). In order to roam history data, the lpHeadInfo parameter must contain a serialized property store instead of the header info. This is done by using PSCreateMemoryPropertyStore to create a store and saving the browser’s properties into it. Then, use IPersistStream::Save to serialize the property store into a byte array in memory. Finally, call CommitUrlCacheEntryA and pass the byte array for the lpHeaderInfo field to store the property store for that URL.
Note: A browser can append arbitrary bytes to the end of the lpHeadInfoStream to store local data that should not be altered or roamed by Windows.
Retrieve binary history data by performing the inverse: use GetUrlCacheEntryInfoA, remove the prefix and username from the returned URL, and then use PSCreateMemoryPropertyStore and IPersistStream::Load to convert the lpHeaderInfo back into an IPropertyStore. The ANSI versions of other WinINet caching APIs such as FindFirstUrlCacheEntryA and FindNextUrlCacheEntryA can also be used to enumerate the cache in a similar manner.
Note: Roaming history requires use of the ANSI WinInet cache APIs to persist binary data. If a URL contains non-ANSI characters, encode the URL using well-known schemes such as percent-encoding.
Detect that new URLs have been added to the cache via roaming by checking the {FMTID_InternetSite, PID_INTSITE_ROAMED} property.
Value of PID_INTSITE_ROAMED Description
Value not set or PIDISR_UP_TO_DATE This cache entry has not been modified by roaming.
PIDISR_NEEDS_ADD This cache entry was added to the cache by roaming. Set PIDISR_UP_TO_DATE once processing of the entry is complete.
PIDISR_NEEDS_UPDATE This cache entry already existed on the local machine, but it was updated by roaming. Set PIDISR_UP_TO_DATE once processing of the entry is complete.
PIDISR_NEEDS_DELETE Roaming detected that this cache entry should be deleted. For example, the user may have cleared his or her browser history. Delete the entry using DeleteUrlCacheEntry.

The following rules govern conflict resolution for roaming browser history:
• The property stores in the lpHeaderInfo stream are merged such that the most recently changed values are preserved.
• If the property store contains the public “visit count” property {FMTID_InternetSite, PID_INTSITE_VISITCOUNT}, the largest of the values is preserved.
• If there is additional data in the local cache entry’s stream after the serialized property store, the local data is preserved.

The following rules govern what history entries roam:
• Roam: URLs with http:// or https:// schemes; Cache entries of type “URLHISTORY_CACHE_ENTRY | NORMAL_CACHE_ENTRY”; The 1000 most recent updated history entries
• Not Roam: URLs to images; Cache entries that do not contain a serialized property store in their lpHeaderInfo; Properties in the serialized property store that would require deserialization (such as VT_UNKNOWN, VT_STREAM, or VT_STORAGE); History entries with more than 2KB in their lpHeaderInfo structure

When the browser has updated or added any history data, use the SHChangeNotifyAPI and send a change notification for the registered known folder. Conversely, when Windows has concluded roaming a user’s history, a timestamp of the most recent operation is written to the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\SettingsSync\Namespace\BrowserSettings\WinInet-browsername!LastRoamed. Compare this value with the last known time that entries were detected to determine if history has changed. Alternatively, running instances of the browser will receive a window message “WM_SETTINGCHANGE” with a wParam value of “0” and an lParam value of “WinINetRoamed”. Specify the window class Windows should send the message to by creating a registry value of name “WindowClassesToNotify” of type REG_SZ and value equal to the name of the window classes, comma separated, in the \Capabilities\Roaming\WinInet registry key. Finally, the browser may register a command-line to be invoked by the roaming framework after new history has been downloaded. Specify this command-line by creating a registry value of name “InitialApplyCommandLine” and type REG_SZ in the \Capabilities\Roaming\WinInet registry key.
Roaming other registry settings
In addition to roaming user favorites, typed URLs, and browser history, browsers may also sync up to a maximum of five other registry keys. Create a registry key with the name of your choosing under the browser’s roaming capabilities registry key. For example: HKLM\Software\Example Company\Example Browser\Capabilities\Roaming\NewKey. Then, create a registry value named “RegistryRoot” of type REG_SZ that specifies the path to the key under HKCU that should be roamed.
Creating a registry value of name “FilterIn” of type REG_SZ and value containing a comma separated list of registry values lets you specify an inclusion list for roaming. Any values not specified that appear under the “RegistryRoot” will not be roamed. Conversely, creating a registry value of name “FilterOut” type REG_SZ and value containing a comma separated list of registry values to exclude lets you specify an exclusion list for roaming. All values under the “RegistryRoot” will be roamed except for those specified in the “FilterOut” value.
Each time a registry key is roamed, running instances of the browser receive a window message “WM_SETTINGCHANGE” with a wParam value of “0” and an lParam value of “Roamed”. Specify the window class Windows should send the message to by creating a registry value of name “WindowClassesToNotify” of type REG_SZ and value equal to the name of the window classes, comma separated, in the \Capabilities\Roaming\ registry key.
For more information, see Application Data.
Windows Runtime API reference
A subset of Windows Runtime APIs are available for use by Metro style-enabled desktop browsers.
The list of runtime classes as documented in the Windows 8 API reference on MSDN.

Additionally:
Windows.ApplicationModel.Activation.SplashScreen
Windows.ApplicationModel.Core.CoreApplicationView
Windows.ApplicationModel.DataTransfer.DataPackage
Windows.ApplicationModel.DataTransfer.DataPackagePropertySet
Windows.ApplicationModel.DataTransfer.DataRequest
Windows.ApplicationModel.DataTransfer.DataTransferManager
Windows.ApplicationModel.DataTransfer.HtmlFormatHelper
Windows.ApplicationModel.DataTransfer.StandardDataFormats
Windows.ApplicationModel.Package
Windows.ApplicationModel.Search.LocalContentSuggestionSettings
Windows.ApplicationModel.Search.SearchPane
Windows.ApplicationModel.Search.SearchPaneQueryLinguisticDetails
Windows.ApplicationModel.Search.SearchPaneSuggestionsRequest
Windows.ApplicationModel.Search.SearchPaneSuggestionsRequestDeferral
Windows.ApplicationModel.Search.SearchSuggestionCollection
Windows.Data.Xml.Dom.DtdEntity
Windows.Data.Xml.Dom.DtdNotation
Windows.Data.Xml.Dom.XmlAttribute
Windows.Data.Xml.Dom.XmlCDataSection
Windows.Data.Xml.Dom.XmlComment
Windows.Data.Xml.Dom.XmlDocument
Windows.Data.Xml.Dom.XmlDocumentFragment
Windows.Data.Xml.Dom.XmlDocumentType
Windows.Data.Xml.Dom.XmlDomImplementation
Windows.Data.Xml.Dom.XmlElement
Windows.Data.Xml.Dom.XmlEntityReference
Windows.Data.Xml.Dom.XmlLoadSettings
Windows.Data.Xml.Dom.XmlNamedNodeMap
Windows.Data.Xml.Dom.XmlNodeList
Windows.Data.Xml.Dom.XmlProcessingInstruction
Windows.Data.Xml.Dom.XmlText
Windows.Data.Xml.Xsl.XsltProcessor
Windows.Foundation.Collections.PropertySet
Windows.Foundation.PropertyValue
Windows.Foundation.Uri
Windows.Foundation.WwwFormUrlDecoder
Windows.Globalization.Language
Windows.Graphics.Printing.OptionDetails.PrintTaskOptionDetails
Windows.Graphics.Printing.PrintManager
Windows.Graphics.Printing.PrintTask
Windows.Graphics.Printing.PrintTaskOptions
Windows.Graphics.Printing.PrintTaskRequest
Windows.Graphics.Printing.PrintTaskSourceRequestedArgs
Windows.Media.PlayTo.PlayToManager
Windows.Media.PlayTo.PlayToSource
Windows.Networking.NetworkOperators.ProvisioningAgent
Windows.Security.Credentials.PasswordCredential
Windows.Security.Credentials.PasswordVault
Windows.Storage.AccessCache.AccessListEntryView
Windows.Storage.AccessCache.StorageApplicationPermissions
Windows.Storage.AccessCache.StorageItemAccessList
Windows.Storage.AccessCache.StorageItemMostRecentlyUsedList
Windows.Storage.DownloadsFolder
Windows.Storage.FileIO
Windows.Storage.FileProperties.BasicProperties
Windows.Storage.FileProperties.DocumentProperties
Windows.Storage.FileProperties.ImageProperties
Windows.Storage.FileProperties.MusicProperties
Windows.Storage.FileProperties.StorageItemContentProperties
Windows.Storage.FileProperties.VideoProperties
Windows.Storage.KnownFolders
Windows.Storage.Pickers.FileExtensionVector
Windows.Storage.Pickers.FileOpenPicker
Windows.Storage.Pickers.FilePickerFileTypesOrderedMap
Windows.Storage.Pickers.FilePickerSelectedFilesArray
Windows.Storage.Pickers.FileSavePicker
Windows.Storage.Search.StorageFileQueryResult
Windows.Storage.Search.StorageItemQueryResult
Windows.Storage.StorageFile
Windows.Storage.StorageFolder
Windows.Storage.StorageStreamTransaction
Windows.Storage.StreamedFileDataRequest
Windows.Storage.Streams.Buffer
Windows.Storage.Streams.InMemoryRandomAccessStream
Windows.Storage.Streams.RandomAccessStream
Windows.Storage.Streams.RandomAccessStreamReference
Windows.UI.ApplicationSettings.SettingsCommand
Windows.UI.ApplicationSettings.SettingsPane
Windows.UI.ApplicationSettings.SettingsPaneCommandsRequest
Windows.UI.Core.CoreAcceleratorKeys
Windows.UI.Core.CoreDispatcher
Windows.UI.Core.CoreWindow
Windows.UI.Core.CoreWindowDialog
Windows.UI.Core.CoreWindowFlyout
Windows.UI.Input.EdgeGesture
Windows.UI.Notifications.BadgeUpdateManager
Windows.UI.Notifications.BadgeUpdater
Windows.UI.Notifications.ToastNotification
Windows.UI.Notifications.ToastNotificationManager
Windows.UI.Notifications.ToastNotifier
Windows.UI.Popups.MessageDialog
Windows.UI.Popups.PopupMenu
Windows.UI.Popups.UICommand
Windows.UI.Popups.UICommandSeparator
Windows.UI.StartScreen.SecondaryTile
Windows.UI.ViewManagement.ApplicationView
Windows.UI.ViewManagement.InputPane