What you need to know about developing for Windows on ARM (WOA)

You’ve probably heard about the new Windows on ARM PCs that will be coming to market with Windows 8. If you’ve been following the TechEd North America coverage, then you’ve also seen these devices in the keynote. In this post, we’re going to cover what this all means for developers.

For an introduction to Windows on ARM, I recommend reading Steven Sinofsky’s post on the “Building Windows 8” blog: Building Windows for the ARM processor architecture. As Steven mentions, ARM testing devices are currently available to a small partner program. However all developers can start preparing their Metro style apps for ARM PCs today.

In this blog post, I’ll walk you through developing an application to run on an ARM PC. What you’ll find is that developing an app for Windows on ARM is the same as developing a Metro style app for x86/64 PCs; that is, the same Metro style app will run on either hardware. Also, many Visual Studio paradigms you’ve come to know from building other application types (designing, testing, debugging, etc.) will carry over to your experience of building Metro style apps. In addition to the walkthrough below, I’ve also recorded a video so you can see this in action:

As Windows hardware has evolved over the years, we’ve been updating Visual Studio to help you build applications that target each version. For example, today you can use Visual Studio to build apps that run on x86 and x64 PCs. You can also use Visual Studio to build apps that run on ARM hardware, including Windows Phone and Windows Embedded Compact. With Windows 8, you will now be able to build apps that target Windows on ARM. (To clarify, Visual Studio itself will not run on ARM, but it will enable you to build apps that run on ARM devices.) For those interested, I’ve provided details on the engineering process at the end of this post, including some history on how we were able to leverage our experience with other chips in the past.


Let’s see what it looks like to build one of these apps in Visual Studio 2012. Regardless of whether you’re using JavaScript, C++, Visual Basic, or C#, if you’ve built a Metro style app that targets x86/x64 then you already know how to build one that targets ARM. You use the same Metro style project templates, which provide the starting point for building an app.


In this case, we’re going to start with the Windows Blog Reader app, and walk through the process of debugging, testing, and deploying it on an ARM device. You can find tutorials to create this app in JavaScript, C#/VB, or C++.


Remote Debugging

Visual Studio provides the ability to do remote debugging. You’ll need to use this feature when working with an ARM device, since Visual Studio will always be running on an x86/x64 machine. Before you can start remote debugging, you’ll need to install the Remote Tools for Visual Studio 2012 RC onto your ARM device. The first thing we’ll do is launch the Remote Debugger from the device’s Start screen. You may receive a prompt to automatically configure your firewall settings (click Configure to continue).


Next from the toolbar we select “Remote Machine”.


(Note: If you’re using C++, you’ll also need to click the Debug dropdown and select Configuration Manager, and then set Platform to “ARM.”) Visual Studio 2012 will bring up the Remote Debugger Connections dialog. If the device is on the same subnet, then the device will appear under “My Subnet” (or if you are doing it through the project properties window, click the “Find…” button on the Debug tab). Alternatively you can manually configure it by entering the device’s machine name or IP address. Select your machine and then enter your login credentials for the machine if prompted (this will depend on the authentication mode you selected).


Next you’ll see a prompt on your ARM device to acquire a developer license:


Visual Studio will package and deploy your app and then launch it on the ARM device. Making all this happen requires a fair bit of work in MSBuild, the compilers, and the package wizard, but this all happens transparently and allows you to just focus on building your app.

At this point you actually have a remote debugger attached! Let’s set a breakpoint so we can actually see the debugger in action. To do this, press Shift+F5 to stop debugging, and open the DateConverter.cs file. Set a breakpoint on the first line of the Convert method, and press F5 again. (For JavaScript set the breakpoint in the getBlogPosts function in the data.js file, and for C++ set it in the Convert method in DateConverter.h).

You’ll see that execution actually stops at the breakpoint, and you have the full debugger capabilities available (i.e. Stepping, Breakpoints, Locals, Watches, Call Stack, Immediate Window, etc.). In particular notice the Registers window, which is supported for ARM and helps you see how things are running on the device. You can now press F11 to continue to step through the method, and then Shift+F5 to stop debugging.







Unit Testing

Let’s look at how we would add unit tests for our app, and execute them on the ARM device. Right-click the solution and click “Add->New Project”, and select the “Unit Test Library (Metro style apps)” template. Name the project “BlogReaderUnitTestLibrary” and click Ok.

Right-click References and select “Add Reference…”, then click “Solution” and select “WindowsBlogReader”. Update UnitTest1.cs with the following code:

public class UnitTest1

