Thursday, February 9, 2012

Windows 8: The Facts about ARM, Metro, and the Blue Stack

Many eyes will be focused on Barcelona on February 29, 2012 when Microsoft releases the Windows 8 Consumer Preview or what many are calling the beta version of the new platform. You’ve probably heard quite a bit about the Metro interface. It has design roots in Zune, Windows Media Center, and Windows Phone. It presents content-rich tiles and is designed to focus on a touch-first experience. Metro provides a unique experience and involves a specific set of tools and technologies. When you read that Internet Explorer 10 doesn’t support plug-ins, you aren’t getting the full story because it’s really only the Metro version that has this restriction.

Of course, we’ve just learned about the experience for Windows 8 on ARM machines. Probably the most revealing quote for me was this one:

“WOA will not support any type of virtualization or emulation approach, and will not enable existing x86/64 applications to be ported or run.”

There’s quite a bit that can be read into that statement, so let’s break it down for a second. Here’s what I understand:

1. Regular Desktop Applications will NOT run on ARM Machines

I never imagined this would be the case because ARM is simply a different architecture. Fundamentally, the instructions used by the CPU at the lower level are different instructions than the ones on x86 and x64 machines. Microsoft bridged the gap between x86 and x64 somewhat by introducing an emulation layer called WOW64 (Windows on Windows 64-Bit) that enables 32-bit (x86) code to run in the x64 environment. I speculated that a possibility might be that Microsoft would create a similar engine for ARM but that is clearly not the case. So all of those programs compiled to x86 and x64 simply won’t work.

It is possible that some applications may make it over. Microsoft was clear, for example, that they will provide special versions of Microsoft Office 15. This appears to be part of the “blue stack” or desktop mode for ARM, which raises some interesting questions. If I were to try to draw the architecture of the Windows 8 stack based on the latest announcement, it would look something like this. Keep in mind this is a typical “stack” diagram that is not a true architecture and there are some obvious issues (for example, Win32 technically extends beneath the Metro stack but I’ve kept it out to keep it simple). Here’s what I am picturing:


Notice that the entire Metro stack sits on top of the full suite of processors, while there is a definite dividing line between the x86 and x64 sides versus the ARM side. So What does it mean? Here is the first thing I can infer:

2. The .NET Framework will not target ARM devices

Notice there is no CLR layer in the blue stack side for ARM. From what I read I don’t think this is the case because if the framework were available, Microsoft would explain that a whole suite of existing applications should run fine. Ironically, one of the early points about the .NET Framework was that it contained an abstraction layer with MSIL (Microsoft Intermediate Language) that should allow it to target different platforms, including ARM. It doesn’t appear this effort was made. However, this does raise a point of confusion that I look forward to learning more about and clarifying as more information becomes available. Take a look here:


I know that on x86/64 machines, the C# version of Metro applications actually runs on the CLR. It uses the .NET Framework. There is a “core profile” that limits a number of Base Class Libraries (BCL) but it uses this nonetheless. There are also projections of the WinRT API that expose themselves as CLR objects. Since the announcement from Microsoft certainly embraced the fact that ARM realizes the full Metro stack, the implication is that this CLR layer exists. So the question is: do they have a version of the framework available? Did they just provide a smaller stub/trimmed down version like Silverlight that just supports the Metro stack needs? Is there a different mechanism altogether on the ARM platform that is something new? I’m sure these questions will be answered but it does make me curious. If we agree that there is not a general framework version available and we also know that there is no emulation/virtual layer, then I can also safely guess that …

3. .There is No Silverlight on ARM Devices

This is actually not something I’m disappointed about. It makes sense. The Silverlight runtime might not make sense for a number of reasons including the overhead of building a version that targets ARM (this has been done to support Windows Phone 7, but it is a different version) and battery/memory management concerns. I still think writing applications that target the platform specifically makes sense. There is a reason why iPad devices are so popular. They are fluid, the applications are responsive, and they just work. While an x86/x64 tablet has the perfect architecture to host the full desktop experience, ARM is a different architecture specifically targeting the mobile space and should be optimized that way.

