In my previous post, I outlined the news that Microsoft has ported Windows 8 to run on ARM-based devices.

While we await details of which specific devices Windows 8 will run upon, we can at least get started with the process of making sure our existing code can compile for Windows/ARM.

In order to do this, we can use the ARM cross compiler & linker for C/C++ that Microsoft included within Visual Studio 11 Developer Preview.

On a machine with Dev11 installed, you can find the command-line tools themselves in the following folder:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm\

Visual Studio, however, makes it a breeze to compile your code to ARM binaries. Simply open the Configuration Manager and then drop-down the “Active Solution Platform” selector.

If you don’t see ARM in the list of available platforms, hit “New” and select “ARM” (copying settings from Win32).

Your project is now ready to be built as ARM code.

When you rebuild your project, your ARM binaries will be placed in the debug or release folder under “<project folder>\ARM\”. If you now open this folder in the Developer Command Prompt and type “dumpbin /headers <name of EXE> | more”, you’ll see that the file is marked as being an ARM binary:

If you then run “dumpbin /disasm <name of exe> | more”, you’ll see the code within the EXE being disassembled and displayed on the screen:

Now, of course, just because your code may compile doesn’t necessarily mean it will run without issues on an ARM device but at least you can get a head-start while we wait for Microsoft to release details of, and hopefully make available, real ARM devices running Windows.

