Questions about the Windows Runtime and the Windows update cycle

Windows 8 WinRT

After spending a good amount of the past month with the Windows Runtime (or WinRT as it was also known before the drunken “Windows RT” branding bus decided to crash the party), it had occurred to me the other day there is still a big unanswered question mark over how exactly Windows Runtime will evolve.

With some practical development experience under my belt now, I believe I can say with some credibility that the Windows Runtime “framework” in its current state is sufficiently primitive – it works and has the basic APIs and controls you expect, but there’s still fundamentals (*cough* no Flyout control in XAML) and nice-to-haves missing with no expectation this will change by RTM.

Of course that’s expected when you’ve essentially reset decades of evolution which has matured frameworks like Windows Presentation Foundation and Silverlight, replacing it with one that is more modern and simplified. That’s not an issue. But what is worrying is how little we know of how quickly Windows Runtime can “catch up” to its predecessors and evolve over time.

An important aspect of this is the fact that for all intents and purposes Windows Runtime as the framework and Windows 8 as the operating system are interlocked. For example, in Visual Studio 11 when creating a Metro-style app, there’s no “Target framework” for a version of Windows Runtime. There isn’t one. You’re just writing an app for Windows 8. Case closed.

In comparison, this is no different to platforms like Apple iOS and even Microsoft’s Windows Phone which also have this framework-OS tie-in. The APIs and the operating system are tied. However there’s one exception – they can and do deliver more frequent platform update/refreshes.

As iOS has shown, Apple was able to update and release new developer framework APIs with every major iOS release on a yearly schedule. Similarly Windows Phone has done the same with NoDo and Mango updates which has drastically evolved the APIs.

If the traditional 3-year-ish refresh cycle for Windows is to be expected, that’s an awfully long time to wait for updates to Windows Runtime APIs. Not only might the framework limit developers what is possible (or practical) for a very long time, it would also slow adoption of newer technology trends that occur between the cycles (which has always been a problem for Windows).

To get around this issue, I would imagine Microsoft is considering or has considered a few options – each with its own pros and cons. They could be,

  • Deliver toolkit-based package – Like the Silverlight Toolkit, which is a separate but frequently updated library of controls and helpers. This is limited to mostly frontend controls and the platform is still limited by the underlying APIs.
  • Update Windows Runtime through Windows Update patches or service packs – If patches contained changes to Windows Runtime, it would allow fast and easy deployment of API changes to a large userbase, but it would introduce app compatibility issues if adoption of updates isn’t as quick or widespread as new iOS or Windows Phone releases.
  • Quicker Windows refresh cycles – self explanatory with its obvious issues in enterprise deployment and adoption

If Microsoft has chosen a strategy, they’ve sure kept that to themselves and will continue to do so well after the Windows 8 general availability. After all, no consumer would or should care. But now with a developer hat on, it’s a question that beckons to be answered sooner than later. What will happen to Windows Runtime after Windows 8 is “done”?

