Slashdot Mirror
Microsoft Ready To Talk Windows On ARM
An anonymous reader writes "After many months of working in secret, Microsoft is nearly ready to start talking about its plans to bring Windows to ARM-based processors. However, while the company is set to discuss the effort at next month's Consumer Electronics Show, there is still a lot that must be done before such products can hit the market. Among the steps needed is for hardware makers to create ARM-compatible drivers, a time-consuming effort that explains in part why Microsoft is talking about the initiative well ahead of any products being ready. Meanwhile, Ubuntu is already starting to ship on some ARM devices and running on many others."
Meanwhile, many other Linux distros have been shipping on ARM devices since before Ubuntu was a distribution.
But Windows' main (and practically lone) selling point is that it works with all your old software. If they rewrite it for ARM, it may say "Windows" on it but it won't run your apps or play your games.
And I'm sure users will enjoy discovering that after they buy "Windows" tablets and netbooks.
How can I believe you when you tell me what I don't want to hear?
Isn't Microsoft always talking about initiatives well ahead of products being ready?
The NT Kernel might be, even after all this time slapping whatever each release thinks is a useful feature into it, but who cares about that. I think I can guarantee Office will not run on ARM, so its pretty much dead already.
Then there's the reason to run Windows at all - the 3rd party apps that are x86 only (many are not even x86_64 yet) and they won't run either. So all in all, this is just fluff. If you want a low-energy server farm full of ARM CPUs (and who wouldn't!) then you might as well run Linux there - many, many server apps run Linux anyway. If you want ARM on the desktop, don't hold your breath, and if you want ARM mobile .. you already have it, even for WinPhone 7.
So, I'm confused. The ARM share price has done well from the rumour, but we'll see what astounding piece of underwhelm-dent gets revealed at CES.
NT was actually more stable on Alpha than it ever was on x86...
Drivers are not really a problem for ARM, since most of these devices will be small (tablets, netbooks etc) with fixed hardware, the hardware manufacturer will supply the necessary drivers.
The problem is apps...
Existing windows apps would need to be at the very least recompiled (or may require significantly more work depending on the code), and with most apps being closed source only the original vendor is in a position to do that... Now as with alpha, ppc mips and ia64, commercial vendors won't port their apps unless they see a market for them... And end users wont buy the platform unless they see available apps, catch 22.
Linux doesn't really have this problem because the vast majority of applications are open source, and have already been compiled for multiple architectures. If the original author hasn't ever tried to compile the app for another platform, chances are one of the distributors has (debian has been supporting arm cpus for years)...
The only advantage ARM has over alpha/ppc/mips/ia64 is cost of hardware, if those platforms had been price competitive with x86 they would have had a lot more sales to linux users (i know many people who wanted an alpha but just couldn't justify the cost).
There is a lot to be said for writing new applications which are actually designed for a tablet or netbook, rather than trying to shoehorn desktop apps onto small devices with different input methods... But if you're going to write new apps, why bother writing them for win32/arm instead of simply writing them for linux?
The only advantage windows has in this area is familiarity, they would lose their traditional selling point of compatibility/lockin, if you go arm you will need new apps regardless and if people have learned anything over the past 15 years they should take this chance to break free of the lock-in rather than getting caught up in another round.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Actually, there's a video of Mark Russinovich talking about all the changes they made to the kernel to make it more portable. They broke it into 3 layers: MinWin, Server and Full and cut any ties that went up or down between them. I would say it's more portable than ever.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
But .NET applications compile Just In Time. So all they have to do is port the .NET framework and compiler and all .NET applications will work with almost no changes, especially if they virtualize the environment to make it look like a desktop (put a phony C: drive on an SD card, etc.)
Peter predicted that you would "deliberately forget" creation 2000 years ago...
ARM chips use a quarter of the power compared to the Atom chips.
ARM core designs can be licenced and integrated into SOC (system on a chip).
With Atom you need the Atom chip plus a northbridge chip, with ARM you can use a single chip. More space in a mobile device means more space for batteries.
Microsoft has an excellent track record of supporting Windows on non-X86 processors. MIPS, PowerPC, DecAlpha, Itanium. With such an excellent track record, I am sure, the industry will take it very seriously and we will see tons of devices, computers in the market very quickly. Thank you Microsoft.
The NT Kernel might be, even after all this time slapping whatever each release thinks is a useful feature into it, but who cares about that. I think I can guarantee Office will not run on ARM, so its pretty much dead already.
I think all they really care about is whether IE, the .NET framework/Silverlight, and things like Office Live will work on it. ARM devices, if they are keyboard & mouse/touchpad devices, are going to be more likely to be ultralight netbooks or nettops rather than desktop-replacement laptops or standard desktops.
It is the same situation as MONO. You can write an app that will run on .NET in Windows and Mono in Linux. Write once and compile for each platform. The problem is it is all to easy to call stuff that wont port. The stark and bleak reality is any .NET app written for win32 or win64 will need major work to run on MONO or .NET-ARM.
As a stupid example. I had to take a Visual Basic programming course. I had to put some output into a multi-line textbox. If I had a choice I would have used a more advanced table control so I could break up the output into columns. Instead, I turned back to my old win32 api programming days and placed a few tab stops into the textbox. This is done with a win32api call, once that is done, the program is non-portable. Any nontrivial app will require some retooling unless it was written from the ground up to be portable.
Without a plethora of win32 apps, Win-ARM will have issues. Even then those apps are not designed for the iPad sized tablet or netbook. Dialog are to large, icons not sized for a touch display. If you Look at WM7 as well as all earlier WinCE stuff, this is not looking good for Microsoft.
vi +
"They are also a quarter of the speed."
Apparently you are talking about clock speed, but 2 GHz or 2.5 GHz is not slow compared to the Intel Atom. The speeds are equivalent.
The MSIL just converts the code to win32 calls.
There is a factual error in pretty much every single word in this sentence.
First, MSIL does not convert anything. MSIL is the bytecode. It is what gets converted, by JIT compiler.
Second, it does not get converted to "win32 calls". It is converted to native opcodes on the particular architecture. All "win32 calls" are in the libraries such as WinForms.
Finally, porting Windows to ARM by definition means "port all Win32 APIs to ARM". So even something that P/Invokes a lot would not be affected.
MFC has nothing whatsoever to do with this. It's not a system API, and it's not used by .NET standard class library in any way.
Wow, you're wrong on so many levels!
MSIL doesn't convert anything. It's the code that gets converted. MSIL (more commonly called CIL, for Common Intermediate Language, now that Mono is a working non-MS implementation) is analogous to Java bytecode.
What does get converted (using a Just-In-Time compiler) is CIL to native code. Typically, this native code is x86 or x64, but there are already JIT compilers for ARM as well. After the JIT completes, the result is saved locally so the overhead is only encountered once.
As for Win32 calls, there's no "conversion" at all. What happens is that after the CIL gets compiled to native code, it links into libraries (native DLLs) that implement functions for the OS (such as Win32 calls). For example, if a .NET function calls System.IO.File.Create(), when that code is run, a managed code function gets called, and it in turn calls an unmanaged function in the linked library. That library makes the necessary translation into the native API (let's say Win32 on NT), resulting in an unmanaged call to CreateFile(), which in turn goes into the Win32 user subsystem library and gets translated into a NtCreateFile() system call, which is sent to the kernel.
If you're on another platform, such as Linux, WinCE, OS X, or other, on any architecture at all, the only difference is that you need to write a library that has the same public interface (System.IO.File.Create()) and calls the correct native function on its own platform (open(), for example). The .NET API is large, so it's not trivial to write this layer, but there's nothing specific to Win32 or x86 about it. Mono has already done this (works on Linux, *BSD, OS X, and even Windows) and so has Microsoft (for WinCE).
As for pure torture, have you contacted the Mono devs recently to express your sympathy?
There's no place I could be, since I've found Serenity...
THE show-stopper is malware. It would take years to rewrite that for ARM, which would put this at a disadvantage for years until malware writers had time to port everything. Not even Microsoft can overcome this obstacle.