Earlier today, I made an update to a previous post, cause I had misunderstood some things regarding WinRT. It is however getting clearer and clearer as we get more and more information.
This post is a way for me to try to explain the Windows 8 developer story as I see it today. I am probably wrong in a hundred different ways, as I am trying to stitch together lots of little pieces of information to get a bigger picture… But I am at least going to try to get what I believe down on paper, and also add my own reflections of course…
Building apps for Windows 8 can be done in flavors, either in the form of “normal” windows apps or in the form of what Microsoft calls “Metro style Applications”.
And this is the first place where I find Microsoft being far off the mark. I know it is only a name, but it is wrong. Metro is a design guideline. It tells s to build light and fast apps with a focus on typography and so on. It is not a technology or platform. Yes, we should definitely build our Win8 apps using the Metro guidelines if we want to fit into the UI and get help from pre-existing controls and so on. But, there is nothing keeping us from disregarding from this guideline at all. So for the rest of the post, “Metro style applications” will be called Win 8 apps…
Anyhow…both Win8 apps and regular apps are built using the same tools that we normally do. That is VS and Blend. And, they can be built in a variety of languages.
Win 8 apps can be built either using C/C++, C#/VB.NET or JavaScript. In the case of C/C++/C#/VB.NET, the UI is XAML based, a whole lot like Silverlight or WPF. In the case of JavaScript however, the UI is done in HTML (5) and CSS (3). They do however always run in fullscreen mode, and have to abide to certain restrictions in the form or launch time, suspension and so on. They are also building on the idea of an “application web” using contracts, which basically means that by implementing different contracts in our apps, they can work together and extend the functionality of each other and Windows as more and more apps are installed.
Our normal apps are built using any of the technologies we have used before, which means C, C++, C#, VB.NET, F# etc. There is nothing new here. The “old” ways are still there, and still work perfectly fine. Any app that runs on Win 7 will run on Win 8 as well.
The difference however is in the layers beneath the IL and in the runtime. And this is where I am getting out on thin ice, but I will try to explain it in my terms. I might be wrong, and in that case I am sorry, but here it goes…
In regular Windows apps, we have the CLR on top of the Win32 API, as well as a base class library full of what we normally just call .NET. When we launch a .NET application, the CLR hosts that application and makes sure that the calls being made are mapped nicely to the Win32 API making everything work. And as I said before, there is nothing new here…
What is new, is the way that Win 8 apps work. They are built into packages and run under a new runtime called WinRT. Win RT is a bit different. It is a layer of native code placed on top of the Win32 API. But native code can normally not be called straight from managed code, as managed code requires a certain amount of metadata to be able to use it. So what WinRT does, is that it exposes a set of metadata files for the native code, making sure that our managed code can communicate with it, without having to add a whole lot of stuff in between. This makes it very fast.
The WinRT is also designed in a way that makes it easy to understand and use. It is designed in an object oriented kind of way, abstracting away the interface based stuff underneath it. But at the same time as it makes the Win32 API nice and easy to use through a layer of native code, it also limits the surface.
So what do I mean by limiting the surface? Well, as the WinRT was designed and built, a lot of the standard functionality in Win32 was removed, or rather not included in the WinRT. This makes the surface smaller, and also makes the apps less likely to be able to change the system in a bad way. Sort of like a sandbox. The less a developer has access to, the less harm can he do.
As a part of building WinRT, they added a bunch of neat things to abstract away the complexities going on under the hood. So if you for example need the user to take a picture with the webcam, you only need a couple of lines of code, and the system will start the webcam, give the user a UI to work with, grab the picture and return it. Much like WP7 works. This makes coding super easy, gives the user a unified way of doing things and minimizes the things that can go wrong.
This also makes it easy for Windows to require you to explicitly request access to certain features before being able to use them. Once again securing the system for the end-user.
There are lots of these simplified APIs in WinRT that make life easier. They however does not exist in regular .NET apps. But on the other hand, in the regular old school apps, we can do whatever we like. It is more code, but also more flexibility…
Regular apps are also not allowed to be part of the “application web”. At least not at the moment, and it seems very unlikely that that will change. So they will not be able to profit from other installed apps, or help extend functionality of other apps.
Win 8 apps also need to be packaged and signed, something that VS handles for us without any problems. However, it requires Windows 8 features to be able to do it. So currently, we can only build Win 8 apps on Windows 8 machines. Something that hopefully will be handled in the future, making it possible to do it on non Windows 8 build servers. But there has been very little or no information about this so far.
This is all good and dandy, but what I feel is missing from Microsoft’s information so far is the fact that regular Windows apps is still there. They are still a viable option. No, they won’t get some of the nice features provided by WinRT, but on the other hand they won’t have the limitations of it either. And wit limitations I mean things like having a smaller API as well as having the whole idea of suspending apps.
And talking about suspending apps brings me to one more point about Win 8 apps. They are pretty much not multitask at all. They work like on Windows Phone 7. As soon as an app gets placed “behind” another app, it gets suspended and potentially killed off. So we will have to save state and so on, just like on the phone.
This might not be a problem in some apps, but in some it will be a major problem. I see the cool idea behind Win 8 apps, and I believe they might spawn a new type of apps for Windows, as well as ignite the interest for app development in amateur devs. But, I do not see it as the natural platform for enterprise applications. Sure, in some scenarios it will work fine for those as well, but I believe that a lot of enterprises out there would expect something else…
So, the conclusion… Well, I am super excited (remember I am a Microsoft fanboy) about Win 8 apps, and have a good app in mind already. So I will definitely play with those, but I want to remind everyone to take a look at the options before rushing ahead. They are not the best solution for everything. They are great for touch-based, tablet kind of apps, but perhaps not that great for enterprise apps… I believe in using the best platform/technology for the job, and examining the variables involved before making a decision…
So, that is my thoughts about that for now. As I attend more sessions I might figure out that I am wrong, or that I have misunderstood something, but for now this is what I think I have understood…
Cheers!