Windows 8 Integration

Intro

Microsoft Windows 8 will be the next version of the Windows operating system which is aimed at desktops, laptops, netbooks, tablets, servers, and media center PCs.

A major part of Windows 8 is the introduction of Metro-style applications which are based on a new application development and distribution framework. This document will summarize the changes and challenges of Metro-style development of 3rd party browsers.

Access to builds

Everyone doing work in this area should have access to early builds. What’s needed to accomplish this?

• Does MSDN or Microsoft Connect or any other program get us earlier access to Win8 or Win8 tools?
  • Download latest Win8 DP from Microsoft HERE
  • Instructions on creating a bootable USB key HERE

Windows Store

• Big question: would there be licensing and certification issues similar to iOS?
  • "Store policy and various runtime restrictions automatically exclude certain types of apps, which can only be implemented as desktop apps." (link)
• Automatic updating - working within the confines of Microsoft's update mechanism

Metro Architecture

• Unlike Desktop, Metro apps will ONLY be available through the Windows store.

• There are no overlapping windows, nor traditional popup windows, everything is chromeless, everything is designed to be consistent across applications.

• Some interprocess communication is possible within Metro, but it is very limited.

• Not possible to simply and easily port existing apps to Metro. A significant amount of conventional desktop functionality will not be available.

• A second app can be shown in Metro app with the snap state. It is shown side by side and you can determine the width of each window via a separator.

• The top and bottom edges are for per app toolbars. The left and right edge are reserved for system toolbars (This my require Fennec redesign if we end up using it for Metro).

• You can schedule popup notifications when your Metro app is not running.

Sandbox Security Model

Metro applications are run in a sandbox/jail environment called the "app container". Process Explorer can show this information for a given process. The sandbox ensures that no application can modify the system or access data from another application directly.

Most of the calls from the process to kernel are direct, but some of them like reading a file or accessing the webcam needs special permission. These calls are proxied through a broker that might ask the user for consent. Most resources that an app requires need to be specified as "capabilities" in a manifest file that is bundled with the binaries.

Language support

• Applications can be built in Javascript, C++, C#, or VB.NET
• WinRT is available in each language through the `Windows` namespace

C++

• Compiles to native code but has some extra syntax flare.

HTML and Javascript

• WinJS library provides access to WinRT
• "Chakra" engine uses metadata to generate js/html projections of WinRT objects dynamically

API Spec

WinRT / Win32 / COM

• General WinRT overview and porting guide Link
• Windows Runtime (WinRT) Link
• Win32 & COM support Link

Graphics

• Subset of Direct2D, Direct3D, DirectWrite drawing apis supported. Link

Networking

• Win32 WS* APIs Link
• WinRT Networking Link

Suspend/resume

• Most of this info comes from this video on Metro app suspension
• There is no multi-tasking of Metro apps: Only one app runs unsuspended at a time, apps are suspended when not in foreground
• Desktop is treated as one app; all other Metro apps are suspended when desktop is active
• Upon suspension, app gets notification that it is being suspended
  • At this point, app must save state because it could be terminated later without notice
  • App gets 5s to handle suspend, otherwise crashes
• During suspension
  • App is not scheduled by the NT kernel
  • No CPU, Disk, Network consumption
  • All threads suspended
  • App remains in memory
• App is instantly resumed when brought to foreground
• Suspension best practices:
  • Save state quickly (<5s)
  • Assume you will be terminated: Save user session data
  • Update app's tile
  • Release exclusive access to shared resources (files, devices, network, etc)
  • Save app data incrementally before suspend

Registering callbacks for suspend and resume (JS)

//Register for the Suspending event and call suspendingHandler when received
Windows.UI.WebUI.WebUIApplication.addEventListener("suspending", suspendingHandler); 

//Handle the suspending event and save the current user sesssion using WinJS sessionState
function suspendingHandler(eventArgs) {
  //We are getting suspended
}

