Posts Tagged‘xaml’

WinRT

Windows 8 and WinRT: On the Cusp of Platform Unification.

Last week saw the much talked about Microsoft BUILD conference take place, the one for which all us developers tentatively held our breath wondering what the future of the Microsoft platform would be. Since then there’s been a veritable war chest of information that’s come from the conference and I unfortunately didn’t get the time to cover it last week (thanks mostly to my jet setting ways). Still not writing about it right away has given me some time to digest the flood of information and speculation that this conference has brought us and I personally believe that Windows 8 is nothing but good news for developers, even those who thought it would lead to the death of their ecosystem.

For starters the project codenamed Jupiter has an official name of Windows Run Time (WinRT) and looks to be an outright replacement for the Win32 API that’s been around since 1993. The big shift here is that whilst Win32 was designed for a world of C programmers WinRT will instead be far more object-oriented, aimed more directly at the C++ world. WinRT applications will also use the XAML framework for their user interfaces and will compile to native x86 code rather than to .NET bytecode like they currently do. WinRT applications also do away with the idea of dialog boxes, removing the notion of modal applications completely (at least, in the native API). This coupled with the fact that any API that takes longer than 50ms to respond being asynchronous means that Metro apps are inherently more responsive, something that current x86 desktop apps can’t guarantee. Additionally should an app be designed for the Metro styled interface it must only use the WinRT libraries for the interface, you can’t have mixed Metro/Classic applications.

If you’re after an in-depth breakdown of what WinRT means for developers Miguel de Icaza (of Mono fame) has a great breakdown here.

WinRT will also not be a universal platform on which will provide backwards compatibility for all current Windows applications. It’s long been known that Windows 8 will be able to run on ARM processors but what wasn’t clear was whether or not current applications would be compatible with the flavour of Windows running on said architecture. As it turns out x86 applications won’t work on the ARM version of Windows however applications written on the WinRT framework will run on every platform with only minor code changes (we’re talking single digit lines here). Those legacy applications will still run perfectly well in the Desktop mode that Windows 8 offers and they’ll be far from second class citizens as Microsoft recognizes how things like their Office suite don’t translate well to the tablet environment.

At the same time Microsoft has also announced that the web browser in the Metro UI will not support any kind of plug-ins including their very own Silverlight. Of course you’re always welcome to switch into desktop mode should you visit a website that requires a plug-in but Microsoft said the aim is for everyone to transition away from plug-ins and onto the HTML5/JavaScript stack. On the surface this seems to verify the notion that Silverlight developers are screwed as all their apps are second class citizens in the new Metro world. However since WinRT apps are developed in a very similar way to that of Silverlight apps the transition to the Metro platform will probably be nothing more than changing namespaces and tidying up the UI so it fits in with the new design. Distribution of said apps will then come via the Microsoft app store, rather than a company’s web server. Sure it’s a paradigm shift away from what they’re currently used to, but Silverlight developers will find themselves right at home with WinRT.

Taking this all into consideration it seems like there will be a line in the sand between what I’ll call “Full” Windows 8 users and “Metro” based users. Whilst initially I thought that Jupiter would mean any application (not just those developed on WinRT) would be able to run anywhere it seems that only WinRT apps have that benefit, with current x86 apps relegated to desktop mode. That leads me to the conclusion that the full Windows 8 experience, including the Desktop app, won’t be available to all users. In fact those running on ARM architecture more than likely won’t have access to the desktop at all instead being relegated to just the Metro UI. This isn’t a bad thing at all since tablets, phones et. al. have very different use cases than those of the desktop but, on the surface at least, it would appear to be a step away from their Three Screens vision.

From what I can tell though Microsoft believes the future is Metro styled apps for both desktop and tablet users a like. John Gruber said it best when he said “it’s going to be as if Mac OS X could run iPad apps, but iPads could still only run iPad apps. Metro everywhere, not Windows everywhere.” which I believe is an apt analogy. I believe Microsoft will push WinRT/Metro as the API to rule them all and with them demoing Xbox Live on Windows 8 it would seem that at least on some level WinRT will be making it’s way to the Xbox, thereby realizing Microsoft’s Three Screens idea. Whether the integration between those 3 platforms works as well as advertised remains to be seen but the demo’s shown at BUILD are definitely promising.

Microsoft’s Jupiter: A Panacea to Developer’s Ills.

