Like many developers, I spent much of last week and the weekend watching the Microsoft BUILD conference and learning about Windows 8, the new Metro UI, and the Windows Runtime (WinRT). My first impression of the Metro interface was that it is compelling and I like it. That has faded a bit as I get into the details of what you can and cannot do with the new architecture. There is a lot to like about the Metro user and developer experiences, all of which you can learn about at Microsoft and the blogosphere. As a developer, I’m thinking along the lines of how I can use the new technology while preserving my investment in existing code and skills. Restrictions built into Metro (by design) have a direct impact on that. While highlighting all the cool new stuff, Microsoft has glossed over the restrictions a bit, so this post looks at things from that point of view. First of all, I should say that this is a developer preview, Microsoft is looking for feedback from developers on their design decisions, and some of those decisions may change before release.
The more I learn about Metro/WinRT, the more I realize it is “Windows” in name only. To start, there are no windows in Metro! Everything is full screen. While there are some things shared under the hood (like the Windows Kernel and file system), for the most part, Metro is separate and isolated from the Windows “desktop”. Metro competes directly with Apple iOS and Google Android in the tablet space, while also being available to PCs. That much is obvious, but being bundled in Windows, you might think you also get access to all the goodness in the Win32 and .NET APIs. That is not the case. This really is two operating systems in one box.
So, why not just sell Metro separately as a new OS? Microsoft already tried that. It’s called Windows Phone 7, and nobody’s buying. Even Windows Vista had 400 million users, so bundling Metro with Windows ensures there is a viable market for apps. Besides, we developers would freak out if Microsoft dropped Windows for something entirely new. Putting Metro in Windows is good all around.
A key point to make is that Metro is client-side technology only. In spite of support for HTML, these are desktop apps. The HTML is not served up by a server, but rather is compiled into the Metro app. Being client-side technology, there are a lot of things Metro doesn’t do. Microsoft expects your business logic and database access to be done on the server and exposed as a service that Metro apps can consume. Of course, they would be happy to host this service for you in Azure, but that is not a requirement.
How about the Windows Runtime? What exactly is it? It could have just as easily been called the Metro Runtime, because it exists for the sole purpose of servicing Metro apps. Under the covers, WinRT components are written in native C++ (take that Dev Div!), and interfaces are exposed using COM and metadata. This does not mean that COM is making a comeback in Metro. Microsoft has used COM (specifically the IUnknown interface) for years as a means of exposing native interfaces, and they are simply using that rather than reinventing the wheel. There are no type libraries, rather interfaces are described in a modified version of the .NET metadata format called winmd.
So, if you’re thinking about accessing the WinRT from FoxPro or other environment using COM, you can forget about that. In fact, this whole notion of automating other applications is absent from Metro. You cannot directly start another application and communicate with it from Metro. This applies to both Metro and desktop apps. You can send info to another Metro app via “contracts”, such as the Share contract in Metro. But you can only use contracts provided by Microsoft, and these contracts can only be initiated by the user, not in code. If you do need to communicate with another app, even on the same machine, then you’ll need to use network protocols, such as IP sockets, http, or web services.
With all this hype, what is Metro replacing? Something has to die, right? I’m sure each of us will draw our own conclusions on that, but I will say that Microsoft always emphasizes the shiny new thing. That doesn’t mean existing MS technologies will go away, or that MS will stop investing in those technologies. At the same time, Microsoft is clearly investing heavily in Metro and will continue to do so, at least until the next shiny new thing comes along. From a technical point of view, to the extent that you can port your code (based on restrictions) and that you choose to adopt the Metro design, Metro replaces almost everything. If every desktop app were rewritten in Metro, then it could even replace Windows as a whole. It’s hard to know what Microsoft’s aspirations are in this regard, but based on the targeted nature of Metro and its capabilities, I don’t see this happening, not for a long, long time, if ever. From the point of view of each technology…
.NET: I can unequivocally say that the .NET Framework is here to stay. Since Metro is only client-side technology, you will need something on the server side, and Microsoft will continue to push .NET for that. When building C#/VB apps, Metro does use the .NET Framework, however it restricts you to a subset of functionality. For example, you cannot use the System.Data namespace, which means no ADO.NET, which means you can’t access a database directly from Metro. You’ll need to build the data access into the server side using .NET. For what it’s worth, I believe Silverlight has the same restriction. Microsoft seems to be deciding what the .NET restrictions are based in part on what they did in Silverlight (more on that topic at http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C). Lastly, do I even need to mention ASP.NET? Browser-based web apps aren’t going anywhere.
Silverlight/WPF: As far as being deprecated, I worry about Silverlight the most. MS will be pushing Metro on the desktop and HTML5 through the browser. Some will say that WPF is already dead. On the other hand, PhotoShop was shown at the keynote and given as an example of an app that would NOT be appropriate for Metro, due to its dense UI design with a focus on productivity. Many line-of-business applications could be described in the same way, so there is still a place for these technologies. As it stands, there are new versions coming out for both, but beyond the next version, we don’t know. Now that the XAML group is part of Windows, Metro will no doubt get the lion’s share of the resources, but I hope investment continues on Silverlight and WPF.
Win32/C++: For the most part, C++ developers will be using WinRT in Metro rather than the Win32 API. MS does allow access to a subset of Win32 APIs that have functionality not addressed in WinRT (http://msdn.microsoft.com/en-us/library/windows/apps/br205757%28v=VS.85%29.aspx), but at this level, WinRT and Win32 really are separate worlds. That said, Win32 is the most used API on the planet. Even if MS doesn’t invest another cent into it, it will be here a long time.
Let’s talk about preserving your existing investments. Microsoft is focused on making sure your existing skills can be used when building Metro apps. That is, as long as those skills include HTML/JS, C#/VB, or C++. You might even be able to port existing code into Metro, but it’s not copy and paste, and it has to adhere to the restrictions. Microsoft demoed porting existing XAML and code from Silverlight and Windows Phone apps that were already written in the MVVM pattern used by Metro. If you want to move from a Windows Forms UI, I doubt there is much you can keep, and you’ll be rewriting the UI in Metro. From FoxPro, you don’t get to keep anything, except what you use on the server side. I’m not a C++ developer, but I imagine porting C++ code would involve replacing Win32 calls with WinRT functionality. I don’t know how feasible that is, so you may be able to bring in code that doesn’t reference Win32 (good luck finding some) and rewrite the rest to use WinRT.
As far as compiled libraries, you can’t just add a reference to a .NET DLL in a Metro app. You can, however, create a “Portable Library” that can be called from both Metro and standard .NET, as long as the library sticks to the Metro subset of .NET. I don’t know how this works in C++, but it may be the same story. MS showed bringing the Boost library into a Metro app, but I don’t know if that was Boost source code or a compiled library.
Moving on to user interface… Microsoft is providing developers with clear design guidelines for Metro apps. Designers may not like being told how to design their apps, but I don’t think it is a requirement that you follow the Microsoft rules. Personally, I am glad that Microsoft is providing guidance on Metro design, because we got no such guidance with WPF or Silverlight. How many times have you seen WPF or Silverlight session where the speaker says “I’m not a designer…”, and then proceeds to show a crappy looking UI that makes you wonder why you would want to use the technology at all? With Metro, I can use the MS templates, follow the guidelines, and end up with an attractive, functional app. If I want to do something extra special, then I can get a professional designer involved.
What about deployment of Metro apps? You will be able to use “side-loading” to test and debug your apps on a limited number of devices. Otherwise, you can’t directly install your Metro app on a device. It must be deployed through the online Windows Store. Each app you upload will be certified against a series of tests to ensure compatibility and compliance. So, if you’re thinking about using some tricks to get around the restrictions I’ve already mentioned, that may work on your machine, but the certification tests will fail and you won’t be able to deploy your app. Microsoft hasn’t released details yet, but most expect they will do the same as the Windows Phone store and take 30% of the price of Metro apps. You may have heard that the store will be free, but I believe that is only for the listing of Windows desktop (non-Metro) apps, in which case, MS just links to your site, but doesn’t handle deployment. There will also be an enterprise deployment option for companies that want to deploy apps internally. Apple charges $299/year so that you can distribute code YOU write to devices YOU purchased. That’s not a lot of money, but it just rubs me the wrong way, so we’ll see what Microsoft does in this regard.
So, Microsoft has Metro locked down pretty tight. Metro limits you to a subset of .NET. You can’t automate other applications or reference existing “desktop” DLLs. MS forces you to deploy through their store and takes 30% off the top. This is not characteristic of the Microsoft we have worked with all these years, but they are following Apple’s lead. At the same time, by exerting this level of control, Microsoft can ensure the integrity, stability, and security of the Metro experience. The restrictions prevent outside code from polluting and compromising the Metro environment. If that all seems a little too Big Brother to you, you still have the option of creating Windows desktop and HTML applications without the restrictions, both of which can still be touch enabled.
With all of this in mind, should you run out and rewrite all of your applications for Metro? Every day, I work on a FoxPro line-of-business app with a heavy emphasis on data entry and productivity. The fact that we’re still using FoxPro should tell you that we don’t jump at every new technology that comes out of Microsoft. But, even if this were a WPF or Silverlight app, I don’t think it would be a good candidate for the Metro style. Maybe that’s a lack of imagination on my part, but displaying info one screen at a time or with a bunch of panning or scrolling would cause a large hit to productivity. Now, are there pieces of our app that I could expose to a wider audience using a simpler interface with touch capabilities? Yes. And the developer and user experience in Metro is compelling enough that I might just target it over an HTML interface that works on multiple devices. I’m looking at Metro as an environment where I can offer new apps and experiences to users when it makes sense, not as a replacement for existing technologies.