I've noticed a lot of speculation about how they will translate code between X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS have been pushing managed code via things like Silverlight and .NET for some time. My tuppence worth: Windows 8 on ARM won't support legacy x86 code, but will run .NET, Silverlight and any other managed code shamalamadingdong it needs to run. I can see Windows 8 on x86 supporting legacy code, but just as 16-bit support is gone completely in x86_64 Windows now, I'm expecting no support for unmanaged x86 code in the ARM version.
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.
> Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see Windows 8 on x86 supporting legacy code
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.
> 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#).
I absolutely agree with you about the penchant, but I know first hand from Microsoft employees that the backwards compatibility issue is a complete pain in the arse. Supporting ARM on managed only paves the way to ditch unmanaged code in x86_64 in the future. Supporting native unmanaged code might require a recompile and some testing, but might be possible (given the Xbox 360) but then you're going to have trouble with x86_64 only references in your code. Implementing some sort of x86 -> ARM is going to be a nightmare of epic proportions, Rosetta-type technologies be damned.
There is the idea that Windows is such a terrible system that the only reason people are staying with it is that they need their legacy applications. It's not entirely without merit, but for a lot of people and businesses, Windows actually works rather well.
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.
The risk that they're taking in consumer apps is the games market -- existing games won't work (although arm isn't that popular for gamers anyway), so it's a kind of chicken-or-egg problem as to getting games developed for that platform. I'm not quite sure how large that segment of the windows market is, but it's going to be a factor in the switch.
It isn't clear to me how portable .NET is in practice, but then I don't think it's a problem either way. Enterprises would not want to run some old .NET binary on a new system with a new operating system unless there was vendor support for it.
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.
LOB stands for Line of Business. These are applications usually built in-house and help the business perform their job.
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.
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)
Interesting that Microsoft's answer to "Why?" seems to be "Because we can." by journalists. Hopefully they have a better strategy than that.
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.
MS has learned from their experience with Windows on Alpha. Even when they released XP for x86-64, they initially wouldn't sell it at retail for fear that people would get confused and buy the wrong one.
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.
Right. They have ten years of .NET penetration into the corporate world, the web, and 3rd party application developers - plus four years of .NET integration right into their operating systems.
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.
The real magic is probably the Windows app store and new app packaging format that are also expected to be introduced with Windows 8. I'd imagine apps will be required to support both ARM and x86.
No, they explicitly stated that their demonstration did not consist of virtualized or emulated x86 Windows. That doesn't at all rule out a dynamic translation layer for x86 apps.
Although IBM seems to own them now, it could be the same Rosetta technology that Mac OS X used. The parent company had many public licensees and MS could have been one, but not announced.
Microsoft does have a license to customize the ARM architecture, so maybe they are planning some x86 compat layer. It's an interesting technical challenge but what business problem does it solve for Microsoft? This lets them run Windows on other processor, but it doesn't give them a better mobile platform to compete with iPad, for example.
I hope they can modulate Windows 8 OEM licensing price in order to convince some OEM to launch an 8 GB of RAM, SATA SSD ARM-based netbook with a x86-sized battery that gives it 48 hours of operation on a single charge.
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.
I think this no fad, and I think Intel must've seriously screwed up. Everyone knew that Intel was promising MS, "we're going to match ARM on performance per watt in the coming years". That roadmap must have disintegrated, as MS would not have come public otherwise.
The batteries will be a little smaller, to reduce weight, but 24 hours of operation on a single charge... that might becomes the standard.
In order for Windows on RISC to succeed, Microsoft and all 3rd parties will have to leave the x86 comfort zone and really support it.
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.
Now they have Office Live, which can be accessed through a web browser. So they don't need to port the entire Office suite, if they're targeting the netbook market. After all, Win 8 + Office Live sounds like pretty much the same deal as Chrome OS + Google Docs.
The x86 comfort zone is always by your side. With virtualization (and app virtualization) you can run x86 apps seamlessly. Fortunately Office apps aren't CPU bound.
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.
How slow? I did some quick profiling of Word and Excel doing basic stuff (text entries, making charts, but no hardcore calculations). Avg CPU utilization: 1%. Peak CPU utilization: 4%.
A factor of 10x slowdown would probably be reasonable. Is the current state of the art on ARM able to get it below 10x?
Average CPU utilization is misleading. Just wait to see how long those small brief moments when you have 50% CPU utilization will extend into minutes under emulation.
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 would have to measure it again, but I remember seeing numbers much higher than 4% peak when I had to use Office. It could be some other latency disguising as CPU usage. The fact is it's been a while since I last used Windows and Office 2010 and I would prefer it to remain that way.
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.
Have you ever tried running Office with a little network latency? The 10x slowdown is barely usable and unavoidably annoying, especially if you're used to a faster computer.
Probably 50% of the time I use office it is over remote desktop over VPN, and honestly I don't really notice it (I really don't notice it for any application except streaming media over RDP isn't great, but surprisingly acceptable).
With Remote Desktop you are running Office on the machine that has a fast network and only transferring the pixels that change. That's not, probably, what jawee was saying.
But I use Office completely w/o a network connection quite often. It's not a web app. It rarely touches the network. Just about the only time I hit the network is when using Excel to access a relational store or if your document is on a file share (and even then the document is stored locally after opening it).
I assumed he meant something where the network latency would impose a keystroke-level degredation in performance.
I think jawee's point is that little latencies (memory, cache, IO) quickly add up to make emulation much harder than that.
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.
Core OS is expected to go anywhere. x86/x64 today. Itanium/Alpha yesterday. Power for XBox360. ARM for embedded. What is XBox720 going to have?
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.
I am saying that a lot more than the base OS has to be ported. That includes, of course, Visual Studio, Office, games, utilities, 3rd-party titles, browser plugins (so you can do net banking), device drivers (so you can scan, print, use a smartcard reader). Windows benefits from a huge complex ecosystem that will have to move with Microsoft.
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.
As you know, they've apparently already ported Office (or are at least well on their way).
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.
Regular ARM should support 4 GB and LPAE supports terabytes (although each app is limited to 4 GB). Current SoCs probably have much smaller limits, like 1 GB. Nvidia's core may be 64-bit, though, which would eliminate these restrictions.
Porting an OS onto a new box can be technically quite interesting, but is only a fraction of the aggregate effort involved.
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.
When the Intel Macs were initial released there was a contest to install Windows XP on it natively (before bootcamp was even announced.) Enough people donated to the prize pool that the winner walked away with 14,000 dollars.
Flip off apple? Really? Apple sell them a device, they own it and do what they like with it. I don't think achieving something non-trivial like getting windows 8 running on an ipad is flipping off apple.
I think it's more thumbing their noses at Apple's propensity to lock down their devices. There's no challenge putting windows on an unlocked device, but putting apple's traditional competitor's os on a product that apple's best and brightest had supposedly locked down must carry some kind of thrill.
I wonder how much effort will be required to port native applications to Windows/ARM. I imagine it won't be too onerous since both x86/x64 and ARM are little-endian. Excepting bits of inline assembly and use of compiler intrinsics I don't think it would be too difficult. I also wonder if there will be a FAT binary extension to PE/COFF, or if applications will have to have separate builds per platform.
So Microsoft sees a real threat in Chrome OS netbooks then?
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 know that the "news" in this announcement is about ARM. But Soc itself is also about making existing PC software run faster. At the moment there is little argument for purchasing new hardware because
multiple cores are failing to significantly improve actual performance of desktop apps for reasons with which we are all familiar.
A system on a chip is a single chip that integrates all or almost all other chips on a motherboard into one chip. So this chip will have a cpu, graphics, memory controller, network controller, io such as usb. That way you can have basically one chip that is all or most of the computer. Sometime RAM and normally storage is separate chips but you basically end up with just a few chips on a very small, normally low power motherboard. It is great for system integrators as they don't need to spend as much development time to build new machines.
Instead of having a motherboard with the RAM, CPU, GPU on different components, you integrate them on a single die or chip.
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.
If this is true, then Windows 8 is not a true successor to Windows 7. Current desktop/server apps assume binary compatibility with x86. This sounds much more like a scaled-up version of Windows Phone.
That's a crazy thing to say. The UI, the APIs, etc. will all be based on Windows 7, and any all-CLR apps should run without change. On Windows 8 running on x86, current apps (and Windows 3.1 apps, and maybe DOS apps?) will undoubtedly still run.
It's just like the Mac Intel transition, but without an emulator to fill in the gaps.
Who knows? MS might be obsessed enough with backwards compatibility to pack an emulator in there, like they did with WOW64 (though it would be more difficult to write an x86 emulator for ARM).
> it would be more difficult to write an x86 emulator for ARM
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.
Would the opposite be easier? It might make sense to offer comparability for Windows|ARM executables on Windows|x86, so if you want to hit both platforms, you'd be doing it in ARM.
I can see ARM being great for corporate desktops: .net LOB apps work, IE will work, Office will work etc.
Sure, but one key advantage of Windows is that it has a huge legacy of software that already targets x86 and that would have to be recompiled/reoptimized to ARM.
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.
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.