This could be a good opportunity for Microsoft to dump a ton of legacy baggage in Windows 8. Windows developers will ultimately need to support ARM/x86 and the path of least resistance is going to be Microsoft's latest & greatest framework. Great time to draw a line in the sand and reinvent Windows. Microsoft can send the message to developers that if you want your app to run on Windows 8 you need to stop using that Windows 3.1 style font selection dialog box, stop barfing files all over random spots of the file system, stop using crappy early 90's style installers, etc.
It would be more like the OS 9 -> OS X switch happening at the same time as the PPC -> Intel transition, but without the old CPU architecture being totally deprecated.
Apple's notable for having made 3 major transitions (68k to PPC, MacOS to OS X, and PPC to Intel), but all three of those were as minimal as they could be given the circumstances. The architecture transitions were made with almost completely transparent binary compatibility and minimal changes needed for source code, while the source-incompatible OS/API change was made as gradual as possible with a long grace period (which a few companies chose to exploit rather than update their apps before it was too late).
Windows as a system is clearly not clean enough at the moment to easily switch architectures without needing a lot of complex compatibility stuff thrown in. If they try to force developers off old APIs and introduce a new architecture, that new architecture will be a second class citizen and will need a lot of external factors to give it traction.
>"Windows as a system is clearly not clean enough at the moment to easily switch architectures without needing a lot of complex compatibility stuff thrown in."
Windows currently runs on two radically different architectures...x86/x64 and Itanium. It has for more than nine years.
I don't see how Microsoft will ever shed the x86 legacy in Windows. Intel would have an interest in killing off arm-based laptops with aggressive pricing, and there really isn't any history of Windows developers rebuilding apps to support other chip architectures.
Wow, that's a sad list. It looks like they didn't even port half of the server components to the Itanium, and they warn you not to use .NET for anything performance-sensitive. The closest thing they've got to a modern, portable environment and their first port of it is so embarrassingly slow that they have to warn you on the feature list. Even worse, their modern GUI APIs (WPF) weren't ported at all, so even simple .NET apps are at risk of not working due to not using an archaic GUI toolkit.
Clearly the NT kernel is quite portable. There's plenty of evidence of that (MIPS, PPC, Alpha, IA-64... ). But there's no evidence that even the most modern and supposedly portable components of the desktop experience are actually at all portable. Hardly any of it has (as far as we know) actually been ported.
There's no reason all of that stuff couldn't run on Itanium too, but it's a matter of choosing what to invest in; OS releases have a huge test cost with supporting anything, and Itanium is too small a market - ARM is different because it's clearly consumer-based and it's here to stay. I assure you, it is all portable.
The problem Microsoft faces is that the primary selling point of Windows is the third-party software... which won't run on ARM.
Solutions: all providers recompile for ARM (unmanageable). W8 emulates x86 (slow). W8 does very tricky JIT recompilation of x86 to ARM, as if it were a VM (amazing).
Launching .Net a few years back means that at least all software written for that is trivially retargeted. A clever (or serendipitous?) leveraging of its platform.
Apple tackled this problem differently: by banning alternative software platforms from iPhone/iPad, they rapidly created a substantial 3rd party software base of native apps from nothing.
.NET was a great start on the road towards portability, but it didn't make it very far. Most serious apps that use .NET also end up using native code for some reason or another, be it performance or third-party libraries or limitations of the .NET framework. All you could really say of .NET is that it makes it easier to identify the non-portable bits of your app so that you can rewrite them (or perhaps compile them as fat binaries?) once Microsoft manages to actually port the whole .NET framework, which hasn't been done before.
I believe that DEC (Compaq?) shipped very capable JIT recompilation of x86 to Alpha a long time ago. They were trying to get past the hurdle of Intel's lock in. It didn't work.
Called FX!32, It was very similar with Rosetta, which came with the Intel Macs. It was viable because the Alpha at the time were really much faster than the Pentiums. On the other hand, low power ARM processors certainly won't be any faster than the competing intels, so that would make an emulation really dog slow.
Actually they shipped some of their workstations with softwindows 95 (which in the meanwhile, became Virtual PC, then was bought by Microsoft). It was close to usable on really fast machines :)
One thing both Google and Apple might be getting wrong is if they won't let developers make serious money. They are both encouraging very low prices like $.99 for "apps", which might mean that a lot of interesting software will never be written for those systems.
Microsoft always allowed and encouraged application developers to make money from their Windows applications, even though a "cheap applications means we can sell more Windows" strategy would naively seem to make sense.
If I had to pick an OS winner, Android is still the one I would bet on, but with this move, Windows definitely seems to me like a more credible contender.
Max Klein wrote about this at one point, but he apparently deleted it. The post is cached here:
> They are both encouraging very low prices like $.99 for "apps"
Please do explain how. Apple at least (I don't know about the Marketplace, apart from it not being available to a number of developers) has a wide range of available prices, there are GPS software for far north of $100 apiece, and a number of other applications which definitely aren't $.99.
Even in games, "big hits" are generally closer to $10 (when not on sale) than $1 (and outlining this kind of stuff is very much why Apple introduced a third "tops" list in the appstore). And please also explain how Microsoft would solve a race to the bottom which is the combination of users being cheap fucks and developers still wanting those users.
Doesn't say anything about iOS, and completely handwaves away the problem for Microsoft (apparently, microsoft "cares that he's making money" and will moneyhat him or something). Garbage.
This feels awfully late given that Windows CE has supported ARM since 1996. I never understood why Microsoft was reluctant to get a full-blown XP running on ARM (minus the x86 & DOS hamstrings). Windows CE always felt like a precursor to something that Microsoft didn't have the vision to follow through with.
Actually, the reason for Office never being ported came down to two things: different byte order and lots of x86 assembly mixed in the office code for performance reasons. Office was never 'portable'.
You pose the question as if those two things were contradictory, but aren't they really synonymous? I think everyone expects that the majority of computers sold in the next few years will be sold in the form of smartphones and tablets, and ARM dominates those markets.
As long as I can buy an ARM-based netbook subsidized by crapware/adware on Windows 8 and replace the thing with a decent OS, I'll be happy.
Sadly, I won't be able to brag about using a Windows-proof computer anymore...
Now, seriously, Windows failed once on RISC platforms because software vendors were not interested in supporting them. Can an ARM-based Windows desktop function when the only software it runs is Windows? And, perhaps, Office? Would a Windows user live without 3rd-party software? Would all 3rd-parties rush to support Windows on ARM? I doubt it.
And, of course, it reminds me of FUD maneuvers of the past, like Windows for Pen Computing. It may well be designed to prevent people from seriously considering moving to Android (or classic Linux) on ARM-based platforms "because Windows 8 will support ARM and is just around the corner". Seen it before. And it worked, BTW.
Now, seriously, Windows failed once on RISC platforms because software vendors were not interested in supporting them. Can an ARM-based Windows desktop function when the only software it runs is Windows?
I guess a lot depends on how much developers embrace .NET; .NET apps are compiled to CLR bytecode which presumably could run on ARM devices just as easily as on Intel.
> I guess a lot depends on how much developers embrace .NET; .NET apps are compiled to CLR bytecode which presumably could run on ARM devices just as easily as on Intel.
The only problem I think would be with mixed assemblies, those containing both native and managed code, which can exist for PC applications. XNA games for example run on PowerPC (Xbox 360) and ARM (Zune/WP7) but their development is much more constrained than PC applications.
True, we've had to put porting our .NET app to Mono (for Mac/Linux support) on hold because of that -- the grid component we were using had a load of native code under the .NET layer.
A lot of stuff is missing; last time I looked, IronPython (Python for .NET) wouldn't run on the restricted mobile CLR due to missing support for various introspection/code compilation APIs.
The most CPU demanding work on a mobile phone is actually the user interface, and on WP7 this is offloaded to hardware. I see no reason why ARM tablets running Windows would be necessarily slower.
We can all hear the collective groan when Steve Balmer said table PCs will run Windows. I don't question his devotion to Microsoft, but I seriously wished he has a bit more imagination.
> a) The ARM architecture is intrinsically slower than x86
Current ARM processors are not designed for speed. I doubt they will be able to outrun x86s in single-thread performance anytime soon. Without faster threads, the machine doesn't feel fast. OTOH, more cores make a machine feel smoother under load, which is very nice.
> b) .NET is intrinsically slow
This is the Java vs. native discussion. JIT and optimization and native libraries go a long way, but I don't see Office being rewritten in C# to run on the CLR. The last massive rewrite to the CLR was during the development of Longhorn and that part was cancelled, resulting in Vista and, IIRC, a two-year launch delay and the retirement of the project lead. .NET and Java (and Python, which is what I use most of the time) are good enough, but I just don't see a major OS rewrite in that direction until writing portable C/C++ and recompiling for each target becomes impractical.
> c) Microsoft wants the same applications that run on the desktop to run on the mobile
This is no mobile platform. If it runs "full" Windows, people will want it to run IE with plugin support. At the very least. People will want Office, games and Photoshop. If it doesn't offer an easy migration (data, programs, skills) they may as well go with iPad or Android that were designed to be that way since the beginning. If it doesn't run Windows software, why build the Windows legacy in?
Also, on your initial post you made the assumption WP7 is runs on .NET, which is mostly incorrect. Microsoft software shipped in WP7 is moslty (if not all) native. What runs under the CLR is 3rd-party software.
> Also, on your initial post you made the assumption WP7 is runs on .NET, which is mostly incorrect.
I never implied this. I just meant that the SDK is based on .NET, so .NET runs on ARM. It was a reply to the comment asking about .NET on ARM. Nothing more.
And when I said "are you trolling?", I was referring to
> Have you tried running Office 2010 on your phone?
so I hope I wasn't downvoted for this.
About the 3 points, "I doubt ...", "I don't see" and "people will want" is no evidence, just personal considerations, and mostly on the short term. So I don't want to continue the discussion any further.
"NVIDIA has obtained rights to develop its own high performance CPU cores based on ARM's future processor architecture"
No shipping date, no product details, nothing.
Wake me up when they have shipping silicon. In the meantime, don't let Intel release anything.
Don't get me wrong. I would love to finally get rid of the x86 ISA, but I know the first ARM PCs (actually they would not be the first ones) won't be high performance. And there is no magic - when we start seeing high performance ARM parts, they will demand more power and will have most of the problems x86s face today. Both camps have very smart people working on the processors we will be using a couple years from now. Presuming one of them has a secret weapon that will annihilate the competition is ludicrous.
They are not trying to beat Intel on their own turf. The phone/pad/netbook craze demonstrates that a lot can be done with relatively weak CPUs. The heavy lifting (if neccesary at all) can be done by the GPU. As NVIDIA their main focus is GPUs I guess that's their strategy.
Can an ARM-based Windows desktop function when the only software it runs is Windows?
They've done a half-decent enough job with Windows 7 to get people to move from XP, even when app support is patchy. Offer some compatibility, so that people don't rule out switching, but not enough compatibility to allow the software makers to remain complacent... That's the trick.
They have a ton of resources, and some half-decent developers, maybe they'll introduce an x86 compatibility layer.
On ARM?! ARM is not so fast. I can imagine ARM reaching Atom on single-thread performance, but nothing near Sandy Bridge.
That said, DEC had it for the Alpha, but only because the Alpha made the Pentium look like a toy. And it was not fun to run Pentium software at Pentium speeds on what was supposedly a very fast computer.
> Windows failed on RISC because when x86 proved too competitive
I remember distinctly how much faster Alpha-based workstations were in comparison to its Pentium Pro cousins. Unfortunately, I couldn't run many programs I had to (Office, for instance, ran under emulation, at Pentium-like speeds). I could run SQL Server and pretty much that was it. And notepad. And Minesweeper.
I can imagine a niche for high-density ARM-based servers running IIS, but, unless licensing is very cheap, I cannot imagine someone paying for Windows on four ARM blades when the same Windows on one x86 blade could do the same work. When licensing is a big part of the whole stack, the hardware evolves in weird, sometimes unpractical, ways.
That happened before too. When the most common Windows version (because it could run lots of popular software), was the 9x series, x86 processors were under specific evolutionary pressures and ended up with deep pipelines and insanely high clocks to remain acceptably fast until past 2000 (and entered an evolutionary dead-end). At the same time, RISC-based boxes that ran Unix routinely had more than one processor since the low 90's. I always thought it interesting that by the time AMD64 was announced, I was retiring our 5-year-old 64-bit mail server.
But there is the Cortex A-15 which puts ARM in the Intel perf ballgame. Not surprisingly, I've heard grumblings for nearly the past decade of an ARM version of Windows in various states of stability. It will be interesting to see how far along this is.
The issue with x86 and clocks had little do with Windows, and more with the Blue Crystal effect (MHz sell CPUs not perf). There's a great insider book about this called "The Pentium Chronicles" by the chief architect of the P6.
And yet, the most popular Windows version couldn't do anything with the dual and quad-processor boxes being sold. Clock number marketing had its share, but the lack of an OS that could run most games or support a lot of the hardware already out (I had a couple gizmos that didn't work under NT) certainly didn't help the evolution of multi-processor x86s. As late as XP-time, most of my friends who were serious about gaming dual booted their boxes between 2000/XP for work and 98 for gaming. For them, a multi-processor workstation would be useless half the time.
For most of 1999/2000, I worked on an IBM PC Server 320 with two Pentium 200 processors and found it was wonderfully "smoother" than the 400MHz P2 (or 3, can't remember that) users who didn't run NT had. I cannot picture myself being happy on a single threaded machine anymore.
> But there is the Cortex A-15 which puts ARM in the Intel perf ballgame
Where "Intel perf ballgame" might mean "within an order of magnitude of Intel's currently shipping ULC chips". A9-based hardware has barely started shipping (as in, hours ago), by the time A15s ship Ivy Bridge will be out. If not Haswell.
- ARM chiops are soon at desktop speeds; further, there are dual-core and quad-core ARM chips in the near future
- Laptops have been fast enough for years that customers can trade off some speed in favor of much longer battery life
- They see synergetic advances in gluing together mainline Windows and Windows Phone with ARM platforms: ARM is certainly going to be a player, they're certain that ARM based minilaptops, netbooks, and tablets, when they become closer to mainstream, are going to eat away market share from Windows/x86
More accurate claim: with "desktop speeds" I meant the processing power required to run a basic 2010's desktop system, including a modern browser and watching videos. ARM is pretty close there already and conversely nearly any x86 laptop today is vastly overpowered for any of those tasks.
The power that is supplied by modern desktop machines and used by heavy gamers, video editing guys, and number-crunchers is a whole another story. That market is probably settled for desktop for quite a long time.
That depends what you mean by "speeds." I used an ARM3-based desktop machine for a while 15 years ago. Personally I think it's a meaningless comparison, but there you go.
Same as everybody else, the ratio between an amount of stuff S and the time T it takes to execute a set of operations P on it
> I used an ARM3-based desktop machine for a while 15 years ago.
So?
> Personally I think it's a meaningless comparison, but there you go.
It's not so much meaningless as irrelevant. I interpreted "ARM chiops are soon at desktop speeds" to mean "ARM speeds are soon at [processing] speeds corresponding to x86 desktop machines at equivalent prices" which definitely isn't the case, not by a long shot. Soon at desktop frequencies yes (the A15 is advertised at up to 2.5GHz while retail desktop CPUs have been stuck under the 4GHz barrier for more than 5 years), performance per watt definitely (ARM has blown x86 away forever there) but actual, raw computational speed not really.
> > I used an ARM3-based desktop machine for a while 15 years ago.
> So?
So the idea of there being a "desktop speed" which ARM fails to satisfy is wrong. There has always been an ARM that can be used to perform "desktop"-type tasks.
