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