Windows vNext with native ARM support paves way for a unified kernel

At the Microsoft Special Press Conference ahead of CES 2011 where Steven Sinofsky first revealed information about the next version of Windows with native ARM support, one journalist asked a great question – since Windows Phone is ARM-centric, whether the next version of Windows will also power the next major release of Windows Phone? Sinofsky avoided to answer the question entirely.

If you think about Steve Ballmer’s quote from Microsoft’s keynote, “Windows will be everywhere”, desktops, laptops, slates/tablets, phones and even Surfaces could all be considered form factors of a Windows PC, running the same operating system across x86 and ARM.

Although the exact definition of a kernel is highly contentious, for the purpose of this discussion I’m looking at it in the perspective of the engineering efforts where the functionality enabled by a single codebase can be used to empower every device running Windows.

Bearing in mind a unified kernel does not necessarily mean the same 10GB+ OS footprint and the same UI for every variation of Windows, what it should mean is faster and more consistent adoption of newer technologies and standards across the Windows family. At the very least, basic needs like high performance, connectivity and long battery life is applicable for all devices.

For a higher level example, the Windows 7 kernel introduced native framework support for biometric devices like fingerprint scanners. This removed the need for vendors to provide their own drivers, applications and SDKs for users and developers to take advantage of them.

Whereas biometrics might make its way into embedded devices and phones running a WinCE-based system (like Windows Phone 7), OEMs would currently have to wait for a different WinCE update cycle to introduce support for biometrics too, if they’re even considering it for the next version.

In an environment with a unified OS, such kernel-level features would be instantly available to all Windows devices at the same time delivering a much more consistent experience across form factors.

Disclosure: I am attending CES 2011 as a guest of Microsoft Australia.

13 insightful thoughts

  1. the downside is you have a infinetely increased surface area for attach vectors (like viruses etc). One platform means your WP7 ecosystem which was only 1.5million devices can now potentially be infected as easily as the ~1 billion ecosystem that is Windows desktop

    I guess you take the good with the bad

    1. Isn’t that basically what MinWin is all about? tiny unified Windows kernel with a small (also unified) attack surface.

  2. I wonder what the update cycles will look like if desktop n mobile os’s are using the unified kerenel. Windows is on a 3 yr release cycle…and WP on 3 month cycle…how will that work?

    1. Well, iOS is a variant of Mac OS X, yet it has its own update schedule which has so far been every mid year, while Mac OS X has been every two years. So, it could work the same for Windows too. Look at products like Windows Server and Client. Although Microsoft RTMed Windows 7/Server 2008 R2 in July of 2009, it kept working on updated variants of Windows, example, SBS which is I believe 6.1.7900.

      Windows Vista and Server 2008 was another example, Vista went to manufacturing in November of 2006, yet the first Service Pack that came preloaded with Server 2008 was also the first SP for Vista which unified the codebase. Anything is possible with software 🙂

  3. Kernels normally dont change that much. What changes is the outer core(UI,apps) etc. So it is entirely possible for WP & Windows to have different release cycles assuming that the kernel support for particular features(now and future anticipated ones) are locked down.

  4. I’m confident this is the direction Microsoft is going and would further justify Minwin and other efforts to isolate/tier service dependencies.

  5. i really doubt this will work out much considering VIA dont make full use of their support so why would ARM builders bother?

  6. It’s not a bad strategy except that MS is late with it. Internally at least, NT on ARM should have been here now. Also, some sort of x86 emulator is a must like Apple had with Rosetta for Power PC.

  7. the kernel is not important, since Silverlight is app model, MS not only hide the native api from WP7 developers, they even hide the .NET CF3.7 from them ! it will be more likely for MS to unify the .NET for Desktop and .NET CF and WPF/Silverlight/Silverlight for Embedded etc, with Jupiter maybe ? then nobody care about the underlying kernel anymore.

  8. Unfortunately, MS should have done this a long time ago. There needs to be an answer NOW with regard to tablet computers. They should have considered Windows Phone 7 as the platform for tablets; however, I can see logic with delaying it. The Kin debacle probably means they will wait until something more pernament, rather than stopgap, is the solution. Nonetheless, I am still wondering what the user interface will become and how the app store will be handled. They need an interim update for Windows 7 within another year.

  9. Does this mean that Windows 8 = Windows Phone 8 = Windows Slate (8)?
    Sure would be interesting. Especially if WP7 interface is anything to go by.

  10. Great minds think alike!

    I watched the CES announcement with great interest. Then I saw Ottelini’s comment from last Friday and decided it was now okay for me to break silence on this subject:

    I believe we’re now at an inflection point for embedded technologies which demands the adoption of powerful, flexible, sophisticated software systems to fuel the rapid increase of sophistication of embedded and portable devices. As embedded devices are increasingly sophisticated and powered by ever more powerful chipsets, the viability of Windows CE decreases. CE was a great OS when Windows was just too heavy to run atop early ARM CPU’s, but this is no longer the case.

    Combined with the fact that Microsoft has finally untangled Windows and componentized it sufficiently to enable its use in embedded and mobile devices, I think it clear that the Windows kernel and OS componentry will be brought to bear on most future embedded devices running on Windows.

Comments are closed.