Next Generation of Windows To Run On ARM Chip 307
Hugh Pickens writes "Sharon Chan reports in the Seattle Times that at the Consumer Electronics Show in Las Vegas, Microsoft showed the next generation of Windows running natively on an ARM chip design, commonly used in the mobile computing world, indicating a schism with Intel, the chip maker Microsoft has worked with closely with throughout the history of Windows and the PC. The Microsoft demonstration showed Word, PowerPoint and high definition video running on a prototype ARM chipset made by Texas Instruments, Nvidia. 'It's part of our plans for the next generation of Windows,' says Steve Sinofsky, president of Windows division. 'That's all under the hood.' According to a report in the WSJ, the long-running alliance between Microsoft and Intel is coming to a day of reckoning as sales of tablets, smartphones and televisions using rival technologies take off, pushing the two technology giants to go their separate ways. The rise of smartphones and more recently, tablets, has strained the relationship as Intel's chips haven't been able to match the low power consumption of chips based on designs licensed from ARM. Intel has also thumbed its nose at Microsoft by collaborating with Microsoft archrival Google on the Chrome OS, Google's operating system that will compete with Windows in the netbook computer market. 'I think it's a deep fracture,' says venture capitalist Jean-Louis Gassee regarding relations between Microsoft and Intel."
Nvidia cpu (Score:4, Interesting)
Re:Nvidia cpu (Score:5, Insightful)
Imagine placing your mobile phone in the docking station on top of your TV and it instantly being transformed in a full-blown desktop-capable PC functionally similar to an average PC of today.
Re: (Score:3)
Amazing for a budget smart-phone.
Re: (Score:2)
Setting DPI (Score:2)
Imagine placing your mobile phone
My mobile phone is an Audiovox 8610 flip phone whose service for a year costs as much as a month's smartphone service.
in the docking station on top of your TV and it instantly being transformed in a full-blown desktop-capable PC functionally similar to an average PC of today.
People appear unwilling to learn to configure an operating system's DPI [pineight.com] to account for the difference in pixel density and seating distance between a desktop PC monitor and a living room TV. What makes you think they'll be ready to do so for a smartphone?
Re: (Score:2)
Mobile? It's going to change the office desktop.
Re: (Score:2)
This isn't about the mobile market though. Windows Mobile and Windows Phone already run on ARM chips.
This is initially about low end laptops and small servers and it will eventually filter up to the whole PC market. That's why Intel should be worried.
Comment removed (Score:4, Insightful)
Re: (Score:2)
ARM is the market referred to in this story, not x86.
I don't expect people to RTFA or even RTFS, but is it too much to ask for people to at least RTFHL?
Re:Nvidia cpu (Score:5, Informative)
Last one to market?
Can you name any other operating system that works on both x86 and ARM procs out of the box, with no modification or intervention necessary on the user end?
Linux. Well, that's the only one I can think of.
Re:Nvidia cpu (Score:5, Informative)
OS X, Linux, FreeBSD, and NetBSD. Not sure about OpenBSD - they did have an unmaintained port to some older ARM chips, which was discontinued, but I think they've got a newer one.
All of these have both ARM and x86 versions that work out of the box. Debian, for example, has complete software repositories for ARM so you can typically install the same software on ARM as on x86, and you have exactly the same user environment on both (well, except that the Linux kernel sucks at providing portable abstractions, so things like power management are very different on both). Apple supports OS X on both platforms, although their ARM port ships with UIKit instead of AppKit and doesn't include autozone, Carbon, Rosetta, or any of the legacy APIs.
Actually, now that I think about it, Windows CE shipped an x86 version (as well as ARM, PowerPC, and MIPS) for a while. Not sure if anyone used it, but it worked out of the box, at least as much as it did on any other architecture...
Re:Nvidia cpu (Score:4, Interesting)
Re:Nvidia cpu (Score:5, Informative)
It's also worth remembering that the x86 version of NT is itself a port. The NT actually comes from Intel's NT architecture, which eventually became the i860. The next target was MIPS, and then x86. It was intentionally not written on x86 to prevent any architecture-specific assumptions creeping into the codebase.
The Alpha version of Windows NT came with a thing called FX32!, which ran emulated x86 apps. It was pretty horrible, because the Windows codebase is full of endian assumptions (the Alpha version did lots of byte order swapping in the background) and emulator technology was not very advanced back then so the emulator needed a fast Alpha to run at a decent speed. It also ran in some weird pretending-to-be-32-bit mode, although they fixed that when eventually doing the win64 version for Itanium.
Re: (Score:3)
Re: (Score:3)
Office is getting ported. That's a start.
Yes, but not much of a start. So the only reason to run WinARM is a familiar interface and Microsoft Office? What about Quicken, Quickbooks, PhotoShop, AutoCAD or any other big time application? You may laugh at the Gimp, GNUCash, or some Linux CAD program now. But when the choice is Linux on ARM with apps and Openoffice (and probably some way to run WinARM Office if you want), or WinARM with AutoDesk and Adobe having NO intention of porting their apps to the platform, Linux looks pretty good.
Or perhaps you
Re: (Score:2)
Re: (Score:2)
Well debian linux runs on arm, it's a bit more of a pain to install it than on PCs but that is more the fault of the arm platforms in question than of linux.
PCs have a standard BIOS that provides a number of basic services including communication with the user and reading boot images from hard drives and CD-ROM drives. Arm systems sometimes have something similar but it's generally specific to a particular subfamily and is often designed to be driven from a serial terminal since a lot of arm hardware lacks
Wow (Score:5, Funny)
I knew it was getting fucking cold in here.
--Satan
But but but but but.... (Score:5, Insightful)
What about the huge catalogue of win32 applications?
If I was to believe the anti-linux trolling of the last decade or so, that's the major reason people won't ever, ever switch!
On a more serious note, I know .Net stuff stands a good chance of working fine, but there's a hell of a lot of windows stuff people use that isn't .Net and I can't see a translation engine or emulation working that great on ARM stuff.
Re:But but but but but.... (Score:4, Interesting)
Re:But but but but but.... (Score:5, Interesting)
Having a cross compiler would probably be a necessity.
ARM is pretty quick these days, but has nowhere near the power of the multicore 64-bit chips coming out of AMD and Intel at the moment.
Also there's the branding to think about. Sure windows ran/runs on a few architectures already, but if it *does* come down to x86/win32 apps not working on ARM machines and vice-versa, won't MS have a bit of a public education battle? Will the general public get confused by windows apps that are for one hardware variant and not another? Or will MS mandate fat binaries if you want Windows 8 certification or something?
Many questions...
Re: (Score:2)
Re: (Score:2, Interesting)
TargetCPU in the "advanced" compile options currently allows targeting AnyCPU( x86, x64 ), x64 only, and x86 only. It'd be somewhat reasonable to have the next version of the framework ( 4.5? ) be able to target ARM as a compile option ( maybe even offer an emulator for your code? ) and ship that as a SP to VS 2010.
Of course, there isn't enough windows bashing in this post to get it modded up, but oh well.
Re:But but but but but.... (Score:4, Interesting)
Well, this depends on their target audience.
If you have C/C++ code, porting it to ARM should be a huge deal. Yes there will be some differences, yes, there will be bugs - but in terms of effort its manageable. And more importantly, every single vendor has to do this effort, so Microsoft doesn't have to do anything.
Because Microsoft are saying this now, with no product that anyone can "buy" right now (or even soon), this probably means the audience for this news is *Developers* (the single intelligent word that Mr Balmer has uttered in the last 20 years, so good, he had to say it multiple times for it be considered a quote). They are now selling the ARM architecture to developers. If the developers buy this story, the applications will follow.
And of course, some developers will be more prepared than others. Don't expect an ARM version of Photoshop anytime soon, but an ARM version of Firefox is something that could be cranked out very easily.
Re:But but but but but.... (Score:5, Informative)
Not true. Different languages expose different abstract models to the programmer. A Smalltalk-family language like Java typically exposes a model where memory is only allocated in objects and instance variables in objects are only accessed by their name. In contrast, most Algol-family languages like C expose a lower-level model where memory can be allocated as untyped buffers and then cast to the required type.
The differences in CPU architectures are typically things like alignment requirements (can it load and store values that aren't word-aligned?), endian (which order are bytes), and so on. In C, there are a few things that you can do on x86 that will cause problems on other architectures. One is silently increasing alignment requirements:
A compiler will typically make this work for you if it sees the assignment to bar, but if it doesn't then it will assume that bar is aligned on a word boundary. If the target architecture doesn't support unaligned loads, then the last line will break things (you may get a trap, or you may just get the wrong result, depending on the architecture). Modern ARM chips will trap to the kernel for this kind of problem, so the kernel can emulate the load, but this is a couple of orders of magnitude slower. There is no way of expressing this code in a language like Java, so the problem doesn't arise.
Another issue comes from endian assumptions. Consider this code:
This will correctly give you the low 32 bits of foo in bar on a little-endian platform. On a big-endian platform, it will give you the high 32 bits. Most of the time you wouldn't do something this simple, but you might when reading data from a stream of some kind. It's bad practice, but that doesn't mean it's not done. Fortunately, ARM is little endian too, so this isn't an issue porting from x86 to ARM - it caused a lot of problems porting from x86 to PowerPC and SPARC though, especially in code that dumped binary data to files, read it back, and found it in the wrong byte order.
And, of course, there are size issues. In C, the different primitive types all have architecture-dependent sizes. Some people make assumptions about them. For example, it's usually safe to assume that long is big enough to store a void*. Unfortunately, it's not true in win64 (although it is in every other platform I've seen), so code that makes this assumption breaks in 64-bit Windows versions (Itanium and x86-64).
Re: (Score:2)
Another issue comes from endian assumptions. Consider this code:
This will correctly give you the low 32 bits of foo in bar on a little-endian platform. On a big-endian platform, it will give you the high 32 bits. Most of the time you wouldn't do something this simple, but you might when reading data from a stream of some kind. It's bad practice, but that doesn't mean it's not done. Fortunately, ARM is little endian too, so this isn't an issue porting from x86 to ARM - it caused a lot of problems porting from x86 to PowerPC and SPARC though, especially in code that dumped binary data to files, read it back, and found it in the wrong byte order.
And, of course, there are size issues. In C, the different primitive types all have architecture-dependent sizes. Some people make assumptions about them. For example, it's usually safe to assume that long is big enough to store a void*. Unfortunately, it's not true in win64 (although it is in every other platform I've seen), so code that makes this assumption breaks in 64-bit Windows versions (Itanium and x86-64).
This is just sloppy programming. Let me go out on a limb and say any decent programmer wouldn't do this. Having had to develop for MIPS, Alpha, PowerPC, Intel, and ARM, I learned not to do that a long, long time ago. Like proper memory management, these things are entry-level programming mistakes.
Re:But but but but but.... (Score:5, Insightful)
This is just sloppy programming. Let me go out on a limb and say any decent programmer wouldn't do this.
And how many Windows programs, particularly those whose original development started a decade or more back, were completely written by 'decent programmers'?
I've seen all of these problems in code that companies I've worked for had to make portable to 64-bit CPUs and other-endian CPUs.
Re: (Score:3)
Let me go out on a limb and say any decent programmer wouldn't do this
I completely agree, but a platform that can only run code written by decent programmers is going to have a very limited market appeal. Especially when you consider that a lot of business apps were written by inexperienced programmers for Win16 and just gradually updated for Win32, so are full of these kind of issues.
It's not so bad in UNIX code, because people typically tested on SPARC64, which is about as unlike x86 as possible so they caught these issues in the past. No one tested Win16 apps on anyt
Re: (Score:2)
You have it backwards. Dealing with the underlying CPU architecture is handled comletely by the compiler, and not in the code at all. Porting a C++ program from x86 to ARM doesn't require any programming at all - you just select a different target and recompile.
You have roughly six million programmers who've had to write portable C++ rolling on the floor laughing right now. Merely getting their software to work on 64-bit CPUs as well as 32-bit has been hugely painful for a number of projects I'm aware of which have done stupid things that only worked on a 32-bit CPU and broke as soon as you recompiled the code for 64-bit.
Re: (Score:3)
Porting a C++ program from x86 to ARM doesn't require any programming at all - you just select a different target and recompile. Perfect CPU port every time.
Not true. Memory alignment requirements, endianness, primitive sizes (eg 32bit vs 64bit pointers), inline assembly etc almost always come into play with non-trivial applications.
Re: (Score:3, Informative)
Why wouldn't you? You could always compile ARM Windows CE/Mobile code on x86, and you could always compile IA64 Windows code on x86 as well. The compiler only needs to run on x86, not the emitted binary. You'd need an emulation layer or virtual machine to run/debug the binary locally, though. Visual Studio has shipped with virtual machine images for Windows Mobile devices emulating ARM machines specifically for this purpose for years.
I really don't know why people are shocked by all of this. Windows is
Re: (Score:3)
The SPARC port barely ran (there were endianness issues that Microsoft never worked out,) and XPe is x86-only.
Re: (Score:3)
You forgot Itanium. Server 2008 runs on Itanium.
Alpha has an x86 to Alpha JIT compiler that would eventually turn an x86 app into native code. It wasn't enough to keep NT on Alpha.
I think everything else got steamrollered by x86.
MS has the work environment locked up. We all run Windows to AD/Exchange/Office/Sharepoint and other native apps. Maybe some users will get a thin client to a terminal server to run legacy apps with a native web browser locally.
Most home users will just need a web browser on a p
Re: (Score:3)
Re:But but but but but.... (Score:5, Informative)
I've been wondering the same thing. What about SDK's? Will there be a separate version of Visual Studio strictly for ARM? I know Visual Studio is mostly targeted towards .NET, but for native apps, will you be able to compile ARM code on the x86?
Visual studio it self is a userland app and as such should run on Windows for ARM with few problems. I'm not sure what MSVS is written in, if it's a native app there will be an ARM version much as there was a PPC and x86 version of Xcode when Apple switched to x86, if MSVS is a .NET app you should get a build once run anywhere App like Eclipse is except Eclipse is truly cross platform while .Net apps are truly cross platform only on Windows flavors. If MS does a proper job porting it, the ARM toolkit for Windows should be every bit as powerful as the Windows x86 toolkit. Win 32 applications on the other hand might be a problem but then again Apple did a pretty decent jop at running PPC applications on x86 machines with Rosetta, I ran pretty heavy PPC applications under Rosetta with no major problems, so I don't see why Microsoft could not do something in a similar vein.
Re: (Score:2)
But I doubt that would happen. Microsoft hates making their technology available outside of the Windows environment, as evidenced by the poor quality of Mac ports of Microsoft stuff. I never really understood why Microsoft made them in the first place. They must have some calcula
Re: (Score:2)
. I never really understood why Microsoft made them in the first place.
I have a two word answer : antitrust regulations
Re:But but but but but.... (Score:5, Informative)
Visual studio is a mixed mode app. The basic shell and environment is native code. But there are many managed components that are loaded into it. Previous to VS2010, the code editing experience was native, but I beleive it is now WPF based and as such is also managed.
A tool for developers as you might expect is highly componentized and extensible, and plugins can be written in either native or managed code.
VS has had cross compiling features for at least 10 years, and that's the number i picked because that's how long i've looked at it. VC 6.0 had th Windows CE toolkit, used for authoring windows CE apps for all the procs that CE supported. Modern VS installs ask you if you want to install the Itanium cross-compilation tools. When you install the Windows phone 7 SDK you get a different cross compiler and binary emulation environment.
Cross compiling, multi-targeting, etc is nothing new for MS. They've been supporting more architectures in more products than Apple, Google, or anyone else for years.
Re: (Score:2)
Microsofts desktop/server toolchains already support x86, x64 and ia64 so presumablly they already have interfaces to allow selection of the build target and since wince already supports arm they should already have an arm complier. So it should be "just" a matter of peicing the bits together and ironing out the bugs.
Re: (Score:2)
Can't P/Invoke on Windows Phone 7 (Score:3)
You can develop for Windows Mobile 7 in VS and it compiles to .NET and then runs that in an Arm emulator which is running the Windows Mobile 7 OS.
If your application is 100% Pure .NET, it won't easily be portable outside a .NET environment. Unlike a C++ application, whose back-end can be shared among front-ends for each platform (see multitier and model-view-controller [pineight.com]), a .NET application runs only on platforms with the .NET framework.
If your application uses a C++ back-end (for portability) and a .NET front-end, it won't even run. As soon as an app running on Windows Phone 7 tries to P/Invoke or otherwise execute code that isn't verifiably type-
Re: (Score:3)
What about the huge catalogue of win32 applications?
If I was to believe the anti-linux trolling of the last decade or so, that's the major reason people won't ever, ever switch!
On a more serious note, I know .Net stuff stands a good chance of working fine, but there's a hell of a lot of windows stuff people use that isn't .Net and I can't see a translation engine or emulation working that great on ARM stuff.
There's absolutely no reason that Win32 stuff would have any problem with the ARM architecture.
Microsoft will just port their Win32 API over to ARM. The problem with bringing Win32 stuff over to Linux is that there is no Win32 API natively available... And the folks developing WINE don't have Microsoft's inside knowledge... So everything has to be reverse-engineered and hacked-together.
It may not be the easiest thing in the world... But there's absolutely no reason why Microsoft couldn't port Win32 to a
Re: (Score:2)
True, but you're still going to be relying on the software developer to actually compile and ship an ARM version. Emulation typically slows things down dramatically, it only really works when your emulator is running on hardware MUCH faster than the hardware you're emulating - which isn't the case here.
Re: (Score:2)
True, but you're still going to be relying on the software developer to actually compile and ship an ARM version. Emulation typically slows things down dramatically, it only really works when your emulator is running on hardware MUCH faster than the hardware you're emulating - which isn't the case here.
Didn't Apple throw the emulation into hardware? Threw another chip or two on the motherboard for a year or so while everyone transitioned from the old Motorola chips to PowerPC?
Re: (Score:2)
Depends on the architectures. ARM and x86 are both little-endian, both 32-bit, both can do unaligned loads and stores but do them much slower than aligned ones. The biggest difference is that operations on floats and doubles are about the same speed on x86 (both are done in the 80-bit x87 unit, unless you compile with SSE, which Microsoft's compilers don't by default) but doubles are a lot slower on most ARM chips.
In contrast, porting from x86 to SPARC64 can be a huge pain - SPARC64 is big-endian, 64-bit
Re: (Score:2)
Porting a program that was written in C without consideration for other architectures to a new architecture is hard, really hard. Seriously, I've done it.
I was under the impression that Microsoft had been maintaining builds of Windows for multiple architectures for a while now, just in case.
Re: (Score:2)
What about the huge catalogue of win32 applications?
If I was to believe the anti-linux trolling of the last decade or so, that's the major reason people won't ever, ever switch!
On a more serious note, I know .Net stuff stands a good chance of working fine, but there's a hell of a lot of windows stuff people use that isn't .Net and I can't see a translation engine or emulation working that great on ARM stuff.
the reason people didn't switch was they didn't know how to change, now with 'smart phones' the kids are learning to be wireless and have no patience for slow clunky windows cloud or no cloud.
Re: (Score:2)
What about the huge catalogue of win32 applications?
If I was to believe the anti-linux trolling of the last decade or so, that's the major reason people won't ever, ever switch!
On a more serious note, I know .Net stuff stands a good chance of working fine, but there's a hell of a lot of windows stuff people use that isn't .Net and I can't see a translation engine or emulation working that great on ARM stuff.
An emulator would work great for ARM/Windows for two reasons:
Re:But but but but but.... (Score:5, Insightful)
I personally think that Microsoft needs to make the break to stay competitive. Continuing to support legacy software is extremely painful for both Microsoft and for their customers. I used to work for a company that was heavily invested in legacy Microsoft technologies. You know those dastardly tactics that Microsoft uses to lock you in to their product? Well, it keeps you from using new Microsoft technology as well. Loss-aversion [wikipedia.org] may be irrational, but, well, you try arguing that you need to switch to new tech to a CTO who has sunk millions into software that requires ActiveX on IE6. That, my friends, is why IE6 is still around. But I'm mildly amused at the irony that Microsoft's own proficiency in the lock-in game is hurting them now.
Re: (Score:2)
I'm guessing they plan to copy Apple, and offer a light version of Windows customized for handhelds and tablets that runs on ARM devices. Expect it to replace Windows Mobile on the phone eventually. Microsoft has proven that NT can be stable enough for an appliance-type device with the Xbox 360.
Re:But but but but but.... (Score:4, Interesting)
"What about the huge catalogue of win32 applications?"
They'll probably create an x86-to-ARM JIT-compiler. Like Alpha did with Windows NT during 90-s. So for a brief period Windows NT on Alpha was the fastest way to run x86 applications.
And it's not like they need to emulate the whole API like Wine has to do, they just need to translate x86 calling conventions to ARM calling convention, which can be done by a fairly simple shim layer.
Who cares about the win32 applications? (Score:3)
If they intend the next windows to be available for both Intel and ARM processors, they expect the ARM-Windows to be used on tablets, smartphones, etc.
It means that they do not want translation engines and automagic emulation - noone wants to get a pile of win32 application 1-to-1 copies on a tablet platform. .NET libraries and win32 api required for porting; but the porting needs to involve changes to the UI in any case, including support for low-precision finger pointing,
They'll supply the changes to the
Re: (Score:2)
That's pretty much why Windows/Alpha and Windows/PPC were duds.
Yes, desktop Windows (NT specifically) did have native Alpha and PPC variants. There were basically no applications so they were a novelty and Linux pretty much killed both of them.
It is obviously possible for a manufacturer to do an architecture switch or support dual architectures (see Apple), but I really don't see Microsoft pulling off what Apple did.
Re: (Score:2)
"Linux fanbois should be happy that Android is bringing people to Linux; more than you'd get any other way I'd wager."
Meh, this liniux fanboy is happy keeping it niche. That way I still get lots of lovely config files to mess with and learn about my system. Dumbing it down is not what I (personally) am after. It is kinda cool that it gets shipped in all sorts of devices now though.
Re: (Score:2)
Office?
That's nothing impressive to the average consumer. Nevermind business users.
That level of "compatability" just isn't going to cut it. They might as well be using anything else besides Windows.
No games. No apps. No obscure vertical apps. No point.
Ancient 68K machines even had office software.
Re: (Score:3)
I disagree, enterprise has plenty of apps (some of them ancient which can't be source ported) required to run their business. Office is the most widespread suite, but it's definitively not enough for most people.
If you're talking about the home market, then I think not even Office is needed for most people.
Re:But but but but but.... (Score:4, Interesting)
Re: (Score:2)
We've been over this in every other story about Windows on ARM.
A modern emulator allows trapping to native libraries. Anything in the standard Windows libraries would come with a stub version that ran inside the x86 emulator and called out to the native ARM version. This makes library calls marginally more expensive, but means that the code inside the library runs at the same speed whether the caller is an ARM or x86 executable. That means any of the time that a program spends in GDI+, DirectX, or eve
Re: (Score:2)
Inside the emulator, dynamic translation can easily get 50-75% of native speed.
But we're talking about running a full desktop OS + applications on a little ARM-based CPU. Those things are slow to begin with... so only getting 50% to 75% of native speed would be terrible to work with. It would really be like running Windows 7 on a Pentium II.
Re: (Score:3)
Re:But but but but but.... (Score:4, Informative)
Emulating non-x86 on x86 is hard because x86 has so few general-purpose registers - but emulating x86 on something else is relatively easy.
Have you actually written an x86 emulator on 'something else'? I have, and 'relatively easy' is not a phrase I would use... at least, not if you want to get any decent performance out of it.
Admittedly we were having to emulate the entire PC hardware so it could run old DOS apps and not just Windows user-land, so that would make life somewhat easier.
Re: (Score:2)
Re: (Score:2)
PowerPC is much more complex than IA-32
Not even remotely. The PowerPC architecture is pretty messy by RISC standards, but it's still mostly orthogonal. x86 instructions have nasty habits of setting semi-related condition flags and so on. There are a few that set condition flags by mistake: there was a bug in some 486 chips and game designers found that they could make their code run faster by taking advantage of it, and Intel had to reimplement the bug when testers complained that their games ('requires 486 or better') crashed on the simulate
Re: (Score:2)
Even though the Z80 is extremely primitive compared to PowerPC and POWER, it still has more instruction opcodes.
Only 5 years later than it should have been ! (Score:3)
Wikipedia tells me that .NET (and therefore managed code) is nearly 10 years old (13 February 2002)
I'm pretty sure that someone in Redmond was thinking about supporting multiple platforms when they started architecting their software compiler strategy back then. It just took their management structure 5 years to wake up to the idea.
Now people have to go in and remove all of that crud which is blocking porting their SW to a different architecture ...
DLL Hell was yesterday, tomorrow is P/Invoke hell.
Re: (Score:3)
not surprised (Score:2)
Re: (Score:2)
Same goes for Windows 2000. I have (had) a Beta of Windows 2000 for Alpha.
Also, there was a version of Windows NT (up to 4.0) that ran on PowerPC!
Re: (Score:2)
I smell Vapourware... (Score:5, Interesting)
Here's where .Net is a Big Win for MS (Score:3)
Properly written .Net apps should run unchanged (needing, at most, a recompile) on Arm. I've written apps (in the .Net 2 days) that ran on XP and CE.Net devices with just a recompile.
Re:Here's where .Net is a Big Win for MS (Score:5, Funny)
As long as it's 5Ghz and has 8GB RAM & 80GB dr (Score:2)
And needs water cooling. I mean this is Windows, no? Plus, do you really think that weekly 300MB patches are going to cruise along on your cell phone network?
Re: (Score:2)
Windows on ARM (Score:5, Interesting)
Windows on ARM? That doesn't matter.
Office on ARM is a million times more important - for a start, that suggests you can open your documents on another new platform without having to worry about export filters and binary compatibility. But hey, I'm afraid OpenOffice and suchlike beat you to it.
The problem with Windows on ARM is that no currently existing Windows program will run on it. It's a new architecture without binary compatibility, like Windows CE was. Sure you can port things over but you can do that anyway and few have bothered. Things like the NET framework are "supposed" to be cross-platform but you can be assured than anything vital that you have to use and that you have no control over development of (e.g. business apps) requires an x86 binary at some point, or isn't supported on ARM. So even your programs that are written in NET need to be ported (which usually means it'll never happen).
Telling people that Windows now runs on ARM is misleading - they will think that everything from Half-Life 2 to Sage should work on it without touching anything. What you mean is that there is now an official OS for ARM that looks and works a bit like Windows. Like Windows CE was. But then, what ARM? There are hundreds of ARM variations and not all of them can be catered to, so you're back to it only working on select platforms that have been especially designed for it - like, erm, Windows CE was. Can I join a domain and run my existing business apps? No? Then it's actually just the Windows *GUI* that's consistent across platforms, not the OS.
Even if the next-gen of Windows 8 can be almost identical on PC or other devices, you're then into the problem that it's not the OS that matters (and that pretty much *does* have to be changed for every hardware variation) but the applications. And "Windows on ARM" will make people think they can install Steam on it and just run everything. That's not the case and never will be.
Windows on ARM is a response to Android, to try to pretend to be as cross-platform. Same as OpenXML was a response to ODF, to try to pretend to be platform-independent. In reality, the headline will grab eyes and then the reality will disappoint. But in the meantime, you've sold a "portable Windows" license to some mobile-carrier who has to repeatedly explain that "desktop Windows" isn't the same as "mobile Windows".
It's just Windows CE. Remember trying to explain to people that Pocket Word wasn't the same as desktop Word? Same thing over again.
Re: (Score:3, Insightful)
Re: (Score:2, Interesting)
Is that the same Office as I get on my desktop installation CD? No? So it's a Microsoft-only product that's been ported by Microsoft to a Microsoft architecture? Windows "runs" on Alpha too. Office "runs" on Mac by that definition. What you're actually doing is BUYING another version of Office written specifically for that particular "Windows" port by the authors of the software who also happen to be the authors of the OS. How many *other* companies do you think stand a chance in hell of doing that, e
Re:Windows on ARM (Score:4, Insightful)
Re:Windows on ARM (Score:5, Insightful)
Surprise, you can't run your Linux binary blob compiled for x86 on ARM... same goes for Windows..
Except all those Linux applications are recompiled for ARM by the distro developers, whereas every single Windows application has to be recompiled by its own developers, and then you have to buy it again.
If you can't run your old Windows applications on this new 'Windows', why would you buy it? Joe Sixpack is going to buy a 'Windows' ARM machine, take it home, and then wonder why his old Word CD won't install.
Re: (Score:2)
Windows on ARM? That doesn't matter.
Office on ARM is a million times more important - for a start, that suggests you can open your documents on another new platform without having to worry about export filters and binary compatibility.
In the keynote, Microsoft demonstrated a recompiled-for-ARM Office 2010 running on their Windows-on-ARM demo systems.
It's just Windows CE.
Not at all. It's more akin to Windows NT for MIPS, PowerPC, and Alpha chips. They demoed a full-blown version of Windows (Win8 back end with Win7 UI), not a forked, barebones mobile OS.
Re: (Score:2)
>> It's more akin to Windows NT for MIPS, PowerPC, and Alpha chips.
And how long were *those* supported? This will survive only until the sales figures demonstrate the pitiful penetration of Windows in the tablet market vs. iPad and Android, then written off (as were the RISC ports) as a bad investment of time/$$$.
Without major app vendors jumping in with ARM ports of their x86 portfolios, this will be, like WinPhone 7, too-little-too-late.
SCOX(Q) DELENDA EST!!
Re: (Score:2)
And how long were *those* supported? This will survive only until the sales figures demonstrate the pitiful penetration of Windows in the tablet market vs. iPad and Android, then written off (as were the RISC ports) as a bad investment of time/$$$.
Perhaps. I agree, at least, that the standard Windows UI, while great on PC hardware, is ill-suited to tablets and the like and will never make the same inroads in that market that iOS and Android are. I was just correcting the factually incorrect assertions of the parent post, not making any predictions about the likely impact of ARM support in Windows. I don't really know what the target market may end up being.
Without major app vendors jumping in with ARM ports of their x86 portfolios, this will be, like WinPhone 7, too-little-too-late.
Agreed on the need for substantial third-party vendor support for this to be meaningful. I disa
Re: (Score:2)
Well, Open/LibreOffice works just fine on ARM today.
Re: (Score:2)
yeah, and everytime I use Open Office on Ubuntu I feel like I've gone back in time about 6 to 10 years....
So it took you back to the last version of Office that was any good, then?
Another one (Score:2)
Re:Another one (Score:5, Informative)
RISC was better 20 years ago because CISC chips were using close to 50% of the die area for complex decoders. RISC chips could use 5%, giving them vastly more space to cram on ALUs and so on. Then the transistor budget increased, but the decoder complexity stayed pretty constant. 50% became 25%, then 10%, and now the increased space on RISC chips is pretty much irrelevant and the space-saving in instruction cache offsets it.
Then people started caring about power consumption, and it turned out that the decoder (or, in the case of x86, the micro-op decoder, which is basically a RISC decoder after the CISC decoder) was about the only bit of the chip that couldn't be turned off while the CPU was doing anything. You can power down the FPU, the vector unit, and any of the other execution units that aren't relevant to the in-flight instructions, but you can't power down the decoder[1]. ARM does very well here. It achieves good instruction density with the 16-bit Thumb / Thumb2 instruction sets, but it can power down the ARM decoder when running Thumb code or power down the Thumb decoder when running ARM code, so the extra decoder complexity doesn't come with an increased power requirement.
[1] Xeons actually do power down the decoder when running cached micro-ops, but they need to keep the micro-op decoder powered, and this has a similar power requirement to a RISC decoder.
Re:Another one (Score:5, Interesting)
Yeah, the other issue is that ARM code is "bigger" but somehow a 900MHz ARM outruns a 1500MHz x86... hmm, why so much faster? The answer turns out to involve small decisions and branches, which on x86 et al involve load-compare-branch (mov %eax ... cmp %eax ... jne), whereas on ARM you have compare-prefix (mov %r1 ... cmp %r1 ... SUBGT, SUBLT, MOVEQ, BNE, etc) that don't take an extra cycle, i.e. MOVGT takes 1 cycle and MOV takes 1 cycle.
This means a lot of simple code compiles to simple instructions, whereas on x86 you have a huge amount of branching to do. A lot of 'if' and 'select' statements can be reorganized to just do one comparison and then drop through a bunch of instructions that are prefixed for simple cases.
This kind of thing reduces the performance penalty of not having a branch predictor--that's right, ARM performs as well as it does with no branch prediction. ARM has a huge number of registers (something like 16 with identical general purpose use and access times, vs x86 4 GPRs), lack of support for mis-aligned memory access (simple, fast data access paths), and a few cherry-picked things like a built-in barrel shifter in any arithmetic instruction (you can i.e. add numbers with shift left/right as part of the instruction). Also most instructions run in 1 cycle--even really crazy ones like conditional-arithmetic-shift (i.e. SUBGT Ra, Ri, Rj, LSL #2)-- whereas stuff like x86 runs an average of 2-3 clock cycles per instruction, with some very long. That means that a 2.5GHz x86 is about as fast as a 1GHz ARM.
ARM is a large amount of compensation for not implementing complex features. They look hard and say, "Well... this is a general good performance feature..." and do that; whereas CISC is like, "Here's a special case we should do... and oh, branch prediction would let us try to speed up branches... and we could add instructions for manipulating ASCIIZ strinsg..." RISC is more like, "Well, let's try to do everything in 1 cycle... let's prefix instructions so that we can avoid branching... let's add a ton of registers... let's not make a slow decoder... let's restrict memory access to avoid performance hits in cache misses..."
It's not about desktops! (Score:4, Insightful)
Everyone seems to rambling on about x86 compatability and running existing Windows applications on the ARM cpu. I see this more as an admission from MS that the desktop environment is stagnant and growth will be found in the market for dedicated devices (phones, tablets, netbooks etc). I don't see that this will be about desktops at all. I see this more like Apple does with iOS and OS X. Same code base but one runs on portable devices and the other is for their desktop machines. I have not real insight but I don't see where ARM desktop machines make any sense.
Anyone remember when Windows NT ran on x86, PPC, MIPS and alpha? It was amazing how much better it ran on the Alpha hardware than any x86 machines. Maybe it'll be a step forward for them - not that I really care.
Star Trek Next Generation (Score:3, Funny)
I specifically remember Cmdr. La Forge always talking about iso-linear chips. Not once did he ever mention ARM chips. Just like Microsoft to support the wrong Next Generation systems.
Intel is also an ARM vendor (Score:4, Informative)
Re: (Score:2)
x86 is a market with very limited competition where you can make hundreds of dollars of profit on a high-end CPU. ARM is a market with massive competition where you're probably going to be lucky to make $1 a CPU.
Key Phrase is "next generation Windows" (Score:2)
Schism? Fracture? (Score:4, Insightful)
What? Microsoft just made the smartest decision in their corporate lifetime. Well, third-smartest, and critical to their survival.
x86 is not the only architecture out there. Itanium is a market failure, RISC is relegated to the memory of us modem-wielding veterans, is there another chip line out there I forgot? If so, irrelevant.
Windows on ARM means:
- Potential NT kernel on phones. Hey, the NT kernel isn't half bad. A single kernel everywhere eorks for Linux, just sayin'.
- Opportunity for new markets like tablets and set-top/integrated TV systems. No, an Atom-powered tablet isn't ery attractive. Power demand is the issue, and ARM seems to be the king of power demand.
- A huge developer base that may not have to learn Java or Cocoa or Objective-C after all to be rlevant in our mobile- social- oriented world.
I mean, Microsoft winning sounds evil, but we should know by now that competition is good. Apple may have to answer this, and the Linux/Android community hasn't changed their value proposition one iota. In fact, consider the appeal of buying a phone and THEN choosing the OS you want - 'WindowsARM', Android, 'OpenIOS'... Or perhaps a hypervisor and VMs running any of the three?
I like it. 2GHz dual-core DX10 phones with 2GB RAM and a uSD slot for another 128G, 4.5" AMOLED screens and 1080p HDMI out? All I need now is to find a table at the Starbucks with the Bluetooth keyboard and mouse, and the 21" display, and I'm rockin.
I can dream, can't I?
All or nothing? (Score:4, Insightful)
is there a tag for "Big Fucking Deal"? (Score:3)
seriously, why is this news? yes, naifs out there associate OS stacks with particular hardware platforms, but the people _inside_ software companies don't. msft has produced extensive app stacks for ppc before, even to some extent mips and alpha. current windows is derived through NT and NT OS/2 from a codebase that was _originally_ developed simultaneously on MIPS and x86. obviously for devices like phones and tablets, even a lot of desktops, there's no need to worry about externally-provided add-in cards and the driver complexities that introduces.
besides, who cares that much about native apps anymore? "appliancy" stuff is browser/flash/java-based. msft itself is probably the main purveyor of non-browser/flash/java stuff, and of course they can retarget their office suite, no sweat (hah).
the interesting question in this is whether there's really any reason for ARM to be more mobile-friendly - that is, what is it about the ISA or implementation that makes it _inherently_ better (if any). my suspicion is that it's mostly a matter of methodology or culture: ARM has traditionally been very parsimonious (think hybrid or high-efficiency car), and the x86 makers have traditionally been more Nascar. Intel seemed to have done Atom almost against its will or corporate culture - followons have been more power-efficient, but they hardly seem like significant, bet-the-company efforts. AMD's recent bobcat-based chips appear to be based on a modestly-tweaked version of the K8. maybe what distinguishes ARM is something simple, like a compact instruction encoding...
It will fail (Score:3)
Re: (Score:2)
Big deal. Remember the NT 3.5 family, running on PowerPC, Alpha, x86, MIPS, and supposedly in the lab, SPARC?
Re: (Score:2)
Remember the NT 3.5 family, running on PowerPC, Alpha, x86, MIPS, and supposedly in the lab, SPARC?
We had most of those where I used to work. Of course there were hardly any actual _applications_ for any of those other than x86, so all you got to do was play with the operating system and run any applications you wrote yourself.
Re: (Score:2)
but did everyone forget what Windows Mobile and Windows Phone are? They are just mobile (i.e. stripped down) versions of Windows XP
no you are totally wrong, the phone os are based on the CE kernel which is totally different from the NT kernel.
Re: (Score:2)