Windows 8 is right around the corner. In fact, most developers are already running the “RTM” (Released to Market) version of Windows 8, which is essentially the same build as the one that will be released to customers, minus a few pieces of sugar coating that typically goes into the final, shrink-wrapped product.
When you see ads for Windows 8 on TV, you see the new Windows 8 design (formerly referred to as Metro but now, for some absolutely stupid reason, Microsoft doesn’t want to use that branding). You see the smooth animation, the flowing interface, the square buttons and the simple, get-out-of-your-way-so-you-can-do-stuff user experience that is the hallmark of Windows Phone 7.x.
This is all well and good, but it’s giving many developers fits. The source of these fits is that that Windows 8 development experience is fragmented, cut nearly in half by a choice most developers don’t want to have to make. Windows 8 has two different types of application modes: desktop and WinRT.
So what’s the problem then? Where’s the Hyde to the good Jekyll? This is where I get frustrated. Desktop mode is like traditional Windows development, where you have access to a .NET SDK that is designed in much the same way as it always has. In desktop mode, you have access to all the devices, peripherals, and everything that windows developers have always had access to.
But you don’t have access to WinRT.
This is the fundamental issue I have with Windows 8. If I want to access a serial port, I am forbidden from using anything in the WinRT libraries. If I want to build a multi-window application, I am forbidden from using anything in the WinRT libraries. The reverse is true, also. If I use any of the WinRT GUI or take part in that isolated silo, then none of my WinRT code can access low-level peripherals, serial ports, create multiple windows, or use a number of other desktop-only features.
Even more frustrating is that if I want my code to be guaranteed to run on all of the Windows 8 tablets, I must write my code using WinRT, because WinRT will run on ARM tablets. The new fleet of lightweight, battery-efficient, Windows 8 tablets are WinRT-only! They aren’t laptops and are not capable of executing any desktop-mode “classic windows” applications.
So what this really boils down to is this: developers forced to write “classic” desktop mode applications are constantly taunted by the UI over on the WinRT side, teased and bullied by the live tiles, the smooth integration of hubs, and everything else appealing. You’d think maybe the GUI libraries would be usable in classic desktop mode but even that’s not consistent. WinRT is its own GUI library and classic desktop mode must use WPF. While both utilize XAML, the set of controls and how they behave is actually quite different.
When you look at iOS and Android and Windows… what has Windows always had as an advantage? Power. Flexibility. Access to devices, hardware, peripherals, and every other part of the system. Now Microsoft is saying that if you want to build apps for the same form factor as the iPad, you’re going to have to suck it up and build inside the WinRT isolated sandbox. While there are achitectural and logistical concerns that make this a requirement, it still sucks. The converse is also true – if you are building a more powerful, more in-depth application in classic mode, then you’re going to have to suck it up and cope with the fact that you don’t get access to any of the awesome GUI controls available in WinRT and cope with the fact that your desktop application will never run on a Win8 ARM tablet.
I can see why this was all done, but the marketing coming out of Microsoft and their technical evangelists has been praising WinRT at the expense of other technologies like WPF. MS is treating WPF like a redheaded stepchild, despite the fact that it is the only viable way for people to build applications that reach outside the sandbox. In short, MS is treating what used to be its biggest class of proponents (desktop app developers) like they don’t matter anymore and that WinRT is the only way to go.
None of this matters to end users, but developers trying to decide what tech they’re going to use for their next awesome app, it’s a frustrating and maddening choice.