This is why I’m fairly sure (and agree with the decision that) the ARM version of Metro won’t run plug-ins. The plug-ins are hosted on Windows machines and are therefore compiled to x86/x64 machine code which is not compatible with ARM. It simply doesn’t make sense for Microsoft to invest in building, what, a special ARM plug-in just for Silverlight?

However, there is a desktop experience and there will be applications released for this mode. So what makes me very curious is this:


So this is just my educated guess but from the post it is obvious there are desktop experiences like Explorer and applications like Office 15 that will target ARM. So what is the platform for building these? Will Microsoft make this available for us to use, so we can do blue-stack development on ARM machines, or will it only host some exclusive products? Is the engine they are using a C++ based engine or do they have a full suite of language options available that can target this area of the platform? Again, right now I can only speculate but it will be interesting to learn.

At this point you might wonder why I’m so calm saying Silverlight on ARM is not a good choice when I just finished a book about Silverlight business applications. The answer is simple. Too many people assume that WinRT is the future for Microsoft and anything that isn’t supported by the Metro stack is going to become extinct. I disagree. In fact, I’ll say …

4. WinRT is NOT the Future for Microsoft

Don’t get me wrong. WinRT isn’t going away and is a major part of Microsoft’s future. I just meant it is not THE future for Microsoft. Contrary to speculation, Microsoft is not putting their eggs all in one basket and are not just focusing on Metro for Windows 8. I am still confident we’ll see traditional WPF and Silverlight development on existing Windows 7 machines and Windows 8 machines for the desktop side moving forward. Do you really think ALL complex user interfaces will go away? That certain people will stop doing CRUD data entry applications, or authors will suddenly be happy using the pen tool to write novels when they can type 15 times faster?

I doubt it.

There will still be a need for devices that run a powerful OS capable of building software and allowing us to use big Excel spreadsheets as well as pop open Word to write a document or PowerPoint to prepare a presentation. I don’t think that blue stack is going away any time soon. I also believe if you do find yourself doing Metro development, you’ll be using many of the same skills you are familiar with in Silverlight.

Don’t take my word for the fact that Windows 8 is not just about Metro. Let’s take a quick look at the evidence for the tale of two stacks.There has been plenty of talk about the jarring experience of falling back to the desktop mode. This mode is backwards compatible for applications that are written for previous versions of Windows and I’ve confirmed this by installing applications like Microsoft Office, Amazon Kindle, and several Silverlight-based touch applications including ones I’ve previously helped write. As my current book Designing Silverlight Business Applications goes into print, it’s comforting this paradigm is still fully supported on the new platform. So what is the evidence that the desktop mode is not just a mere fallback to Windows 7 that hides behind the Metro stack?

Here are a few announcements from Microsoft and changes with the desktop mode for x86/x64 targets that really stand out:

Fast Boot and Reduced Memory Footprint

Windows 8 boots fast. It’s not an illusion either. On an SSD machine you can shut down, press power for a cold boot and be working in your next application within seconds. This is a huge benefit – how many times have you actually delayed firing up your laptop because you dreaded the long boot time? That completely goes away with the new boot.Read about delivering fast boot times in Windows 8. Learn more about how these features also reduce the memory footprint.

Graphical UEFI Boot

The boot is not only faster. The boot supports the UEFI standard and is graphical. Remember those old text-based menus we used to have to navigate when dual-booting? Those are a thing of the past. Not only do you get a nice graphical boot interface, you also benefit from features like touch support so you can use your tablet to navigate the boot options. You can see screenshots of the experience and learn more about it in this link. This is not just an illusion, it works and it works with your Windows 7 applications.

Windows 8 on a Stick

This is a phenomenal feature that I haven’t seen covered much. It refers to the capability to install your Windows instance on a thumb drive so it can travel with you from work to home. This special version of the OS is capable of recognizing the device/hardware configuration and hosting the instance based on the environment you boot to. Imagine being able to install your favorite applications and configurations, then be able to take them and use them on your work desktop as easily as your personal laptop. You can learn more about this feature here.

New Explorer Experience and Features