//Register for the Resuming event and call resumingHandler when received
Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", resumingHandler);

function resumingHandler() {
  //We are getting resumed, in general do nothing
}

Activation Example (JS)

//Register handler for activation event
Windows.UI.WebUI.WebUIApplication.addEventListener("activated", activatedHandler);

function activatedHandler(eventArgs) {
  if (eventArgs.kind == Windows.ApplicationModel.Activation.ActivationKind.launch) {
    //Tile activation initialization logic here
  }
  else if (eventArgs.kind == Windows.ApplicationModel.Activation.ActivationKind.shareTarget) {
    //Share activation initialization logic here
  }
  //etc...
}

Live tiles

• Apps that have tiles implement the `Windows.Launch` contract
• Tile is specified by an XML file that follows a template (limited number of templates provided by Windows?)
• Tile (XML) can be updated while app is running
• Tile can be updated using push notifications
  • Push new tile XML to a URI provided by "Windows Push Notification Service" (WNS)
  • WNS pushes tile to user's device

Contracts

• There is a new concept called contracts for interconnection/sharing with different metro apps.
• Implementing contracts provides more integration with the OS (e.g. with the "charms" toolbar)
• Known contracts are:
  • Windows.BackgroundTasks
  • Windows.File
  • Windows.FilePicker
  • Windows.Launch - Apps that implement this get a tile in the Windows 8 Metro "desktop"
  • Windows.Protocol
  • Windows.Search
  • Windows.ShareTarget
• Information about which apps fulfill each contract is maintained in the registry
  • HKCU\Software\Classes\Extensions\ContractId
  • One key for each type of contract, subkeys are registrations for all extensions that implement that contract
• Apps can be activated through the contracts they implement
  • Event args provide context

Internet Explorer 10 vs Regular Metro Apps

On Windows 8, IE10 is both a metro app and as a regular desktop application. When run as a metro app it does things that are known to be off-limits for metro applications. This section details what we know so far about IE10 that is unexpected from a metro app.

Observations

• Metro instance loads WinRT dlls (Windows.UI.dll, Windows.UI.Immersive.dll) but aside from this, same executable, linked to the same standard libraries for both Metro and Desktop instances.
• Unlike standard Metro apps, IE runs in the desktop configuration (medium integrity parent process, multiple low integrity children).
• IE can be suspended according to PE.
• Security related arguments for a single browser within Metro fall flat considering Metro IE does not appear to be running within the sandbox.

Process Exploration and Security

The following investigation was done with Windows 8 build 8102 and Process Explorer of 9/20.

The image is a screenshot of the latest process explorer. The tree in the far left column is the process tree, with child processes indented from their parents. The second column is their process id, denoted as <pid> in what follows.

Process Explorer screenshot

It seems all metro processes are children from one single svchost.exe in this case <700>, which seems is some kind of souped up DCOM launcher. This makes sense because a lot of the machinery of Metro has been borrowed from COM. As its children, you can see a bunch of Metro apps. Here we have IE10 <4960>, Remote desktop client <5020>, Copper (a 3D game) <5112> and Labyrinth <3524>. Copper seems to be a native c/c++ metro app while Labyrinth seems to be an html5 app.

The other child processes of <700> are the RuntimeBroker <2784> which is in charge of accessing privileged data or devices on behalf of regular metro apps and wkspbroker which is the "Remote app and desktop connection runtime broker". To sum up, <2784> and <4948> are not metro apps but metro support infrastructure.

We shall limit the rest of the analysis to Copper and to IE because they are the closest to our scenario, but most of that follows will also apply to html5 or C# metro apps as well.

As it can be seen in the integrity column, all metro apps except IE10 (and its child) run in the AppContainer integrity level which is new to Windows 8. Very little is known about it except that it is engraved in the process token itself. As a medium integrity process, IE10 can do anything it pleases and it does not require the broker to do file access. For example, If the broker <2784> is terminated, one can still use IE10 without a problem. However, When Copper, running at AppContainer integrity, tries to save the process in the current level it crashes. Upon restarting Copper, the broker was automatically launched again.

