Windows On ARM

Microsoft has caused a small earthquake when it announced that Windows 8 will be offered in a version compatible with ARM processors. Actually it's not the first time that Windows leaves the preserve of the x86 assembly: Windows NT has been proposed among other platforms Alpha, MIPS, PowerPC, and already in his time on ARM and Windows CE MIPS and ARM. However this is the first time that the "standard" version of Windows ventured outside the box of x86.

The announcement raised many questions, more so when Microsoft announced later that the ARM version of Windows would also have, as on x86, the "classic" mode in addition to Metro, with the good old windows such that we currently know them yet.

That gave birth to the wildest speculation: How Microsoft had she accomplished such a feat? If it were conceivable that applications are dealt with "fat binary" (containing both code compiled for ARM than x86, as was the case a time when switching on Mac 68k processors to PowerPC and the PowerPC in x86), at least in the version for Metro, the ARM architecture left much less latitude to run Windows applications in "classic" material constraints in much more limited.

Languages ​​and towers of Babel

Let a few basics: software is a binary code that uses two languages, one processor (assembler), and the operating system (the Application Programming Interface, or API, which allow an application to function calls low-level managed by the OS). Each processor family has its own assembler (also known as machine language). To avoid to rewrite every application for each assembler, most software is written in an intermediate language (mostly C or a derivative thereof), which is converted to assembly language for a given processor family with a compiler. Thus, provided that an operating system is available on several CPU families, simply compile the same code for each assembler, producing as many dedicated applications that run indifferently on any platform without more work. Applications "fat binary" (or "universal binary") contain several binary codes for multiple processors, only the one on the platform on which the application is launched will be executed.

However there are different remedies for the incompatibilities of platforms:

- When we want to run software that was compiled for a processor compatible with that of the machine on which you want to run it: an emulator will enable it to run by reading its binary code and adapting on the fly the target machine (the price of a slowdown, which requires that the host machine is more powerful than the source emulated to run real-time). This is a more or less faithful reconstitution of equipment that will run until the OS itself, in addition to the application, in a software environment.

- When we want to run software that was compiled for a compatible processor, but uses the API to a different operating system: an adapter (or wrapper) will connect the calls to the API of an OS to the other without requiring the presence of the OS which the application is intended. Alternatively, virtualization allows you to run concurrently OS which application is intended over the host OS, making it possible to run an application that the assembler is compatible with that of processor. Apple used a variegated these techniques to maintain compatibility across the ages: the 68k emulation on PowerPC (primarily in software and then directly in the PowerPC) PowerPC emulation on x86 (with Rosetta), virtualization (with Classic), and adaptation with Carbon on OS X.

All these solutions are however fairly resource-intensive material and therefore unthinkable on machines with RAM, CPU power, and autonomy are limited, as is the case of tablets. For an application runs on both Windows x86 on ARM, so Microsoft has no choice but to go through a rebuild, and the process of fat binaries. And that is precisely what it offers with Windows runtime (WinRT), which provides unified API for Metro x86 ARM as well, allowing you to program in C + +, C #, VB.NET, and JavaScript.

But the problem of Windows 8 is still more structural than just APIs and assembler. If Microsoft finally offering Windows on ARM is to remain competitive against these new mobile platforms, iPad in mind. X86 processors having so far proved unable to compete with ARM processors in terms of tariff autonomy, so that machines running Windows can meet the tablets with the same arguments so we had to go through this change processor. But the material constraints do not stop there, as to offer the same autonomy and the same rates, requires equipment similar to RAM, and a drastic management of consumption. Knowing that the iPad has only 512 megabytes smaller, so how to keep Windows and various applications in such a short memory? And how to ensure that its management of the tasks to come to the end of the processor is less powerful than other x86 or battery or both? This is where things suddenly become clear. The conventional mode of Windows is not a port of its counterpart on x86, nor for the Office suite. This is not emulation, but simulation: it reproduces the apparent behavior without invoking the inner workings.

Thus, instead of proposing an adapted version of the interface Metro Office suite, Microsoft has chosen to build any decor to offer an Office which works similarly on ARM platform, without opening Windows Classic to other programs. Thus avoiding having to deal with precisely the problems mentioned above. It remains to be seen what the actual limitations, and there will be. Microsoft says that Office 15 will consider a tactile interaction, and is fully compatible with Office files, failing to regain full functionality. However the classic mode will probably be more usable with a keyboard and mouse - both devices all compatible shelves WOA will have to take into account - given the size of interface elements that are destined to more than one cursor the fingertip.

Some are surprised also to see the office suite comes standard with WOA, knowing that Office has always been a golden goose for Microsoft, even more than Windows. For now, however, nothing says that more will be provided free, and it is not clear battle plan from Microsoft. With rumors of the arrival of Office on iPad (read "Truth" on Microsoft Office for iPad erupt "within weeks"), it may well be that Microsoft is strong on "everything but Android" ...

As long as the PC on ARM meet with some success, developers who want to go to as many people will support the interface Metro - Microsoft and conditions for the distribution of their software on its online store. He will always be possible to have applications from Windows Classic as it has always done on x86, but it remains to be seen whether this platform will remain dominant in the future. Tim Cook for his part seems convinced that the PC as it has always been known tomorrow will represent a minority of the market in favor of new mobile platforms like the iPad.

With WOA, Microsoft is a chance to play his card in this new market, but his choice to keep Windows Classic all costs leaves something thoughtful. Even on x86 is that Metro will be the default interface, the classic mode being upstaged. While Apple, despite a dialogue between OS X and iOS, seems determined to offer decidedly different things on both platforms, Microsoft is proud to turn his back to compromise. But frankly, the presence of this ersatz ARM does fig leaf of Office. Microsoft held on to its philosophy "Windows Everywhere" as it may have, to do more in appearance so as not to deny. One spin all the more useless it does not include the compatibility of Windows history repository, spearheaded that Microsoft has always supported its hegemony.

It remains to be seen which strategy will be the most cost between these two different approaches, but leaves to make a risky bet, Microsoft might have been cheaper to take until the end. Windows 8 "consumer preview" will be available in the version x86, from February 29.