Never mind the hype about the user interface, there is a structural change in Windows 8 that really does mark the start of a new era. Some of the superficial details appear to be the same but underneath the world really has changed.

Yesterday the Win32 API that has sat underneath every Windows application was sidelined by Windows Run Time, WinRT- a C++ object-oriented API.

WinRT isn't a shell that sits underneath the Win32 layer; it is an application interface at the same level. Applications can choose to use either the old Win32 API or the new WinRT but not both. Hence this is a real break with the past.

From the developer's point of view September 13, 2011 is the day that Windows started again - it is year zero (again) for Microsoft developers.

At this point you may say that this is too sensational and the old technologies will still be there and still be supported. This is true, but it ignores what a fickle group of people programmers are. You might well be shouting about keeping Win32, WPF, Silverlight and the rest because you have an investment, but given a new technology what are you going to choose for your next brand new project.

It is a law of computing that a new platform immediately turns the existing platform into a legacy problem, even if they are supposed to coexist.

New isn't always better but it always has the attraction of being new.

So what does this new world look like?

It looks a lot like programming a mobile phone. When you start using Windows 8, and in particular when you start creating apps, it just feels a lot like creating apps for Windows Phone 7. A lot of this has to do with the way that the project templates are set up to generate multi-page touch user interfaces. You can create something that looks like a form with a button and textboxes, but overlapping Win Forms are now a thing of the past. Win Forms were provided by the Win32 API and reinvented by WPF. Both could be used from a managed .NET language, but only Win32 was available from an unmanaged language.

Of course WinRT is delivered to the programmer via XAML (or HTML), so it looks superficially as if you are using a variant on WPF, or Silverlight even, but you are not. XAML is just one of the possible markup languages that create WinRT UIs.

Let me say it clearly yet again: no more Win Forms.

There is also no more need for P/invoke. As Win32 isn't being used there is nothing to invoke. There is no API lurking beneath the covers. So anything that you used to do via P/Invoke you will now have to find a way to do via WinRT. Of course, you can still use Win Forms and the whole Win32 API, but if you do then your application will run under the familiar desktop and not the new Metro UI.

When you create a Page object with WinRT and run it then it expands to fill the entire screen real estate - there are no overlapping windows, just as there are no overlapping windows on a mobile phone. If you want overlapping windows and dialog boxes you need to stay on the desktop. In a sense: Metro takes the windows out of Windows.

You have to ask the question - if overlapping windows are such a bad idea for a desktop machine why is it that they have been a central feature of operating systems since graphical interfaces were invented?

So we have a list of things that we have lost in moving to Metro land... what do we gain?

The only real gain is a unity with a phone-like UI.

Admittedly you can now use HTML and JavaScript to create the same sort of application but it isn't clear why you would want to. The JavaScript that you have to write isn't like any JavaScript you would write anywhere else because of the need to call so many internal system methods. This isn't standards-compliant HTML5/CSS/JavaScript but a custom environment. In short, your Windows HTML5 apps will work on Windows 8 and nothing else unless you customize them heavily.

What of Silverlight and what of Windows Phone 7?

Silverlight currently serves two purposes in life. It lets you create web applications using .NET and it lets you create Windows Phone 7 applications using .NET. But now we have a way to create mobile applications using Windows 8 and Silverlight is nowhere to be seen. Surely Windows Phone 7 has to move to a non-Silverlight approach for development? If it doesn't, where is the unity between tablets running Windows 8 and Windows Phone 7 devices? 

Oddly, what seems to be missing from the Metro approach are web applications. You can't simply take an HTML5 app that runs under Metro and treat it like a web page - the JavaScript and the services available are very different. Of course, Microsoft could make a browser that does run Metro HTML5 apps, but that's not a standards based approach.

We are in the early days yet and there is time for things to mature, but at the moment there seems to be a lot of missing pieces from the Metro approach. Perhaps there is a unity that is difficult to see on the first encounter. Certainly the uniformity in using C#, Visual Basic, C++ and JavaScript when creating a Metro application is admirable.

I guess the final question is - do I really want to create a Metro application?

The answer, as always, is yes - if the user wants to run them.

See also:

Windows 8 - the Developer's Take

Creating JavaScript/HTML5 Windows 8 Applications

If you would like to be informed about new articles on I Programmer you can subscribe to our RSS feed, follow us on Twitter or Facebook or sign up for our weekly newsletter.