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.
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.
"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.
Apple wrote a translation app called Rosetta
No, they didn't. They licensed it, from a company that is a spin-out from Manchester University. The same software has also been licensed to a few UNIX vendors to allow them to run legacy code on other architectures (and, in a few cases, to help customers move from a competitor's system).
It wasn't quite full emulation like a VM - just a dynamic translator, so it had some limitations but it was pretty successful in most cases
It wasn't at all like a VM. The thing that made it perform well was that it was the opposite of a VM - it emulated as little as possible. It provides a mechanism for including stub libraries, which trap out of the emulator. When you call a function in one of the stub libraries, it tweaks the arguments (swapping byte order and so on) and calls the native version. Since a typical program spends a significant proportion of its time in third-party libraries, this means that even a relatively poor emulator[1] can achieve good performance, because all of the time spent in Apple-provided libraries is spent running native code. This includes all of the Cocoa frameworks, CoreGraphics, and so on. Complex things like text layout and antialiased rendering are all done in the native code.
Microsoft could easily license the same code and include it with Windows. Almost anything in a system DLL would be native. For a typical app, this is quite a lot of the total run time.
I am TheRaven on Soylent News
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.