Windows 10 on ARM
channel9.msdn.com
channel9.msdn.com
First I was amazed with them getting Xbox 360 (PPC) games running at full speed or better on the Xbox One (x86) and now we have x86 on ARM.
They have some wizards working on this stuff.
Edit: I wonder if Dave Cutler is involved in this x86 on ARM stuff? I think he was with the Xbox 360/Xbox One.
EDIT: https://en.wikipedia.org/wiki/List_of_Xbox_360_games_compati... "Unlike the emulation of original Xbox games on the Xbox 360, the Xbox One does not require game modification, since it emulates an exact replica of its predecessor's environment – both hardware and software operating systems."
I stand corrected.
> Xbox 360 games run within an emulator on Xbox One, which means you'll be able to use most features from both systems while playing games, such as screenshots, broadcasting, and Game DVR.
So they probably can get away with static recompilation.
looks like api translation like wine does. ...which is rather easy if you wrote the original api.
If not using Visual Studio, search for 'Acquire on its own' on the page. There is a link in that section.
It uses Hyper-V so you will need a Pro version of Windows.
At the very least make it a pro feature.
But look at the timing. Everyone was nagging on google for years about slow emulator. They didn't do shit for years. Microsoft released an emulator, which was superior in almost all aspect. Just after that Google released new emulator. and now it does make sense to discontinue that project.
Sure is convenient for VMware that you can't run Virtualbox and VMware Workstation at the same time
Absolutely a business decision by Microsoft, and not a limitation of the x86 chip
No it didn't. If platform specific solutions make sense then we should use platform specific solutions. Not everything has to be cross platform and 100% identical across all platforms.
It's astounding that people still try to ignore the last 30 years of evidence of this.
>Trying to be identical across 3 platforms always means adopting the lowest common denominator and always results in being equally shit on every platform.
In that case we're fortunate that Xcode isn't cross platform.
Linux users should get the best possible experience on the system, so should the windows users. If a better emulator is available on windows why should they get shafted? Linux tools even have the advantage that they may not need full emulation in the first place, but instead we end up with the worst of both worlds.
> Android Studio and the emulator work very well on all 3 platforms.
In my experience nothing about android development works very well on any platform. I'm not a huge fan of MS, but windows phone development and tools are an absolute dream in comparison.
And again, we've got 3 decades of evidence that show precious few good cross platform solutions, so investing the saved money into making a better product doesn't seem to work.
You seem to be under the impression that if you develop a cross platform solution that it's going to be inherently inferior. I disagree with that and the new Android emulator is proof of that. It's superior to the MS Android emulator in every way and it's also available on all 3 platforms.
>In my experience nothing about android development works very well on any platform.
In that case you probably don't have much experience developing for Android.
>I'm not a huge fan of MS, but windows phone development and tools are an absolute dream in comparison.
If developing for windows platform is a dream then why is their app store a cesspool filled with horrible looking apps?
They hire PhDs capable of sorting out the incredible whiteboard and phone CS exercises for something.
Also apparently all those Phd weren't able to do what GenyMotion guys and girls were happily developing.
Coincidentally, that was around the same time that Microsoft filed an Amicus brief supporting Oracle (in Oracle v. Google) arguing that APIs should be copyrightable[1].
Did that Project Astoria implement Android APIs? Would Google go after Microsoft in court had they officially released this? My guess is "yes" to both these questions. Nothing says wilful infringement louder than submitting a legal document to the courts spelling out why you think what you're doing (Astoria) is wrong.
1. http://www.groklaw.net/articlebasic.php?story=20130221153759...
https://blog.rthand.com/post/2017/05/02/good-bye-visual-stud...
Also probably licensing issues, for games with tech that old
I think they're kind of doing this already with Windows Defender App Guard [1] thing, which for one is a mouthful, second, it should have nothing to do with the exploitable Windows Defender code [2].
It should be part of Windows' lower-level systems, so that not much can interact with it, and it should be available for all apps, not just Microsoft's own apps. Windows on ARM, Project Centennial, App Guard, and more, prove that Microsoft has the ability to do that.
If they don't do it, it will only be for political reasons like not wanting Chrome users to benefit from the same technology, or wanting to sell it as "value-add" to enterprise customers, or whatever (basically the same BS they're pulling with Bitlocker).
[1] https://blogs.windows.com/msedgedev/2016/09/27/application-g...
[2] https://arstechnica.com/information-technology/2017/05/windo...
Mobile data collection tools on iOS and android devices are rather poor (at least open source ones), hopefully this will help solve this problem—we'll just be able to use windows applications that work and are better developed. The windows ecosystem still seems easier to me than iOS / Android, perhaps that's just my bias or that I see more development options.
This could be a huge turning point for Microsoft's mobile divisions.
x86 drivers are still something I'm curious about here...
[edit: I should also mention, the reason why geospatial tools comes into play here is because the snapdragon CPUs have integrated GSM and GNSS (GPS) on the die. Currently, x86 based tablets have to use a separate component, and many don't come with it or even provide GNSS as an option]
Also, I have a bizspark Azure subscription and it's not a perfect UX; but man does it beat AWS
How so?
On AWS I was through a sea of services I don't need w/ poor docs, clunky configs and a lot of security tiers. Their pricing is baffling and I really just think it looks terrible. Azure has similar issues; but I can navigate it better and feel more comfortable w) it
Azure has one too; they are both clunky and more than I need but; and someone who uses AWS hopefully will chime in-- my guess is most people use the API almost exclusively. I don't have enough familiarity to judge it; have only use it a bit and a while ago
I actually disagree with this pretty strongly. The Azure UI seems flashy for the sake of being flashy. The AWS UI is much easier to navigate and use for me.
Azure's UI is more unified though. There are some random AWS services (e.g. sqs) that have a totally different UI theme going on.
Edit: the Azure UI is only more unified if you ignore the fact that there are two totally separate versions (classic + the new portal), and you end up having to hop between the two in some instances if you have some older infrastructure because feature parity is not perfect.
But all in all, the technical offering is pretty good and easy to be productive in.
1. In the talk they claim that they get "near native" speed from the translation. Can we have some real number of what can be expected? What about warm up time?
2. Is the x86 translation layer only available in user space, or can x86 drivers be loaded for hardware that doesn't have arm drivers yet (or the manufacturer doesn't care about making them)
3. Are there any plans in the future for supporting x64 code as well in the translation layer?
Edit: One more:
4. Are there any plans on supporting Arm v7 in the future, e.g. with Surface/Surface 2 support?
See: https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_m...
This is a deep rabbit hole because modern processors are speculatively executing THOUSANDS of instructions ahead. So what you have/haven't written to memory is slightly existential.
Here is a good blog post about it http://preshing.com/20120930/weak-vs-strong-memory-models/
The TLDR: x64 tries REALLY HARD to ensure your pointers always have the newest data. ARMv6, very much. ARMv7 kind of. ARMv8 fairly.
With up to 96 in scheduler. 72 loads, and 56 writes.
Link: (summery you find hard intel references internally) https://en.wikichip.org/wiki/intel/microarchitectures/skylak...
224 per core. We're talking concurrency. So a 10core, 20HT server class can have 2240 instructions in flight.
It's neither "thousands" of instructions in flight for a single processor, nor is it thousands "ahead" for multiple processors, let alone both. It's like taking 4000 basic single-stage CPUs and claiming they execute thousands of instructions "ahead", which makes no sense.
Although the idea of "lots of instructions in flight" was right. From programmers' point of view there's no difference between out-of-order windows of tens, hundreds or thousands. One just needs to be prepared that CPU can and will reorder things within limits of the defined memory model. Which does not define limits for out-of-order window size.
Nope.
Because we're talking about cross-core guarantees of concurrency. So you actually do care about what another, or all cores are doing.
What core is loading what, and what core is storing what.. and what is pending/holding up those loads is actually extremely important from the perspective of atomic guarantees.
Weaker CPU's (Like say POWER7) that do batching writes (you accumulate 256bits of data, then write it all at once) don't communicate what is in their write-out buffer. So you may write to a pointer, but until that CPU does a batched write the other cores aren't aware. You have to do a fence to flush this buffer (in the other cores).
There are some scenarios where the same situation can arise on x64 but its rarer. The intel cache architecture attempts to negotiate and detect when you are/aren't sharing data between cores. So for _most_ writes it uses the same situation as POWER7, but if it can predict your sharing data it'll use a different bus and alert the other CPU directly.
This is why x64 uses a MESIF-esque cache protocol [1][2]. It can tell when data is Owned/Forwarded/Shared between cores.
[1] https://en.wikipedia.org/wiki/MESIF_protocol
[2] Intel hasn't updated their white papers in 5+ years they're likely using a more advanced protocol.
This is mostly about load/store order of an individual core. How individual core decides to order its reads and writes to memory.
> Weaker CPU's (Like say POWER7) that do batching writes (you accumulate 256bits of data, then write it all at once) don't communicate what is in their write-out buffer. So you may write to a pointer, but until that CPU does a batched write the other cores aren't aware. You have to do a fence to flush this buffer (in the other cores).
You can actually do same on x86 by using non-temporal stores. Although you're not talking about store ordering, but about visibility to other cores. A store won't ever be visible to other cores until it at least hits L1 cache controller.
> There are some scenarios where the same situation can arise on x64 but its rarer.
Yup, that's right. That's why x86 (and x64) got mfence and sfence instructions.
> This is why x64 uses a MESIF-esque cache protocol [1][2]. It can tell when data is Owned/Forwarded/Shared between cores.
Reordering happens before cache controller. When cache controller is involved, the store is already in progress.
> http://preshing.com/20120930/weak-vs-strong-memory-models/
If you want more details of memory models of some CPU architectures, read
> http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2...
Note that "x86 OOStore" is not a model that you should be concerned about (according to https://groups.google.com/forum/#!topic/linux.kernel/2dBrSeI... it was only used on IDT WinChip)
For a perspective on memory barriers for different memory models with a focus on the Linux kernel look at
> https://www.kernel.org/doc/Documentation/memory-barriers.txt
If you are specifically interested in some subtile details of the x86 memory model, have a look at
> http://www.cl.cam.ac.uk/~pes20/weakmemory/index3.html
Best begin with
> http://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf
---
I hope this should give you enough information to start reading up on the subject.
The 2nd part of his talk goes into some of the differences between x86 and other architectures (about 31 min in):
https://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-20...
I hope the answer is not "by restricting all emulated threads to one CPU core".
Visual Studio used to(probably still does) this around volatile for x86 which leads to fun bugs when you port to ARM/etc.
Not sure where MikusR gets this info from, but it could be right given that Snapdragon 820 is Qualcomm's custom core.
[0] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
So, an emulator like this isn't going to be perfect, and applications which have been getting lucky due to x86's ordering model and avoiding proper sync primitives will likely break, and there really isn't much that can be done in those cases but fixing the application although it wouldn't surprise me if there is a compatibility flag which falls back to some slow path emulation mode which orders individual loads/stores and runs at 1/10 the normal speeds.
This is not always true. See [1] for an example. Because of the semantics of the x86 memory model a sequentially consistent load does not generate a lock'd instruction. When such loads are translated to ARM64, you need to introduce barriers or use a ldacq instruction.
This is about memory order. How CPU is allowed to reorder normal unsynchronized loads and stores. X86 has strong order, but ARM CPUs can reorder loads and stores significantly more. Thus on ARM you very often need memory barriers on ARM where x86 needs none.
If memory order is not handled according to specifications, programs executing simultaneously on more than one CPU core, relying on CPU memory model/ordering will not work correctly.
You don't want to make every ordinary load and store atomic, because that would incur a rather high performance cost.
If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well since threads can be migrated between cores and the compilers are fully allowed to reorder load/stores as well as long as visible side effects are maintained.. I could go into the finer points of how compilers have to create internal barriers (this has nothing to do with DMB/SFENCE/etc) across external function calls as well (which plays into why you should be using library locking calls rather than creating your own) but that is another whole subject.
The latter case is something I don't think most people understand... Particularly as GCC and friends get more aggressive about determining side effects and tossing code. Also, volatile doesn't do what most people think it does and trying to create sync primitives simply by forcing load/store does nothing when the compiler is still free to reorder the operations.
An emulator is also going to maintain this contract as well. That is why things like qemu work just fine to run x86 binaries on random ARMs today without having to modify the hardware memory model.
Incorrect. On x86, if you write to memory n times, other cores are guaranteed to see the writes in same order. Second write is never going to be visible to other cores before first write. It's correct to rely on x86 memory model in x86 software.
On ARM, those stores can become visible to other cores in any order.
> since threads can be migrated between cores
Irrelevant. This is about code executing concurrently on multiple cores. Operating system and threads are irrelevant. This is about hardware behavior, CPU core load/store system and instruction reordering, not software.
> ... and the compilers are fully allowed to reorder load/stores...
This has nothing to do with compilers. This has everything to do how CPU cores reorder reads and writes.
> Particularly as GCC and friends get more aggressive about determining side effects and tossing code
If GCC has bugs, please report them. Undefined behavior can give that impression, but again, this topic has nothing to do with compilers.
> An emulator is also going to maintain this contract as well. That is why things like qemu work just fine to run x86 binaries on random ARMs today without having to modify the hardware memory model.
This is not true. See: http://wiki.qemu.org/Features/tcg-multithread#Memory_consist...
Remaining Case: strong on weak, ex. emulating x86 memory model on ARM systems
I recommend you read this: https://en.wikipedia.org/wiki/Memory_ordering.
If you have complete control over the whole stack, sure. But we are taking windows user space applications. You continue to ignore my point originally that the edge cases you are describing may cause problems, but are just that, edge cases which can be solved with slow path code (put a DSB following every store if you like), and are likely depending on behaviors higher in the stack which aren't guaranteed and are therefor "broken". If your code is in assembly, and never makes library calls, etc then you might consider it "correctly written" otherwise your probably fooling yourself for the couple percent you gain over simply calling EnterCriticalSection().
Well, hardware feature is a hardware feature. Load/store ordering is a hardware feature.
Operating system, user space or kernel space, compiler, etc. are not relevant when discussing about CPU core hardware operation.
You don't need complete control of the stack. You just need to have CPU cores executing instructions on multiple cores.
And I will repeat this again, for "correctly" written code this doesn't matter. Because the data areas being stored to should be protected by _LOCKs_ which will enforce visibility. If you think your being clever and writing "lock free" code by depending on the memory model your likely fooling yourself.
Please don't conflate visibility with load/store order. It's a different matter.
See how C++ memory model operations map to different processors, especially how many cases are simple loads or stores on x86.
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html (link from another comment in this discussion)
Although this is somewhat of the reverse in architectures, going from CISCy to RISCy.
The only thing that concerns em about recent Microsoft developments is that they seem very keen to move their OSes into more of a walled garden like iOS and the Mac App Store, and extract 30% from every third party application transaction. They could use one of these sorts of transitions as an opportunity to advance that business strategy further.
Not to diminish Apple's accomplishment, which was indeed impressive, but a lot of this was because by that point, PowerPC was so, so far behind Intel's chips that, even after the emulation performance penalty, the Core 2 chips were fast enough to make it no big deal.
There's not a similar Intel/ARM gap this time around so Microsoft will have to rely on their chops alone.
Apple started with the Core Solo and Core Duo chips (Yonah), which were fairly fast but weren't remarkably faster than the PowerPC G5. A single core G5 iMac held up quite well versus the two-core Core Duo and thrashed the Core Solo. Aside from memory reads the G5 did quite well.
The strength of the Core Duo and Solo were in performance per watt and that's what Jobs was looking for.
In the case of Windows in particular, it's a chance to leave the installation wizards, the registry and the DLL hell behind and use the packaged model that macOS adopted from the get go.
I don't think that's a dealbreaker, especially when they'll let people trade from 10S to 10Pro for free. But it's a pretty big caveat that got added very quietly.
Apple did the same when they moved from 68K to PPC. The PPC would run the 68K code in emulation or, if it was a "fat binary" with both 68K and PPC code, it would just load the functionally equivalent PPC binary and run it.
There were utilities to compress executables that deleted the versions not for the current CPU - very handy in low-power 68Ks
ARM doesn't have this advantage over X86, at best its probably somewhere around 1/2 the absolute performance. Of course intel has been selling a _LOT_ of really slow CPU's down the product line, so for someone upgrading from a atom class machine the ARM will probably appear to be pretty reasonable. Not so much, if your running a fairly high end laptop.
And yes. At that time, PPCs ran rings around x86's and 68K's.
This seems tragically the inevitable, but slow direction. We can only hope that it accelerates the transition of app stores to state-regulated markets rather than private arbitary fiefdoms.
I put "successfully" in quotes because MacOS in that era was notoriously crashy-buggy.
4. Are there any plans on supporting Arm v7 in the future, e.g. with Surface/Surface 2 support?
I think that Office version already is native, and that they gamble/expect that the likes of Photoshop and Mathematica will soon ship real native versions (rightfully so, as that is what happened when Apple jumped PC architectures, too, with the exception of Quark Express, which consequently got eaten by InDesign.)
http://blog.mcchristie.com/wp-content/uploads/insights-brick...
EDIT: no [1].
[1] https://www.theverge.com/2016/12/7/13866936/microsoft-window...
The macOS development stack has been re-tooled to output LLVM bitcode within its "fat" binaries for a good while now. It'd be very simple for Apple to throw the switch on a compile farm ala the one Google has for Android APKs, and suddenly have ARM downloads for everything on the Mac App Store (without requiring any re-submissions.) Which means it wouldn't be hard at all for Apple to ship a "functional" ARM macOS computer... just, until now, such a machine wouldn't have had a very good Windows story. No Boot Camp, no cheap virtualization, etc.
Suddenly, that story is a solved problem.
Yes, you could do the same thing with a plain x86-ISA binary, but such a binary might have sections that are very hard to transpile efficiently/effectively—because e.g. they exist as the result of compiling hand-optimized x86 ASM source modules. Targeting bitcode constrains the inputs a bit more, such that the input to the transpiler won't be using extremely-microarchitecture-specific instructions.
And yes, the results wouldn't be 100% efficient. But it would be efficient enough—like Rosetta—to serve as an effective stop-gap to allow ecosystem consumers to continue to consume their purchased apps on new devices, until ecosystem developers upload explicitly re-optimized apps. (And it would—like Rosetta—at least let apps from "dead" development studios run, rather than killing them off entirely.)
However you are forgetting three very important points:
1 - Apple is free to use their own fork of LLVM bitcode
2 - Apple controls what those bitcodes actually mean on their compiler stack
3 - LLVM guys already had a few talks at LLVM conferences about creating an actual platform independent form of bitcode
Everything old is new again!
Intel shot itself in the foot by replacing the Core architecture in mobile Celerons and Pentiums with Atom, and also by starting to rename lower performance Core M chips to Core i3 and Core i5. This will make it easier for ARM and AMD to "catch-up" and even beat Intel at these levels, because Intel got greedy and tried to trick the market with lower-performing chips at the same price points as for previous (and more powerful) generations.
Core mobile Celeron and Pentium are still available, for example Celeron 3865U [1], it's just Intel got tired of having names with useful information in them. That processor should probably have a name like Core v7 2C-2T 1.8Ghz-15W which has most of the useful information, but 3865U is what we got, so you have to filter out the atom chips yourself.
[1] https://ark.intel.com/products/96507/Intel-Celeron-Processor...
(Although I'm in the UK, where the carriers are less abusive)
Microsoft has chosen to drop a lot of older models from the Creator's Update, but is still providing cumulative/security updates to the Anniversary Update right now, which is supported on all phones which run Windows 10 Mobile.
At least, at present, if you have a Windows 10 Mobile device, you have recent security updates, regardless of make or model.
I would say, Microsoft has a reputation for long term support and backwards compatibility, but it seems like it's something they're trying to get away from.
The manual intervention to upgrade to 10 is because, as noted, the big change is that Windows 10 Mobile upgrades are handled by Microsoft, so the update servers had to be changed. Prior versions to 10 had the same carrier-based update issues Android had.
I'd argue that change alone points to the fact that Microsoft is getting better at long term support, not worse.
No, that's a good thing. Pushing major updates and new features instead of just patches is what makes users (and IT departments) disable automatic updates.
Worse yet if the update fails...
Any phone above 300€ is not worth my money, I am not buying a gaming desktop.
Seems pretty alive to me.
My current Lumia 650 cost £60 refurbished, which is a tenth what I'd pay for the next best option. It's fairly trivial to stop a Windows Phone reporting your entire life history upstream, and unlike pretty much any Android handset I ever owned, this firmware receives constant security updates, as did its predecessor for the 3 years I owned it (old phone cost £120).
I wonder if this ends up being the inheritor of Windows CE for embedded ARM-flavoured devices. I also wonder if this means that the Win10 ARM kernel has the full Windows API - so if you built an ARM PE executable that could run natively. I suspect 95% of the pieces are in place for that but it's not yet been productised.
Killing Windows RT was the right choice, because it was never designed to do something like this. It had a weak translation layer for Win32's API built right in, and they would have needed to do some wizardry to have the two live side by side. No, I think RT was a useful but failed experiment, and I'm excited to see them take this approach with Win32 emulation on ARM. If it works as well as these demos suggest it does, it could finally provide a good path for ARM into consumer laptops and even desktops, to spark some great competition in the space. I'm excited to see where this goes.
But when it comes to hardcore system software development stuff. They are unbeatable. Emulating entire x86 on ARM? This is mind blowing.
They have pulled good emulation before too (one I think was inside XBOX).
But this is going to be serious. I would say very serious.
Extremely good battery life would give Microsoft, very good edge over Apple.
1) Qualcomm will be the winner. and so other ARM CPU manufacturer. and Intel is the biggest loser here.
2) Microsoft will hit market with this. After this they will have extremely good position to release good phone, and here we stand, I see successful future for Windows Phone.
3) From Computer Architecture perspective, the bottleneck is not memory or CPU speed. It is IO and energy. I don't know how this will impact on IO. But I am almost sure this is unbeatable from energy efficiency, and when I (and almost all people I know) buying a laptop. battery life is almost the most important aspect of it.
Imagine the motherboard on your phone, but in your laptop. The rest of the space would be used for batteries.
I can see a potential milestone Windows 10 S on an Arm V8 based laptop with all day battery+. Sort of a Surface RT but without any excuses.
If Apple follows suit and creates a light weight, network centric laptop experience around iOS, then you'll have three contenders for the 'appliance' environment, ChromeOS, Windows 10 S, and iOS. Each with their own 'laptop' design ethic, Pixel, Surface, MacBook.
Consequently, all this ARM talk has got to be making Intel nervous. I don't think now would be the best time to buy any INTC stock. :/
Community ROMS? Keep an eye on Halium, unifying a common base for porting sailfish/luneos/plasma mobile/ubuntu; with anbox for Android apps.
https://www.indiegogo.com/projects/gemini-pda-android-linux-...
It's billed as a handheld gaming system but you don't have to play games on it.
Runs Windows 10 on a 5.9-inch 1920 x 1080 screen. Atom processor.
Whether it will lever get made is another matter (it's an ex-Kickstarter project now taking pre-orders), but the approach is interesting.
I personally see the much larger performance regression for Windows 10 on RPi3 in the fact that at least on Windows 10 IoT Core there was no hardware acceleration of graphics on RPi3 when I last tested it (about a year ago), which caused it to feel rather sluggish.
Snapdragon 835 will probably be the minimum level of ARM performance Microsoft will accept. We may start seeing Samsung's Exynos and a high-end MediaTek processor being supported in a year or two.
http://i.imgur.com/mRdk6ZD.jpg
This is an ancient chip, however I also found MediaTek ones for ~ $10, which had 4 cores and were 1.6ghz SoC.
Sounds to me like we could seriously see $100 laptops that actually function soon.
They're essentially supporting the end result, I would hope they don't force developers to go through emulation to try to encourage them to write a universal windows app
-- ST boot sector guy
(2) There's no reason why Samsung or one of the Chinese manufacturers couldn't make a Windows 10 phablet. Microsoft made Windows free on small-screen devices, so I assume it will continue to be free, or at worst, "zero paid".
[Microsoft had a Windows offering where OEMs paid $10 for the OS but got a $10 rebate for setting Bing as the default search engine. So technically, Windows wasn't free, but OEMs didn't pay anything to use it.]
It feels like microsoft these days think that people who make desktop apps and don't sell them in the store are robbing them.
Microsoft just needs the library of legacy Win32 apps to get their Windows-on-arm to take off, but they want as much as possible of new apps to be using the store. Not least evident by the new "The app you are installing is not from the windows store" messages in Creators Update.
If they can get the huge chunk of people who are using their computers without an enterprise domain, and without heavy workstation apps (basically just doing internet/docs/games) to use a cheap and safe iOS-style windows, then they can at least start getting 30% cut of the app sales from all those people.
I'm not too worried about that as long as there is a proper windows for professionals. In the above scenario they could start charging more of a premium than they do today for the legacy windows desktop because there would be no consumer version of it.
I assume they will be releasing a build configuration for native ARM software deployment on Windows.
https://developer.microsoft.com/en-us/windows/bridges/deskto...
Edit: Apparently Surface 2 isn't AArch64, so probably not.
(1) Microsoft makes generic install media available (rather than just device-specific restore media, for devices that ship with Windows 10 ARM), and
(2) Windows 10 ARM will run on ARMv7 devices, rather than being restricted to ARMv8 (AArch64) devices.
Embedded devices, yes, but ARM on servers is more like ARM's perpetual future.
Yes, Qualcomm was "established", but few would've thought Intel can't at least beat lesser known competitors such as MediaTek. It couldn't because Atom chips and Intel's cost structures in general are much higher than those of ARM chip makers - to the point where it prohibits Intel from competing head-on with ARM chip makers. Intel invested at least $10-$15 billion in the mobile market, and it only had 2% market share to show for it at the end. You can't even blame LTE modem technology for it, because Intel actually had better LTE tech than MediaTek, second only to Qualcomm. If anything, it should've helped Intel become Qualcomm's main competitor.
For now, we'll only see competition between ARM chips and Intel chips in budget laptops (which happen to be the most popular type of laptops), but with Moore's Law dying and Intel hitting a ceiling on performance/core, there's no reason why ARM chips can't catch-up to Intel at the higher-end levels of performance, too.
And don't forget that right now ARM chip makers are still building first for smartphones. That means they try to have a 4-5W TDP for the entire SoC at most. They haven't even tried to build a chip that has 15W, 30W or 45W TDP for a laptop. But if things go well enough for them in budget laptops, I could see them start building those types of chips, too.
This is also MediaTek's story in the mobile market. It started out competing with Qualcomm only in $100 smartphones with low-cost chips, and now it has just announced a 10nm high-end chip (Helio X30) that will compete against Snapdragon 835. It may not be quite as good still, but it should be close enough (the closest MediaTek has gotten, in fact). I imagine Microsoft will begin supporting that chip (or its successors) in Windows 10 soon enough, too.