Profile photo of marc


Thoughts on Windows 8 and “Metro”

September 17, 2011 in .NET, Data Abstract, Delphi, Elements, non-tech, Oxygene, Platforms, RemObjects, Visual Studio, Windows

I just got back home from 360iDev in Denver, one of the best third party conferences on iOS development.

In parallel, another big conference has been going on in Anaheim, introducing big and significant changes to a completely different platform. I’m talking of course about //build/. As you probably heard, if you’re not living under a rock, Microsoft announced both Windows 8 and – more interesting to us as developers – Visual Studio 11, and has made preview releases of both products available, as well.

The good (and unexpected) news is that all the doomsaying about .NET has proven to be false; if anything, Windows 8 strengthens .NET as one of three ways to build high quality apps for its new Metro application platform. It does so by essentially making .NET, C++ and HTML5+JavaScript equivalent tools that can use the same APIs to create apps. Given the choice of those three, what would you choose? Clearly, .NET is the winner here.

XAML, integral part of both WPF and Silverlight in the past, has been promoted to the default UI paradigm for “modern apps”; it is interesting to see that (a) Microsoft is dropping the WPF nomenclature and talking about XAML itself and (b) making XAML UI also accessible to non-managed development using C++. The new UI layer that lets you build Metro apps is backed by WinRT, a managed class library (and subset of the full .NET framework), and together Metro and WinRT are presented as the way forward for building what Microsoft, literally, called “modern apps”. Classic Win32/Win64-based applications are still supported, but relegated to the “old” Windows desktop. It also seems (although Microsoft has not been completely precise in talking about this, so there is still some discussion and interpretation going on) that the Win32 model will not be supported at all on ARM based Windows 8 slates (i.e. not only will x86/x64-built applications not run on ARM devices, which seems obvious; no, there will most likely also not be the option to recompile classic Win32 apps for ARM. To run on ARM systems (and Microsoft is making it clear that they expect all/most tablets shipping with Windows 8 to be ARM based), the new Metro/WinRT APIs will need to be used.

It sounds like this seems to spell the end of traditional “native” Win32 development tools, at least for “modern” Windows applications.

Metro itself looks like an impressive and ambitions “reimagination” of Windows, indeed. Of course only time will tell how successful it will be and how well it will run (in my first attempts running the Windows 8 Developer Preview in VMware Fusion, it certainly feels awkward and clunky in places, and unnavigatable without touch in others), but IMHO one must applaud Microsoft for taking such a bold step.

For developers, creating apps for Metro will be a paradigm shift, much akin to targeting a completely different platform. In fact, watching the excellent Eight Traits of Great Metro Apps presentation, a lot of the purposeful “limitations” of the development remind me of iOS: the way application backgrounding is handled (your app will be killed as it gets off screen) or how Windows Push Notifications will need to be used to give the appearance of non-running applications staying live, updating their tile and providing notifications.

This goes to show, I think, how important it is to develop applications with platform-appropriate tools, not one-size-fits-all solutions. I’ve made the argument before that anyone trying to use Win32-rooted tools to create applications, say, for Mac or iOS is doomed to fail and produce sub-par results. The same, I believe, will now apply to using Win32-based tools to create Windows 8 apps: Your applications will look out of place, and/or be relegated to the legacy desktop.

In the same vain, it is great and refreshing to see Microsoft talk about and stress how important good design, a quality user experience and conformance to the Metro design paradigm is (same video). They really copied the right pages from the Apple playbook here.

So What about Our Tools?

Windows and .NET are a very important platform for us here at RemObjects, and that continues to be the case going forward. The teams here are already hard at work at providing support for VS11, WinRT and Metro, based on previous access we had to internal betas as well as of course the Developer Preview that is now available via MSDN to everyone.

Data Abstract (and RemObjects SDK) will be integrated into Visual Studio 11 soon, and will let you build Metro clients (something which is especially important since the client data access story on Metro/WinRT seems to be pretty thin, otherwise). We’re not forgetting Hydra, either.

And Oxygene will, of course, let you create Metro/WinRT applications, allowing you to build native applications with lots of shared Object Pascal code for Windows Phone 7, Android and Metro – next to, of course, regular Windows and cross-platform apps with .NET, Mono and Java.

I don’t want to promise exact timelines, but we’ll let you know more and will have beta bits for customers to play with, Real Soon™.

Exciting Times Ahead

As most of you know, I’m mostly a “Mac and iOS guy” and have not been a big fan of the Microsoft platform for a while. But what I’m seeing here looks impressive, and while I’m not contemplating to switch <g>, real competition is good for everyone, and it is great to see a new quality platform coming out of Microsoft, and I believe this will be a great opportunity (and challenge) for Windows developers. The next couple of years will be very exciting, as far as development platforms go!


11 responses to Thoughts on Windows 8 and “Metro”

  1. “I’ve made the argument before that anyone trying to use Win32-rooted tools to create applications, say, for Mac or iOS is doomed to fail and produce sub-par results.”

    In which you would include Delphi and Firemonkey?

  2. Interesting.

    I hope for my sake you’re wrong – I like being in my comfort zone… will be watching things unfold with interest over the next 12 months.

    • Indeed, i think the next year or two was already going to very interesting, on a lot of fronts; Windows 8 and Metro certainly adds to that, and will make sure we’re not bored. ;)

      WRT to Delphi/FireMonkey: don’t let what i said above keep you from giving it a try; there’s certainly a lot of different approaches to cross platform development – it just happens to be my personal opinion and preference that i like to use the platform native tools (say, Xcode/Cocoa on Mac/iOS, .NET for Windows Phone 7, Java for Android) rather than abstraction layers that make all platforms look the same. i think each platform and each platform’s development tools have their unique ways of doing things, and embracing them, rather than “fighting the framework” will usually give the best results.

      I think Delphi developers, in particular, have a tendency to want everything funneled into a Delphi abstraction, and are often missing out on a whole range of great technologies that are out there (and often a joy to work with) while they wait for Delphi to provide a step in. And i say that fully aware that i was doing the same for a long time, for example never giving .NET a real chance “back then” while i waited for Delphi 8 to come and support it (and was, of course disappointed by it ;). Im glad i didn’t do the same mistake WRT Xcode, as not only have i been able to code for Mac and iOS for years already, i also found i actually enjoyed using those tools far more than i ever enjoyed working with anything else.

      But, again, that’s just my personal opinion/experience. if a different solution (including Delphi/FireMonkey) works out well for you, thats of course great (and our “for Delphi” products, if you use them, will support you on that path all the way)


      • marc,

        Firstly, apologies for jumping into this conversation thread.

        Secondly, it’s nice to hear your confirmation of continuing support for your Delphi products. I’m a v.happy (and relieved) RO SDK and DataAbstract user.

        Whilst I do tend to agree with your opinion regarding tooling, I do feel its a rather utopian view. There are things that, imho, get in the way.

        Sure, I would *love* to go out, buy a Mac and start producing an OS X version of my apps. But then, my customer base (which is btw, the largest single employer in europe) have 99.9% of their machines on Windows XP. (Yes, they are very behind the curve when it comes to new tech).

        I work for myself, which gives me a nice “quality” of life, but I’m no Richard Branson ;) Any expenditure on new tooling (including XE2) has to undergo very careful consideration. And of course, expenditure on tooling includes the weeks/months of not earning whilst I get up to speed on the tools, and then actually write something useful. And then of course there’s new license fees for the new components that give me what I already have in Delphi from RO, DevExpress, etc.

        Given that any investment in new tooling is a massive time & financial commitment, picking the wrong platform/tools could be a devastating mistake. Do I go .NET or Web? And now there’s Metro/WinRT to consider. I have to follow my customers’ lead, and they’re still Win32 native.

        When I do move platforms & tools (and yes, I think it’s a “when” not “if”) I would *dearly* love someone to put on a “[insert name of new platform] for Delphi Developers” course. And yes, I would pay for that course as the alternative would be weeks of unproductive (and hence costly) self-learning.

        I’m aware that this may sound like yet-another-whiny-Delphi-dev, but that’s not my intention, I just wanted to throw a little of my situation into the mix. Perhaps subconsciously I’m looking for some answers?



        • Stuart,

          firstly: never apologize ;). your comment is welcomed and appreciated.

          oh, sure: i’m not saying that everyone should develop for the Mac. obviously, there’s a business case to be made whether creating s mac application makes sense for your product or not, and with 99% Windows customers (and assuming that is a good number for you) there might not be one in your case (but then, who knows 99% of your customer base might be only 10% of your potential customer base ;).

          i’m just saying that *if* one develops for a different platform, one needs to choose the right tools. in particular on Mac and iOS, customers are *very* sensitive to well-done native UIs, and (assuming the market is there, for the kind of app), having a good, native UI can be the make-it-or-break-it factor.

          as for the “[insert name of new platform] for Delphi Developers” – i think we did a bit of that at DSConf last spring; we’ll probably do it again ;)

          • Thanks marc. You’re right about the numbers of course. I’m targeting a small niche within a huge organisation, but with feint hopes to take that niche to other organisations world wide, and who knows what they’re running? (Note to self: do some homework)

            WRT DSConf, do you make session replays available for those not able to attend?

        • I hear you whining and recommend Remobjects to replace ‘This is not your Daddy’s Pascal’ to ‘This is not your great Granny’s Pascal’;). Honestly my both GGs worked and made a living under lot harder conditions. They did not need a training in cooking when presenting something new and I also invest 30/10 to 40/15 (productive work-time/research time). Passion comes before making money anything does not work very good.

          ‘Still XP’ assuming many companies upgraded to XP at the time of SVP2 or SVP2 on the the horizon. I take my hat off to their challenges if the Enterprise is this big. I show a certain understanding for those companies wishes for a ‘terminal’ and replacing the one or other IT function with a ready made solution in order to somehow mange complexity. If you have 1 to 2k SAP from consultants to support people at one trust then things like Metro are not the real challenge.

          Metro is a response to the fun societies demands in the context of a type writer. Very limited perspective. This ‘rectanglation’ by force and putting things into one default layout (at least presented this way from the video), looks like a somehow quick way to hide conceptual leaks in the area of MS multi-touch devices and a way to somehow jump on a train that departed a long time ago.

          • Michael,

            Thanks for your response, but your points about parents/grand-parents leave me a little confused.

            Yes, my customers are still mostly XP, and yes, they have a massively complex Enterprise. (I’ve even recently seen Windows 2000 desktops – I have to conditionally deploy gdiplus.dll in the setup.exe just in case). That said, one of my customers has just got 3 tablets PC’s running Windows 7-64. (64-bit was required to run some Adobe software apparently).

            I agree with you that Metro does look a little like square-peg in round hole. I see no reason that the Windows desktop could not have evolved into Metro, rather than starting from scratch. Seems a little like “throwing the baby out with the bath water” to me. (Admittedly, it’s not been thrown out, more “relegated”, but I hope you see the point).


          • Stuart – :) Oh, no the point with the grand-parents was not addressed at you. I just used a nice introduction. Whining does not help anyway.

            Agreed it is not so simple to have on one hand existing developments that have to be maintained and serviced and beside get to know a second OS was always hard and especially since the OSes evolved into platforms with offerings for desktop and mobile …

            This worked for the web because the web started simple with scripting alternatives and was very early designed in order to provide a simple path for non developers especially but evolved from this.

            I have no idea why MS does the step with the Metro on Desktop … there is a huge club with ‘Things the world does not need’ imho this club will welcome a new member soon.

          • Thanks Michael, I understand a little better now. :)

            Indeed, I can foresee a lot of “power” users almost immediately turning Metro off. In fact I know one who was given a W8 beta tablet, and did exactly that. :)

            I think the problem with Metro is that it falls into the category of “one-size-fits-all” — which is one of marcs’ pet-hates (rightly so). There has to be a desktop PC OS, and there has to be mobile/tablet versions. They have to be different (or behave differently) because simply put, tablets/mobiles emphasis information consumption, whereas desktop PC’s (mac AND windows) emphasis content creation. The two are just not compatible with the same OS interface.