For developers using a language targeting the CLR (i.e. C#, VB.NET), your code should generally require little/no change whatsoever and should run unmodified on an ARM device. The main reasons you may need to modify your code before running on ARM include:

• Your code contains “unsafe” code that makes assumptions about machine/processor architecture specifics which may require modification when running on an ARM device
• Your code is an add-in and is built specifically targeting x86 / x64. in this case you will need to modify and rebuild your assembly.
• Your code references an API that has been removed/modified in Win8 in which case you’ll need to modify your code to work-around the missing API. Microsoft hasn’t released details yet about whether any API’s have been removed in Windows/ARM.

In general, aim to keep most of your .NET code clean and machine architecture independent and the job of porting your code from Intel to ARM will be much easier.

I have just returned from a great week in Anahiem, CA, where I attended Microsoft’s BUILD conference where Windows 8 was unveiled in detail, along with Windows 8 Server and the next version of Visual Studio (VS11).

I’ll have a lot more to say about Windows 8 in future posts, but I just wanted to briefly cover a subject that I’ve had many conversations about during and since BUILD.

One of the most important new features of Windows 8 is that Microsoft have ported Windows to run on devices powered by ARM processors.

ARM processors are used by almost all smartphone and tablet manufacturers due to their great performance per watt characteristics. Companies like nVidia, Qualcomm, Freescale, Ti and Marvell combine ARM processor cores with graphics, networking, WiFi, Bluetooth, audio and other useful hardware into individual (tiny) packages that are referred to as Systems On a Chip (SOC):

Image Source: Anandtech.com

Hardware manufacturers then attach SOC’s to circuit boards, add some memory, physical connectors for USB, radios for WiFi, cellular, GPS and BlueTooth, etc.

Image Source: BeagleBoard.org

OEM’s then take the (often miniscule) motherboard, add a battery, some storage, a screen and some buttons, stuff everything in a case and create a wide variety of smartphones and tablets for your enjoyment.

While ARM cores have primarily been extremely frugal in terms of electrical power consumption, their processing performance has not allowed them to be used in more complex and sophisticated devices such as laptops and PC’s. Until recently.

Current-generation ARM-based chips are now able to compete from a performance perspective with some of Intel’s low-end processors whilst sipping a small fraction of the power required by Intel’s chips. Further, while today’s ARM-based SOC’s are not as powerful as Intel’s processors, from a processing performance standpoint, ARM is working hard to execute on its aggressive plans to rapidly close the performance gap with Intel whilst keeping its power-consumption requirements very low.

By porting Windows 8 to run on ARM-based devices, Microsoft is massively expanding the reach of the world’s most widely used operating system and application platform to a MUCH broader ecosystem than now includes a large array of different devices offering a wide variety of form factors, sizes, styles, shapes and designs. And by creating new user experience tuned for both touch and traditional keyboard/mouse interactions, Microsoft is providing a formidable platform upon which application developers can build compelling new applications and experiences to delight their customers with.

The first generation of Windows really started with the launch of Windows 3.0 in 1991. The second generation of Windows started with the launch of Windows 95 and has pretty much carried us forwards (albeit with some important improvements) through Windows XP, Vista and Windows 7.

The third generation of Windows starts here and now with Windows8’s new-found touch-centric, multi-device evolution. It’s going to be fascinating to see how this story unfolds, how customers react to the biggest change to Windows since Windows 95 ushered-in the start menu and how the rest of the industry adapts to the re-emergence of what they thought was a sleeping giant.

Game on!

Intel’s CEO, Paul Otellini, may have inadvertently pre-disclosed Microsoft’s plans for the next versions of both Windows and Windows Phone. We’ll call them Win8 and WP8, respectively.

During a conference call to press and analysts after Intel announced record Q4CY2010 quarter ($11.5Bn in revenue for the quarter if you’re interested), Ottelini was asked about Microsoft’s move to port Windows to ARM. He said:

The plus for Intel is that as they unify their operating systems we now have the ability for the first time, one, to have a designed-from-scratch, touch-enabled operating system for tablets that runs on Intel that we don't have today; and, secondly, we have the ability to put our lowest-power Intel processors, running Windows 8 or the next generation of Windows, into phones, because it's the same OS stack. And I look at that as an upside opportunity for us.

So, according to Ottelini, it appears that WP8 may well be built atop the Windows Kernel and OS subsystem. Windows proper, not built atop Windows CE as WP7 is today!!! Not only that, but Win8 may will include a brand-new touch-centric UI that is built from the ground-up for tablet scenarios.

So, is it even feasible for future versions of Windows Phone to run on the Windows kernel?

To understand why, let’s dig into this a little more.

MinWin – the history of the future of Windows:

In order to handle the explosive growth and breakneck development schedule of Windows 2000 and XP, Microsoft relaxed its own rules around modular interdependencies between OS components. This resulted in Windows increasingly becoming intertwined around itself – essentially turning into a ball of string.

Microsoft has spent a great deal of time and effort over the last 10 years cleaning up the Windows OS architecture and codebase. This effort, sometimes called MinWin (Minimal Windows), was a huge undertaking that benefitted Windows Vista a little but truly bore fruit in Windows 7.

With most of the Windows OS now cleanly modularized and far less fragile, Microsoft began the process of replacing pockets of what were once the necessary evils of embedded assembly and machine-architecture-specific code with machine and processor agnostic code. Once the code was finally clean, they could complete the work to port Windows to ARM.

Digging deep

Now this is where things get interesting:

I know from my discussions with colleagues during the latter stages of my 10 year career at Microsoft that the MinWin project had gone very well and that they’d actually managed to exceed their initial goals by creating a totally isolated core kernel (MinKernel) that depended on nothing. Built upon the MinKernel are the remaining kernel and OS features that were not considered as absolutely essential to the core kernel.

Therefore, the networking stack, graphics and media drivers and services, most device drivers, storage drivers, IO drivers, printer drivers, etc. were implemented atop a VERY small, efficient, stable and secure kernel.

In a Channel9 video interview, (the always awesome) Mark Russinovich indicated that much of the confusion about MinWin was due to the the improper nomenclature used to describe the various aspects of OS architecture, I contacted him and suggested referring to the parts as CoreKernel, Kernel and CoreOS and OS:

• CoreKernel is the indivisible minimum kernel (controlling the processor, memory and critical hardware)
• Kernel includes everything else that runs in the kernel (e.g. logical kernel abstractions including threads, processes, etc., networking stack, device drivers, printer drivers, graphics & media drivers, KTM, ETW, etc.)
• CoreOS is the core (mostly user-mode) OS substrate upon which the OS itself depends (e.g. Win32, COM, OLE, RPC, WMI, DirectX, etc.)
• OS is the remaining set of other high-level essential and non-essential features that may, or may not, be installed by the OEM/user/etc. (e.g. Explorer, Silverlight, .NET, Media Center, IIS, etc.)

Using these abstractions makes it easier to see the boundaries around which Microsoft may well be architecting both Win8 and WP8.

I know from prior conversations that CoreKernel is small. VERY small. Last I heard it was around 32KB on disk! Yes, that’s 32 kilobytes!! It gets the machine booted, initializes the processor and memory and loads the rest of the OS. Its core role is then to provide the very lowest-level services to the rest of the OS (e.g. switching threads, allocating memory, managing processor cache, etc.)

Now add to CoreKernel the logical kernel abstractions and infrastructure (e.g. threads, jobs, processes, jobs, etc.), a networking stack, the device drivers necessary to control a PC, phone or tablet’s hardware features and you have a kernel.

Now add on top selected CoreOS and OS services and features.

There’s little reason why Microsoft couldn’t port a slightly modified version of the current WP7 OS & UI running on an ARM board inside a phone or tablet. Or port some/all of the rest of Windows for that matter. After all, one of the huge benefits of WP7’s OS is that it’s largely built on .NET and Silverlight – both of which are already easy to cross-platform and both of which isolate .NET and Silverlight apps from any dependencies upon the underlying operating system.

What’s the point?

Now, you may be wondering what’s the point in doing this? After all, Windows CE is a perfectly adequate kernel and OS for small embedded devices and already powers Windows Mobile devices, Windows Phone and several 3rd party devices like bar-code scanners, process control devices, monitoring equipment, etc.

Right? Right … but only up to a point!

Consider the vast leaps forward in Smartphone technologies in the last 5-6 years. Phones have gone to something you talk with to computing devices in your pocket that largely out-perform a full-blown high-end PC of 8-10 years ago. Modern smartphones already display HD content, play games that used to require a $400 graphics card and contain more data than ever.

With this in mind, and progress in this space accelerating, Microsoft will want to bring technologies like Silverlight and WPF to the phone. They’ll want to enable users to view content streamed wirelessly as well as watch content protected with DRM to enable offline viewing during an agreed period.

These technologies are already built-in to Windows, but are missing from Windows CE. Porting these technologies to Windows CE is just too costly and too cumbersome. CE is a fine embedded OS but is NOT sufficient for the kinds of complexity thrown at modern-day connected devices.

Conclusion

So, in short (after a lengthy post), I believe porting Windows to ARM is perhaps the most important thing Microsoft will have done in over 10 years. Doing so enables mobile and tablet entire scenarios that were just not possible with today’s embedded Windows CE kernel and OS. And, yes, there’s NOTHING to stop the already finely tuned and thoroughly tested Windows kernel operating beautifully on modern ARM chips.

Stay Tuned!

Will any of this come to pass? Will Microsoft finally standardize its embedded, integrated, desktop and server OS’ upon a common kernel & OS? We’ll just have to wait and see how this story unfolds!

Just be sure to revisit regularly as I’ll be keeping a very close eye on this story and reporting what I find