How are WinRT / Metro apps restrictions enforced?

Question

The new Metro style / WinRT apps in Windows 8 have certain restrictions as to which APIs you can call. Also, you have to use asyncronous techniques and your app has to be pauseable, etc.. I'm wondering how, and if all of this is enforced.

Are the new Metro apps simply execuable programs, or are they something else (e.g. more like COM controls, with a set of defined interfaces)? How are the API restrictions enforced, at compilation, at runtime (via sandboxing etc.) or just via Windows Store policy (similar to the situation in iOS)? If I was feeling devious, could I e.g. get a handle to the screen and manipulate the interface, add floating windows on top, launch something in the background, or otherwise break out of the confines of Metro?

One reason I'm asking is that I'm looking into creating a WinRT library for Python, so that one could use it for writing Metro apps. However, the Python core obviously uses a lot of non-WinRT API calls, so this might be doomed from the beginning. I'd also like to get a feel for the anatomy of Metro apps in general.

---

Edit: According to this thread, you have all the functions of the C runtime available. It seems like you can compile stuff that calls forbidden functions, but the "application verifier" complains. I'm wondering if you could just run such a hybrid app, if you don't care about the Store (and maybe make it Store compatible later by writing workarounds for the forbidden functions)...

Answer 1

There are (at least) two separate sets of technical restrictions on what a Metro style Windows Store app can do.

The first is a set of security restrictions: Windows Store apps run with low privileges, and thus are limited in how they are permitted to interact with the rest of the system. For example, a Windows Store app cannot access arbitrary locations in the filesystem, it can only access files in a predefined set of locations, and files to which the system expressly gives access. You cannot violate these security restrictions (if you could, that would be a rather problematic operating system bug).

The second set of restrictions is the API partitioning. Windows Store apps are only permitted to call system functions that are present in the App Partition. The documentation for each system function on MSDN specifies whether the function is present in the App Partition. You can also find out by looking in the header file that defines the function: functions are conditionally defined depending on the API partition targeted by the project: the WINAPI_FAMILY macro controls this (see winapifamily.h in the Windows SDK for more information).

If you call an "unapproved" function, the results are undefined. It might appear to work; it might fail catastrophically. It might appear to work fine today and fail catastrophically tomorrow (or after a Windows update is applied, or with the next version of Windows).

The API partitioning is enforced in various ways. The headers are constructed such that it is difficult to call an unapproved function. If you define the function yourself or change the WINAPI_FAMILY, your app will fail the Windows App Certification Kit (WACK) process. My understanding is that the CLR prohibits calls to unapproved .NET functionality at runtime, though I am less familiar with the .NET restrictions. In any case, my understanding is that if your app calls an unapproved function, you cannot submit it to the store, per the "Windows 8 app certification requirements" (please read those requirements yourself, though; I have not read them in detail and I certainly can't interpret them for you).

If you don't care about submitting your application to the Windows Store or just want to write some test apps or play with WinRT, then there's nothing stopping you from trying to call unapproved functions. For example, I find it is useful to create a console window for debugging purposes. That appears to work fine, and I don't much care that it fails Windows Store certification since it's for debugging and testing only.

Answer 2

You have a limited part of the .net api available:

The .NET Framework provides a subset of managed types that you can use to create Metro style apps for Windows using C# or Visual Basic. This subset of managed types is called the .NET for Windows Store apps and enables .NET Framework developers to create Metro style apps within a familiar programming framework. Any types that are not related to developing Metro style apps are not included in the subset.

You use these managed types with types from the Windows Runtime API to create Metro style apps. Typically, you won't notice any differences between using the managed types and the Windows Runtime types except that the managed types reside in namespaces that start with System, and the Windows Runtime types reside in namespaces that start with Windows. Together, the .NET for Windows Store apps and the Windows Runtime provide the complete set of types and members available for developing Metro style apps with C# or Visual Basic.

There are app store requirements.

3.1 You must use only the Metro style APIs to implement the features of your Metro style app We describe these APIs in the Metro style apps API reference. Your app may only depend on software listed in the Windows Store.

Apps are sandboxed.

In short, you must you the api provided.

Answer 3

They aren't standard executables. You're restricted to a subset of .Net 4.5 to create the applications which doesn't let you (or rather, makes it extremely difficult to) do anything that MS don't want Metro apps doing. They're pretty heavily sandboxed as well.