Microsoft: No Windows 8 ARM support for x86 apps 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 …
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?
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.
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.
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
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).
2. Software emulation, which is almost as silly as the Javascript x86 emulator which you can play with here (if you have a US keyboard): http://bellard.org/jslinux/
I doubt very much that Windows on ARM will amount to anything.
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.
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.
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.
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).
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.
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.
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?
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
"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.
"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.
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.
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.
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.
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.)
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.
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.
Give it a couple of years, and despite all the negativity, it'll sell more than any other O/S in history, and the vast majority of users will love it.
.NET apps will be easy to port across, even if you have to check an extra box in VS.
Long haired men with pony tails and beards will still prowl these forums explaining proudly how they can still do everything faster and better with obscure command line commands and don't need these new-fangled cosmetic interfaces.
There will be the same caustic comments about Windoze / M$ / Wintards, promoting the view a computer should be viewed rather like an airliner or nuclear submarine, and only those with the pre-requisite years of training should be allowed to operate them.
And yet the vast majority of the market for computers will still be to casual users who want something that is cheap and easy to use, and they'll sell it by the truckload.
Yes, it's relatively easy to compile Linux stuff to run on an ARM processor. I've got various programs running on both ARM and x86. It's a bit slower on the ARM, but then a multi-core x86 chip consuming almost 100W is going to outperform an ARM running under 5W any day.
If Windows has a well-defined API fully implemented on both platforms and programmers stick to the API then they'll find their programs work on both platforms. I wonder what mark-up there will be for adding the ARM compilation ability to the existing x86 tools? If that's anything above a nominal amount then people won't bother.
I guess that well-defined API is Metro (for GUI) and WinRT (anything else), and of course .NET. Well that's the problem with Microsoft - they have plenty of APIs and majority are "legacy" in one way or another. So they replace them with even more APIs.
Good point about pricing you made there, though.
"I wonder what mark-up there will be for adding the ARM compilation ability to the existing x86 tools? If that's anything above a nominal amount then people won't bother."
Good news. Microsoft have supported both x86 and ARM processors for their embedded OS for many years and it *is* just flicking a compiler switch.
Before everyone gets their knickers in a twist, lets be clear what's being said here:
Windows 8 on ARM systems will not run x86 apps out of the box.
Is that surprising? No. Would Apple ever try to get Mac software to run directly on the iPad? No chance! If MS did provide out of the box support for old software, would most reviewers and users complain about how poor performance is and battery life is for Windows 8 on ARM systems? Definitely - even though it's in no way MS fault.
There will be ways round this:
1) Cloud based virtualisation.
2) Server based virtualisation.
3) Hyper-V (when it's ported, which it probably will be) virtualisation.
4) Cloud-based replacements (e.g. Office 365).
Not only this, but lets face it... how many ARM computers are going to have the grunt needed to run x86 apps properly anyway? Anything with any real hardware demands will need to be re-written. CAD software on what is essentially a netbook?
Businesses and home users need to get real - if you expect to run old software designed for a single-core P3 or P4 PC with permanent mains supply and dedicated graphics processor etc on a 1GHz quad-core tablet / budget laptop smoothly without sucking the battery dead in five mins you're deluding yourself. Look at Motorola's experience with Android - 7/10 returns for Motorola handsets are (apparently) down to the user installing poorly written apps that make the phone unstable and kill the battery. And those apps are deigned to work on the hardware in question!
And let's get off this whole app thing. The big selling point of W8 is that it is universal user experience, not that it has loads of apps. Most home users won't want to run old applications on their W8 tablets any more than they'd want to run them on their smartphone. What MS are offering is the same way of accessing all your cloud-based stuff from all devices, be it Xbox, phone, PC, netbook, smartphone, virtual server session etc. Yes, lack of apps will slow sales for tablets - but I'd suggest this is short-term only and in the business sector is already more than compensated for by native support for all the MS products that most businesses already use.
So, realism is called for. MS don't help themselves, that is true, but posters on El Reg should know better. Will Windows 8 become the dominant OS on tablets? Not for a while. Will ARM become the dominant architecture on computers? Also, not for a while. Remember, the RISC / CISC debate back at the turn of the millennium? The only way ARM will ever seriously take off for productivity computing is when all those old x86 apps are rewritten or moved into the cloud - irrespective of what Windows 8 does or doesn't run.
This is not a Windows 8 issue, it's an ARM issue.
> The big selling point of W8 is that it is universal user experience
What are you saying ? That it has every different GUI: XP style WIMP legacy, ribbon style, WP7 touch, Metro; so it must therefore be 'universal' ?
Or are you saying that _everyone_ will be forced into the 'one true way' of metro and therefore it will be 'universal' in that way ?
W8 is a mish-mash of several incompatible UIs tossed together as MS tries to catch up to the way the market has moved over the last few years.
> Yes, lack of apps will slow sales for tablets
Only of Microsoft tablets. iPads, Androids and others will still sell well. One reason that WP7 failed to sell because WM6.x apps could not run and there was a disjoint between those that used WM6 (corporates) and the market target of WP7 (consumer, twitterers).
W8 falls in the same boat. There are no substantial apps for W8 tablets and no point in using Desktop apps on tablets, or for using Metro touch on desktops. XP and Win7 users will continue to use those, tablet buyers will buy iPads and Androids.
"lets face it... how many ARM computers are going to have the grunt needed to run x86 apps properly anyway?"
This year's ARM tablets can wipe the floor with the sort of "heavy" desktop machines that were available 5 years ago. There were *plenty* of Windows apps that managed with those "limited" resources. Most of them are still in use. Most of the horsepower added by Intel and AMD in the last five years has gone into running the OS and the desktop, not the apps.
This post has been deleted by its author
Trying to support all the legacy applications has hobbled innovation at microsoft and given us crappy operating systems (especially compared to OSX).
Now they're doing the right thing and everyone's jumping on them for not making the kind of mistakes we used to slag them off for.
Seriously, what is the value of porting the entire windows Ecosystem to ARM by means of some lame intermediate layer that will effectively kill the "Windows on ARM" concept by making slow and cumbersome?
M$ seems to be taking a page from Apple's strategy book here:
Applications that are really relevant will get ported. People who need to use legacy x86 applications (i.e. primarily corporate users) will choose to run windows 8 on x86 PC's and tablets.
As Steve Jobs would say "it's not that big of a deal"...
> what is the value of porting the entire windows Ecosystem to ARM
The value is in regaining control of the OEMs. The ARM version of W8 (Wait? Weight? Windows 8 my homework?) is not about being sold to users it is about control of the OEMs and killing of ARM tablets.
When the netbooks first came out they were cheap machines with DVD screens, SD card 'disk' and zero cost Linux OS. MS 'persuaded' the OEMs that if they did not install Windows on them then they would lose their 'discounts' and 'advertising partnerships'. ie would have to pay MS $millions more. MS even revived XP for this.
Now the OEMs are making ARM netbooks and tablets with Linux (Android, WebOS) installed. MS can't wave loss of discounts yet, not until a version of Windows _could_ be run on them. When W8 ARM is shipped then the OEMs will fall into line and will put W8 on them, or payup millions to MS. These won't sell because of
lack of legacy apps. The OEMs will switch to Atom tablets and laptops with W8 so legacy will work. MS will regain control of the market. Or such is the plan.
You're being very silly.
No one with a clue is suggesting that. Not yet anyway.
What people with a clue can see quite clearly is that 95% of what 95% of PC users do with PCs uses a lot less "grunt" than the PC vendors like to sell. But that's been OK so far because people have been convincable that they need a Window box else it's not really a PC.
Unfortunately for the old ways, the genie is now out of the bottle and Joe Public can quite clearly see courtesy of Apple, Android, and others that what Joe Public mostly needs, and even what Joe IT User mostly needs, is not a deskbound box or even a laptop, to be incompatibly replaced every two or four years, but something far more basic (and less profitable for the suppliers, but hey...).
And when Jo Finance Director at Enterprise Customer 1 susses this too, based on the stuff her friends and family use at home, I wouldn't like to be the account manager at the desktop PC supplier, or their IT department contact...
The times, they are a'changin.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
