Free ESG report : Seamless data management with Avere FXT

Microsoft spooked .NET developers earlier this year by emphasising HTML and JavaScript as the programming platform for Windows 8. Any questions were met with the answer: "Wait until BUILD." Well, BUILD took place last week, so what is happening with .NET and Windows?

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.

Instead, Microsoft went back in time and used COM, or something very like it, as the core of the new runtime. However, programmers do not need to know the intricacies of COM in order to code for the Windows Runtime. Instead, Microsoft borrowed the metadata format used by the .NET ILDasm disassembly tool from .NET and used it to add metadata describing the runtime's interfaces, stored in .winmd files. Next, it modified the .NET Common Language Runtime (CLR) and Internet Explorer's Chakra JavaScript engine so that the Windows Runtime APIs are projected into these other runtimes.

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.

Limited interaction

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.

5 ways to reduce advertising network latency