Windows on ARM

It probably escaped the notice of most consumers, but a fairly major announcement was made at CES 2011 that will shape the future of mobile computing for the next few years.

Yes, Microsoft announced that Windows has been ported to the ARM processor. I don’t mean Windows Mobile (Microsoft’s now legacy Mobile OS, or Windows Phone 7 – built on Windows Embedded Compact 7) which already runs on ARM. I mean the Windows desktop, the OS that there is a 91% chance you are using if reading this article from a desktop computer.

ARM processors power a significant portion of mobile and low powered devices including smart-phones, TVs, and industrial hardened portable devices. They can be found anywhere that a system designer needs to conserve power due to battery life, or needs a low-heat high performance processor for a specific task. If you haven’t noticed, this is not the world of Windows.

Windows has always been relegated to mid-range to high performance computers for consumers or businesses. But there is an entire emerging market of smaller embedded computer devices that are becoming the norm. From smart phones to tablets, there is an overall pattern that is becoming apparent. The hardware these devices are running on is starting to rival desktop computers from a few short years ago. Desktops that are still perfectly capable of running a modern operating system with a few bells and whistles turned off. In the time between now and when this software is ready for prime-time, the gap will close even further. In fact, it’s highly likely that Windows 8 and Windows Phone 8 are going to be the same operating system.

Some would argue that Microsoft is late to notice this trend, just as they were late with noticing the trend towards touch based computing. This is further from the truth as can be. It takes years to produce working software as complicated as an Operating System. It takes quite a bit of time, planning, and financial backing to port an OS to an alternate micro-architecture. It’s likely that Microsoft put the plans in motion several years ago for this announcement, just as the Microsoft Surface sat in R&D labs at Microsoft since the beginning of the last decade before making its public debut. It takes careful consideration to release a product into the marketplace, and it’s all about timing.

Back on the subject of ARM however, some would point out a small issue on this subject. Software. You can’t run x86 or x64 compiled software on an ARM processor. You can’t run any natively compiled software on a processor that it’s not specifically compiled for. So this small caveat prevents almost every commercially available piece of software ever written for Windows from being run on Windows for ARM. So why would they do such a thing? Again, it’s all about timing.

The .Net Solution

.Net is a hardware agnostic technology that Microsoft release in 2002. It’s largely been relegated to development of Line of Business software due to its nature. It allows rapid development of software for several mediums (Windows, Web, Mobile) while using a (mostly) common API and set of languages. When used by a skilled team of developers, it’s a technology that produces a high return on investment by lowering development costs and making your IT department as versatile as possible though the application of the same skills to the various target platforms.

What’s special about .Net is that an application is compiled to MSIL (Microsoft Intermediate Language), a processor agnostic language that is JIT-compiled at runtime on the target platform, or pre-compiled during install time, again specifically for that target architecture. Although you can target your compilation for a specific architecture with .Net directly, there are usually specific reasons to do so that would prevent you from running a particular assembly on an alternate architecture anyways.

.Net is not a technology that is widely used in commercial software. There are likely very few software packages the average consumer has installed that use .Net. But it is there. Windows Vista and Windows 7 both have a desktop rendering engine that uses .Net. Microsoft began its push towards full .Net user interface several versions of the framework ago. A push that is finally starting to show a return on investment.

An application written in .Net and compiled for “Any CPU” will run on an ARM based Windows implementation the same as an x86 or x64 PC. It’s the runtime installed on the specific OS that knows about the underlying architecture, freeing the developer to write software that meets business requirements and not just internal platform specific plumbing.

There is a drawback though.

.Net has no first party equivalent on alternate OSs. Yes, there is Mono, but Mono is not a complete implementation of the .Net framework and has no real support or commercial viability due to timelines for support of new features.

Instead, Microsoft has spun off purpose specific versions of .Net. Silverlight, XNA, and to a lesser extent, the older deprecated .Net Compact Framework (Windows Mobile 6.5 and below).

XNA can be used to develop games or 3D interfaces – and works for Windows, Xbox 360, and Windows Phone.

Silverlight is usually found in browser distributed software and exists as a plugin to host the runtime for all the major browsers on both Windows and Mac (and through the Mono implementation for Linux).

Silverlight and XNA are in fact the only way to develop for Windows Phone (an alternate platform for embedded phone devices that shares only its name with the Windows desktop). A move that has ensured that all Windows Phone software moving forward will continue to work on every iteration of the OS and for every type of hardware. This is quite important if what I predicted earlier becomes true – that the Windows desktop OS will displace the current Windows Phone 7 OS in the mobile space. The consumer should not notice.

It’s also possible to use Silverlight for Web development for both Windows and Mac. And through a Silverlight specific version of Click-Once deployment called Out-Of-Browser, you can run Silverlight software just like regular desktop applications, including having a start-menu entry for start-up.

