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: http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005.
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.
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.
Demo also showed off system wide spell check in text inputs again.
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.