WinRT isn’t another abstraction layer; it resides directly on top of the kernel just like the Win32 API. This marks the first major break in the core of Windows since Win32 was introduced in 1993 with Windows NT. WinRT represents a new application execution environment with semantics that are very different than Win32.
Unlike Win32, which was designed with C in mind, the WinRT APIs are written in C++ and designed from the beginning to be object oriented. Consistency, ease of use, and performance are key aspects of the new runtime API. Every object in the WinRT API supports reflection so that even dynamic languages such as JavaScript can use them efficiently. Along with this comes a unified object model, a rarity for C++ based libraries.
Side note: The Win32 API has not been removed and older applications using the traditional application execution environment will continue to work as expected.
C++ Development
User interfaces in C++ will be written primarily in XAML. This libraries for working with XAML have all been ported to C++ and are compiled to native x86. Metro applications written with XAML and C++ do not run on top of .NET, they get compiled directly to x86 just like any other Visual C++ application.
Calling methods on UI controls is just like calling methods on any other object in C++. At the machine code level one pushes the this pointer onto the stack and then invokes a function via a v-table. This allows for the best possible performance even on low power devices.
Libraries used by modern C++ applications such as Boost are supported.
Overlapping Windows No Longer Exist
Dialog boxes, a core concept from previous versions of Windows, does not exist in WinRT. The performance cost and usability concerns are simply no longer justifiable to Microsoft. Applications that wish to use this pattern will have to develop other ways to express things such as message boxes.
Another library that didn’t make it into WinRT is GDI. If an application is going to use the Metro interface it needs to do so from top to bottom, it appears that mixing Metro and classic user interfaces is not possible.
PlayTo Contract
Another contract that is being exposed is PlayTo. This allows applications to send media files such as audio and video to a charm. The charm will then allow the user to choose which application they want to use to view the file. Presumably these aren’t just physical files, but rather any form of media that can be expressed as a data stream.
C#/VB: The end of P/Invoke
Calling native functions from .NET usually involves building up structures and manipulating pointers. Under WinRT all APIs are exposed as objects that C# and VB can consume directly. This puts .NET developers on level footing with C++ developers.
Application responsiveness is very important to Microsoft. In order to convey that to developers all OS-level API calls that take longer than 50 milliseconds will be exposed as an asynchronous operation.
JavaScript
The fourth major language for Windows 8 is JavaScript. While it doesn’t use XAML, it does have direct access to the underlying WinRT API just like native and .NET applications. This isn’t just a container like PhoneGap, JavaScript developers get the same rich API that other developers use.
Since this is JavaScript the UI toolkit of choice is HTML and CSS rather than XAML. The same rendering engine used by Internet Explorer 10 us used by Metro JavaScript applications, though they don’t actually run in a browser. A JavaScript application looks just like any other Metro application.
User controls in JavaScript are nearly on par with those in C++ and .NET. Some controls are intrinsic to the HTML rendering engine, others are written in JavaScript. These JavaScript based ones are div based much like controls built using jQuery.
App Container and Application Permissions
Metro applications run in what’s known as the “app container”. This appears to replace the windowing environment used by Win32 based applications.
Most API calls are sent directly to the underlying kernel. Some, however, some will be routed through the system broker. The system broker ensures that applications can only access features that the user has approved. For example, the first time an application tries to access the camera the service broker will prompt the user for their approval. Applications are required to include a manifest that indicates all of the restricted services the application may need. This model will be very familiar to mobile device developers.
All Metro applications run within WinRT’s app container and thus are monitored by the system broker, even those written in C++. The idea is to limit the ability of applications to damage the system. While probably not impossible, building malware with WinRT will be much harder than it is in Win32.
All Metro Applications Must be Digitally Signed.
Anonymous applications are not allowed. Applications can be self-signed for testing, but by the time they appear in the app store they will need to be signed using a real certificate.
