Notes from BUILD – Day 1 – Big Picture Session 2 Part 1 – Ales Holecek on the WinRT APIs

This is part of a transcription of my notes from Microsoft’s recent BUILD conference in Anaheim, CA, minus anything that might be considered Red Gate confidential. Thus, they’re somewhat unstructured, sometimes ramble off-topic, and often contain dodgy grammar. My own commentary and observations will generally be italicised so you can easily distinguish it from the reporting on what actually happened. Much has already been said about this conference, and about Windows 8, but I hope you find these useful. Please feel free to comment or ask questions and I’ll be happy to answer them as best I can.

Ales Holecek is a Distinguished Engineer, Windows Developer Experience at Microsoft Corporation:

The new Windows Runtime (WinRT) APIs are part of a new app execution environment for Metro apps. They are OO, and are a direct binary call – basically a vtable dispatch – with very low overhead.

They are designed to be consistent, and to provide the right APIs. Moreover you can use your existing skills and knowledge to use them since you can access them from the programming language of your choice, be that C#, VB, C++, or JavaScript/HTML5.

WinRT is part of the OS, not part of a separate framework. It does however include reflection to support dynamic languages.

Demoed a HelloWorld grid app written in C++. Showed the XAML for the page, MainPage.xaml, which is obviously new for C++ – note that Metro apps are page based rather than form based.

The XAML runtime library has been reimplemented in native code, meaning that calls are now basically “push this pointer, then do this vtable dispatch”.

Made some comment about C++ portability which I was a little sceptical of because, at the very least, you’re going to need to recompile to run your app on ARM. Of course, C++ developers have always had a subtly different definition of portability from people working in the managed world.

Showed how you could take an external library, in this case boost, include it in your C++ project, and make it “just work”.

WinRT does not include the full Win32 API, for example, there is no overlapping windows support in the Metro SDK, since Metro doesn’t allow windows to overlap. There’s no GDI either – the only way to render is to use DirectX.

The surface of the WinRT APIs is exposed in such as way as to put XAML and HTML5 on an equal footing with respect to the Metro UI.

Showed a quick C# WinRT demo.

In WinRT, if an operation might take more than 50ms, the API for the operation will be async – many of the APIs are therefore async.

WinRT feels natural to use from C#, and offers rich access to the device, OS, and services.

The new “App Execution Engine”:

  • Much of this is implemented in the kernel
  • All Metro apps (but not Win32 apps) run in this environment
  • Provides a set of “brokered APIs”
    • You must request permission to execute these APIs in the .appxmanifest file associated with your application
    • Brokered APIs provide operations that could affect
      • System integrity
      • User data integrity
      • Or, have security implications
    • Generally there shouldn’t be a problem with any of the above if the APIs are used properly, but brokering protects the user from unwanted software operation (malware, amongst other things)

There is a new scheduling state for apps: the “suspended” state is a low resource usage state that Metro apps enter after they are swiped off screen. The app’s threads are not scheduled, although the app will remain in memory. If resources are running low the OS may choose to terminate the app.

I still have this question: what if you want/need to do some background processing? From what Eric said, it seems that provision is there for media playback and downloads, but not for anything else – so if you have an app that needs to do some long running calculation, and you want to do something else whilst this is happening, you’re left out in the cold. Hrm. This is a shame because Metro truly can lead to some beautiful apps and, as far as I can see, there’s no reason the kind of apps that do this can’t also be beautiful – although limiting them to Win32 pretty much guarantees that they won’t be. It’s an understandable choice for mobile form factors where battery life is a consideration but makes little sense for desktop machines, or even a laptops.

Moving on to using WinRT from JavaScript. This might seem like an abomination but in practice works as seamlessly as it does from other languages. This demo also illustrated the use of the .appxmanifest to gain access to the camera, pictures, and videos folder. Fortunately there’s a nice easy to use configuration UI for this provided in Visual Studio. When the app is run the user is prompted, in a UAC-esque fashion, as to whether they are willing to grant access to the requested resources. You have no control over this, it just happens – what isn’t clear to me is whether it happens every time you start an app, or just the first time you run it. I think the latter would be preferable, both from a user experience, and for developers, because it’s the only possible bridging mechanism between Metro apps and Win32 – if you have to approve every time a Metro app wants to launch a Win32 process, it could become rather jarring, to say the least. This is the only possible solution to the “long running background calculation problem”, although it’s not clear to me if/how you could publish results back to Metro – can you get access to the Notifications mechanism, or tile update infrastructure from a Win32 app?

Control rendering is hardware accelerated from HTML and JavaScript – this might seem at first surprising, but why would it be? These are after all Metro controls that are laid out based on the HTML content.

HTML is remarkably convenient for laying out certain types of content so I wonder if it’s possible to have a hybrid C#/HTML/JavaScript application? (Apart from, of course, resorting to the use of WinRT components, which might be the only option.) I suppose there might be some browser control in the WinRT libraries you could use.

Demo also showed off system wide spell check in text inputs again.

Also showed JavaScript source code for share contract implementation – nothing special to comment on.

Metro apps, regardless of their implementation language, are all packaged up as .appx packages, which are just zip files with a different extension (support was added in .NET Reflector 7.4 whilst I was still away at the conference, which was easy because of the existing Silverlight XAP support, and is available in the current 7.4 EA build). There are no installers for Metro apps, and in fact installation is declarative.