Windows 8 to support ARM, System on a chip, architectures
microsoft.com
microsoft.com
Where all this gets interesting is with things like Mono and Moonlight. If MS goes down this route, they could really be exposed as Mono and Moonlight mature.
Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's typical users (mom and pop) should not have to deal with.
Also that'd be a pretty drastic policy shift for Microsoft seeing the pains they've gone to maintain compatibility with older software.
My guess is that, at the very least, Win8 apps running native code will be packaged into a universal binary of some sort. I find that half-hearted though, since it requires recompilation of the original software.
wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off.
JITing x86 - ARM might not even be fully necessary for most modern apps. It might be possible to do some sort of interception and JIT-style translation for certain parts of code but it might also be possible to provide a DLL level compatibility layer as fallback. That way when DLL functions are called they're called natively, and the main module executes via JIT.
I'm not suggesting that would be easy, it'll be balls to the wall hard, but that's the only thing I that immediately springs to mind that wouldn't come with a massive performance penalty.
The fragmentation argument is valid and an excellent point to make, however we don't really know who this is being targeted at or the defined primary use cases at this point. If Microsoft can fck up the user experience so badly with Vista and Windows 7 Starter, they can fck up the user experience with ARM and not worry too much. It might also be worth bearing in mind that if a recompile is needed, it's going to be in the next Visual Studio, which will support a lot more managed code features through the CLR than unmanaged code on x86_64 (by which I mean the CLR supports more languages and has fairly tight integration - if you use C++ in Visual Studio you're probably using less of Visual Studio overall than if you're writing ASPX in C#).
On one hand I doubt this as MS has a penchant for backwards compat and there is an emulation layer for EVERYTHING in Windows as is.
On the other hand, I'm seeing them move away from their backwards compat religion and CISC to RISC sounds fucking horrifying to me.
The importance of x86 is overstated too. Many applications will be pretty close to a recompile away. There is of course the usual chicken-and-egg issue that all platforms have, but if Windows/ARM (WARM?) takes off, they will be recompiled.
And if there is vendor support, then they would probably just get something certified for the ARM systems.
EDIT: The flamewar detector is preventing me from replying, but I don't think anybody is really disagreeing all that much.
I agree with Ken, most of the business applications in big corporations are based on .NET. (J2EE used to be big but from what I am seeing .NET is eating J2EE's lunch)
The only thing I am saying is that even if the bytecode theoretically makes it possible, businesses will not generally want to move their applications to a new operating system and platform without the involved vendors supporting it. Hence, .NET vs native is not all that important, because they would just get new versions from the involved vendors anyway.
I agree with Ken, most of the business applications in big corporations are based on .NET. (J2EE used to be big but from what I am seeing .NET is eating J2EE's lunch)
For example, a company may have a matching donations program, and they may have a LOB app that employees go to to submit requests for matching funds, see status, list of qualifying charities, etc...
Large enterprises are often filled with hundreds, if not thousands of these applications. These applications are often what dictate the platform a company uses.
That said, I'm all for more ARM support in the world.
It looks like it will run .NET apps with little or no reworking. They probably borrowed a lot of the work of the .NET Compact Framework team for a reverse port. Expect native SDKs later, after the initial launch.
Then I can install a decent OS on the machine and be happy.
Unfortunately, I'll have to live with an unsupported hardware. I have no illusion this fad won't be a short-lived one.
The batteries will be a little smaller, to reduce weight, but 24 hours of operation on a single charge... that might becomes the standard.
Last time MS tried to be multi-architecture, they failed miserably. They couldn't even be bothered to port Office to non-x86 machines. And nobody buys a PC to run only Windows and Office. They'll have to do a whole lot more than they did and I don't think they would be capable of.
Right, this has always been the play on virtualization for the OS. Don't get stuck in legacy mode, virtualize, and move on. MS may finally be doing what everyone said they should do.
Not on ARM. Emulation is possible but will be really slow.
A factor of 10x slowdown would probably be reasonable. Is the current state of the art on ARM able to get it below 10x?
And, BTW, nobody would buy a computer that can run only Windows and Office.
To be fair, only the Office part would have to run under emulation. As soon as the code calls into core Windows, the machine would be running ARM code. I don't know where the boundary is with Office.
I do agree that only running Windows and Office is not sufficient. But its a starting point for the discussion.
Also, consider that A-15 may be competitive with current x86 designs. Who knows what will Intel and AMD bring by the time A-15/Denver machines hits the shelves.
That said, I find my modest Atom good enough for Django programming the slightly less modest Core i5 very reasonable with Java and Eclipse. It will take some iterations until ARM catches up (I assume it will move faster than x86 because of its simple architecture). I have no doubt a relatively modest ARM machine will be good enough for most of my then current usage.
Maybe we just have really fast networks.
I assumed he meant something where the network latency would impose a keystroke-level degredation in performance.
The picture may not be that grim if at least timing-critical parts of Office can be made into fat binaries. I would not bet on straight emulation of uncooperative code, however.
The HAL was built so that you can retarget quickly. I think people would be pretty upset if it was your team that checked in some code that blocked them from porting to a new platform quickly.
Tell that to those who wanted to run Office and Visual Studio on their Alpha boxes...
It took years before AMD64 was fully supported and it's semicompatible with ancient x86. ARM is a completely different beast. I am pointing out Microsoft tried to make this move before and failed.
When Apple did it (and they did it twice), the carrots were huge performance gains. This carrot implies a loss of performance. Unless hardware makers start flooding the market with Windows 8-compatible ARM machines, 3rd parties may opt to stay within the comfy confines of x86/AMD64.
It is a very tricky move.
Also, since most of what a Linux distro offers (and that includes OpenOffice, editors, IDEs, languages, games) already runs on ARM, this move would also benefit the competition that's already positioned to benefit from this without the need to convince 3rd parties to jump along. I imagine Microsoft will impose restrictions on what OS and software you will be able to install on those machines to counter that.
It will be fun to watch.
The carrot in this case is battery life. And I think the markets will turn out to be different ones. The ARM machines will largely be tablets and netbooks. The Intel SoCs will have poorer battery life, but better perf. That's where you'll have VS and such.
Of course .NET apps will run across both. And the Windows Marketplace will largely be .NET apps.
They failed at this before, because there was no motivation to succeed. Alpha, MIPS, Itanium, were all DOA. But they did help ensure that the Windows kernel was portable.
I'm betting they have some compatibility magic cooked up that we haven't seen yet.
Emulation has already been suggested. How about the possibility of having a launch hook that recompiles x86 machine code to ARM machine code? MS is on the short list of companies with the necessary resources to pull that sort of trick.
http://en.wikipedia.org/wiki/Rosetta_(software)
http://en.wikipedia.org/wiki/QuickTransit
It is running on everything from embedded systems, to phones, to desktops, to clusters. Throw in that all the hardware vendors who are interested in "the Next Windows" and Microsoft has just laid out a roadmap for the next ten years.
It's the business issues that matter. Whether you can recoup the costs, and when.
Application availability, third-party support, hardware vendor support, testing, and whether there's enough of a draw (coolness, compelling price advantage, better battery efficiency, whatever) to pull your user bases to the new platform, and pull in new customers.
There's the additional risk with whether and when key vendors will move. It might well technically be a recompile and go for the applications, though the vendors of key applications are probably going to need to see a sufficient market, or they may want some funding for porting. Vendors tend to be (reasonably) loathe to accept this porting and testing and support load without some form of revenue plan.
Emulation and translation are technically possible, though that too can be problematic; various vendors can tend not to support emulated or translated code. For understandable reasons, more than a few vendors wouldn't support their applications on Windows on Alpha via FX!32, for instance.
I'm also surprised that Microsoft is discussing this now; whether this is a cudgel on some providers, a palliative for their partners considering adding other OS platforms (Android, WebOS or otherwise), customers that are accepting other OS platforms, or whether they're really (seriously?) talking about a project and a potential product that's two years out.
Wondering what their particular motivation(s) here might be, still.
To put it another way, how many macbook pros are running Win7 solo, aka w/o bootcamp or VMware?
That's the only place I see this being relevant. Windows in any form that can meaningfully execute legacy x86 code is not going into a non-PC device. (dashboard computers, pocket computers, pmps, phones, tablets, etc)
So the only thing left is netbooks. Is that really a relevant play in 2011? Do they think this isn't a feature Google can match and beat them to market on? Do they think the legacy of Windows will be a compelling alternative to the relative simplicity and security of Chrome OS in that market?
I've tried wikipedia, but just got even more confused.
It is going to cost you a lot of money to do it right(you can use multiples dies inside a die but the real thing is just using one single die), but if you can sell enough(like Apple) you win on price per unit, reliability, mount cost, size volume and weight.
It's just like the Mac Intel transition, but without an emulator to fill in the gaps.
Building an x86 emulator is easy. Building one that can run Windows 8 software at speeds comparable to then current Intel or AMD x86 processors will probably be impossible. There is no such performance gap between ARM and x86.
I can see ARM being great for corporate desktops: .net LOB apps work, IE will work, Office will work etc.
The performance of a built-for-speed x86 is very forgiving. Eclipse runs well enough on my Core i5, but I suspect it would have problems on an energy-efficient ARM.