Although not perfect (it would be nice to have one framework to rule them all ;-) they’ve done an admirable job of organizing the chaos with all of the different platform possibilities out there. It’s also quite an exciting time for .Net development from the perspective of someone like me as commercial development begins to take hold and wider industry adoption takes place. The possibilities seem endless.

Advertisements

4 Responses to Windows on ARM

  1. Ross Rydman says:

    Interesting your covering some of the stuff I spent a lot of time discussing in the office this last week. I see a lot of potential things unfolding from this Windows on ARM announcement.

    I feel Microsoft has the perfect opportunity to create a solution that will rule on all platforms but I fear they don’t have the vision and inner-company communication to pull it off.

    I believe the future solution is an OS kernel such as Windows that is compiled to run on any device platform, coupled with a programming framework such as .NET/Silverlight that makes the application package CPU-agnostic, combined with a serious UI/UX guideline backing from Microsoft.

    I believe for 80% of the applications out there, the majority of the program logic could be shared across different device form factors and the only difference between devices would be the user input methods (and as a result, different devices would need different UI’s). Most of the code could be shared, most of the art/assets could be shared, and only the UI design would need to differ.

    It would be a dream to develop a program once and have it run on a phone, tablet, laptop, and desktop PC.

    Another interesting paradigm you should think about is the Motorola Atrix. It may be that in 3-4 years we only own a phone. No desktop PC, no laptop, and no tablet. Our phone becomes those devices simply by plugging into different sized screens/docks. I think in this scenario it would be even more important to have what I described above, but make the UI layer of the application even more detached. You could have the UI/UX change depending on what dock/screen your phone is plugged in to.

    PS: Pretty funny now but it seems like the old oft-hated Palm Folio idea was years ahead of its time.

  2. “I believe the future solution is an OS kernel such as Windows that is compiled to run on any device platform, coupled with a programming framework such as .NET/Silverlight that makes the application package CPU-agnostic, combined with a serious UI/UX guideline backing from Microsoft.”

    There is a non-Windows OS in the works at Microsoft written in .Net that will run on a thin hyper-visor and will succeed Windows – probably in the Windows X timeframe. Is this what you’re talking about? It used to be called project Singularity during it’s research phase, and last I heard it was called project Midori.

    As for a UX guideline – it’s specific to the UI. A guideline can be written for Windows Phone, but as far as the desktop is concerned, it’s still emerging. No real standards are in play because no-one has yet to establish a real look and feel for WPF applications.

    If you look at Microsoft’s Future Vision, you can see there is a general direction for User Interface Design, but again it’s going to be specific to type type of device running the application.

    This video previews new types of devices, and new form factors for existing devices that would require different types of UI. Even gesture based input has specific UI requirements in order to be user friendly. I don’t think it’s possible at the moment to write such a document – everything is too new. :)

  3. Ross Rydman says:

    Midori wasn’t really what I was thinking about but I do recall it now that you mention it, last I heard it was still a Research project though.

    I know NT at its core was built to be CPU-agnostic and years ago they had builds that ran on PPC and DEC chips, among others. I think the problem that may drive the adoption to a new kernel such as Midori may be the need for a more lightweight and flexible UI layer running on top of the Windows kernel. I’m not a Windows OS developer but I imagine making sweeping changes to the UI in the Windows OS is not exactly easy whereas if the entire UI layer was built with a framework more akin to Silverlight/WPF, changes could be made much more rapidly.

    And given the fact that everyone is dogging Microsoft for not having an OS that runs well on a tablet (90% of which can be attributed at the UI), maybe thats the issue at hand here? Maybe the desktop OS team needs to take some pages out of the Windows CE team’s book and separate the kernel from the UI work (since Windows CE comes in many forms of UI layers on top of the CE kernel and as a whole the CE is much more modular).

  4. Actually making sweeping changes is only an issue if you’re trying to keep backwards compatibility. Microsoft has already done this work though with Vista. The desktop is run as a WPF compositing engine with older apps being rendered and texture mapped onto window geometry. The legwork is done with WPF.

    The kernel has always been seperate from the UI. Microsoft never had an issue with this, only in keeping everyone happy with everything. Tablet is case in point. They’ve already stated that a UI is in the works for windows that is dedicated to tablet, it’s not the desktop UI.

    This version of a Windows tablet will likely be based on Windows Compact Embedded 7 if running ARM, or the full Windows if running an x86 processor like Atom. The UI will also likely look something like this.

    Honestly, the underlying OS will no longer matter soon. A UI written in some form of .Net will be portable and run anywhere – allowing them to swap out the underlying OS if upgrading from Compact Embedded to the full Windows kernel. As long as they get the UI right, the consumer shouldn’t know the difference – only when switching between form factors like Phone, Tablet, or Desktop should it differ.

    Midori by the way is an incubation project at Microsoft, not in research like Singularity was. It’s being developed as a real product and is still very much alive.

%d bloggers like this: