The man who makes no mistakes does not usually make anything - Edward John Phelps
|
|
|
Existing Windows applications won't run on ARM chips
THE LITTLE DUSTUP between Intel and Microsoft over the next version of Windows has attracted the attention of industry watchers.
This argument heated up after Microsoft rubbished Chipzilla's claim that existing Windows applications will not run on ARM chips and Intel said it's ready to support Linux instead to pick up the slack if that becomes necessary.
On the face of it, Intel would appear to be right. The prospect of legacy Windows applications running on ARM-based devices seems like pure fantasy, and I'm prepared to bet that it won't happen.
Not much is known about the next version of Windows, Microsoft declining to even confirm that Windows 8 is the official codename for the development project.
What is known is that Microsoft demonstrated a version of next-generation Windows running on ARM at CES earlier this year, and that the company plans to release a version of the platform for x86 PC systems and a version for ARM-based devices.
This is a world away from saying that the same applications will run on both platforms, and this is the point that Intel was trying to make during a shareholders' meeting earlier this week.
While it is possible that some applications will be available on both Windows for x86 and Windows for ARM (Microsoft has hinted there will be a native version of Office for ARM) it will most likely be down to the individual developer to produce a separate version for the two processor architectures.
Alternatively, Microsoft might be looking at a way for developers to produce a single executable capable of running across both platforms. But this would lead to new applications built for Windows 8 being incompatible with any existing version of Windows, which would be a drastic step for the company to take.
Whatever Microsoft is planning for the future, Windows applications today are compiled into native x86 instruction code, and will simply not work on ARM chips without running them through some form of emulator. This could be done, but the end result would be cumbersome and lead to an unsatisfactory experience for the user.
It isn't even certain yet whether Windows 8 on ARM will sport the same user interface as Windows 8 on the PC. Microsoft is said to be supporting the ARM architecture because it sees this as better suited to tablets and other mobile form factors, and this version of the platform could therefore have a user interface designed around touch input rather than a keyboard and mouse.
Tellingly, Microsoft accused Intel of being "factually inaccurate", but did not specify which of the many statements made by the Intel spokesperson were incorrect.
The company has declined to clarify any further details at this early stage in the development of next-generation Windows, but my money is on Intel being right, and that legacy Windows applications will not be seen on ARM devices.
Whether that will really matter in the end is a different issue, of course. µ
A version of this article first appeared on V3.co.uk.
Share this:
Share
Steve is right and I would just like to add that I have actually been making .NET binaries for years that runs on both Windows 2K/XP/Vista/7 for x86 AND Windows CE 4/5/6 for ARM.
As long as you only use functionality that is supported on both platforms you are fine.
Jeez you guys have short memories. There's a lot of history in the IT industry keeps getting forgotten.
"Applications compiled for NT Alpha do not run on NT x86"
No but applications compiled for NT x86 ran perfectly OK on NT Alpha, courtesy of a fine piece of software called FX!32. And equally if anyone did actually want NT/Alpha apps to run on NT/x86 there are a variety of NT/x86-based Alpha emulators around these days, which emulate complete Alpha systems so run NT/Alpha, or VMS, or Tru64...
Back to FX!32 though. It was a binary translator not just a runtime emulator, developed by some fine DEC employees, some of whom may well have ended up working for Intel or ARM after the Alphacide.
Emulation/virtualisation technology has moved on a great deal since then and there is little reason why almost any user-mode x86 Win32 code couldn't run just as well on ARM as it does on x86.
Two of the main things that stopped FX!32 being more succesful were lack of marketing and lack of endorsement from Microsoft. Those will not be problems for an ARM equivalent.
Once Windows is on ARM, there will be marketing for it (it's one thing MS are good at) and it is inherently endorsed by Microsoft.
It's not a good time to hold Intel shares.
"(Microsoft has hinted there will be a native version of Office for ARM)"
That would be like the native version of Office for Alpha/WindowsNT then would it?
"Some kind of Emulator" doesn't have to be awful. MacOS Leopard (for instance) featured a quite nice piece of code that ran PowerPC binaries very well and very transparently on Intel-based Macintoshes. It was very much a "It Just Works" experience.
Getting such a thing really right is non-trivial and I don't know if the ARM chips (or which of their many variations) can do do the same for WInTel binaries but it has been done well before in the MacOS PowerPC to Intel example.
I believe there was also a period where the very fastest way to run Solaris SPARC binaries was by running Solaris/SPARC on a particularly well done emulator running on a very fast Intel processor under Solaris/Intel.
@msbpodcast, you have it wrong. Binary compatibility is the major reason people stick with Windows.
It is true that source code can be recompiled, but only people with access to the source code can recompile it, and they aren't going to do it for free.
People stick with Windows so they won't have to pay for new versions of all their software.
For example, I need Windows to run the software I use to program my remote control and read data from my power meter. These programs are years old and no longer supported, but everything still works. If a new Windows won't run these programs without recompiling them, I won't be upgrading to the next Windows.
All that needs to be done is to recompile the source code onto a different machine target.
The target doesn't even have to be real, eg: Java VM, Smalltalk VM etc.
You can also make API libraries for function/procedure calling equivalencies.
That is as close to a non-issue as you can have in computing.
@Anon: Really, the Hardware Abstraction Layer abstracts the Hardware?!? Maybe we could get a definition next time that didn't include the abbreviated words in the description!!
Think of the legacy applications as being written in a different alphabet, using different grammar. You can't make a different language understandable just by saying it, it needs to be reinterpreted to be understood. Likewise, a legacy app made in one instruction set cannot simply be run on another.
The hardware abstraction layer (HAL) is for device drivers and IO. It means that when you tell a program you want to write to a file, or play audio, or draw something to the screen, you can just tell the HAL to do it and not need to mess with the specific details of how it is done. The HAL is why Windows can run on so many different hardware configurations, and still work. The HAL cannot, however, abstract away the instruction set because that would mean reinterpreting every instruction in the program into the specific instruction set of the hardware, not just device or IO calls.
That's what virtual machines are for. They emulate other hardware, reinterpreting the instructions into something the host system/hardware can understand, and vice versa.
Maybe the ARM will be fast enough to do this with reasonable speed, but I don't have many hopes for that. Intel was trying to do that with their Itaniums but that didn't go that well, and that processor line was made for heavy duty processing.
bubba here listen up. I am a software expert with experience in everything from Amiga to Z80. Windows 8 ARM edition will run all Windows binaries period end of story. Yes this includes IA-64 binaries. Ivy Bridge and Bulldozer can call it quits because they have been beat. Clever folk at ARM. Even Windows 7 itself will run unmodified on ARM.
We don't know this yet.
I can (and do) build .net applications in windows that work fine (unmodified) in linux. I suspect those same apps would work fine on arm as well, as is.
I can (and have) built .net applications in windows that don't work fine in linux, mostly because alot of .net apps still use pinvoke. They might work on windows arm, we'll have to see.
I also have windows programs that worked on xp that don't work in vista/7... etc. I have little hope any of those will work on arm.
As other people have said, microsoft could emulate, they could do a binary translation, there's lots they could do. But often those tricks don't work 100%. Programmers sometimes make simple assumptions (that are flawed) that will break between versions of windows or between architectures.
My guess is we'll be somewhere in between. Some apps will work as is, some will have native arm versions (probably anything from microsoft), and some won't work until the developer makes some minor patches and/or recompiles for arm.
For many apps, all that will be required is to rebuild them in the visual studio and make a few tweaks. So even if intel is right, there will likely be a lot of high quality and familiar windows software available for arm very quickly. Stuff that we're not even close to seeing for android/ios etc.
I am quite aware of Windows NT, in fact I referenced it in my post.
Applications compiled for NT Alpha do not run on NT x86, or vice versa.
Yes, there is a common API (actually APIs, Win32 and NT API) between the two, but that does not mean you can plop an application from one platform onto the other and expect it to run. You have to recompile (and possibly rejigger some of your code, if you've been doing Naughty Things with your pointers) for each platform.
This common Win32 API has nothing to do with the HAL, however, you could think of it as a common API for the kerel. It let Microsoft write the NT kernel once and compile it for multiple different architectures. It is the "common API" that the kernel talks to to get to the hardware. But it has nothing to do with running an Alpha binary on x86 or vice versa.
.Net of course is an entirely different animal, obviously it is cross platform once you've ported the .Net VM.
Jeremy is right. The HAL does abstract the underlying hardware.
Other CPU architectures have been supported before without the need for special software versions:
http://en.wikipedia.org/wiki/Windows_NT
Applications for Windows usually use the various libraries and APIs available. As such, this is further abstracted as MS would make the necessary changes to these.
The .Net Framework has added an extra layer of abstraction onto this enabling portability through OS versions.
Your memory is fuzzy indeed. That is not what the HAL does. The HAL hides certain architecture-dependent features from the kernel itself. When I say "architecture" I don't mean "processor architecture" as in x86 versus Alpha, but rather more like an IBM-compatible PC versus an SGI workstation. Both might use an x86 processor, but might have radically different memory controllers, buses, etc. The HAL abstracts that out of the kernel.
x86 apps ran on NT x86, and Alpha apps ran on NT Alpha. You can write an emulator (like, for example, Rosetta when Apple switched to x86) but that is not the same thing as a HAL.
My memory is fuzzy, wasn't NT based code supposed to have a hardware level that had Windows interfacing the hardware and software interfacing Windows?
That way you wrote an application and Windows ran it regardless of the underlying system. NT 4.0 ran on either x86 or Alpha.
At least that is what I though going back the 13 years or so since I last set up an NT 4.0 box.
Its no big deal I run a Hackintosh and Linux on a virtual PC from within windows and I can run various arcade consoles from within windows using an emulator. I can also run windows 16 and 32 bit applications on my 64bit os through Wow totally transparent to me the end user. Finally I can run Windows Phone 7 applications through a development emulator on my machine. Its not native and there is a performance hit but it works very well.
Intel should just shut up or Microsoft should just optimize code around AMD cpu's and for the love of god drop all support for Itanium.
Doesn't Intel make ARM chips? If windows runs on Intel's X86 chips and Intel's ARM chips, then what's the big problem between the two companies?
And as far as legacy applications working, if they don't, no one is going to buy a new PC AND have to replace all of their applications as well. Not in this economy. The so called "recovery from the recession" hasn't really happened yet, with high gas prices and unemployment. I sure as heck am not going to replace all of my apps just to buy some new PC. The PC I have right now is just fine with me.
Create an installer, that will install either the Arm or x86 version of the code, I means that why we have DVD's right? for all that space!
At something called .NET. Microsoft have been pushing it as their primary development environment since 2002. It creates intermediate code and compiles that to the actual target platform on the fly. Most if not all .NET code will work quite happily on both ARM and X86 platforms.
There's also a idea called a fat binary that Apple pushed durring their migration from PPC to X86. Developers that want a native binary can create one app that runs on two or more processor architectures. The run-time linker loads the correct portions from a single EXE file,
There's a third idea that involves on-the-fly recompiling of binary code to another platform. The results tend not to be quite as fast as native code, but quite quick enough for a lot of legacy code.
Any one of these three solve the binary compatabiliy issue. Intel must be quaking in their boots at the idea of competing in a marketplace where the competition is selling their kit, complete with customised onboard IO controllers, for circa $25