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.
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.
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.
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();
"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();
"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.)
%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_184.108.40.206_ARM_Debug.cer
Now type the following command:
vstest.console.exe BlogReaderUnitTestLibrary_220.127.116.11_ARM_Debug.appx /logger:trx
The /logger:trx switch creates a trx file which can be used for detailed analysis of the results.
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.
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
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.
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.
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.