Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Next Generation of Windows To Run On ARM Chip

samzenpus posted more than 3 years ago | from the let-the-chips-fall-where-they-may dept.

Microsoft 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."

cancel ×

307 comments

Sorry! There are no comments related to the filter you selected.

Nvidia cpu (3, Interesting)

assemblerex (1275164) | more than 3 years ago | (#34775152)

just happens to be coming out as well.

Re:Nvidia cpu (-1)

Pojut (1027544) | more than 3 years ago | (#34775354)

This means absolutely nothing now, given what mobile hardware looks like today. In the 2-3 years when Windows 8 is actually released, though? Whoa. So long as the execution is done reasonably well, and unless Apple is hiding something from us, this could very well change the entire face of the mobile market.

I'm surprised this isn't getting more attention in the "mainstream" press, considering how easily the news could be dumbed down to be understandable by the average Jill and Joe.

Re:Nvidia cpu (0)

click2005 (921437) | more than 3 years ago | (#34775440)

I agree. Why isn't the 'mainstream' press making more of the fact they're the last one to market and their product won't even be available for 18 months. I guess its Microsoft's only option when they cant buy/steal an existing product.

Re:Nvidia cpu (-1, Troll)

Pojut (1027544) | more than 3 years ago | (#34775630)

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?

Re:Nvidia cpu (1)

RoboRay (735839) | more than 3 years ago | (#34775678)

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 (4, Informative)

ArcherB (796902) | more than 3 years ago | (#34775686)

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 (4, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34775780)

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 (2)

aztracker1 (702135) | more than 3 years ago | (#34775808)

Debian (and other Linux distros), FreeBSD (and others)... What makes you think that no modification or intervention is necessary for users running ARM based windows? Outside of .Net applications that don't use P/Invoke (FYI, anything relatively complex in .Net probably uses P/Invoke, or a library it uses does). Native applications will need to be recompiled, and users will need to be aware of said differences.

Re:Nvidia cpu (4, Insightful)

mwvdlee (775178) | more than 3 years ago | (#34775456)

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:Nvidia cpu (2)

Inda (580031) | more than 3 years ago | (#34775688)

The wife's HTC Wildfire is more powerful and has more RAM than the P3 I still use to run FF, file servers and other stuff.

Amazing for a budget smart-phone.

Re:Nvidia cpu (1)

TheRaven64 (641858) | more than 3 years ago | (#34775794)

Imagine your TV having a high-end multicore ARM CPU and both the phone and TV running Xen, so you just live-migrate the VM from your phone to your TV when you get home. Samsung had a demo of this working in 2007, but I've not seen it in any shipping products yet.

Re:Nvidia cpu (1)

MrHanky (141717) | more than 3 years ago | (#34775628)

Mobile? It's going to change the office desktop.

Wow (5, Funny)

Anonymous Coward | more than 3 years ago | (#34775168)

I knew it was getting fucking cold in here.

--Satan

Re:Wow (1)

Smidge207 (1278042) | more than 3 years ago | (#34775408)

The devil finds work for idle circuits to do.

First Post? (0)

Anonymous Coward | more than 3 years ago | (#34775170)

ARM's share price did quite well from the announcement. http://www.bbc.co.uk/news/business-12127451

Great, but, why did they announce this at CES? (1)

Anonymous Coward | more than 3 years ago | (#34775184)

They forgot the C in CES?

But but but but but.... (5, Insightful)

Nursie (632944) | more than 3 years ago | (#34775192)

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.... (3, Interesting)

Major Blud (789630) | more than 3 years ago | (#34775212)

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?

Re:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775226)

I can't speak for WinMo7 but WinMo6 used VS as its development platform. Obviously the devices involved weren't x86.

Re:But but but but but.... (1)

igreaterthanu (1942456) | more than 3 years ago | (#34775316)

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.

Re:But but but but but.... (4, Interesting)

Nursie (632944) | more than 3 years ago | (#34775236)

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:But but but but but.... (2, Interesting)

Anonymous Coward | more than 3 years ago | (#34775256)

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.... (3, Interesting)

johnhennessy (94737) | more than 3 years ago | (#34775286)

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.... (0)

Anonymous Coward | more than 3 years ago | (#34775398)

Huh? The language has nothing to do with it, it's the compiler/toolchain and libraries that must support it. If Microsoft (Intel, gcc, Borland(?), Open Watcom, etc.,) do their job correctly you, the developer, coding in LANGUAGE$, will get a working target executable.

Re:But but but but but.... (4, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34775976)

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:

char *foo = malloc(12);
int *bar = (int*)(foo+1);
// in another function
int wibble = bar[1];

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:

int64_t foo;
// Set foo to something
int32_t bar = *(int32_t*)&foo;

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:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775432)

> And more importantly, every single vendor has to do this effort, so Microsoft doesn't have to do anything.

That's a weakness not a strength - that means every single vendor you deal with has to make the effort to port and test, or you can't switch. Every single in-house app has to be revisited or you can't switch.

Re:But but but but but.... (1)

Barefoot Monkey (1657313) | more than 3 years ago | (#34775702)

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.

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. Perfect CPU port every time. The difficulty of porting a program to another device is in all the differences other than the CPU - mainly the differences in the available software environment (system calls, DirectX, OpenGL, Cocoa, .Net, etc.) and possibly different peripherals.

Re:But but but but but.... (3, Informative)

Anonymous Coward | more than 3 years ago | (#34775296)

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 isn't a non-portable OS. It's run on various other platforms in the past, including MIPS, Alpha, Sparc, PowerPC and even ARM (Windows XP Embedded). Microsoft just doesn't port to platforms for the sake of doing so; they follow the markets for those devices. The IA32 and x86-64 platforms more or less emerged as the only marketable commodity platforms for servers and workstations and the ARM platform for portable devices and Microsoft has always followed both with appropriate offering. This blurring of the lines between a portable workstation and a portable device in the realm of "tablets" or "slates" is really a more recent phenomenon and Microsoft will follow it there as the market allows.

As for the rest of the x86 applications, sure, they aren't going to run, but Android and iOS have both demonstrated that there is probably little need for them. A slimmer version of Windows with a fully functional Office suite could be a very successful market, especially with the server and desktop markets as leverage. That could certainly be considered anticompetitive behavior, though, so that might turn interesting.

Re:But but but but but.... (2)

bhtooefr (649901) | more than 3 years ago | (#34775380)

The SPARC port barely ran (there were endianness issues that Microsoft never worked out,) and XPe is x86-only.

Re:But but but but but.... (1)

Anonymous Coward | more than 3 years ago | (#34775314)

Back in the late 90s when Windows NT could run on Alpha, MS didn't support cross-compilation. We had to buy an Alpha system to compile our code for Alpha.

On the other hand, you can compile for x64 on 32-bit Windows.

I think we'll have to wait and see. But I wouldn't be happy shipping code for a platform I didn't have and had never tested on. There are a few things (missing libraries, alignment issues) that can bite you in the ass.

Re:But but but but but.... (2)

robthebloke (1308483) | more than 3 years ago | (#34775330)

Visual C++ has been able to compile for arm for some time..... Just create a new solution platform from the configuration manager.

Re:But but but but but.... (1)

lysdexia (897) | more than 3 years ago | (#34775744)

Just create a new solution platform from the configuration manager.

So I convert the configuration manager to a drinks trolley?

Gad, I'm confused.

Re:But but but but but.... (4, Informative)

Savage-Rabbit (308260) | more than 3 years ago | (#34775336)

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:But but but but but.... (1)

raddan (519638) | more than 3 years ago | (#34775624)

What I think would be really interesting is if Microsoft decided to leverage .NET to help them expand their software ecosystem. There's already a .NET runtime on Linux: Mono. Hey... just so happens that Android runs Linux...

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 calculation somewhere that shows that it's better to keep people at least partly hooked to their stuff...

Re:But but but but but.... (1)

JonySuede (1908576) | more than 3 years ago | (#34775908)

. 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.... (0)

Anonymous Coward | more than 3 years ago | (#34776014)

Back in 2003 I saw a version of Windows 2000 running on an prototype multi-core ARM CPU, so they've been at it for a while.

ARM has really cool technology so it's no surprise the engineers at Microsoft want to use it, then and now. Perhaps it's just now that the engineers have got management to listen.

Re:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775234)

I'm no expert in the architectures, but from what I know, PowerPC is much more complex than IA-32 and Apple wrote Rosetta to move Mac stuff over.

Re:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775356)

PowerPC is much more complex than IA-32

What? PowerPC is considered a RISC and IA-32 is considered a CISC.

By definition, IA-32 is more complex than PowerPC.

Re:But but but but but.... (1)

91degrees (207121) | more than 3 years ago | (#34775620)

Z80 is CISC. Pretty certain a PowerPC is more complex than one of those. The complexity simply refers to the instruction set design. Even "reduced" is something of a misonomer since some RISC processors have more instructions that contemprary CISC devices.

The key point is that RISC devices tend not to have certain types of unneccessary instructions.

Re:But but but but but.... (-1)

Anonymous Coward | more than 3 years ago | (#34775252)

If they've got Word, Powerpoint, and Excel, that's 99% of the catalog that 99% of the people care about. And I mean real Word, real Powerpoint, real Excel; not OpenOffice work-alikes.

Most of the people I know who won't switch -- it's just because Linux isn't Windows and doesn't come from Microsoft. That was true for OS/2 as well.

Face it, Linux will be a geek niche product for a long time to come. Linux fanbois should be happy that Android is bringing people to Linux; more than you'd get any other way I'd wager.

Re:But but but but but.... (1)

Nursie (632944) | more than 3 years ago | (#34775280)

"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:But but but but but.... (1)

jedidiah (1196) | more than 3 years ago | (#34775478)

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:But but but but but.... (2)

icebraining (1313345) | more than 3 years ago | (#34775616)

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.... (0)

Anonymous Coward | more than 3 years ago | (#34775264)

What Apple has done with OS X and its apps when moving from PowerPC to Intel.

Damn you Slashdot for frakking up the login system. - ivucica

Re:But but but but but.... (3, Interesting)

dingen (958134) | more than 3 years ago | (#34775464)

Apple got away with virtualizing and emulating the old architecture and shipping the new architecture because the new architecture was faster. But this transition on the other hand is from a faster to a slower platform. You can't emulate x86 on ARM with any decent performance.

Re:But but but but but.... (1, Troll)

raddan (519638) | more than 3 years ago | (#34775714)

But also, Apple customers are used to breathlessly thanking The Steve for making their lives momentarily miserable. As long as they're promised to receive Teh New Shiny, and that all of their problems will be solved in the next iteration, Apple customers will do it.

Microsoft customers are different. Microsoft's main selling point for the last decade, whether it was true or not, was lower TCO. Bean-counters love Microsoft, and crusty old entrenched IT managers love Microsoft as well. And Microsoft's customers have poured millions into Microsoft's enterprise technology, all of which was tied closely to x86 until .NET. I know a guy who works for Philips-- when Microsoft deprecated an API that Philps had heavily invested in, Philips complained, and Microsoft un-deprecated it.

I think the main point is that Apple's important customers are largely home end-users. Microsoft's important customers are businesses. Businesses tend to be a bit more conservative.

BTW, I'm not sure the "emulated x86" platitude holds anymore. x86 chips themselves have emulated the x86 instruction set for quite awhile now. They're something like RISC inside now... Whether that means that ARM can emulate x86 well, I don't know, but it is clearly possible to do well.

Re:But but but but but.... (-1)

Anonymous Coward | more than 3 years ago | (#34775968)

Jesus Christ, dude.

Re:But but but but but.... (1)

hattig (47930) | more than 3 years ago | (#34775300)

If only Microsoft offered a software development kit that most Windows developers used - they could incorporate ARM builds into it so that current software would be available for ARM in time for the release. They could even allow applications to have both ARM and x86 variants within the same application binary, as Apple do with Mac OS X software. Older applications that won't get recompiled will surely perform well enough under software emulation.

Sadly, as Microsoft don't offer any form of SDK or compilers or anything of the sort, this Windows on ARM thing is doomed to failure. Right now they're writing the bits for Windows 8 for ARM by hand, flicking switches and pressing a button to store that instruction into memory.

Re:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775340)

It's deja vu all over again. NT on MIPS/Alpha worked OK, shame about the software availability.

Re:But but but but but.... (2)

Ephemeriis (315124) | more than 3 years ago | (#34775344)

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 any architecture they feel like.

Or, if there are truly fundamental problems with getting some bit of code to run on some bit of hardware, just toss some emulation underneath it all.

Re:But but but but but.... (1)

m50d (797211) | more than 3 years ago | (#34775534)

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.

Re:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775586)

> There's absolutely no reason that Win32 stuff would have any problem with the ARM architecture.

Win32 stuff compiled for an x86 chip will only execute on either a chip that supports x86 instructions or a emulated version of chip that supports such instructions. The API is only one part of the problem. .NET and Java get round this by using a "virtual CPU" (The Java Virtual Machine and the Common Runtime Environment).

Re:But but but but but.... (1)

jimicus (737525) | more than 3 years ago | (#34775598)

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:But but but but but.... (1)

kesuki (321456) | more than 3 years ago | (#34775406)

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:But but but but but.... (1)

bluefoxlucid (723572) | more than 3 years ago | (#34775468)

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:

  1. We have all the relevant libraries, so basically just the program and any libraries it brings get emulated; the linker links non-native and native libraries, of course. The tricky part is call-backs to function pointers, since "get me the address of $function" is a pretty raw machine activity and not a call to a facility somewhere.
  2. We're addicted to JIT these days, so of course we could just JITter the code to ARM. Callbacks via function pointer would work.

Re:But but but but but.... (4, Insightful)

raddan (519638) | more than 3 years ago | (#34775474)

Microsoft might be viewing this much the way Apple views iOS: it doesn't matter. Mobile devices, especially touchscreen devices, are different enough from their hardwired brethren that people may not seek to run the original software. Add to the fact that most technology companies are seeking to push software "to the cloud" (and indeed, Microsoft already has a cloud version of Office), this may become less and less of an issue.

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:But but but but but.... (1)

m50d (797211) | more than 3 years ago | (#34775550)

Why do you think emulating on ARM would be hard? Emulating non-x86 on x86 is hard because x86 has so few general-purpose registers - but emulating x86 on something else is relatively easy.

Re:But but but but but.... (0)

Anonymous Coward | more than 3 years ago | (#34775614)

> Why do you think emulating on ARM would be hard?

The memory segmentation woe ?

Re:But but but but but.... (3, Informative)

0123456 (636235) | more than 3 years ago | (#34775906)

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:But but but but but.... (1)

drinkypoo (153816) | more than 3 years ago | (#34775756)

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.... (3, Interesting)

Cyberax (705495) | more than 3 years ago | (#34775832)

"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? (2)

Peeteriz (821290) | more than 3 years ago | (#34775872)

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.
They'll supply the changes to the .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, multitouch, physically small screens, etc. All MS needs to do for the current applications is to make the porting process reasonably cheap.

Re:But but but but but.... (1)

Andy Dodd (701) | more than 3 years ago | (#34775892)

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.

Only 5 years later than it should have been ! (2)

johnhennessy (94737) | more than 3 years ago | (#34775220)

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:Only 5 years later than it should have been ! (2)

cnettel (836611) | more than 3 years ago | (#34775352)

Proper P/Invoke declarations will work just fine carrying over to ARM. "Proper" ones being approximately those that work across x86 and x64.

not surprised (2)

llung (1841162) | more than 3 years ago | (#34775278)

Not all that surprising. Back in the day, NT ran on MIPS and Alpha and you could compile native code for both from respective versions of Visual C. That was a long time ago but all the code infrastructure to support different CPU architectures are still there. 3rd party code is a different story.

Re:not surprised (1)

blind biker (1066130) | more than 3 years ago | (#34775318)

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:not surprised (1)

Major Blud (789630) | more than 3 years ago | (#34775414)

I happen to have an old Enorex box that uses an Alpha CPU. It was running Windows NT 4.0 on it when I got it (although it has since been switched over to Linux). The only way to get x86 Windows code running on this box was to use FX!32 from DEC, which was an emulation layer. You took a huge performance hit when trying to do this, and not all software worked correctly. Granted, things have come a LONG way since then, but I'm not sure that emulation/virtualization is the way that we'd want to go.

Re:not surprised (0)

Anonymous Coward | more than 3 years ago | (#34775346)

MIPS, Alpha, and PowerPC (as well as x86).

I smell Vapourware... (5, Interesting)

advocate_one (662832) | more than 3 years ago | (#34775338)

Microsoft are pre-announcing something to try to stop customers and OEMs from moving over to ARM based kit now... they've got a long history of pre-announcing stuff that will be available soon... They did it with DOS 5 to stop people from jumping to DR-DOS 5 which had lots of features DOS 4 didn't have [theregister.co.uk]

on 2nd May 1990 MS-DOS product manager Mark Chestnut said: "On the PR side, we have begun an 'aggressive leak' campaign for MS-DOS 5.0. The goal is to build an anticipation for MS-DOS 5.0 and diffuse potential excitement/momentum from the DR DOS 5.0 announcement. At this point, we are telling the press that a major new release from Microsoft is coming this year which will provide significant memory relief and other important features."

Re:I smell Vapourware... (0)

Anonymous Coward | more than 3 years ago | (#34775788)

I've also considered just how much hardware one needs to merely install the latest version of Windows. I mean, sure, there's watered-down version for lesser systems, but the big announcement implied to me that they were peddling "real" Windows. Does that mean I didn't actually need to upgrade to a four-core system after all?

Re:I smell Vapourware... Released with... (-1)

Anonymous Coward | more than 3 years ago | (#34775840)

Yes you to can get it bundled with Duke Nukem Forever!!! all for the low price of hot air. :)

Anonymous Coward (-1)

Anonymous Coward | more than 3 years ago | (#34775412)

headline incomplete; should end with:

"Very Poorly"

Here's where .Net is a Big Win for MS (2)

wiredog (43288) | more than 3 years ago | (#34775422)

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 (4, Funny)

dingen (958134) | more than 3 years ago | (#34775476)

Just a recompile should take Adobe about a year though.

Big deal? Remember Windows CE (1)

mschaffer (97223) | more than 3 years ago | (#34775434)

I don't see what the big deal is. Has anyone heard of Windows CE or Windows Embedded? These versions of Windows ran on non-Intel platforms, including ARM.
I know people like to bash Microsoft, but did everyone forget what Windows Mobile and Windows Phone are? They are just mobile (i.e. stripped down) versions of Windows XP. Just like these versions, I doubt that we will see any virtualization that will let you run x86 software on it. Everything will need to be recompiled, just like Windows CE.

Re:Big deal? Remember Windows CE (1)

SuiteSisterMary (123932) | more than 3 years ago | (#34775556)

Big deal. Remember the NT 3.5 family, running on PowerPC, Alpha, x86, MIPS, and supposedly in the lab, SPARC?

Re:Big deal? Remember Windows CE (1)

0123456 (636235) | more than 3 years ago | (#34775994)

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.

As long as it's 5Ghz and has 8GB RAM & 80GB dr (1)

gelfling (6534) | more than 3 years ago | (#34775436)

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:As long as it's 5Ghz and has 8GB RAM & 80GB (1)

aztracker1 (702135) | more than 3 years ago | (#34775876)

Well, eliminating the code debt wrt unmanaged code, especially in the ARM port would alleviate a lot of the burden on resources. MS has been pushing in this direction for the better part of the past decade. Though it's taken a long time to get their core application suites more portable.

Windows on ARM (5, Interesting)

ledow (319597) | more than 3 years ago | (#34775444)

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:Windows on ARM (3, Insightful)

yapplejax (931268) | more than 3 years ago | (#34775484)

No existing Windows app will run on it? Office, as demonstrated at CES, isn't a Windows application?

Re:Windows on ARM (1, Interesting)

ledow (319597) | more than 3 years ago | (#34775646)

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, even with MS's co-operation, and having it work, let alone actually making money on the idea?

It's "Office-like" or even an "Office-port" but it's not "Office". Office ports have run on MacOS for decades. Office can run under Linux if you use WINE. It doesn't mean that "Office is on Linux" or that it's supported (no support = no business use). Also doesn't mean that even 1% of the apps that a business runs or plugs into Office will work on Mac or this or anything else.

There is a new version of Office - that's the news - that can run on ARM and open standard Office docs. The whole "Windows on ARM" thing is a load of misleading marketing nonsense. That's *not* Windows on ARM, and certainly not any other primarily-Windows application on ARM (probably ever). It's a program that normally works on x86 architectures being ported to work on one other architecture and then claimed as being a "Windows on ARM". I bet it gets all the feature parity, updates, support, combined licensing that Pocket Word does (that's "Office on Windows CE", right? (sarcasm) ) or even Office on Mac (no ActiveX integration - how would they? -, no RTF emails, no ODF support, etc. etc. etc.).

*This* Office is not a Windows application. That's entirely my point. It's an ARM application. Running an ARM application on an ARM OS is no shocker. Running a *Windows* (and hence suggesting x86) application on an ARM OS *would be*.

Re:Windows on ARM (3, Insightful)

aztracker1 (702135) | more than 3 years ago | (#34775946)

If it's a compatible API then it is *windows* on ARM... is Firefox running under Debian for ARM not Firefox? or Linux? Surprise, you can't run your Linux binary blob compiled for x86 on ARM... same goes for Windows.. that doesn't make it suddenly less Windows... it does mean there will be fewer apps available out of the box. Though most cross-platform efforts for .Net based applications will probably run fine at or very near launch.

Re:Windows on ARM (1)

bkaul01 (619795) | more than 3 years ago | (#34775664)

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:Windows on ARM (1)

rkhalloran (136467) | more than 3 years ago | (#34775752)

>> 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:Windows on ARM (1)

KiloByte (825081) | more than 3 years ago | (#34775666)

Well, Open/LibreOffice works just fine on ARM today.

Re:Windows on ARM (0)

Anonymous Coward | more than 3 years ago | (#34775848)

yeah, and everytime I use Open Office on Ubuntu I feel like I've gone back in time about 6 to 10 years....

Re:Windows on ARM (1)

0123456 (636235) | more than 3 years ago | (#34775940)

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?

Re:Windows on ARM (0)

Anonymous Coward | more than 3 years ago | (#34775716)

I'm sure it'll have notepad.

Another one (1)

bluefoxlucid (723572) | more than 3 years ago | (#34775488)

When I was like 8 I looked at RISC vs CISC And I was like, "Why are we doing this? RISC looks better..." RISC processing was going to change everything, and we went with CISC. 20 years later, we're going back to a prefixed RISC processor.

Speaking of Chrome in the future tense? Why? (1)

eyenot (102141) | more than 3 years ago | (#34775560)

Shouldn't the article read, "the Chrome OS, Google's operating system that WOULD HAVE competeD with Windows"?

Because wasn't it news here not too long ago that Google's Chrome was, in the words of Google's own Chrome devs, "dead"?

So long wintel! (0)

Anonymous Coward | more than 3 years ago | (#34775720)

Hated you. wintel [wikipedia.org]

It's not about desktops! (3, Insightful)

AntEater (16627) | more than 3 years ago | (#34775726)

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 (2, Funny)

Dcnjoe60 (682885) | more than 3 years ago | (#34775790)

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.

Wow, Microsoft is Dumb! (-1, Troll)

MacGyver2210 (1053110) | more than 3 years ago | (#34775844)

So they're just abandoning any hope of increasing performance and speed in favor of portability?

I'm not about to abandon a 2+ GHz Intel chip for a ~32MHz ARM chip or something. I haven't seen anything fast and stable come out of ARM pretty much ever.

Intel is also an ARM vendor (3, Informative)

HighOrbit (631451) | more than 3 years ago | (#34775858)

I think calling this a swipe at Intel is overblown. Intel has historically sold ARM-based processors ( see the XScale at http://en.wikipedia.org/wiki/XScale [wikipedia.org] ), although they sold-off most of their ARM business to a company called Marvell. However, Intel continued to Fab for Marvell until Marvell was able to build or rent their own Fab. I don't know the current situation, but there is a good chance that Intel still has an ARM production line running under contract for Marvell. At the bottom of the wiki article it says, "Intel still holds an ARM license even after the sale of XScale." So they can move right into the business again if they see the market justification for it.

Re:Intel is also an ARM vendor (1)

0123456 (636235) | more than 3 years ago | (#34775970)

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" (2)

RockofSisyphus (760916) | more than 3 years ago | (#34775988)

Microsoft has shown/announced a lot of cool stuff that will work on the "next generation of Windows". If only half of it ever made it into a shipping version of Windows, I might actually consider Windows an option.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?