Microsoft's high-risk Windows 8 .NET switch
Revenge of COM, or something like it
You can frame the beginning of this story in various different ways. Development manager Martyn Lovell said that the Windows team, while working on Windows 7, asked themselves what the operating system would look like "if it was a better development platform". That said, Apple, competition from iOS, and the need to make Windows touch-friendly were all important factors.
Consequently, the Windows team took the once-in-a-decade opportunity to redo the Windows programming model, though bearing in mind that Windows 8 has a dual personality and includes traditional desktop Windows alongside the new Metro-style environment. Microsoft evaluated several approaches, including one based on Silverlight as in Windows Phone 7, but decided that the new runtime would not depend on .NET.
The result is a runtime that can be called from either C/C++, or .NET, or the IE engine. The use of metadata makes it easy to surface rich statement completion and API help in Visual Studio.
Microsoft also took XAML, the layout language used by Silverlight, and used it to define the user interface for Windows Runtime apps. In order to do this, XAML was rewritten in native code, so there is still no .NET dependency.
C# or Visual Basic programming for the Windows Runtime uses version 4.5 of the .NET Framework. This is a revised and extended version of .NET Framework 4.0. It is the full CLR, but with a cut-down profile of the Framework class libraries. Microsoft took out anything that was duplicated by Windows Runtime APIs, or deprecated, or not applicable. Silverlight also has a cut-down version of the .NET Framework, and .NET programming for the Windows Runtime looks similar to Silverlight. This is not only due to XAML and C#, but also because of the security model. There is no inter-app communication, apps have isolated storage, and interaction with system devices is limited to what is allowed by pre-defined "contracts" for which apps can be a consumer or a provider.
An example of this is file I/O. The API includes read-write file access, but these only work for an app's isolated storage. If you want to read a file from elsewhere, you use the FilePicker contract to display a file open dialog, and the user controls which file is selected.
Another restriction that caused some consternation among those attending BUILD is that there is no SQL Server or other database client in the Windows Runtime. Data access is either to local isolated storage, or via web services such as WCF RIA Services, originally developed for Silverlight.
Third parties not welcome
Only a small, safe subset of the Win32 API is available to Metro-style apps. The runtime throws an error if you try to call a disallowed API. You can use your own native code DLLs and call them from .NET using platform invocation (P/Invoke), but if that native code DLL calls a disallowed API again an error will be thrown.
This is a locked-down platform then, with hints that it will be especially locked-down in its ARM incarnation. One tap gets you back to desktop Windows with all its chaotic freedom, but Microsoft is determined to make the Metro-style side a safe platform and on ARM it is possible that even the desktop side will be restricted.
The WinRT framework is not really extensible, other than with code that you install into your app's own directory. There is provision for shared framework extensions, which can be downloaded on demand from the forthcoming Windows Store, but Microsoft says that third parties will not be able to create these shared extensions, other than in corporate roll-outs.
Within those deliberate limitations, Microsoft has built what looks like a programmer-friendly, high-performance platform in WinRT. There is no message loop and no Graphics Device Interface (GDI), to mention just two fundamentals of the old Win32 API. The user interface (UI) is always rendered by DirectX.
Another notable feature is the number of asynchronous APIs. Microsoft claims to have made every call that may take more than 50ms asynchronous, and Redmond has not provided synchronous alternatives. "Developers call them even when they shouldn't," we were told.
The pain of asynchronous programming has been largely removed by new language features, such as the "await" keyword in C#, which enables developers to code in a synchronous manner even though callbacks are used behind the scenes. The UI is on a single thread.
What then are the implications for .NET on the client? It was obvious at BUILD that it is C# developers that dominate on Microsoft's platform – sessions on the language were packed to overflowing – and it is likely that more WinRT code will be written in C# than in any other language. It is also obvious that Metro-style apps are not capable of everything Windows developers want to code, so desktop development will remain strong and largely .NET-based.
Looking into the future as Microsoft envisages it, though, desktop Windows seems unlikely to evolve much beyond what we already have in Windows 7, which is set to become the new Windows XP in terms of its life on corporate desktops.
Silverlight 5.0 is due to be released soon, but we heard little about it at BUILD and it is no longer strategic for Microsoft. Microsoft's energy is all going into WinRT, into trying to catch up with Apple on tablets and into promoting cloud services for consumption by Metro-style apps.
Porting most existing .NET applications to WinRT is not easy. The UI will need to be reworked, the code ported to allow for all the parts of the framework that are no longer available, and the architecture revised to work with the WinRT cloud services model.
Fear and programming
In one sense then, the fears of .NET developers were justified and COM has its revenge. In mitigation, C# and Visual-Basic programming is alive and well, XAML remains, and WinRT works seamlessly with the CLR. The mood at BUILD was generally upbeat, as developers have enjoyed the responsive and touch-friendly Metro-style Windows – even though when you talk to them many admit that their apps will not work in Metro and they are not rushing to support it with apps. One factor is that corporate developers dominate at BUILD, but Metro has so far been perceived as more of a consumer than a professional platform.
Windows 8 has made a good impression at BUILD, but it is a high-risk strategy for Microsoft. ®