19 insightful thoughts

  1. The good thing about WinRT is that since it’s sandboxed, if an app doesn’t do anything it’s not supposed to, Microsoft can update WinRT without breaking apps. I’m sure they’ll have yearly platform updates, otherwise, they’re going to get left behind.

    1. But it would increase some burden on the developer to be aware of differences in WinRT API “versioning”. Depending on how it’s deployed to end-users, they may or may not have it on their machines and it could break the app compatibility if it depended on some new API.

      1. True. However, I expect versionning to come as soon as Windows 8 SP1 comes out. Current VS11 don’t need versionning, there’s only one version.

    2. “if an app doesn’t do anything it’s not supposed to, Microsoft can…”
      Sure, and if we all love each other, we can construct a society with no crime or poverty, and live happy together in Happy-Land, in a gumdrop house on Lollipop Lane.

  2. They should definitely choose the 2nd option. Windows Update is a very mature and reliable technology which has worked for more than a decade. They can tackle the app compatibility issue by simply asking the user to update Windows seamlessly whenever they try to install an incompatible Metro app from the Windows Store.

    1. The consequence of that is there is no need for Windows 9. I do not think it’s realistic (or better to say, this option just masks the problem, sooner or later you will get fragmentation and versioning anyway).

      1. On the second though, may be that’s the plan – to force people to upgrade device, not OS

      2. There will always be some need or reason to pick a new version of Windows. Most general Windows applications today are Vista or Windows 7 only. Developers aren’t aiming for XP anymore. The same will probably happen with Metro apps too. Microsoft will officially stop updates at some point to an older OS.

        Microsoft will likely update for Windows 8 apps for a long time until Windows 10 or 11 or something.

      3. @Dmitry, can you give me at least 5 examples of apps which are Vista/7 only which aren’t Microsoft or Adobe apps?

  3. This has bothered me too. I’m all for Separating the Concerns between the OS primitives (the basic API services to access services) and the controls and other stuff that are more value-add. There’s no Windows Runtime Toolkit yet, but I would expect one to appear (probably more than one, actually) and I would hope that MS new found love of open source contributions would continue.

    As for the primitive APIs, they would be revised with the OS (new peripheral support etc). I don’t think a 3-year cadence is going to cut it for Win8, with WinRT competing with the iPad’s yearly cycle. This is where Windows Update comes in, the market palce will ensure that apps requiring specific API features will only be deployed after the update has been rolled out.

    That’s my thinking anyway….

  4. Here is what will probably happen:
    1) Microsoft will release an update to WinRT via Windows Update. These updates will be a “side-by-side” update, so that existing applications written for an earlier version will continue to be compatible. Because of this, these updates may even be automatic for most users, included by default along with security updates.
    2) Enterprise IT departments will need to approve them just as they have to approve even security updates. But, since the update shouldn’t break compatibility with existing apps, these updates will normally just get automatic approval like security updates (unless your IT department is being stupid, which sadly is a common occurence).
    3) Wireless data carriers and OEMs will probably have their grubby hands all over the update process for WindowsRT tablets, so who knows when or if existing devices get updates.
    4) Developers will have an interface for selecting which version of the runtime their app targets. If we’re lucky, we’ll also be able to provide a package for each version of the runtime and be able to update the app for each target runtime version independently.

  5. I have heard talk of “Platform Updates” coming at a quicker cycle than Windows versions. Perhaps it will be a minor/major update twice a year as it has been with Windows Phone.

  6. I’ve had the same concern. WinRT is pretty immature at this point, and will need to receive updates much more quickly than Windows itself if it’s really going to grow.

    In fact, the entire Metro UI is pretty immature. I’ve wondered if they might need to release intermediate updates to Metro between 8 and 9. Ideally we’d see updates to Metro yearly, while NT might still get updates only every 2-3 years. Sort of like the Windows Phone / Windows CE relationship.

  7. Ida guessed that Metro’s minimalism means that as UI libraries are developed, you can simply drag them in with your project. Far as I can tell all components work this way too. Why provide bloat as part of the platform when you can ship bloat in your app – or not – as needed?

  8. Well, my concern about Windows Runtime is that since it’s advetised by Microsoft as the future of Windows application development, I don’t like the idea of Windows becoming a more closed-down eco-system like Apple. For example, today you can write a piece of software for Windows and deploy it any way you want, you’re not tied to one place (in this case the Windows Store), have to give Microsoft a 30% cut-off, or have to pay a fee to even get a developer license. While for consumers the Windows Store surely means a higher level of security and better virus and malware protection, I think for “power-users” (or: users that are aware of what they do when they use a computer) it is something that can get in the way, especially when you think about open source solutions. I’m a developer and not a consumer user most of the time, so I want at least an option to be in full control of my system. I’d like to be able to install applications from any “non-trusted source” I know that is safe, for example. I don’t like Windows to become another iOS. I would like it to remain a platform that is open and flexible from development to deployment.

    Well, nevertheless the Windows Runtime has to evolve quickly, and I’m sure Microsoft is doing so because they made such a big bet (kudos) in creating that platform. It would be just silly to let it sit around like this for the next three years.

Leave a Reply