In Windows Vista and Windows 7, all applications run are by default run with medium integrity. An application that is elevated from a UAC prompt is run at high integrity.

Another difference is that named kernel objects of an AppContainer process are in a different namespace. For example, in this case the regular 'interactive user' session is session 3 so a regular named object 'Foo' from a traditional desktop application will be "\Sessions\3\BaseNamedObjects\Foo" which is what we see for IE10, while for metro apps it would be:

"\Sessions\3\AppContainerNamedObjects\S-1-15-2-wwwwwwww-xxxxxxxx-yyyyyyyy-zzzzzzzz\Foo

Were w,x,y,z are are part of a unique SID which is neither the interactive user SID or the user logon SID. In fact, it seems to be some kind of per-application id.

The significance of that is that a good chunk of IPC mechanics become really cumbersome to bootstrap without being able from one process to create a pipe, semaphore, event, or sharedmem and from the other open it by name.

3rd Party Browser Requirements

In general, browser vendors would prefer access to the system similar to that of Internet Explorer 10. From all outward appearances IE is currently able to bypass security restrictions of the Metro sandbox by running as a medium integrity process, effectively running as a standard Windows desktop application with additional extensions which allow it to latch into the Metro interface.

If however this type of access is not made available, vendors feel changes should be made to the current restrictions which will facilitate the ability of 3rd parties to compete with Microsoft's products in this new environment. The following section describes areas or changes various 3rd party browser vendors need in order to provide a compelling browser experience within the Metro interface.

Memory allocation and sharing

(VirtualAlloc / HeapAlloc and friends)

Memory execution - Virtual* / Heap* apis are necessary for allocating executable memory (JIT). We have been successful in allocating memory using CreateFileMapping/MapViewOfFileEx, but based on comments by ms employees [1,2] it appears applications that attempt to do this will not pass Windows Store certification.

Shared memory - While it appears DuplicateHandle is available and passes validation, without an approved method of allocating shared memory, process creation and pipes for communication memory can not be shared between processes.

Pipes

(CreateNamedPipe, ConnectNamedPipe, DisconnectNamedPipe)

IPC - None of the current pipe apis passes validation. According to ms employee comments no IPC type mechanisms are currently accepted [3].

Processes

(CreateProcess)

The CreateProcess api currently does not pass validation.

Links

• [1] Larry Osterman and Steve Rowe comments on StackOverflow
• [2] Osterman's short answer on VirtualAlloc
• [3] Note the question by Klimax in http://blogs.msdn.com/b/larryosterman/archive/2011/09/16/what-has-larry-been-doing-for-two-years-and-why-has-the-blog-been-dark-for-so-long.aspx

Questions

• Is there added overhead in going through WinRT networking APIs compared to more direct socket calls? Networking looks doable but there are concerns about a performance disadvantage.

Hardware Configurations

Everyone working in this area needs hardware. MSDN says "any win7 hardware should work? Here's what MS has to say

What do we have experience with or recommend?

Computers and peripherals that work well with Windows 8:

• HP TouchSmart 9300 Elite
  • Multi-touch capable (up to two fingers)
  • Beefy enough to build code on it
  • Not very portable
• Samsung Series 7 Tablets
  • Relatively solid "classic" and "metro" performance.
  • Finger and stylus touch inputs.
  • Bulkier than android and ios tablets.

Computers and peripherals that DONT work well with Windows 8:

• Wacom Bamboo tablet
  • Current generation of drivers do not generate native touch events

Links

• Building Offline Experiences with HTML5 AppCache and IndexedDB
• Lap around the Windows Runtime
• Windows Runtime internals
• Bug 686835 - Windows 8 / Metro Support
• Building on/for Windows 8
• API for Metro style apps
• ARM support
• lack of inter-process communication support
• Reusing some existing code
• Capability SIDs
• App Container SIDs