My Build Event Insights
You didn't have to go to //BUILD/ to get the information and knowledge of the new Windows Platform APIs; you could watch all the sessions from the comfort of your home, and I encourage you to do so, however attending the conference helps obtaining a perception about the future of Microsoft and especially the future of Windows technologies and the reaction of the developers that attended the conference.
I didn't want to post about the conference before I have a clear picture, and believe me the picture was obscured. According to the first day keynote and the discussions on tweeter and the various mailing lists, I got it all wrong; however by digging into the implementation of WinRT, by talking with people from the Platform team and by attending the last day sessions, I got a better and clearer picture.
So what is Metro Style Application, what is WinRT, and should I learn C++ or HTML & JavaScript?
Let's start with the underlying system. Windows Run-Time (WinRT) is a new platform for using and consuming the Windows OS resources. It is a modern native layer on top of Win32 and the Windows Kernel that replaces Win32 APIs and other frameworks like MFC for the native world and many of the .NET classes and technologies for the managed environment.
- WinRT has a new type system, quite similar to the .NET Common Type System (CTS), however it is optimized for native code usage and for cross language calls with .NET, JavaScript and C++ in mind. The type system also provides rich type information that is based on the same metadata schema of .NET, however for native code there is no IL, GC and JIT.
- WinRT is heavily based on COM, however it is not IDL based, and we get all the goodies of a modern Object Oriented based technology such as classes, static functions, methods, properties, delegates, events and inheritance.
- WinRT APIs are either asynchronous for potentially long operations, or synchronous for fast non-blocking functions.
- WinRT provides the installation facilities as well as the environment activation and hosting.
- WinRT is based on components. This enables sharing implementation between languages.
- WinRT provides rich mechanism for inter Metro application communication through Contracts - as a developer you have the Launch Contract, Search Contract, Share Contract and many more. You can provide contract implementation or consume a contract.
Metro is the new client development platform. It is based on WinRT classes. Metro applications are fast, smooth, and safe. Metro application can use only "safe" APIs, which are the WinRT classes' members and a white list of other APIs. For .NET a special client profile is provided that contains only non (potentially) blocking calls and does not contain duplications for APIs provided by WinRT. To use sensitive user information such as location devices or a Web Cam, you need to declare these needed capabilities. Windows will ask the user for permission to run your code and use these capabilities (much like the standard for mobile applications). Metro Apps occupy the whole screen (chrome-less) and have a new life time management. They have to start quickly, they get suspended once they are in the background and background apps get terminated if the system resources are low. Each WinRT application runs as an STA COM component, and if there is a need to answer a new contract request, a new STA instance is lunched.
Now to some of the BIG concerns, what are the consequences of these new Windows mechanisms?
If you are a Windows C++ developer, it means that you get much better tooling and a framework that resembles the .NET development API. You need to learn the XAML concepts and the Metro UI object model. You also need to learn the C++ extensions for WinRT – although if you are familiar with C++/CLI, the extensions are very much the same. If you haven't upgraded your knowledge to C++ 11, you also need to handle this learning curve. The result is much better productivity, safe code, and fast & fluid user interface.
C++ is back, as Herb Sutter said in his talk – for fifteen years we didn't care about performance, but now that we pay for running our code in the cloud, or we target lightweight hardware such as slate devices and we want to preserve power, performance is a big issue again. C++ and WinRT are performance tuned and WinRT ref-count based resource management provides deterministic finalization which means that we don't hold unneeded resources.
If you are a C#/VB developer and productivity is more important to you than execution speed and low resource consumption, continue to do what you already do. Use the Metro profile with the .NET framework. WinRT provides all the metadata information that is needed to create and call WinRT objects, while .NET provides the GC, JIT, and all other mechanisms that make .NET so easy to use. To call a WinRT component .NET uses the same CCW/CRW mechanism that is used for COM interop, however the borrowed metadata mechanisms plus the new WinRT type system make this interop story much easier and faster. I hear a lot of complaints from .NET developers that WinRT "kills" many .NET technologies, however the exact opposite is the true! WinRT borrowed many of its concepts from .NET, its metadata, properties, delegates & events and others. Metro UI is based on XAML and the Silverlight/WPF object model. It is easier for a .NET developer to develop new metro application compared to a native C++ MFC developer.
If you are a web developer, JavaScript is a first class citizen for developing Metro style application on top of WinRT. You get the WinRT object model, and method names even appear in Camel Casing even though for C#/VB/C++ they appear as Pascal Casing.
If you are a UI/UX developer, Blend 5 and Visual Studio UI editor are upgraded to support Metro style application. You can also design HTML/CSS using Blend. You get to preserve all your old knowledge and practice while designing with the new Metro style. You also get many predefined UI templates.
If you are a Windows developer, many of the technologies that you know are there. Everything behind the scenes is COM, with major abstraction on top of COM. You can choose the language that you want or the one that you think is better for the job. You can develop C++ based components using native libraries such as boost and consume them from JavaScript or C#.
There are many new details to dive into now, but we also have the time. We are not even in the beta phase of the system and things will certainly change, but we are starting to see the tip of the iceberg.