WinRT: An Object Orientated Replacement for Win32
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.
Side note: The Win32 API has not been removed and older applications using the traditional application execution environment will continue to work as expected.
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.
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.
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.
"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."
If a call is done asynchronously or not should not be dictated by the callee, as it's a problem of the caller, hence the caller should be able to decide. Imagine something in some worker thread wants to call any of those potentially long-running methods. It's not on an UI thread or anywhere where blocking is a problem. But now that Windows dictates to use an aysnc method, the caller HAS to handle an async call.
Or are they going to offer both async and sync?
But then again, they could just offer a normal method and the caller will decide how to call it. There are means to convey something to developers other than forcing them to use something with development and runtime overhead...
Now that software development tends to go 'functional' why is Windows going 'object orientation'? I wonder if that's future-proof.
Metro apps have to be signed: I hope this is not going to be 'Apple light' where every poor open-source developer has to jump through potentially costly, but certainly boring hoops to make software available to other people. That would suck.
While that is the recommended pattern, you can turn any async call into to sync call using the "Task.Wait" method.
> Or are they going to offer both async and sync?
Nope. Looking at the list, it looks like you are only going to get one or the other.
> Now that software development tends to go 'functional' why is Windows going 'object orientation'?
OOP is still the best way to create extensible data structures. FP just happens to be a really good way of writing the code that glues the objects together.
> Metro apps have to be signed:
From what I can tell you can simply self-sign the application if you don't want to pay for a code signing certificate. A good thing too, considering that VeriSign charges $895 for a two-year certificate. Hopefully this will encourage other companies to offer more reasonable prices.
Wonder if async api calls will map well to C# async or the .Net async model (for F#).
Promoting XAML to the core is a win for all.
Certs are expensive. The prices could be lower but the cost reflects the validation (human effort) certificate authorities need to do before issuing certs. GoDaddy started out by selling SSL certs at very affordable prices but have recently increased the prices - presumably to cover validation expenses.
How inefficient. I want to do a synchronous call, but it _has_ too be done on a different thread and then joined back into the calling thread later.
> OOP is still the best way to create extensible data structures.
Is it? I think it has never been the best way, it just has been 'the way', and slowly more and more OOPers come to the conclusion it doesn't work out. Examples:
* Immutability, being suggested for a couple of years (Lippert, Goetz) because of benefits such as: No need for defensive copying, guaranteed to be thread safe, good testability. But, it doesn't work that well with 'setter' properties, which are the way OOP is done in most languages (C#, Java).
* Composition over inheritance, which is what many Gurus in the c# world are preaching these days.
If you throw away mutability and inheritance, what's left of OOP? Encapsulation and related concepts used by OOP are not specifically OOP, as FP does those, too.
"WinRT isn’t another abstraction layer; it resides directly on top of the kernel just like the Win32 API. "
is not factually accurate. Quite a bit of WinRT is just a wrapper on top of Win32. According to Larry Osterman,
"Some Windows Runtime APIs are thin wrappers around existing Win32 APIs (XML and the sensor APIs, for example). Some Windows Runtime APIs are completely new (the XAML APIs and the input stack). So it's not true to say that the windows runtime is a wrapper around Win32, but it is true that parts of the windows runtime are layered on top of Win32."
– Larry Osterman
In particular, file IO and thread management in WinRT are just wrappers for Win32 APIs.