Microsoft’s last Web application platform – or its current one, depending on which side of the Build 2011 doors you stand on this week – was Silverlight. Its purpose has been to serve as a subset of the .NET Framework, one that can be redistributable to other platforms. On Windows, Silverlight enables an app delivered through the Web to gain access to system services, and to use the rendering engine of Internet Explorer. A Silverlight-based Web app can look “installed,” and can run in its own window or panel outside of the browser. JavaScript is one of the languages Silverlight supports (actually, it was the first one it did support), although JS for a Silverlight app is not the same as JS for HTML. It’s the same language, but not with the same purpose.
Beginning in the middle of Windows XP’s product cycle, Microsoft distributed what it called foundations, which collectively form the .NET Framework. These foundations are code bases which provide the fundamentals of applications for .NET developers to build upon. Not long ago at all now, Windows Presentation Foundation replaced the old WinGL graphics library, enabling richer and more visually resplendent usage models; and Windows Communication Foundation creates a rich, service-oriented data sharing model for enterprise-class applications.
The differences .NET provided to Windows applications were stunning. Office 2007 belonged to a whole new world compared with its WinGL-tethered predecessor. Silverlight is one way for a lightweight app deployed over the Web to tap into foundations like WPF and WCF, and still remain secure and reasonably incapable of being exploited.
When Windows Vista adopted the entire set of .NET foundation classes for the first time, the word from Microsoft was that Windows would never abandon the rich investment that developers over the many years had placed in WinGL applications. That was the company’s polite way of thanking WinGL for its service, while at the same time, giving itself a back-door exit when folks noticed many of Windows’ system drivers remained rooted in older libraries.
So when Microsoft engineers this week promised that Windows would never abandon the rich legacy of investments developers have made over the years in .NET, its foundation classes, and in Silverlight, folks were right to call out the familiar sound of a certain violin.
WinRT is not a subset of anything. Microsoft officials tell RWW that WinRT is the provider of all Windows system services to interpreted code. Networking, device access, file system access, security protocols, and graphical layout are among these services – the same categories you’d expect from .NET, but not the same functions.
This platform diagram for WinRT, which premiered today, does appear to shove the concept of Desktop applications more than figuratively to one side. Veteran developers will note that the Desktop development model prior to WinRT was not nearly as simplified as the bright blue column on the right suggests.
The other message of the platform diagram is this: HTML5/CSS/JavaScript and the languages normally associated with .NET (C, C++, C#, and VB) will be treated as equal citizens by WinRT.
The examples of WinRT-supporting code we’ve seen thus far do not indicate specifically why apps that use WinRT must, by definition, have the Metro style (whose name, we were told today, may be temporary and subject to change). But we do know the following for certain:
1. Microsoft is promoting WinRT development as preferable to Silverlight development, mainly because the former does enable the Metro style.
2. There will not be a redistributable subset of WinRT, analogous to Silverlight’s role with the .NET Framework.
3. Developers moving to the WinRT model as Microsoft suggests are making the choice to develop Windows apps as opposed to cross-platform apps, even though they may be using standards-based Web apps tools to do so.
4. There do not appear to be plans to deploy WinRT apps “in the cloud” the way .NET applications are deployed “in the cloud” via Windows Azure today. In fact, those I asked about this looked at me like I was from Mars for even asking. WinRT apps are designed to be client-side programs.
Although Windows’ engineers are touting the benefits of HTML5 and JavaScript as appealing to a broader range of developers, the WinRT apps you build using these standards-based tools are for Windows exclusively. The term HTML5 developers use is “native”, and they acknowledge (begrudgingly) that sometimes native apps are necessary for Web-based functionality to have any depth or reach whatsoever into the power of any one platform. (Microsoft used the phrase “native HTML5″ recently in marketing to mean something different, though has recently backed away from that phrase.)
Windows engineers are advocating this week a migration path for Silverlight developers that enables them to continue using the same languages, including C++, C#, and Visual Basic, and to continue producing XAML, the XML-based code used to describe the layout of an app. But that migration path would transition developers away from Silverlight, just in a way these engineers say won’t be noticed much. The result will be Metro apps that are distributed through the Windows 8 app store (which we hope won’t be called “Store” for long), and that follow the company’s newest design motif.
Article source: RRW http://feedproxy.google.com/~r/readwriteweb/~3/0JKt_Gbu624/build-2011-what-is-winrt-and-i.php