The Windows Explorer experience has been completely revamped.While remaining familiar to users of the legacy version, it provides more functionality through the expanded ribbon interface. When you manipulate files from within Explorer, you will immediately experience the improved file management basics. Operations such as mounting VHD drives or ISO images have been completely integrated out of the box.The new concept of Storage Spaces allows you to organize pools of storage and virtual disks that behave like physical disks. Disk support has been extended to allow for larger disks with large sectors. This is a completely new file system experience that remains compatible with the legacy features you are familiar with.

Enhanced Task Manager

Microsoft took a new look at the task manager and completely refreshed its capabilities.This is substantial because it wasn’t just extended to support the new Metro platform. It now has a simple view for killing applications that does it quickly and efficiently. The grid was enhanced to help diagnose performance issues by providing heat maps and lighting up resource usage. It also groups like processes together.

There are actually many other features that address the non-Metro space for Windows 8 but I’ve gone on far enough in this post. I’m again very excited about Windows 8 on ARM and commend Microsoft for taking a non-compromise approach to making it the best experience possible. Although WinRT and the Metro platform is definitely the future for mobile and touch-based devices with Windows 8, I encourage you to keep pace with the desktop-based enhancements and remember there is an entirely different stack available for line of business applications that might not make sense in the Metro paradigm.

As a developer with XAML and C# skills you are well positioned to navigate both stacks as you build applications and have the freedom to choose what makes the most sense for your end user. Of course, I’m not assuming those are the only languages my readers know – and now there is a first class space for C++ development as well. No, I didn’t forget our HTML5 and JavaScript developers, but to be honest, that is the one block in the stack that I’ve spent the least amount of time in. I’m currently writing my next book on “Building Windows 8 Metro Applications with XAML and C#”. I believe there will be a huge benefit for existing Silverlight developers to work in both worlds. Look for more details from Addison-Wesley soon on that new title.

