Intel: Windows on ARM won't run 'legacy apps' Update: Microsoft has taken issue with Intel's comments on the next version of Windows. An update to this story can be found here. Microsoft may be porting Windows 8 to the ARM architecture, but the general manager of Intel's software and services group insists she's not losing any sleep over a bruising battle in a more- …
Actually I'd have thought that most things should run on Win 8 for ARM after being recompiled for the platform, but then they would be native not legacy.
The problem here is twofold. First that shonky piece of crud you've had for years, you don't have the source for, is important to your business and which would cost you an arm (hah!) and a leg to have rewritten and second, not wishing to go through the whole recompile, sort out issues, regression test, recertify and deploy cycle for everything you have that's not shrink-wrapped and available in a new version off-the-shelf.
If Windows on ARM implements Win32 then it will be a fairly simple job to recompile for the new platform (just as it was for Windows on Alpha). However, the article says "On ARM, there'll be the new experience, which is very specifically around the mobile experience, specifically around tablet and some limited clamshell, with no legacy OS", strongly implying that Windows on ARM won't have Win32. Whether this is true or Intel FUD remains to be seen.
@Captain Scarlet: Unless An emulator is developed to emulate X86 and x64 on the ARM version, might run a bit slow though but for legacy apps that are traditionally very old the processor speeds from ARM when Windows 8 arrives might be powerful enough.
What Intel means by "Not now, not ever" is "If you even try to field an X86 emulator on ARM we're going to sue you back to the stone age."
Similarity to Windows x86. Maybe this will be enough to get mainstream end-user purcharsers.
As much as I hate to say this, I hope windows 8 on the ARM takes off, mainly because if it does = more ARM devices for us to mess around with.
I am curious though, if .NET exe's are not portable between both ARM and x86. It would seem a bit foolish of microsoft if this were not possible or maybe just something they and intel have some secret dealings about.
I myself hope that windows 8 retains its C API's (ie win32) for those of us who kind of like that thing and don't like .NET etc.
Imagine a tablet that has a touch friendly tablet UI when you're walking around with it, but plug it into a dock and suddenly you have a full desktop on it. Even if that desktop just has MS Office, Outlook, IE it's still useful.
I do think MS are making a terrible mistake not including emulation of any kind. I just hope they make it easier for devs to target non x86 devices than they have in the past so that at least some popular apps make it across.
"Our competitors will not be running legacy applications."
That sounds more like a compelling reason to switch to ARM than stay with Intel. Seriously, damn the bad luck, I won't be running shitty, broken and obsolete software that insists it should have administrator privileges so it can totally screw up the system. No half arse coded software that some genius decided should run on every windows version since 95. I welcome the chance to install a newly released software package that doesn't require me to use "XP mode". Really, WTF is up with that?
All legacy apps are shitty, broken and obsolete. Cool. What a relief to know that engineers these days only write apps that aren't shitty, work properly and will never be superceded.
It's not like Microsoft have built a highly profitable business out of making sure that new windows runs old window's apps. Except they have.
And not all old software is shit.
I'm sorry, I didn't mean to imply that old software was shit. Generally it is of higher quality than the new stuff on the shelf. That said, the new stuff is mostly shit because some bean counter decided it would be better to have one version of software work equally bad on every version of windows known to man. For old software that runs well and is reasonably optimized, I have no problem using an emulator such as "XP mode" but for new software which has been tacked together to support legacy operating systems back to 1993 and is mostly broken because it relies on XPs quasi-compatibility with Win95... yeah, I've got issues.
In the long run, I guess I misspoke, it isn't legacy software I have an issue with, because that's what emulators are for, it's the marketing B.S. on a 2011 software release that says on the box that it runs on Win7 but what it really means is that it runs only on Win7 in the aforementioned "XP mode". So... I stand corrected, legacy is Ok (when running on the proper legacy/emulated environment) and misleading marketing bull shit for the sake of half arsed backward compatibility isn't.
It says something about software (or people) when data files are less backward compatible than the application that makes them. Perhaps it's time to change the paradigm of upgrading apps four or six times as often as the OS. I know, we bitch at Jobs for trying to do this and bitch at Balmer just as often for not trying to do this. Oh well, I'm looking forward to being held in loving ARMs.
Which means you'll still have that same 50:50 chance it will insist it needs to run in privileged mode. As for the rest of it (half-arsed code, backward compatibility) I'd say you still get to spin the programmer roulette wheel. Just because the OS people aren't making it backward compatible doesn't mean the Apps people won't try to bolt it on afterward.
>>> When Apple moved to x86, all its old users had to stick with their legacy apps and architecture, right?
Newer apps are fat-binaries and include the legacy PPC code, something which ARM isn't going to be able to do. Seems to me to be pretty fucking obvious that Windows on ARM was never going to run Intel code...
It's not beyond the realms of possibility to run x86 code in an emulator / interpreter on an ARM system. Sure, performance would be seriously lower than natively, but for some classes of apps that may just be a matter of 10ms per user-interaction rather than 1ms. Provided Windows was done right, all system calls would be in native mode, and it ought to be possible to call some shared-library code in native mode as well.
Wouldn't .Net make it easier to port code across? I can't see why you couldn't create an 'ARM.NET' set of libraries, an ARM CLR, etc- and once you've done that your .NET application could be ported with little or no problem. I mean it's almost there with the .NET Compact Framework, so just ramp that up a bit to cover the WHOLE framework.
I assume MS Office is/will be a .NET application now or in the near future, so the world's dominant Office suite would still be useable- so a good number of business users would be able to take advantage of the new low-power, quiet, mobile computers without losing any functionality or having to learn new software.
In fact, none of the user-facing stuff need change except to cope with lower processor power. Multitouch is supported through WPF, cameras and voice are supported through every Windows this century so tablet/phone functionality can be retained.
Done properly, you could transition a good number of users to ARM-based Windows without missing a beat.
Anything not .Net, right?
.Net is hardware independent so that programs can run on windows of any flavour. Good strategy I suppose.
I gues sit all depends just how legacy we're talking too - I don't think it'll be long before someone ports DosBox to Win 8 on ARM, then you can run your real legacy apps!
It's quite possible that MS will manage to arrange things so that recompilation of source code will probably produce a working ARM version of an existing x86 application. It's different to Mac's migration from PPC to x86 - there was an endianness change.
But with x86 to ARM there isn't, and that makes a pretty big difference to the porting task. All MS really need to do is to ensure that C structures (or the equivalent for your chosen language) are packed in memory in the same way and that's quite simple to achieve. Sure, there'll be testing to be done, but I'd put a whole £0.05 on that testing being confirmatory rather than fault finding, provided MS get it right.
MS have already shown some good evidence for it really being that simple. They showed Office 10 printing to an Epson printer. I don't know about Office 10 (.NET?), but the printer driver was simply recompiled and just worked. If a recompiled driver just worked OK, there's good chances for applications too.
And of course, .NET, Java, Javascript, Python (and so on) apps would just run anyway.
There will be an emphasis on software providers actually bothering to recompile their applications. But if it really is that easy then open public beta testing will probably be an attractive way of keeping porting costs down.
a) It's not just a case of recompiling. You still need to thoroughly test the device, support it and so forth.
b) Most enterprises are still bogged down with crappy applications that only run on IE6/7 or similar. Their heads would explode trying to contemplate a move to ARM.
I'd argue that in the first instance Windows on ARM needs emulation even if its just crappy slow emulation, and secondly MS should stop their tools from targetting x86 at all by default. Do what LLVM does and target an abstract processor and convert to native instructions at runtime. The latter means devs only have to build, sell and test one app regardless of where Windows is running.
"applications and operating systems can run from one generation of Intel platform to the next generation"
Yeah, but they are talking about a new version of Windows. Loads of our legacy apps didn't run on Vista, nor on Win7 (Some not even in XP compatibility mode).
So saying that Win8 on ARM might not support old apps doesn't matter. Win8 on Intel might not either.
the difference was that it was Microsoft forcing those incompatibilities and not the hardware. Intel is trying to spread FUD about ARM because that's all they have to use to compete since x86 won't be as efficient as ARM and they know they can't keep shrinking the die to just get close.
And Windows 8 can not be incompatible with Windows 7 or Vista apps. Microsoft does not have that luxury any more. As for Windows 8 for ARM, that is not going to look like desktop Windows, it can't. I even have my doubts they can get it running well enough on the ARM platforms of the time and have it run well without gutting much of what people come to believe and know as Windows. I doubt many desktop .Net apps will run well on the ARM version and MS Office is so full of binary junk it's going to take years, if ever, to figure out how to port that. Just look at how OOXML was spec'ed for a clue as to how much binary junk is unknown to them.
And seriously, is it not obvious that Windows 8 for ARM will not run current or legacy x86 Windows applications? Really, this is news?
Who would have thought a change in CPU architecture would do that. But, mainly who cares, if MS Office, and desktop products are also ported, then it's only a matter of file formats.
I doubt ARM will be going for servers from day one, Microsoft didn't, and look where they are.
The real test will be the uptake of Windows ARM by other premium software vendors in business, but the success of iPads and Androids seems to indicate that might not be an issue.
Good luck to ARM.
It looks to me like it's more drastic than that.
It looks like they're actually forking the desktop version of Windows off, just keeping the NT kernel, breaking compatibility with everything, and betting the farm on tablets with the UI. Then, on x86 platforms, sticking Virtual PC and a copy of Win7 in there for software that doesn't run on the new UI.
So, this migration is more like Mac OS 9 to Mac OS X, than, say, Mac OS X 10.4 PPC to Mac OS X 10.4 x86 - a complete reboot of the platform, rather than just adding a new architecture.
"They are neither forward- nor backward-compatible between their own architecture – <snip> – nor are they compatible across different vendors. Each one is a unique stack,"
Not sure what cloud she is sitting on. Code from my 10 year old ARM7 dev platform runs perfectly happily on my Cortex-9 Android phone - ARM code is forward compatible, although not always backwards compatible. Hell, you can't use the latest x86 binaries on an older cores if you any of the new instructions like SSE3, so this isn't exactly something Intel can do either ...
I terms of things being different stacks, that's like claiming all desktop PCs are different because you need different device drivers for peripherals. I assume Intel have heard of "device drivers" so this is just their PR machine kicking up FUD.
It's a combination of the truth and FUD.
Every modern x86 system, things are in consistent places, because they're all following the standard set by the IBM PC AT. ARM systems, they have no such rules.
However, Windows NT has a way to handle this, the HAL.
IIRC, Windows NT only has one HAL for an x86 PC (and another for an x86-64 PC). That's enough to get far enough along that everything else is a driver.
However, for a DEC Alpha system, it has one HAL for every motherboard. The installer will start in ARC/AlphaBIOS, where the firmware does hardware abstraction, then it'll try to autodetect your motherboard, or it'll ask for a floppy with your HAL if it can't. (This was back when NT4 asked for a floppy for everything.)
There's no reason that Microsoft can't do something similar for ARM - every chipset gets a unique HAL.
First off, if they want Win8 to run on a lot of existing Atom devices, they need to support 32-bit, because Intel disabled 64-bit support on the first-gen mobile Atoms.
Second, there's no 64-bit ARM architecture, just the 32/26-bit original one, the 32-bit current one, and the 32/40-bit one that's coming out.
Why did Intel disable 64-bit support in Atoms?
I am bored of running 32-bit VMs to run all my software, and wishing transition to 64-bit would hurry up.
Guess there's not going to be a 64-bit ARM version, but at least they'll be the usual plethora of SKUs ... read over on Engadget that there are eight for Win8-ARM alone.
Ignoring the nightmare that is the windows API, if MS do port it to ARM, then all .NET apps should build and run on it. And that means Azure, which means the power budget of a datacentre drops massively. leaving spare money for MS, rather than Intel.
Today the big datacentres run CentOS or some other $0 variant of Linux, stick in one 4-6 core CPU per server, then decide whether to spend the money on a second CPU (10% extra costs), or buy 10% extra storage instead. Low cost, low power CPUs change the economics.
"James also reminded her audience that Intel and Microsoft are closely intertwined. "We've been working with Microsoft on Windows for probably 20 years, this year. We've been their partner for a long time"
Hmmm so it's quite surprising that MS are producing Win8ARM then...
The only way Intel will make this stick is if they continue to enjoy the connivance of MS. That's not something to bet the farm on, I would have thought. Still, they survived the whole NT on Alpha/PPC/... thing but I don't know the background to why they did.
"everybody writes about it, everybody talks about it," she said."
but not usually in a good way.
is not where ARM (and Windows on ARM) is right now or will be after the Windows 8 launch, but where it is going to be in a few years time.
If Microsoft make some/all of their server products available for ARM then you might see something interesting happening with system builders making low powered "appliances" - for example based on Forefront like some already do with x86 based "appliances". Or Windows Storage Server based NAS boxes.
Computing is an ever-changing field and I think we could be on the cusp of a very big change. I don't know where it's going to end but as someone who needs to keep their job and therefore their skills relevant, I'm keeping an open mind about all things.
Even though Intel's business isn't exactly under the same risks and pressures as my little bit of a career, I'd suggest they're also worried about remaining relevant as things change.
So, as everyone is thinking... why in hell should I use windows 8 then? People want to run applications, not OS or HW. Those are just the means for running APPs.
If they can't run theis old ecosystem, and have to move to a new one, why Microsoft? MS should remember that companies use Windows BEACUSE they want to run legacy Apps.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