public void ValidateConvertForYearWithValidInput()
var converterInstance = new DateConverter();

//checks if Convert method returns the year properly.
DateTime currentTime = DateTime.Now;
string actualYear =
typeof(string), "year", "Invariant");
string expectedYear = DateTime.Now.Year.ToString();
Assert.AreEqual(expectedYear, actualYear,
"The expected year to be returned by the Convert method and the actual returned value are not equal");

public void ValidateConvertWithInvalidInput()
var converterInstance = new DateConverter();

//checks if Convert method throws exception when invoked with a string input.
string currentTimeSTring = DateTime.Now.ToString();

Assert.ThrowsException<ArgumentException>(() =>
"Invoking Convert with a non-DateTime type doesn't throw");

Similarly, C++ has a Unit Test Library template for Metro style apps. One key difference to be aware of is C++ unit tests work against a WinMD file and not against an EXE project, so in the case of this walkthrough DateConverter.h would need to be moved to a separate library project and compiled as a WinMD. The Windows Dev Center has more information on how to unit test Metro style apps.

We can use the new Test Explorer to launch our tests by clicking Test->Windows->Test Explorer. (Note this will run the tests on your Visual Studio machine, not on the ARM device.)


The Remote Tools for Visual Studio 2012 RC that we installed earlier include a command-line unit test runner (vstest.console.exe) that we can use to execute our tests on the ARM device. It supports .trx files for offline viewing and sharing of results. (Note that JavaScript Unit Testing is not supported on ARM.) Start by creating an AppX package from your test project (right-click project, click on Store->Create AppX package). Follow the prompts and select “ARM” as the type of package you want to build. Now copy the AppX package to the device (a USB stick can help here). From a command prompt, change to this directory:

%ProgramFiles%\Microsoft Visual Studio\11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow

Run this command to install the certificate for the AppX:

certutil –addstore root BlogReaderUnitTestLibrary_1.0.0.0_ARM_Debug.cer

Now type the following command:

vstest.console.exe BlogReaderUnitTestLibrary_1.0.0.0_ARM_Debug.appx /logger:trx

The /logger:trx switch creates a trx file which can be used for detailed analysis of the results.


Manual Testing

You can execute manual testing scenarios on your ARM device with the help of Microsoft Test Manager. To do this, you run Microsoft Test Manager on your x86/x64 machine and connect to your remote device. As you test, the bugs that you log have all the diagnostic information collected from the attached ARM device. You can also take screenshots of the device directly from your host machine and auto-create bugs in Team Foundation Server.

Let’s see this in action. Launch the Microsoft Test Tools Adapter service on your device, which is responsible for collecting diagnostic information:


Click ‘Start Service’:


From your host machine, launch Microsoft Test Manager and go to your "Test" center (assuming we have already created test plans and test cases already):


Click the "Modify" link:


Finally, enter the name of the remote device that would like to connect to:


You can also chose to install your WindowsBlogReader app in to the remote device right from the testing center using the "Install Windows metro style App" link. Click "Run" in the toolbar to start the manual testing session. You’ll see a popup message on your device indicating that the manual testing session has started.


Now you can execute the individual test cases, mark them as pass or fail, and log bugs with rich diagnostic info captured directly from the device.

Remote Profiling

Due to their power and size goals, WOA and SoC devices have different CPU, memory and I/O subsystem characteristics than a typical development machine. Performance testing will help guide any tuning that is needed for you to build best-in-class apps for your users to use, on any device.

Let’s look at how we can setup remote profiling to analyze the app’s performance. Click Debug->Start Performance Analysis. You’ll see a note to check the remote machine for UAC prompts (for a program named VSPerf.exe). Accept the elevation prompt on the ARM device, and the application will deploy and run on the remote device with profiling.


The profiler’s now attached, and you can execute your scenario:


Once you’re done working with the app, click Stop profiling. The report will then be copied back to your development machine and opened in Visual Studio.


There are all sorts of ways you can investigate the results – you can zoom on the graph to see results for a particular range of time, you can use the summary page to get a quick view of what was the most expensive parts of the selected time range, and you can drill down on call tree branches and their cost. Here is the Call Tree view:


The Function Details View lets you see a visual representation of the cost of the methods that call the method you are interested in, the breakdown of the methods it calls, and the cost of each line of code executing in the method itself.


It’s also worth noting that remote profiling supports pause and resume functionality just like local profiling does.

Packaging Your App

