"People who don't care about legacy apps will never understand those who do."
"Yeah, but we won't care."
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- …
"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?
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."
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.
>>> 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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
... There will be a "Windows 8 traditional", she said, that will run on x86 chips
hold on, when the hell are we getting a full 64bit windows os???
I thought windows 7 was going to be the crossover point :/
And who still uses 3gb of ram, i get low mem just running chrome with 20+ tabs open with 6gb for gods sake.
As already pointed out, who wants ill-behaved legacy code anyway. But for those who for whatever reason are stuck, FX!32 showed that Alpha boxes could run well behaved x86/Win32 apps quite effectively, and where that isn't an option, I believe virtualisation/emulation may catch on eventually...
""There will be four Windows 8 SoCs for ARM. Each one will run for that specific ARM environment, and they will run new applications or cloud-based applications.
"They are neither forward- nor backward-compatible between their own architecture – different generations of a single vendor – nor are they compatible across different vendors. Each one is a unique stack," she added."
no one will care as long as 3 of these 4 supported ARM SOC are generic 4 core Cortex/NEON SIMD capable A9/A15 from the likes of Freescale this year.
Arm cortex with generic NEON SIMD is perfectly good enough for any OS to make a compatible platform for the future , No NEON no good longer term in other words.
maybe there is a reason there is still so much 32bit-ness in Windows 7 64bit. We keep hearing about how Windows X is new an written from the ground up but we also constantly find out it is not true and there's lots of old code still in there.
because of all the old stuff still in Windows, the ARM version is not going to look nor act much like what you would consider as Windows. Much like how Windows CE/Mobile/PocketPC/Phone7 are not like Windows. _that_ should be the news IMO and not that Windows on ARM will not run x86 code. The latter is just stating the obvious.
Having a team inside MS tailoring your chips to their specific requirements is not actually a good idea. It's a recipe for over-specialized processors that get left high and dry when the market changes.
x86 is a model-T being made to run at F1 speeds by the application of massive amounts of heat. The design is almost 30 years old, with a little tinkering for the 64bit version but nothing like what's needed for processing at 6Ghz+.
.......whistling very loudly. Whatever ones opinion of Microsoft is it is fairly obvious that they did not decide to go for an ARM version of Win 8 just for giggles. They regard it as a strategic imperative in context with small but increasingly powerful mobile devices. With coding Win 8 for both ARM and Intel architecture MS are taking an each-way bet to ensure as far as they can that they remain relevant whilst the current paradigm shift is in progress. To paraphrase an old and famous quotation what we are seeing in the mobile devices market is not the beginning of the end, nor even the end of the beginning. It is quite simply the very beginning of something that is likely to be a pretty bump ride for a lot of companies. Bluntly put MS does not give a shit about whether or not Intel misses the boat, what they care about is that *they* do not miss the boat, and if that requires ARM and at some stage in the future saying "vaya con dios" to Intel then that is precisely what MS will do. All fair in love and business and all that jazz.
The market has stampeded towards mobile devices and the lack of legacy app support hasn't been a problem. Microsoft have at least noticed that and realised they need an OS on ARM to even play in this game.
Intel have their heads in the sand. They have no stake in the new markets because they can't fulfil the power requirements. End users aren't going to sacrifice half their battery life just to run legacy apps and Intel seem incapable of building real low power devices - so that market is closed to them. Increasingly the server rack market will close to them on the power issue.
Intels argument collapses to: "you'll continue to be able to run legacy apps on desktop PC's". Wow. Non story and no upside for Intel. The only question is whether ARM catches up to x86 performance before Intel pull their collective fingers out and take power consumption seriously.
Windows users DO expect legacy support.
The reason other operating systems like Android, iOS get away with it is because they're too young to have serious legacy issues. Fast forward a few years and it will be a different situation. I'd say Android's NDK and some early decisions on issues with screen density & layout behaviour are already biting a bit.
So recently Intel stated that it's new super-tiny process will not be used to make ARM chips, period. And today a Microsoft press release appears to throw serious amounts of doubt over the ability of ARM code to be usable on different devices...
"They are neither forward- nor backward-compatible between their own architecture".
When you are writing the operating system, this is fairly true. Each ARM SoC has slightly different interfaces, slightly different video capabilities, and such. But then this has always been the case in the x86 world (is your mouse serial, USB, or PS/2? video VGA? SVGA? etc?). That is a problem that the operating system, if halfway competent, is able to take care off.
Applications, on the other hand, run on top of the OS. And an application compiled with the basic instruction set will work across a variety of platforms. I say "basic instruction set" as an MP3 player using UMULLS will not work on an ARM3, in much the same way as a Windows application with Pentium or MMX instructions will not work on a 486.
However, that said, you might like to investigate RISC OS. It is Acorn's custom operating system, largely written in assembler, which will run on the earliest clunkiest Archimedes machines, right up to the latest Iyonix... and beyond, for RISC OS is running on the BeagleBoard, and there is little reason why it couldn't be ported to an old Android handset (other than the UI being remarkably unsuitable for touchscreens, so it is probably a pointless exercise). Now provided your code is compiled in a 26/32 bit neutral way (in other words, don't assume the processor status is part of the program counter) and doesn't use processor-specific instructions, the same binary application ought to work across the entire range of machines... pretty much in the same manner as a Windows binary will work across a variety of processor types.
Thank you Renée. Please continue, provide more FUD that can be shot down in flames. ;-)
MS has been here before. When NT ran on a multiple architectures they let developers fairly easily target different Windows architectures from a drop down in DevStudio. How many developers actually bothered to target those architectures? Practically none of them.
It's a pain in the arse to build the same code multiple times, test, QA, certify, produce, sell and support products for each architecture. It's just not economically viable.
Microsoft really needs to implement some form of x86 emulation in ARM or it will suffer a dearth of apps. No legacy app is going to work on the device which includes a vast array of useful stuff. It doesn't have to run fast but it has to run. I expect an emulator could probably produce something passable, maybe netbook fast given that the Win32 APIs would be native and only the app's code would be emulated.
In parallel MS really need to move devs away from targetting chipsets at all. Things like LLVM mean I could compile a C++ app into an intermediate form and have it run on any architecture. At runtime the intermediate form would be translated into native instructions so it doesn't matter to me the developer what chipset is underneath. That's what Microsoft should be promoting - a platform neutral way of developing apps. I'm not talking .NET either but lower level. LLVM would be a good example to follow.
I expect even Apple will go this approach too. They sponsor LLVM after all and use it in iOS. While they may still support fat binaries, it's still a pain to test two builds of the app. Therefore I expect they'll include LLVM support in their next OS X update and devs will be expected to build with that. Then when their ARM device turns up it won't matter, the apps will still run.
What no one has noticed is that
all use ARM - all that uses Intel at Apple is Laptops/Desktops/Servers now given they've already done the PPC-> Intel what says they can't do Intel -> Arm? They've got the hardware guys, they've got the software guys, so it's possible. I'm betting Intel are shovelling discounts at Apple not to move to ARM. If Microsoft have Windows or ARM, then Apple can release a "boot camp" for ARM to take advantage!
I don't see why this is such a big deal. 10+ years ago when DEC Alpha was still around, there was Windows NT 4.0 for Alpha, and DEC provided a binary cross-compiler called FX32 to perform cached real-time x86->Alpha conversion. There is no technical reason why this sort of thing couldn't be done for x86->ARM binary cross-compilation.
Hey Renee, remember the switch from PowerPC to x86 on the Mac? Remember the switch to Itanium? Intel invested HEAVILY in binary translation technology and showed the world that legacy apps would 'just work'.
Now you say it's difficult? Me thinks you talk out of both sides of your mouth.
Sorta sad that Intel sold off that ARM license, huh?
would like to run ARM-based hardware. It's smaller, lower-power and hence more flexible (it can be a desktop, laptop, mobile, etc). They'd like this switch to be simple- so all your apps work out of the box.
So it's not MS who want to drop x86, it's some techies and some developers of, say, windows Tablet PCs.
It doesn't, you know.
And there's more than one HAL for NT-derived OSes on x86, or at least used to be (eg HAL for uniprocessor vs HAL for SMP).
What happened with Alpha, and what may happen with ARM (I don't know), is that there was agreement between vendors on what the core bits of an NT/Alpha system would be and where the bits they would be. The organisation fronting this for NT/Alpha (and NT/PowerPC and ...) was the Advanced RISC Computing consortium, go read about it. Their work on a common standard meant that you did not need a different HAL for every different motherboard; just a different HAL for every incompatible motherboard (spot the difference).
Back then the main difference between a simple Alpha motherboard and a simple x86 motherboard was the processor socket. Lots of the other chips (the junk IO and so on) were just the same on Alpha as on an x86. The processor-memory interface and processor-IO (PCI etc) interface weren't the same on Alpha as on x86 but then these interfaces on x86 change between generations too.
ARMs don't generally need much on a "motherboard" because there's so much on the chip itself, but the interfaces still exist.
This stuff has all been done before though many people either weren't there or have forgotten it Despite that, the technology is actually tried tested and proven. The technology didn't kill Alpha, CEO-level politics did. Times (and markets) have changed since then, but how much have they changed, how serious are Microsoft this time (they weren't serious last time) , etc.
Is it just me, or did everything Intel say in Santa Clara reek of Intel executives screaming in as many words "OH MY GOD!! RISC IS BACK, BUT ITS MAINSTREAM NOW, AND ITS PISSED!! AT US!! WE ARE IN DEEP, DEEP SHIT!! MAYBE SAINT STEVE CAN SAVE US, BUT OH THATS RIGHT, HE'S SWITCHING TO ARM TOO!!! SO WE'D BETTER SCARE ENTERPRISE CUSTOMERS AND END USERS" trying to delay the inevitable because Atom sucks.
Remember, these are the exact same people who predicted that Itanium would be the killer processor of the past decade, as well as this one. Intel's track record isnt exactly shining in predicting the future. Slot 1 anyone?
It seems like Intel just wants to spread FUD without anyone really knowing what Windows 8's true capabilities are as far as emulation/legacy support goes.
Does it really matter what MS supply (and, ahem, "support") any more?
As a (probably) hypothetical but far from impossible example, if this decades corporate favourites, VMware, were to decide to buy or build and support an x86 emulation engine for ARM , to run unrecompiled Windows/x86 apps on ARM-based corporate servers and notebooks and desktops and other such "virtual desktop infrastructure", and if the support for that execution environment came from VMware and not some random collection of Certified-MS-dependent Systems Engineers...
Where does that leave Intel in the corporate market?
And where does that leave Intel outside the corporate market?
Just askin, like, especially bearing in mind that VMware are already trying to flog their warez to the cellphone market (which is obviously ARM based), and this would be an interesting, simple, and potentially lucrative logical combination of the two...
[meanwhile a reward may still be available for anyone who can name an Intel success outside the x86 market in the last decade or so]
The trouble with linear extrapolation prediction models is that they tend to overlook 'new' events.
For example: iPad, iPhone.
The questions really are:
are consumers ready for change
are content producers ready for change
are such changes widespread or have potential to be so
could stack 'em high, sell 'em cheap models provide sufficient returns to justify investment
Your answers may differ, mine are:
Cusp: (sophisticated) IT as a high cost fringe activity or (sophisticated) IT as a lo-cost, widespread activity?
Say: google, ARM, MS (ARM), ...
Now that Microsoft and Intel are having their little spat, the truths spill out so loud the neighbors can hear.
The future is broken.
All the folks who were counting on riding the WinTel thing to retirement have got about 8 months left to make that happen. Intel wants to survive, and that means they make gear and push it even if it doesn't run Windows. Microsoft wants to survive, and that means they push Windows on everything, even if it's not Intel.
Caught between the titans are the OEMs, who also want to survive. HP and IBM will side with Intel or play both sides, Dell will stick with Microsoft and Asus too: the CEO is a coward. Acer and the others? I dunno. The rest are up in the air.
Both Intel and Microsoft will be demanding fealty, which is exactly the wrong thing to do here. Both will be thrashing about harming their partners for no good reason. It's a power struggle 'twixt massive egos. At the same time they'll be struggling internally to avoid cannibalizing their traditional profit centers.
The ARM/iOS/Android vendors will remain laser focused on their target: to make products that delight and amaze; that enable and empower their users to do things that they want or need to do and stay out of the way the rest of the time. To make and sell products that people want. To win profits for themselves, their retail partners, their developers. To cannibalize all of every other business they can. In short, to compete for end-users, which is the field the actual battle is being fought on.
It's probably early to call a winner on this one, but that last bunch looks like they're on the inside track.
It would be very wise for Microsoft management to insist that their employees do not reveal the name of their employer when in public. They have to be the most unethical company (next to Apple, that is) in the whole world - and that includes a whole raft of arms suppliers. There have been times on the London underground when I have seen Microsoft employees proudly telling us of the fact via prominent name badges. Why is it that you can never find a machine gun when you want one?
I have no desire to purchase a new operating system whenever I buy a new computer. It is like buying a new car and having to learn to drive all over again. For instance, I have just had Windows 7 foisted upon me. I have no desire for libraries, thank you. I know how I want my files organised and Microsoft do not. Also, I have a lot of old software that I like and am used to, yet I find that a lot of it will not work on this new machine.
Microsoft should be forced to make XP (32 bit) available on all new PC computers. We are not all sitting in some office with an IT department that can obtain the latest software. Indeed, in some parts of the world, the only way students can access the internet is via old machines supplied by some charity or other. There will come a time when their machine will fail and will no doubt have to try to get another. Heaven help the poor souls if their 'new' machine has Windows 7 on it.
Biting the hand that feeds IT © 1998–2019