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.
Next page: Third parties not welcome