title: How are WinRT / Metro apps restrictions enforced?
body: <p>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.</p>
  
  <p>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?</p>
  
  <p>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.</p>
  
  <hr>
  
  <p>Edit: According to <a href="http://mail.python.org/pipermail/python-dev/2012-January/115426.html" rel="nofollow">this thread</a>, 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)...</p>