After the //build/ keynotes, I looked for more informations regarding WinRT and a few teams gave me the answers to my questions.
There are two stacks for building Windows 8 applications:
- Classic mode (Win32 / .NET)
- Metro-Style mode
The classic mode is the one we all know, will not change and will be maintained for the future. WPF applications, Winform and HTML will continue to work. These applications run on the desktop in the classic Explorer shell and will continue to work as in Windows 7.
Applications can't use both modes. If they use WinRT can not use Win32. If they use Win32 they can't use WinRT therefore are they are not WinRT Metro (and will run in the old desktop).
Server applications using .NET Framework will continue to run without any changes. The framework is still there and will stay with everything you already know.
Client applications can work without changes (Win32 and .Net will be supported) but cannot be Metro-style. A Metro application must change the way interact with the operating system (see below).
The Metro-Style mode has a number of interesting features:
- Metro is not just a matter of styling but a set of specifications for interacting with the operating system. The Metro 8 is radically different than Windows Phone (from the engine perspective).
- Each application is isolated, it can use only what is allowed by the user. The developer requires permission by a manifest which is controlled by WinRT through a broker that works as a supervisor on the activities of the application. The environment in which the application is not running a virtual machine/environment and is not the .net framework
- Application deployment is done via a package that contains everything the Windows Store need need to install the application on the target machine. The concept of private Store is still under discussion.
- One of the most interesting technology is the Contracts that let your application that allow the application interact with other apps and the operating system (read a feed, a Facebook page, search, etc..)
- is the Windows runtime that exposes the functionality of the operating system in an object-oriented flavour.
- It is not managed code and does not need. NET Framework
- Managed languages sitting on WinRT still need the CLR. The .Net Framework included in Windows 8 is version 4.5
- WinRT is built with COM technology and keep all relevant mechanisms (IUnknown, AddRef / Release, Apartment for threading models, the STA message pump to handle).
- WinRT simplifies many of the old COM concepts. For example it removes connection points and IDispatch to allow dynamic languages to interact with it.
- The WinRT type system is small but larger than the COM. For example, BSTR no longer exists but, for example, the string has a memory layout similar to the one used by the CLR. This avoids the copies during marshalling. WinRT can expose the memory of the string to both managed and native code without performance penalties.
- Among the changes in the type system there are the collection (including observable type) that are constructed / mapped by the projection automatically.
- The projection of C++ directly map to the structures compatible with the STL (Standard Template Library).
- Projections in WinRT are customized language-by-language and allow for the best performances.
- You can write extensions to expose custom native code to applications using WinRT. But these extensions are private to that application and cannot be shared (no regsvr32)
- Metro Contracts are exposed as COM interfaces, and most developers will never need to go down to level COM interface in order to use them
- At the lowest level there is WinRL, a C + + library used by the Windows team to build anything that exposes WinRT. It is believed that no one needs it (except myself of course)
- WinRT versioning is based on the concepts of COM and allow evolving the interfaces in future versions of Windows.
- It is useful to those who need the CLR benefits (garbage collection, etc..) And therefore will be used in C # and VB.NET
- Many libraries (BCL Winform, and everything he does I / O on video disk and so on) are not used by Metro. Applications must use specific WinRT functions. For example everything related to XAML (Metro-style) has been rewritten in native code.
- There is a new XAML interpreter written in native code that maps XAML controls to Metro native controls
- In the same way (for those who knows PhoneGap) html5 tags are mapped to native controls WinRT
- XAML and HTML5 are peers, interchangeable and sit on the graphics engine (based on DirectX) applications that render Metro
The Tools. In addition to what has already been seen and said in the keynote:
- Visual Studio 11 includes everything you need to package and publish it on the Windows store that is not yet available.
- The private store is under discussion.
- WinDBG is still there, but all its features have been integrated into Visual Studio
- Visual Studio 11 includes wizards to create drivers in kernel mode, user mode, the tests (static analisys) and remote debugging (including reboot and install certificates on remote machine)
Stay tuned. This is just the beginning.
My comment? WOW, it's fantastic and finally there is the real platform that I expected from Microsoft.
(sorry if the translation is not decent, but I worked hard to publish the information I collected in two languages)