Windows Fragmentation |
Written by Mike James |
Friday, 04 November 2011 |
While there is a lot of excitement at the prospect of Windows "reimagined" in the form of Metro or WinRT, or whatever Microsoft finally settles on calling it, there is an interesting and serious problem - fragmentation. Basically you have to ask yourself, what will the world look like when Windows 8 launches alongside Windows Phone 8? Before you object that there might not be a Windows Phone 8 for a while, I need to point out that the situation will be the same, or possibly worse, with WP7 and Windows 8. Microsoft has had to work hard to achieve a single codebase for Windows and now it seems happy to throw that all away. Perhaps this is realistic, but I have a feeling that they don't even realize that this is what they are doing. Back in the early days, there was Windows 98, the desktop OS, and Windows NT, the server OS. After a lot of effort they were unified in the Windows XP and Windows Server releases. From this point on there has been a single codebase for Windows, with the different versions of the OS essentially being customizations. This, by and large, provided a single programming model for Windows. There were sub-systems only available on particular versions, but mostly you could code your Win32 application without worrying which version of Windows it was to run on. The same remained true when the programming model tried to move on from Win32. You could code for the .NET framework without really being aware of which version of Windows it would run under. Windows was, and at the moment still, is a single programming platform. Now we have the prospect of WinRT and Metro style apps and this is about to change.
Windows Phone 7, WP7, is an odd Windows platform. It isn't really Windows at all and yet you can code for it using .NET Silverlight and XNA. Your Windows 7 apps won't run unmodified on WP7, even if they are written in Sliverlight and XNA. However, it doesn't take much effort to make the changes necessary. After all you can argue that coding for a mobile phone is bound to be a bit different from coding for the desktop. This is more or less the situation with Android before version 4. You had Version 3 for tablets and Version 2 and earlier for phones. Guess what? Programmers complained of fragmentation of the platform! Why didn't they complain about the WP7 and Windows 7? The simple answer is because Microsoft didn't, and still doesn't, do tablets. The point is that the difference between a desktop app and a phone app is huge. Well it is huge when compared to the difference between a tablet app and a phone app. At the moment Microsoft programmers don't really identify the situation as fragmentation - they see it more like "horses for courses". They can use most of the codebase from a desktop app because Silverlight is essentially a subset of WPF and the whole thing is .NET anyway. That is, the commonalities are .NET, Silverlight, C# and a well known UI with a few extras. Now consider Windows 8. It still has the old Win32 API and the managed code .NET system on the desktop. However, the new Metro startup area is based on a completely new API - WinRT. It uses run time objects based on COM and while you can use C# and VB .NET it also works well with unmanaged code via C++ and JavaScript. So you can sit down and craft a new Metro app using a familiar language, but the rest is new territory and you might even decide to use C++ or JavaScript instead. It is a new world and now we have one system for the desktop and one for the tablet. Of course Metro apps will still run on the desktop, but in a sort of special play area that looks and behaves like a tablet. You can think of Metro and WinRT as a sort of tablet emulator running on Windows desktop. When it runs on a real tablet, however, the chances are that in most cases the desktop environment won't be there. Notice the fragmentation now? Things get even worse when you add into the mix WP7 or WP8. Remember WP works with what looks like a 100% managed code environment. It knows nothing of COM and it isn't obvious how it can be made to know something of WinRT and Metro without a lot of re-engineering. Ask any programmer working with WinRT if it is anything like working with Silverlight and the answer will be no, not really. You are working in C# or VB and you can make use of XAML and this at least makes the environment seem slightly familiar. The rest, however, and the foundations just below the surface are completely new. This isn't Silverlight.
When Windows 8 tablets appear the situation will snap into sharper focus.
This is much worse than any fragmentation Android has experienced. The programming environment for Windows 8 tablets, i.e WinRT/Metro, is totally different from WP7's Silverlight/XNA environment. So what happens with Windows Phone 8? This is a really important and difficult question. Microsoft could simply put up with the fragmentation and push WP8 onward with Silverlight 6 and the existing operating system. This really doesn't sound sensible. But what about the alternative - a migration to WinRT/Metro to unify the tablet and phone environments. That is, WP8 apps will be WinRT/Metro apps. This is a shift in the Windows Phone eco system that is so huge it is difficult to comprehend. After establishing a mobile phone technology Microsoft would effectively have to throw it away and start again. Neither future looks particularly logical or sensible, but on past experience my best guess would be unification of the systems, if not at Windows/WP 8 then at the next version. The more I work with WinRT, the more I get the feeling that it hasn't really been thought through. It may well have swept away .NET, WPF and Silverlight for a COM, DirectX and C++ based world, but there is a little pocket of resistance left isolated and holding out for some time to come - Windows Phone 7.
To be informed about new articles on I Programmer, subscribe to the RSS feed, follow us on Twitter or Facebook or sign up for our weekly newsletter. |
Last Updated ( Friday, 04 November 2011 ) |