When it comes time to upload your app to the store, you can build a “Neutral” package if you only have managed code in your app (C#, VB, JavaScript). This indicates that the package contains code that will run on either x86, x64 or ARM. To create the package, right-click the project and select Store->Create App Package.


If you have a mix of both native and managed code, you’ll want to build packages for each of the architectures that you support, including ARM.


Prior to uploading, it’s a good idea to run the Windows App Certification Kit (WinACK) on the actual ARM device, to verify everything works as expected in the target environment. In Visual Studio 2012 RC, we’ve made this easier by providing a single MSI that includes everything you need for installing it on the ARM device. You can get this MSI by downloading the Windows Software Development Kit (SDK) for Windows 8 Release Preview. After installing this SDK, you’ll see a file called “Windows App Certification Kit arm-arm_en-us.msi” under C:\Users\<user>\Downloads\Windows Kits\8.0\StandaloneSDK\Installers. Just copy that file to your ARM device and run it from there.


Behind the Scenes: Engineering for ARM

Designing for ARM

Within the engineering team, we established some design principles for targeting multiple chip architectures. For one, we wanted to abstract most chip differences from developers, with the goal that you can write apps that run on multiple chips without needing to do anything special. Second, we wanted to limit the places within the product that deeply know about chip architectures, with the goal that porting our product to new chip architectures is narrowly defined and straightforward. This enables our team to add new features and scenarios efficiently in the future.

The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details of the various runtimes and compilers.

JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are platform neutral, and you can write once to run on x86/x64/ARM.

C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro style apps using C# or Visual Basic can be compiled once to run on x86/x64/ARM.

C++ is close to the metal, and compiled to the machine language for the platform that you’re targeting. This offers developers full control, but also requires that they specify the hardware where the app will be supported.

Taking these differences into account, we were able to create designs that worked well for each respective language platform.

Engineering Process

The story about how we engineered for ARM begins one decade ago, when we ported the .NET Framework to 64-bit. While we always intended to support multiple chip architectures, this real-world experience was very useful. It motivated design changes that stayed with the product, and that made supporting ARM easier. We also have a lot of experience in the Developer Division writing compilers and runtimes for the ARM architecture itself, through our work with Windows Phone and Windows Embedded. The .NET Compact Framework first shipped 10 years ago and we’ve supplied C++ compilers to build the Windows Embedded Compact operating system since the mid-1990s. Our focus in the phone and embedded space has always been to make code run efficiently on small systems. However, today’s smartphones of today are more powerful computers than desktop computers of a decade ago! A group in Microsoft Research did an experiment running the main desktop .NET Framework on a smartphone, and found that it performs well. Their experience made us confident that our work to port the desktop .NET Framework to ARM would be successful.

As a result of our existing product designs, we were able to support the ARM chip in a relatively straight-forward way. There was no need to make architectural-level changes to accommodate ARM. That said there was still substantial work to do.

For example, we found assumptions in a few source files, where a 32-bit process was assumed to exclusively mean an x86 environment, but it could now also mean ARM. We also experienced the advanced scenarios mentioned in the section above, firsthand.

The biggest challenge was working with pre-release hardware, particularly early in the release. At first, we had to telnet into Windows to get anything done, since we were working with a Windows build without the Windows shell. We soon got a Windows PE build and hardware with video-out, USB and Ethernet. At that point, we could use Windows more like you would expect.

You can see a picture below, of some of the hardware that we used while building Windows 8.


A really exciting aspect of targeting a new platform is that everything is changing at once. The tool stack is one additional piece of movement. It takes a lot of coordinated teamwork to build systems as large and important as Windows 8 and the platform for Metro style apps, and this release couldn’t have happened without the great partnership between the Developer Division and Windows.


In this post, we walked through the process of developing a Metro style app to run on Windows on ARM. We saw that there are very few differences to make your Metro style apps target ARM. We covered a few specific tips that you need to know, such as how to do remote debugging and profiling on the device. Finally, we ended with an inside story on how the team went about enabling it all. I hope that this post helps answers some questions that you might have had, and also helps prepare you for developing apps that target Windows on ARM.



Follow me at twitter.com/jlzander.

Comments (12)

  1. lmkz says:

    So… just curious. If today's ARM processors are fast enough to run the .Net framework in its entirety, why weren't Windows Forms and WPF ported too (I assume they are not)? Surely it wouldn't have been hard. Mono has done a good job of it. A cut down version of Windows Forms was in the old compact framework.

    That would have instantly made a LOT of software backwards compatible (or nearly so) and provided a more familiar avenue for developers wanting to leverage their existing experience to create tablet/desktop hybrid apps. I really don't want to learn yet another way of creating apps (ummm… programs) (Metro). I know it looks old and boring but Windows Forms can do pretty much anything.

    Or I could be wrong and these could be included which would be great (and the logical thing to do surely).

  2. @Lachlan01 Given that WoA *will* apparently be running desktop apps (but only MS's desktop apps) I suspect that they *have* ported the whole .Net framework (inc. WinForms & WPF). Maybe not, I don't know. I suppose they'd only need to if there were portions of Office 2013 RT that needed it, or components of the OS (e.g. control panel). As they appear to have been pretty slow to embrace .Net in the Windows & Office divisions they might not have a dependency at all.

    The thing that jump out at me from this post is the installation of the remote tools. Here we have instructions to download and run an executable on the device. The executable in question appears to be a native ARM bootstrapper around a set of MSI installers (built with WiX). It's signed by Microsoft.

    That is interesting in that it means that the "the only desktop applications you can run on WoA are Microsoft ones" restriction does NOT mean you can't install new apps after the device has shipped. Instead it means something else. Only applications signed by Microsoft? A (huge) whitelist?

    I'd never even considered what would happen if you copied a valid (ARM) executable to the device and double-clicked it in Windows Explorer. It would appear that under certain circumstances (signed by MS?) it will run. What happens otherwise, though, I wonder?

  3. lmkz says:


    Yes I had to wonder when I read this post whether the "Get a developer license" thing would become a means for savvy users to work around the app store (or whatever MS calls their version of it). Pirates will work around it one way or the other.

    I highly doubt that MS is using any part of .Net for the core Office applications. It hasn't in the past, that I know of. I suspect that has more to do with a huge legacy codebase and fear of reverse engineering than any other valid engineering reason.

    I have my doubts that any of the "desktop" platforms from .Net (Forms, WPF) are included in WOA as every blog post I have read skirts completely around the topic. I have had a good look on Google and can find no mention anywhere. I think this will be yet another shot in the foot, as per no VS Express for desktop, and the new VS 2012 UI. Makes you wonder who is making the big decisions at MS, they are doing a pretty terrible job.

    If I can run my pure managed WinForms programs on WOA tablets, I think that will be pretty cool, and applaud MS. If not, I will be wondering why not, as it is obviously not for technical reasons.

    Another thing that jumped out at me when reading this post was: where's the tablet emulator? Surely we don't have to go through all this rigmarole to test Metro apps (not that I will be writing any!)?

    Anyway, I am eagerly awaiting a reply on this forum and some clarification/explanation from Mr Zander.

  4. lmkz says:

    PS supporting legacy "apps" (even if only pure .net) was Microsoft's big Ace Up The Sleeve which could've been a great selling point. If they don't, then I'm sorry but people will have no reason to choose WOA over iPad (I am not an Apple fanboy by any means).

    Just been reading this post blogs.msdn.com/…/building-windows-for-the-arm-processor-architecture.aspx (which despite its length is still ambiguous as to which parts of .Net Framework are included). In a way, I applaud you for starting with a clean sheet for WOA. It obviously does not make sense to include Win32 APIs etc.

    But I think if you have deliberately excluded the desktop elements of .Net and failed to implement any sort of emulation for native Win32 applications, then that is a MASSIVE failure in recognising what your customers actually want.

    I certainly won't be buying one if it is "just another iPad". But if I could download/write legacy software, that would be tempting.

  5. lmkz says:

    I've noticed a trend with MSDN blogs…. whenever someone comments along the lines of "I can't get XXXX to install", the blogger will get right back to them with an answer.

    However, if anyone questions their design decisions, or provides "constructive" criticism, there is inevitably deafening silence.

    I'm not trying to be antagonistic, I am genuinely curious as to why these design decisions were made and what exactly is in/out of WOA as far as the .Net Framework is concerned.

    And how has MS created Office for WOA desktop? What were the APIs used? There must be some common layer above the HAL that both Metro and "desktop" apps are using; the equivalent of Win32.

    There have been a few posts now around WOA but they all skirt these areas that we as developers are actually interested in. I know MS wants the platform locked down, but surely they realise that all this information will come out eventually anyway, so why not satisfy our curiosity?

  6. @Lachlan01 Indeed.

    I can personally see the reasoning for WoA tablets only running "Metro Style" apps (still hate that name) and carefully selected native apps (i.e. Control Panel, etc & Office 2013 RT). That keeps power usage (and thus battery life, heat output) under control, which is necessary to be a serious iPad rival. If you want legacy, then you need to get an x86/x64 tablet instead (which it seems is how they're targeting enterprises).

    I suspect that "most" people would find that the legacy apps they wanted to run would be either contain native code, have a badly written P/Invoke signature somewhere or a poor installer (e.g. that assumed x86/x64 registry paths or something). Given then that MANY legacy apps would simply fail to work, I guess it's a short leap to just saying "don't allow any non-metro apps" to keep support costs reasonable.

    I'll be interested to see how it pans out in the marketplace (long term), though.

    Personally: I'm looking forward to having a Win 8 tablet (to replace the iPad 1 I got on the cheap). The single biggest thing that kills the usefullness of the iPad for me is that it has no user accounts. I share the thing with my wife and kids, which means neither she or I want to leave it signed-in to our mail, twitter, facebook, bank, etc, etc, etc. User accounts are a *massive* win for me.

    I'd still be interested to know *how* the blacklist/whitelist mechanism works for actually limiting running native apps works, though.

  7. lmkz says:

    I guess the crux of the problem is that there is no way (given what can be gleaned from these vague blog posts) to write an app that is portable between, say, Windows 7, Windows 8 and WOA. I think that is the core failure. Windows 7/Vista/XP will be a huge chunk of the Windows installed base for many years to come. Hence it will be impossible to write an application that "runs on Windows" (any Windows).

    That is working on the assumption that Metro is not back-ported and that WinForms/WPF is not ported to WOA.

    Pretty terrible decision from a technical point of view, but I can see how from a naive marketing perspective this could be seen as pushing users towards Windows 8. Unfortunately it will mean a repeat of the XP situation whereby Win7 will just linger forever.

    If Metro were back ported to Win7 I could perhaps generate a little more enthusiasm for it. That would at least give some incentive to start developing with it. As it is, there exists no market and a lot of uncertainty, so why take a risk? I will carry on developing for the web and/or WinForms/WPF thanks very much.

    I am convinced that WOA should have either been a full blown 100% compatible version of Windows (via emulation if necessary – remember "XP mode"??) OR a completely separate product (WITHOUT "Windows" in the name). I just can't see how this Frankenstein product is going to work out.

    I appreciate that a new API was required that covers both touch and the desktop, but I'm not sure Metro is it, having not used it. From what I have seen on the net it errs too far to the tablet side, not enough to desktop. If it was suitable for writing complex desktop applications as well as touch apps I would be more inclined to embrace it. If this is the direction for all Windows software, then I can see some major churn of the API coming up over subsequent versions as features are added to support desktop. This seems to be the Microsoft way.

    You had a good model with the Compact Framework; that took Windows Forms and gave us a subset that could be used on PDAs etc. I think you missed a golden opportunity here to make THE Windows API/Framework that could do anything from desktop down through tablet to phone, with less features being available at each step down (or leave features, but add caveats).

    That is the holy grail, one OS for all devices. You had a chance to beat Apple and Google to it, but botched it big time from what I have seen. So we will get more change in 2 years time. Yay.

  8. Prolog & Lisp says:

    @Jason Zander

    Visual Studio needs one New artificial intelligence programming language.

    F# for  functional programming

    C/C++for  Native programming

    C# to easy programming and …

    but for artificial intelligence programming in Visual Studio …?

    Prolog Syntax is hard . please redesign new syntax for artificial intelligence programming in vs.



  9. Prolog & Lisp says:

    @Jason Zander

    Visual Studio needs one New artificial intelligence programming language.

    F# for  functional programming

    C/C++for  Native programming

    C# to easy programming and …

    but for artificial intelligence programming in Visual Studio …?

    Prolog Syntax is hard . please redesign new syntax for artificial intelligence programming in vs.



  10. FMODE says:

    @Prolog & Lisp

    Names Such as  : Alog  or  A#log or …

  11. Mike says:

    Echoing previous comments, where's the ARM tablet emulator? Do you expect all developers that want to develop Metro style apps to buy an ARM tablet for each developer? I don't see any provision for:

    (1) emulation (like we do for phone development)

    (2) running "remotely" into a Hyper-V or VMWare ARM Windows RT image (since Windows RT cannot be downloaded separately and only comes with devices)

    Do you see any potential for lack of developer adoption because of the requirement of remote debugging and deployment testing into an actual physical machine?

  12. Mads Torgersen [MSFT] says:

    @ Prolog & Lisp

    It’s certainly an interesting idea. Logic or relational programming languages come with some unique challenges, not least of which is building helpful IDE support. It is a field in some need of revamping, and it would be a daunting – but interesting! – task to do so.

    It is not a common request we’ve received, but we will certainly make note of it.