If you’re a Windows developer the past few months of Microsoft’s various announcements about Windows 8 and the future of their developer ecosystem haven’t been particularly kind to you. With Microsoft announcing that their new Windows Phone 7 inspired UI for Windows 8 will be based on HTML5 and JavaScript many were left wondering if the heavy investment they had made Silverlight and .NET technologies was going to be wasted. It didn’t help matters much when Microsoft told everyone to wait until BUILD in September for more details, which let speculation run rampant amongst the community.

However it has come to my attention that Microsoft has been hinting at a potential panacea for all these woes, for quite some time now.

Back in January there were many rumours circling around the new features we could look forward to in Windows 8. Like any speculation on upcoming products there’s usually a couple facts amongst the rumour mill, usually from those who are familiar with the project. Two such features which got some air time were Mosh and Jupiter, two interesting ideas that at the time were easily written off as either speculation or things that would never eventuate. However Mosh, rumoured at the time to be a “tiled based interface”, turned out to be the feature which caused the developer uproar just a couple months ago. Indeed the speculation was pretty much spot on since it’s basically the tablet interface for Windows 8, but it also has a lot of potential for nettops and netbooks since underneath the full Windows 8 experience is still available.

The Jupiter rumour then can be taken a little bit more seriously, but I can see why many people passed it over back at the start of this year. In essence Jupiter just looked like yet another technology platform from Microsoft, just like Windows Presentation Framework and Silverlight before it. Some did recognize it as having the potential to be the bridge for Windows 8 onto tablets which again shoe horned it into being just another platform. However some did speculate that Jupiter could be much more than that, going as far to say that it could be the first step towards a unified development platform across the PC, tablet and mobile phone space. If Microsoft could pull that kind of stunt off they’d not only have one of the most desirable platforms for developers they’d also be taking a huge step forward towards realizing their Three Screens philosophy

I’ll be honest and say that up until yesterday I had no idea that Jupiter existed, so it doesn’t surprise me that many of the outraged developers wouldn’t have known about it either. However yesterday I caught wind of an article from TechCrunch that laid bare all the details of what Jupiter could be:

  • It is a new user interface library for Windows. (source)
  • It is an XAML-based framework. (source)
  • It is not Silverlight or WPF, but will be compatible with that code. (source)
  • Developers will write immersive applications in XAML/C#/VB/C++ (sourcesourcesource,source)
  • It will use IE 10′s rendering engine. (source)
  • DirectUI (which draws the visual elements on the screen, arrived in Windows Vista) is being overhauled to support the XAML applications. (sourcesource)
  • It will provide access to Windows 8 elements (sensors, networking, etc.) via a managed XAML library. (source)
  • Jupiter apps will be packaged as AppX application types that could be common to both Windows 8 and Windows Phone 8. (sourcesourcesourcesource)
  • The AppX format is universal, and can used to deploy native Win32 apps, framework-based apps (Silverlight, WPF), Web apps, and games (source)
  • Jupiter is supposed to make all the developers happy, whether .NET (i.e., re-use XAML skills), VB, old-school C++ or Silverlight/WPF. (Source? See all the above!)

Why does Jupiter matter so much? If it’s not clear from the technical details above, it’s because Jupiter may end up being the “one framework” to rule them all. That means it might be possible to port the thousands of Windows Phone apps already written with Silverlight to Windows 8 simply by reusing existing code and making small tweaks. Or maybe even no tweaks. (That part is still unclear). If so, this would be a technical advantage for developers building for Windows Phone 8 (code-named “Apollo” by the way, the son of “Jupiter”) or Windows 8.

In a nutshell it looks like Microsoft is looking to unify at all of the platforms that run Windows under the Jupiter banner, enabling developers to port applications between them without having to undergo massive rework of their code. Of course the UI would probably need to be redone for each target platform but since the same design tools will work regardless of the platform the redesigns will be far less painful then they currently are. The best part about Jupiter though is that it leverages current developer skill sets, enabling anyone with experience on the Windows platform to be able to code in the new format.

Jupiter then represents a fundamental shift in Windows developer ecosystem, one that’s for the better of everyone involved.

We’ll have to wait until BUILD in September to find out the official word from Microsoft on what Jupiter will actually end up being, but there’s a lot of evidence mounting that it will be the framework to use when building applications for Microsoft’s systems. Microsoft has a proven track record of creating some of the best developer tools around and that, coupled with the potential to have one code base to rule them all, could make all of Microsoft’s platforms extremely attractive for developers. Whether this will translate into success for Microsoft on the smartphone and tablet space remains to be seen, but they’ll definitely be giving Apple and Google a run for their developers.