Microsoft Ready To Talk Windows On ARM 342
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."
Does this article really need to mention ... (Score:5, Informative)
Meanwhile, many other Linux distros have been shipping on ARM devices since before Ubuntu was a distribution.
"Ubuntu is already starting to ship on some ARM... (Score:4, Informative)
...devices and running on many others."
Eh. Debian has fully supported ARM for years.
Re:No surprise (Score:5, Informative)
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.
Re:No surprise (Score:2, Informative)
It is not that simple. The MSIL just converts the code to win32 calls. Some of these are for more modern versions of Windows that are x86 specific. You would need to rewrite and port part of the win32 apis and MFCs. Sounds like pure torture.
How Dave Cutler got it to work last time ... (Score:4, Informative)
They can just trot down to the Azure lab and ask Dave Cutler how he got it to work last time.
The NT dev team's method is no secret, throw everything out and start from scratch.
FWIW, note "NT" not "Windows NT", it actually started as "OS/2 NT". Back in the day MS was telling people that Windows was a temporary thing for users sticking with DOS rather than migrating to OS/2 1.x plus the Presentation Manager GUI, a 16-bit protected mode environment. IBM was going to do a more expedient x86-only 32-bit version, OS/2 2.0, while Microsoft was going to do a 32-bit portable version targeting various CPU architectures, OS/2 NT. At some point Microsoft decided to split up with IBM and renamed the product Windows NT.
2 or 2.5 GHz is not slow, it's equivalent. (Score:5, Informative)
Apparently you are talking about clock speed, but 2 GHz [infoworld.com] or 2.5 GHz [brightsideofnews.com] is not slow compared to the Intel Atom. The speeds are equivalent.
Re:That's nice... (Score:5, Informative)
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.
Re:With such an excellent track record.... (Score:3, Informative)
Mac Office has been out since 1989. It ran on the Motorolla 68000 and later the IBM PPC.
Re:No surprise (Score:5, Informative)
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.
Re:No surprise (Score:3, Informative)
You probably own more than one ARM CPU and just don't realise it. They're in most mobile phones. They're in MP3 players, TVs, routers, printers, set-top boxes etc. Depending on who you believe, ARM CPUs have 70-90% of the embedded market.
I think it already is. Around 5 billion ARM CPUs ship per year. Compare and contrast with 385 million PCs per year. Total. Not just PCs with low power Intel units. And there's not much other use of X86 processors besides PCs.