Despite prior hints – and a Redmond developer conference that was all about app compatibility – Microsoft’s Steven Sinofsky has said that software for x86 Windows 8 systems will not run on ARM architecture. For months, Redmond has promised that any code that ran on Windows 7 would run on Windows 8, with the expectation for many …
smoke and mirrors
smoke and mirrors, the truth leaks out but the microsofties continue to fantasise of the tablet that runs everything from desktop apps to metro pull-my-finger's... all hail the masters of smoke and mirrors, pull up a chair and pass the grey clothing and face masks, its time to film the 1984 remake
"will mean significant developer time has to be spent porting applications for system on a chip (SOC) devices"
Or more like 30 seconds adding the build configuration for ARM devices in Visual Studio, as well as the usual x86 and 64 bit build configurations.
Tablet != desktop
Oh, of course... You mean that there's no difference between a tablet-centric app and a desktop application for use with a mouse, keyboard, large screen and unlimited CPU power.
Not to mention fat fingers and handheld UI optimisation.
Do you really hate your customers - or 'users' as you would refer to them?
You are both correct, apps written in .net should just need a compile switch and / or minor modification.
But many larger apps aren't suited to a tablet anyway.
That makes no sense.
If you develop a Metro app you can compile it for both x86 (or more likely x64) and ARM platforms.
It will work fine on both. The interface is another matter entirely. There are tablets with ULV Intel SOCs and ARM SOCs. Why would the interface differ?
You assume any application written for x86 will be legacy desktop application. This is not necessary or even likely in the future.
As for legacy apps, porting some of the to ARM makes sense for people who will use tablets that dock with Keyboards and Mice. The iPad does this already (has a docking keyboard and you can use a blutooth mouse if you jailbreak - not the recommended option but its perfectly functional).
I use an iPad and a laptop at work and desperately need to dump the laptop and just plug my ipad into a dock. If windows 8 does that we'll be migrating all our users over time.
"Do you really hate your customers - or 'users' as you would refer to them?"
Careful analysis of both the hardware and software industried suggests that the appropriate emotion felt by manufacturers and vendors towards customers and users should be either hatred or contempt, or a combination of the two.
There's probably an ISO standard that people comply to, considering the attitude is all but ubiquitous.
Two disparate operating systems
Windows 8 - two operating systems that share the same name. Sure, there'll be some code sharing, but the kernels will be quite different to support the fundamentally different requirements of a tablet (diet Windows) and the full-fat bloat of the desktop.
Win f**ked up if you ask me.
** = or/uc your choice.
x86 tablet is basically configured the same way as an ARM tablet. Most code in NT is C/C++ and so that is just a cross-compie (hardly disparate operating systems). Outside of some Neon code for ARM vs. SSE for x86 (in codecs or rasterizers, for example) most code is the same.
Also, unlike freetards, Microsoft actually understands binary interfaces and binary components, so the same x86 kernel binary can run on different HALs and interoperate with quite different hardware. (Although their userland dependencies are a complete intertwined mess).
There are only 2 ways that an x86 legacy application can run on an ARM:
1. Hardware emulation - this effectively means designing a System-On-a-Chip with an Arm core that does the same things that an x86 does (but slower, until it's had the 35 years of development that the x86 has).
I doubt very much that Windows on ARM will amount to anything.
Software emulation of x86 on ARM has been around since 1987, I still use an old version of SoftPC from time to time to check interoperability issues.
And, how does it do with SIMD and other extensions? How does its performance compare to a Core i3, let alone a Core i7?
Being able to get the software running is one thing, getting it to run at a usable speed is something totally different.
Getting heavy weight LoB apps running on a tablet will probably be a pretty miserable user experience. Re-writing and optimising for touch, while you are at it, will be a much better solution, especially for the users.
I'm pretty sure, we'll se that the other way around as well. Apps running on tablets won't all be ideal for using on a corporate desktop machine either.
There are more solutions which are better
For new applications which make use of native code instead of html, js, .net, etc... it will be possible to use app packaging (AppX), possibly similar to Mac bundles to distribute binaries that are compiled for multiple platforms. But this is not an issue for existing applications which is the reason for the original posting in the first place.
Software emulation that you mention isn't as silly as you'd make it out to be. Unlike the Mac Rosetta Stone project which effectively added an entire PPC subsystem to the operating system with optimized thunks in places where performance mattered full system emulation will be needed to make this work. Of course, you could use Wine and optimize the thunks as well, the problem is at that point that Wine isn't really that good.
Full system emulation will be necessary. By using something like QEmu as the core which has an really nice an speedy x86/x64 emulator or suffering the horrible performance of Bochs, it'll be easy enough to launch a full PC implementation. Most often, full system emulation is used for things like DolphinEmu which lets Wii and GameCube games function on PC. Those systems are a nightmare because long string instructions can't be optimized or even vectorized because data most likely is stored in files (that might be memory mapped) as big endian data which then needs to be converted to little endian on a PC for each individual load and store instruction. There are no nifty SSE instructions for byte swapping that can be used effectively for this. ARM however typically runs in little endian mode and that's the #1 reason why performance of ARM emulators on PCs are so good.
Endian swapping performance is generally the biggest problem with implementing full system emulators. ARM on the other hand is a close enough match to the x86 processor that long instruction chains can be optimized and even auto vectorized for NEON by a proper dynamic recompiler. It might even be possible that when executing new code chains for the first time, the compiled code and be instrumented for metric measurements and longer chains of code could be traced. This type of tech could make it so that in many cases, the code natively written for x86 might even run faster in some cases on ARM than on the native x86 core (clock per clock). Of course, then using the same dynamic recompiler on x86 to compile x86 to x86 might be faster. This is why modern development tools often offer an option called profile guided optimization.
I wouldn't suggest trying to run things like x86 builds of Handbrake (which makes use of x264, possibly the most optimized x86 code currently in wide use) through a full system emulator. The performance decrease would most likely justify the wait for a new build native to ARM. Though given the insane dependence of x264 and ffmpeg on GNUish compilers, it could be a relatively long wait before there's a decent ARM compatible GCC for Windows and corresponding mingw tools.
Now, one the system is emulated, using x86 applications from the desktop for a normal user would be no different than how you use XP virtual machine apps via Virtual PC for Windows 7. The virtual machine is started in the background, running an x86 build of Windows 7 or Windows 8 for example, then using RemoteApp, the ARM Windows desktop becomes the destination for the application. Then icons on the desktop can be created which would start the x86 apps by sending a message to the virtual machine (starting it first if need be) similar to how you can use SEXEC with X Windows tunneling on Linux to execute an application on another system by view it locally.
None of this technology is particularly difficult and for the most part, the concept would be to permit general user apps to run, not high performance ones. It should be good enough for most everything. And with a bit extra work, it might even be possible that code that is accelerated through GPU computing via Cude, OpenCL, or even just fragment shaders can run just fine as well. The x86 app's hooks for sharing buffers would just need to adjust memory locations to compensate for the second emulated MMU. An even bigger performance increase could be to merge the MMU code between the two systems as the ARM MMU and x86 MMUs are similar enough the Windows virtual memory subsystem calls for allocation can be pushed directly from one system to the other.
This is just one possibility, I could probably do all this one my one as it's a pretty easy thing to do. But I'll wait a few more weeks until someone else does it.
The biggest reason this came up more than likely is that x86, even in software form generally requires an x86 license from Intel to collect money for. Microsoft should have no problem getting one, but I doubt they value it that much. I'm not 100% sure, but I believe the x86 emulator on Alpha was made by DEC and the x86 emulator on Itanium was made by Intel. Microsoft might not even have an x86 license, otherwise, they could theoretically have just bought transmeta way back when.
That's what Apple did with their applications when creating a 'universal' binary.
@ 3 ways...
Well, if recompilation from unmodified source code is all it takes, then you're right. But if any rewriting is necessary, then it's no longer "legacy code", innit?
Can someone explain
How what Intel said was at all “inaccurate and unfortunately misleading,”? Unless I've missed something, it sounds like it was totally correct?
It's misleading from MS's POV because it indicates that windows software will never run on ARM. Whereas MS have said that Windows 7 apps will run on Windows 8 And that windows 8 will run on ARM (excepting where the aforementioned windows 7 apps are running on windows 8 under ARM). The word "never" is the only misleading word I can see.
I think I would round the statement to:
If you think all your current Win7 software will work on an ARM tablet, don't hold your breath.
They never said x86 code would run on ARM, they just said that existing Windows 7 apps will run under Windows 8.
Given the architecture differences, it is blindlingly obvious (and no surprise), that x86 code won't run on a weaker, slower, less capable processor. It will run on Windows 8 desktops, laptops and tablets with Intel innards.
.Net stuff probably has a good chance of being easily converted to ARM.
Microsoft have hinted at this all along. I really don't see where the surprise is coming from at this announcement.
".Net stuff probably has a good chance of being easily converted to ARM."
Indeed, but the installation-time translation of CLR byte-codes to ARM instructions is no easier than the installation-time translation of x86->ARM would be.
So, it's just as easy to translate a crazily un-orthogonal PoS instruction set to ARM as it is to translate a completely stack based set of byte-codes? I don't really buy it. In fact it's quite possible that some blocks of x86 code (e.g. a context switch?) are completely un-translatable at all from x86 without a human getting involved. Let alone working out an efficient way to translate SSE to Neon (for example).
Re: So it's just as easy...
Er, yeah. Firstly, x86 hasn't been un-orthogonal since the 386. The instruction set with its modr/m and SIB bytes is different but no less regular than the ARM with its 16 classes of instruction and thumb stuff.
Secondly, you write a grammar for the user-space part of the x86 instruction set and use a parser generator to spit out functionally equivalent ARM instructions, given some pre-defined mapping of the x86 registers onto a memory structure. The resulting code inevitably contains lots of redundant loads and stores but is semantically correct. Then you let an ARM peep-hole optimiser replace some of those memory references with register usage.
It's nothing like as hard as virtualising the kernel-mode stuff and all the machine state.
And here is the other shoe
Anybody remember Google making noises about optimising for Intel silicon a few days ago? And now Microsoft are making noises about how it wil be harder than expected to move stuff to non-Intel silicon.
I'm probably too cynical, but this looks like the start of yet another Intel anti-competitive squeeze.
Intel doesn't need help to not be competitive. In fact since Grove retired Intel has missed two big sea changes at first (x86-64 and now arm phone/tablets).
Thank god I can't choose an icon. I deserve everything the Reg gives me.
This has to be the most confusing product pre-anouncement ever. I fear for developers, or anyone else's sanity. Windows 8 is both windows and metro - so you have two GUIs to cater for, but it's more. It has ARM bits and x86 bits. ARM bits are metro like but might not be x86 like. x86 bits might be Windows 7 like but then not work with ARM. x86 bits that are metro like might or might not also be ARM like. For a developer, where's the beef? Go for x86, which is becoming a limited niche in terms of numbers of units, or go for ARM - in which case why bother with all these complexities from an OS supplier which is no-where on ARM based devices and where they're really trying to say develop for ARM and get x86 as a bonus. But not the reverse.
Except for the corporate desktop - which Microsoft itself owns since it 'absorbs' other developers useful products - it increasingly looks like ARM plus a non-Microsoft OS is where the money is. Why develop in a market where, if you're good, Microsoft itself will compete against you? And if you're off the corporate desktop then the ARM world is where it's at. And what has Microsoft to offer you here that isn't being delivered better by someone else? A horrendously confusing story from Microsoft. Why would you buy Microsoft in these circumstances?
missing the point somewhat
for new metro-style C++ apps, it seems like compiling for ARM will be as easy as clicking a checkbox (though I'll believe that when I see it, and of course deliberately writing things that are limited to one processor is trivial)
so if you're still at the "choosing what to develop for" stage, you should be able to target both
"A horrendously confusing story from Microsoft. Why would you buy Microsoft in these circumstances?"
Simple, MS has jumped the shark.
<icon: Arthur Fonzarelli wearing a Guy Fawkes mask>
That's: Arthur Fonzarelli OBE wearing a Guy Fawkes mask.
"Why would you buy Microsoft in these circumstances?"
Why? The exact same reason you've been buying Microsoft for the past 20 years. Because no-one's ever been fired for buying Microsoft.
"Faced with running most Microsoft code or settling for what gets ported to ARM, it’s clear which most buyers, and developers, will choose."
Sorry, but no.
Office will be ported to ARM, for sure. A W8 ARM tablet will not run 'legacy' Windows apps, but will a tablet buyer care? I don't think so. Whether W8 ARM tablets will sell in large quantities is unknown, but it certainly won't be the lack of support for older Windows apps that determines this. Lack of support for OSX apps did the iPad no harm.
Developers will follow the market. If they think there's money in porting x86 apps to ARM, or writing new Metro UI apps, then they will do so.
I think you've picked a nice metric to see if Microsoft has fixed its internal warfare. In order to port Office to ARM, they'll have to port the UI to Metro (if I've managed to make sense of their roadmap).
The Office group refused to port to the old Windows tablet PCs, after all.
"Office will be ported to ARM, for sure."
Or more likely, some cut down heavily touchified version thereof. Remember.. we are talking tablets. Not powerful PCs with huge hard drives and 4 gig or more memory. And no.. I have no idea how much space Office needs to run. But I'm betting it will be way more than a tablet can manage without serious rewrites.
Office readers, with limited editing capabilities.. Sure. Office the fully functional feature compelte package.. Nah..
A tablet 4-5 years from now, perhaps... if they still exist. But one from the next two years.. No.
Just how many failed implementations of desktop Windows on a hand-held device do you need before the fact sinks in that they are two different use scenarios, so need two different UI concepts. That will take a wee bit more than a recompile.
Which means numbers are needed to get the big developers on board. Big numbers.
"A W8 ARM tablet will not run 'legacy' Windows apps, but will a tablet buyer care? I don't think so."
Really.. Ask 5 non tech people what they expect a windows tablet to do.. If the top five answers do not contain "run windows applications" I'd be astounded.
Apple broke away from OSX, and made iOS. They make an iPad, and an iPhone, which is different from a Mac. and at no time is it portrayed as the same OS, the same hardware, or even as a computer. Nobody really expects it to work like a Mac.
Android is a new and expectation free OS. There is no desktop version in common use, no multiple hardware platform implementations. So no expectation that anything but Android software will run on it. And as it's basically Java, not a big cross platform problem anyway.
But Windows is used by people who think every comptuer comes with Windows.
All software is made for Windows.
All Windows computers can run Windows software.
And as a Windows tablet is a Windows computer, it surely must run Windows software.
When they find out it is not true.. Oh dear.. Especially after the sales zombie in Dixons talked them into a six month paid virus scanner.. ON CD..
Windows tablets might very well have a place in business. Built in full MS connectivity is a real selling point. But for the generally computer illiterate home user. Android or iOS are perhaps more natural choices. And pretty much any name brand software outside MS stuff. Forget it for the first six months.
I've known all along what this was, but dared not say it before it came to fruition, lest I scared them off it. Now they've taken their leap of faith and I can point and laugh - but first to the prior AC...
AC Friday 16th September 2011 00:07 GMT
Intel doesn't make operating systems. There's nothing anticompetitive about optimizing their processors for Google code, any more than there's been anything anticompetitive about optimizing for Microsoft code this last quarter century. Track layers must cooperate with train makers or the freight won't roll.
One might complain if their documentation weren't so appallingly complete, verbose and correct. But I doubt if they made it secret any could call it illegal: we don't have the magic interfaces for WinModems yet, do we?
And on to the subject to hand.
Windows 8 is more properly named after 7&7, the preferred anesthetic of the discotheque barfly to dull the pain of knowing she's going home with whoever's buying. Obviously whoever came up with this idea had had a few.
The OS is Windows 7 desktop (7), with(&) the Windows Phone 7 "Metro" interface (7) - and a couple minor tweaks just for garnish. At least on Intel Architectures it is. So you get the popular desktop OS, with the usability features that have made Windows Phone 7 a runaway hit (yes, that's sarcasm.) Because Microsoft knows that what we crave is their 0.6% market share phone OS on everything. We just don't know it yet because we haven't tried it. They'll alleviate that by making us try it on every desktop and laptop shipped in the world. They're sure this will only increase uptake of their desktop OS as well as secure their passage to the Mobile promised land. Oh my.
On ARM it's just Windows Phone 7, with a few minor tweaks. Microsoft get to claim that the Intel Architecture tablets can run both legacy applications from your desktop and Windows Phone - and they can. They know people will take this (and retail advertisers will milk the ambiguity even more than they) to mean that the much less expensive long battery life W8 ARM tablets also will, when they won't - because they have the SAME NAME. Which leads to confustion, disappointment and mistrust. A perfect way to preserve brand value!
And the Samsung tablet they gave away at BUILD? The best of both worlds (sarcasm again - one mustn't be too subtle on the Internet): A tablet with a full Windows Desktop just like the ones that have been selling by the dozens for years - but with the WP7 "Metro" interface. Because it was the lack of a Windows Phone interface that's kept full Windows tablets from taking off like the iPad did.
In summary, the company has gone schizophrenic, manic and suicidal all on the same day. Looking back it seems like they've been getting sketchier by the year, but when Ballmer only got half his bonus from the Board they just completely lost it. This isn't an Android killer or an iPad killer. It's a Windows killer.
It's going to be a great two years, starting now.
"compiling ... will be as easy as "
And that's where the work stops, innit, when the app ships whether it's ready or not.
Nobody has to test these things on a few families of radically different platforms, because by now PC users have mostly got used to software that might or might not work. Nobody has to provide a support team with copies of the software and the relevant hardware and some training, because PC users have mostly got used to worthless script-reading support teams in the IT department and beyond.
Good job it's Friday.
Would existing .NET apps run on ARM?
I personally can't stand Windows and am normally the first person to bash Microsoft, but this is a complete non-issue as they've never said that there was going to be x86 emulation included in Windows 8 for ARM. A few dumb anal-ysts and journos might have jumped to that conclusion, but I think that most people would have been astonished if Windows 7 x86 apps ran on ARM based Windows 8 systems. With software x86 emulation they'd be dog slow.
voice of reason
Analysts are often too fast to jump to conclusions, but developers should know better.
As for software for ARM Windows 8 tablets - nobody promised x86 emulation, so it will NOT happen (not from Microsoft anyway). It's too expensive on so many layers. Especially since its not needed - pure .NET is bytecode so does not even need recompilation, while C or C++ programs can be simply recompiled for new processor. One obvious requirement is going to be that non-portable library/runtime bits can't be used. Of course, "legacy" software would have to be rewritten to replace "legacy" calls with new runtime - this is going to be expensive and thus (probably) rare.
There is also question of pricing in "app store" - tablet users aren't used to range of prices that desktop users would normally pay. It might be difficult to sell anything on tablet above certain price limit (like $20), but Windows software shops only rarely sell software below this level. Meaning the app store might not lift as swiftly as expected, and/or there will be many new names but few established vendors.
As for general direction - I think Microsoft is taking bold steps, introducing yet another runtime (i.e. Metro and WinRT). Hope some of it will work well with existing APIs , libraries, runtimes, compilers etc., anyway I wish them luck. It is high time to replace Win32 with something better, without it Windows platform would die out in 10 years.
Seems so tragically behind the times.
We're still stuck with behind-the-times XP at work. Once we get Vista (scheduled for early next year), I might stop hating.
Once we get Vista (...), I might stop hating
Uh, I've got bad news...
There have been x86 emulators for ARM since the PC-emulator for the Acorn Archimedes, which came out around 1988 (+/- 1 year). On an 8MHz ARM2, the emulator could run DOS applications at around the same speed as a 4MHz 8086 PC -- some thing slower, some things faster.
I expect more or less the same to be true today -- on an X MHz ARM you can emulate an X/2 MHz x86 (32-bit) processor. A combination of running OS calls natively and JIT-compiling x86 code will allow this.
If MS won't make such an emulator, I'm sure third parties will.
Building an x86 emulator does not just require running the application, it would also require running all the API implementation that is used. In particular the GUI layers and probably a complete Windows 7 installation.
DOS was easy to implement because it was fairly well documented and was mainly only a disk handler. An ARM W8 is likely to just be CLR and Metro. Everything below that need not be Win32API.
You may well start with ReactOS and/or WINE and run that in emulation and hope that the application will work on top of that.
Hmm, *I* was assuming that the ARM Win8 would *have* all the Win32 API implementation. That is, I assume that is *is* just a port of the bloated backward-compatible nightmare we know and love. After all, .NET on desktop Windows is a layer above Win32, not alongside it. An ab initio implementation of the CLR (and supporting APIs) on new foundations would be a major development, and a major risk for MS. (The last time they tried that was the Longhorn re-write that got ditched, making Vista two years late *and* a rushed job as a result.)
...people what it to run both Arm and x86 at the sametime, but in the same breath will complain that Windows is a resource hog and bloated.
We'll you can't have a Single OS that does both, without the bloat.
Only an adiot would have ever thought an x86 COMPILED BINARY would run on ARM. Adding ARM support si similar to adding x64 support... vendors have to start releasing an ARM version.
While it may be true that a program could be recompiled for ARM it is likely that ARM W8 (Wait? Weight? Windows 8 my homework?) does not have the Win32API nor the WinXP/7 GUI API. It will be CLR .NET and Metro only.
An odd comparison, since all my x86 compiled binaries run fine on the x64 build of the OS and I've no intention of releasing an x64 version because MS made such a pigs ear of the 64-bit API.
Even odder, I actually *have* Windows apps that build for both x86 and ARM, at the flick of a compiler switch.
Windows 8 ARM = WebOS part 2
I had wondered from the outset how they were going to get programs written for X86 to work under ARM and now its clear they cant/wont. I predict Windows 8 ARM to become another WebOS, all hyped up for months then lasts for a few weeks because people realise that it has no apps for it and it can't run there legacy apps, so its an expensive door stop that can run office (which isn't really suited to touch screens anyway) so go back to buying iPads. Coming so late to the market too im not wondering if it can even catch RIMs share never mind Android or Apples now.
- Vid Hubble 'scope snaps 200,000-ton chunky crumble conundrum
- Updated + vids WHOA: Get a load of Asteroid DX110 JUST MISSING planet EARTH
- 10 years of Facebook Inside Facebook's engineering labs: Hardware heaven, HP hell – PICTURES
- Very fabric of space-time RIPPED apart in latest Hubble pic
- Massive new AIRSHIP to enter commercial service at British dirigible base