What are your thoughts about the recent announcements? Are you going to try to be first in line to download the next version when it becomes available?


  1. Great post, but without easy to use tooling I don't see the average developers that I work with moving away from ASP.NET web forms. These are the people that I was not able to convince to use Silverlight. So the Microsoft tablet will come down to price because it basically offers what an IPad does.

    1. Have you considered that many developers might be smart enough to avoid bogging their systems down with bloated junkware such as Silverlight when there are better products with wider appeal and few bugs available for multiple platforms?

      It would be very nice if users could actually Hide Silverlight permanently in Windows/Microsoft Updates, but since it is clearly something many tech savvy folks don't want infesting their machines, MS has chosen to keep it repeatedly showing up as a new update, even if the user consistently goes through the extra effort to mark it as "Hide". Could it be that MS is hoping that some people will be careless enough to install Silverlight by mistake, or are foolish enough to blindly follow Microsoft's "Recommended" update choices?

  2. Great article but I disagree about WINRT and the importance to Microsoft and their future. I think providing a stable, fast and robust OS requires WINRT and anything outside of this is potential problem.

    1. So do you believe this should also be the runtime that includes tools like Visual Studio to develop applications, Excel, Visio, etc.? And if so, should those tools be dumbed down to the Metro interface, or should WinRT be extended to embrace alternative UI stacks and paradigms?

    2. The second one, WinRT be extended to embrace alternative UI stacks and paradigms.

      I see Windows 8 as a stepping stone between Win32 and WinRT, hopefully Windows 9 will be all metro.

  3. "Microsoft bridged the gap between x86 and x64 somewhat by introducing an emulation layer called WOW64..."

    Nope, that's not emulation, that's thunking:

    1. Thanks for the clarification - I agree with other posts, not the best example.

  4. I disagree, I think WinRT is essential to Microsoft. Thinking of it as the 'mobile API' is a mistake, IMO. There's essentially nothing stopping you writing the same experience in WinRT/Metro as you can with Silverlight. It's not touch only - just touch enabled. We're likely to see some very cheap ARM based netbooks and keyboard enabled form factors (docking etc). There are questions here though. Will the fullscreen only mode and sandbox really provide for power users. The answer is obviously to move some of that functionality to the cloud.

    The Windows 8 strategy hinges on the success of merging the touch and desktop paradigms. I think we all still need some proof that this can be done.

  5. A superb article, thanks. I had always considered that the motivation for not allowing plugins was rooted solely in commercially controlling the platform. You've just opened me up to the view that it may also be about controlling the experience on the platform. And, that feels better :)

    In section 3 you say that you are "so calm saying Silverlight on ARM is a good choice", did you mean "not" a good choice?

  6. You're right, "not" is the key term - corrected. Thanks!

  7. you're not so bright... Windows Phone, in case you didn't know... runs on ARM and in case you didn't know is programmed with the CLR and in case you didn't know all the UI is written in Silverlight.

    Of course there is a CLR that runs on ARM. The CLR is just a PAL with the BCL stacked on top of it. The BCL is built in C# and the PAL is built in native code. It should be obvious to anyone who claims to be a pundit that your article is baseless and it's quite sad that code project picked it up.

    1. Very familiar with this - not sure what the complaint about the article was. It's not a question about whether or not there is a CLR layer on ARM, but rather how extensive it is and whether it will support development outside of the constraints of Metro. I don't believe it will ... but that is just a guess.

  8. Jeremy you have had some really good articles in the past - but I hate to point out some really blatant issues in this one: it's a pity because the rest of it is quite insightful.

    Firstly - WOW32 (and subsequently WOW64) worked for one specific reason: it all worked against the same chipset with compatibility provisioned via the instruction set and because the architecture (interrupts, calling conventions, etc.) worked the same. 'WOWARM' is not only "not the case" but simply **impossible** (seriously, end of story impossible) - it's a completely different instruction set - the entire module (DLL/EXE) is completely useless: you can't just do instruction patching and ship 32bit libraries - you would literally need to recompile the x86 ASM into ARM ASM on the fly (Bochs partially does ARM to x86 but still needs to virtualize). Something akin to "XP Mode" would be possible: but I don't think an x86 CPU has ever been emulated on ARM (I stand to be corrected there, though): it would take a Virtual PC ARM edition to get this right - and it would likely be **dog slow**.

    Secondly, the C++ stuff would likely be done exactly how Apple and Google are doing it (and how Microsoft did it before them with <= WinMo 6.5). You would either have the x86 equivalent of the UI libraries and would simply cross-compile to ARM (and as implied, Microsoft does already have a C++ compiler that does this); or you would have an ARM emulator/VM for x86 machines. Considering that the x86 and ARM versions would likely share interface/headers as far as libraries go I would assume it would be the former. In other words it's highly likely you will need an x86 machine with Visual Studio.

    "C++ as a first class language" is still mythical, really. I have to do C++ at work (under protest - I personally hate the language) and it's really quite amazing how dreadful the Visual Studio experience has become (or, rather, stagnated) with C++. The libraries have been modernized: but it will fall flat on its face if they don't fix the development experience.

    Finally, I only hope that Microsoft eventually release a ARM CLR runtime. Considering that they released one for the very niche Itanium architecture it wouldn't surprise me if they eventually did. At least until then we have Mono + Moonlight.

  9. So I appreciate all of the feedback and comments. I think the term "WinRT is not the future" threw some people off because of the clarification, "WinRT is not THE future" ... but after reading some of the responses, I have to say I should have worded this, "Metro is not THE future." I could be wrong, but I agree that if WinRT is opened up to the blue stack that this would become a unifying API for the platform, but right now it is formally restricted to Metro and I don't believe Metro can encompass all of the use cases we develop for. It will be interesting to see how this evolves. Thanks everyone for the feedback and keep it coming!

  10. Makes you wonder why they did't just do Windows on ARM as Windows Phone 7 XL.

    .. in the same manner as an iPad is effectivaly an iPod touch XL.

    1. I don't disagree with this approach. I do hear the "conspiracy theory" and "app store lock down" threads but I truly think there is something to be said for control, stability, low memory footprint, battery consumption, etc. I think the architecture that targets the touch/tablet experience is a great one, I'm just questioning what the strategy is for the more powerful workstations that will drive building software, video editing, etc. I doubt you'll be doing heavy video encoding on an ARM device any time soon (although I could be wrong).

  11. I think the CLR and silverlight will be available on ARM devices. Currently Windows Phone 7 only supports CLR and Silverlight Apps. Windows Phone 8 is rumored to share the same core as Windows 8. They have said all WP7 apps will work on WP8. Why would Windows 8 ARM not support the CLR if it already works for the ARM Phone?

    1. Because it's a different CLR and different version. The Windows Phone is not the CLR, it's the Core CLR for Silverlight. The CLR for x86 machines is the full .NET Framework 4.5. The one for ARM is ... well ... that's the question, isn't it? Based on what Microsoft said in their post, however, I'm putting the odds against seeing full .NET Framework or even Silverlight on the ARM platform.

    2. Silverlight on non-desktop (Phone, XNA) is a Compact Framework version of 4.x. There's a whole host of things it doesn't do, being that it's a subset of the framework, designed to run on CE-style platforms.

  12. From time to time MS wants to fail or some sort..
    They had Widows Milleniu fail very bad XP was good
    They made Vista a miserable fail even Gates admites ,but made W7 pretty good
    Guess what is coming?
    Yep W8 ,will fail like Vista or worse..
    Next W9 will make a compiler something that will have the compatibility-X86.
    Everyone will applaud !
    Now ARM does not have the pover to run emulator.But in 6 mouths ,after they launch W8, will be 5 emulators had will drain faster than will can say "MS is Stupid because they didn't provided one ".
    They are trying to be like Apple,guess what they can't.
    Guss what the average Joe will say after buying windows and can't install any off the application /games etc ,they are using normally on a Windows PC .

  13. Ok, I want to ask for clarification please? Do you mean the Silverlight plugin won't work, just like SL apps won't run on WP7, OR do you mean NO xap/xaml apps will run? I'm VERY much expecting MS to allow my SL XAML apps to run on Win 8 on ARM JUST like my SL XAML apps run on WP7.

    In fact, it only makes business sense to me, that MS would do this. Otherwise, WHY would I even consider buying a tablet? The other tablets (like the i3s given at Build) are just glorified laptops, they still have a loud fan AND SHORT battery life.

    The only way I can see MS competing with iPad is to release Win8 on ARM. Hopefully it's less expensive than wintel tablets, MUCH longer battery and NO FAN! BUT, don't do like RIM and cripple the thing before it's released by not running the more than 50,000 apps on the WP7 Marketplace! That's just DUMB! Why release a new OS on new HW which requires new compiler and new apps? RIM's Playbook inability to run existing BB apps is devistating, AND QNX requiring the current java devs to learn C are not happy!

    To me, if MS wants Win 8, WP and Win Server to be a success, the path is clear, make sure XAML apps run on ARM!

    1. Yes, that is my clarification. When you buy a Windows 8 ARM device, my proposition - this is just a guess not having access to the ARM configuration myself - is that you will NOT be running the Silverlight plug-in. XAML apps will run because you can develop Metro-style apps using C# and XAML, so you'll use a similar technology, but it will be WinRT-based, not Silverlight-based. So if they DID want to support the existing apps, as someone else in the comments thread pointed out, they would either have to get all of those companies to agree to compile to target ARM or put together some sort of emulation layer which would likely throw performance out the Window. So my guess = Metro apps and some specific, custom apps like Office 15 and Firefox that target the ARM chipset.

    2. I apologize, didn't mean to come off as arrogant, I'm just more frustrated.

      re recompile
      Isn't the promise of having SL the ability to "compile" down to IL code, and have the runtime environment actually do that real compile down to byte code? If true, then there's no need to recompile, MS just needs to create a runtime. You mentioned that above which you don't like, but I think it's esier for MS to do that, than to force everyone else to recompile and release two diff vers to marketplace.

  14. Call me old-fashioned, but isn't it just plainly obvious that x86/x64 apps won't run on ARM processors? It's a different processor... different machine code...

  15. Slightly off topic, but I get so tired of people insinuating that Microsoft is on some type of OS failure cycle because of Windows ME and Windows Vista. Everyone seems to forget that ME came out at the same time as Windows 2000 workstation, which was very successful and won high praise in the industry. ME was simply Windows 98 "third edition" and was released to carry the consumer side of the house over until everything could be unified under a common platform (Windows XP). The only real "failure" from a market standpoint was Vista. So please - stop the insanity on this note and give Windows 8 a chance to succeed on it's own merits.