ARM-Based Windows 10 Portable PCs? Hell Yes | Hacker News Reader

ARM-Based Windows 10 Portable PCs? Hell Yes

thurrott.com

79 pointse271828117 comments

Download my great free Windows program now! Please choose:

    EXE installer     32-bit x86   64-bit x64   32-bit ARM   64-bit ARM
    MSI installer     32-bit x86   64-bit x64   32-bit ARM   64-bit ARM
    Portable Zip      32-bit x86   64-bit x64   32-bit ARM   64-bit ARM

(Download my great free macOS program now!

     Click here

)

This is already a usability problem, and adding 2 more target chipsets makes it worse.

Given both bandwidth and smart programmers, couldn't Microsoft make an installer creator that works on all the above architectures and installs the right version of the program? No problem shipping 4x too much code right - most installers that are big at all, are big because of assets, not code size.

I guess politics vs the Windows Store team would prevent this from happening within Microsoft, but given how awful the Windows Store is and how it still can't be used to download and install boring oldschool desktop applications, this is a usability nightmare waiting to happen - despite the obvious benefits of not being locked into a single chipset architecture anymore.

https://www.microsoft.com/en-au/store/apps/windows

"it still can't be used to download and install boring oldschool desktop applications"

it can.

https://msdn.microsoft.com/windows/uwp/porting/desktop-to-uw...

Are you sure? Afaik you can convert most apps to UWP apps but they don't have the same rights and capabilities as the oldschool desktop apps. I don't exactly know what the limits are but I doubt stuff like Wireshark or f.lux could run as an UWP app.

You can now publish win32 binaries to the Windows Store, which run in a virtualized environment. They get the same rights as normal win32 exes because they _are_ exes.

I'm still confused. Why are they run in a virtualized environment then? Can a Windows Store win32 app change system display gamma settings? Monitor all network traffic?

From what I've seen, most of the virtualization that remains is filesystem/registry virtualization, primarily with the goal to insure clean install/uninstall. Security is handled in most of the usual Win32 manners (user token privileges, UAC, et al).

From your examples, I believe gamma settings would be accessible, but every tool I've seen that reliably monitors all network traffic uses a kernel-level driver and I don't think you can install kernel-level drivers from the Store right now.

Awesome. This makes me wrong and my entire rant flawed. Thanks!

It's not really different from choosing among 32 bit or 64 bit programs, or even, for Linux software choosing the package that's best for your distribution. It's not really a pain point. People can read. People who use Windows and Linux know how computers work. People are smart. People should not be babysat by their operating systems. It's gonna be OK. Don't worry.

Am I missing the sarcasm tag here?

If only...

Well, one guy I work with, I've had to install DraftSight for him on three computers now.

In my head I think "Google download draftsight, click click, how hard is that?", then I remember some of the guys I work with csn hardly read but at least this guy can draw rectangles in DraftSight.

I put Linux on my SOs laptop, she llove it, but I still have to remind her to install updates occasionally.

The right balance for notifications, nagware, user interaction, download and installing things, is hard.

There was literally a post about this on HN yesterday [0]. I'll accept that people using Linux are better at computers. But Windows is too broad in terms of user skill.

[0]: https://news.ycombinator.com/item?id=13111768

I encourage anyone who wants to know how to manage software transitions to watch Apple's presentations about Next, Rhapsody and OSX between 1997 and 2000. This was IMO a textbook example of how to move over a whole ecosystem to a more modern underpinning, even under very difficult circumstances (where Apple's leadership first had to think about how they can survive another year even).

Sounds intriguing, could you offer up a more detailed insight or a link? :-)

Basically, you get a corporate drama, a human drama and a tech drama all wrapped up in one series of presentations:

Jobs' return (as a consultant) 1997, promoting technologies from NeXT. Watch basically everyone asleep at the wheel except Jobs, the man with a plan. https://www.youtube.com/watch?v=4QrX047-v-s

WWDC Q&A - 'the art of saying no' https://www.youtube.com/watch?v=6iACK-LNnzM

Jobs' hostile takeover in July by doing a (probably illegal?) stock dump https://en.wikipedia.org/wiki/Gil_Amelio#Apple_Computer

Announcing a Deal with Microsoft as de facto CEO in August, booed by the crowd https://www.youtube.com/watch?v=IOs6hnTI4lw

Internal meeting in September 1997 https://www.youtube.com/watch?v=9GMQhOm-Dqo

iMac introduction 1998 - Apple is back https://www.youtube.com/watch?v=oxwmF0OJ0vg

Macworld 1998 - Apple is essentially saved as a company https://www.youtube.com/watch?v=gdYiqVzPjAc

OSX Strategy reveal (if you only have time for one presentation, watch this one) https://www.youtube.com/watch?v=E5dWDg6f9eo

1999 - OSX Server launch https://youtu.be/NuCYHrSig94?t=48m40s

2000 - OSX launch https://www.youtube.com/watch?v=Ko4V3G4NqII

I find it interesting to hear how important developers were in the 1997 video. I feel like the first Intel Macs were indeed machines build for developers. But since, like, Snow Leopard, the developer experience has either stagnated or regressed. The command line tools are ancient, managing packages has been left for Homebrew and the like, etc. Macs more and more become pure Facebook consumption machines.

Basically they had to attack the problem from the chicken side. Nowadays there are so many eggs (users) that the chickens (devs) come free. At some point not catering to them will likely backfire however.

Note that in the 1997 video, everyone in that room was Mac application/hardware developers, and the Mac ecosystem at the time didn't intersect much with the Unix/Linux world at all.

It wasn't until OS X that Unix/Linux developers started coming to the Mac. (see this 2002 Mac magazine ad: "Sends other UNIX boxes to /dev/null." http://xaharts.org/funny/Apple_Mac_OS_X_Unix_ad.html)

Wasn't one of the points of the .NET Framework to make architecture independent apps? The CLR is compiled to the native instruction set, but apps are only compiled to IL and thus are dynamically recompiled to the native instruction set.

So, ideally, you'd just have one download.

Yes. It is promoted strongly inside MS, however it seems it is not much used by them.

And this is exactly how it works with Windows Store apps. You upload .NET bytecode, and the Store delivers the correct compiled-to-native code for the user's architecture.

You can also make fat packages, if you don't wanna distribute through the store.

1. I don't think it's going to explode the compatibility matrix... it seems to run unmodified x86 executables on ARM.

They demo Photoshop running on a Qualcomm processor: https://www.youtube.com/watch?v=A_GlGglbu1U&feature=youtu.be

2. Existing "desktop app" authors can opt to package their app in a way that will make it possible to distribute through the Windows Store.

https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

You can also run 32-bit apps on a 64-bit OS (also because of an emulation layer), but still people offer 64-bit downloads of programs. Why? Speed and memory. With ARM it'll be similar.

I hadn't considered that. I assumed this was only x86 desktop apps on ARM via emulation.

If they're going to let people build/distribute native ARM binaries for Windows 10... then I'm even more impressed. I guess I would've expected that to be mentioned though.

If this is the case, that would certainly invalidate my comment about the compatibility matrix. I guess in that scenario, I'd agree and hope that those folks are working on a "fat binary" or "universal binary" or something to aid with the potential confusion.

> If they're going to let people build/distribute native ARM binaries for Windows 10

Hasn't that been possible since Windows RT?

Sort of. Windows RT only ran Microsoft-signed ARM binaries. Hence why I assumed it would've been an explicit announcement if they were allowing devs to distribute native ARM executables.

Windows RT supported C/C++ "native" compiles for ARM, so long as you published it to the Store and used the WinRT runtime/lifecycle. It just didn't support Win32 binaries compiled to ARM outside of the exceptions for Microsoft's own applications.

I don't think we have details if the new plans include allow developers to cross-compile Win32 apps to ARM, in addition to the x86 emulation.

If they want the surface phone to be a slam dunk they need to give it ability to run android apps as well as UWP and emulated win32, if the could get a license from Google to merge in the android app store with the windows app store it would fill in a lot, add the ability to run win32 and the ubuntu for windows console and you have a pretty killer does everything device.

And that's how you plan to build something that never materializes; not to mention the horrible user experience in dealing with so many different types of apps with different philosophy and UI.

macOS (nee OS X) has supported PPC (32-bit and 64-bit), x86-32, and x86-64 over the years. Furthermore there are plenty of applications that require 10.6+, 10.8+, etc. I get your point, but macOS is at least at fragmented as Windows in terms of needing multiple binaries.

macOS can support all three of the platforms above with a single fat binary.

You are mostly right, I had forgotten about fat binaries. However, 10.6+ only supports x86{-32,-64}, and and 10.8+ only supports x86-64 [0]. Having Windows 10 (?) support 4 architectures is a feature, in my opinion. But, I'd still agree fat/universal binaries would be a usability enhancement.

[0] https://en.wikipedia.org/wiki/Universal_binary

Aside from universal binaries, Apple's approach to 64 bit also provided a better user experience. Microsoft required you to choose either a 32 bit or 64 bit version of Windows, with the 64 bit version breaking driver compatibility. Apple enabled 64 bit apps to run atop a 32 bit kernel, enabling driver compatibility, at a slight perf cost.

Probably these new ARM machines won't support legacy hardware, though that may not be relevant nowadays.

10.6 could also run PPC binaries if Rosetta was installed. (It wasn't installed by default, but was an optional install from the installer disc.)

This sounds like an application/website problem rather than an operating system problem. You don't need to distribute both an EXE and an MSI installer. That's like distributing both a .pkg installer and a .dmg/.zip for your Mac program. Just pick one technology. Most programs don't need both.

You don't need to use Microsoft's installer technology either. Installers are simple programs. You can roll your own or use third-party installer technology like NSIS. I remember old versions of Chromium had a very simple "installer" which was just a dialog that ran on first launch and asked you for some basic settings.

The architecture problem is easily solvable too. Simple programs can just target the lowest common denominator (32-bit x86.) You can simulate "fat binaries" by having a 32-bit x86 wrapper program that includes builds for other architectures as data, extracts the correct one to the Temp directory and runs it (I think Bvckup 2 does this.) For large programs, you can have an online installer which picks the right version and downloads it (with options on the website to download an offline installer.) Also, the website itself can point the user to the correct download. It doesn't even need JavaScript to do this, since the user's architecture will be in their user agent string. Use this information to emphasize the correct option in the UI. Maybe even hide the other options behind an "Other downloads" link.

You don't even need to bother with 32-bit x86. Nobody has 32-bit x86.

The ARM emulator only runs 32-bit x86 binaries.

Looks like trying to pick the installer for Linux except there are also different distributions.

Here is the announcement from Microsoft: https://blogs.windows.com/windowsexperience/2016/12/07/devic...

Qualcomm also announced a 48-core ARM server SoC today, which is based on "Falcor" cores, and is to be manufactured on a 10nm node.

http://semiaccurate.com/2016/12/07/qualcomm-announces-10nm-c...

Interesting development. Could this be a good thing that encourages OEM to standardize on something like the IBM-like PC that we have for x86 systems so we don't have to deal with each individual boards in Android or the traditional GNU/Linuxes?

Furthermore, if the x86 emulation turns out to be as fast as they promised and demo'ed, will this kind of technology be developed for desktop linux? Is it even necessary as most apps tend to be open source and can recompile already?

I'm actually more interested in getting a standard ARMv8 laptop rather than a tablet to run Linux on it.

Windows 10 being an entry point to get these machines into the market is perfectly fine.

+1 A major issue with ARM boards is you can't expect [name-your-arm-os] to run on all ARM boards. Each implements it's own boot sequence and drivers aren't the best. Something like this might push for a unified spec.

UEFI is the boot environment for Windows on ARM

> ... as such, it will be late 2017 or sometime next year ...

Well, that could be clearer.

> Perhaps Surface phone isn’t a phone in the traditional sense. Perhaps it is, instead, just a new kind of PC with a small—for PCs; I’m hearing 6-inches—screen.

This sounds a lot like what others have been doing / try to do for a while now with Android devices (albeit not hugely successfully ... yet). So it's not surprisingly that Microsoft is considering jumping on that bandwagon.

Interesting. I must say that I'm surprised that MS didn't give up on Continuum after Intel hosed them by cancelling their Broxton smartphone x86 chip. MS might just be throwing good money after bad.

The two keys will be performance and compatibility for the x86 emulation. If they can get it to the point where it's effectively as fast as Intel's low power Atoms while still keeping broad Win32 app compatibility, then Microsoft's Continuum concept is back on track to become a game changer.

> I must say that I'm surprised that MS didn't give up on Continuum after Intel hosed them by cancelling their Broxton smartphone x86 chip. MS might just be throwing good money after bad.

Intel didn't hose Microsoft, it hosed Intel.

Microsoft was already developing for ARM so nothing changed for Microsoft. Intel stopped developing for smartphones and tablets so something changed for Intel.

Windows 10 is free on small screen devices so Microsoft didn't even lose any revenue....

>Intel didn't hose Microsoft, it hosed Intel.

I'm not sure I follow your logic. Surely you'd agree that implementing Continuum running x86 apps on Microsoft's rumored Surface Phone would have been far easier if Intel hadn't cancelled Broxton and MS had been directly able to use it as the target processor?

Not at all. The apps were being developed for Windows Runtime. You shouldn't confuse that with the old Win32 API used by traditional Windows software.

The only advantage of having an Intel processor would be for the old-style traditional apps, and if you allow those, you have all sorts of problems. They're not sandboxed like runtime apps, and you can't stop them from eating your battery. It's actually better to run them in an emulator.

>"The only advantage of having an Intel processor would be for the old-style traditional apps, and if you allow those, you have all sorts of problems."

That's precisely what MS is allowing. From Thurott's article:

"Even better, Windows 10 on ARM will supply a long-rumored feature: The ability to run 32-bit Win32/x86 desktop applications—Apple iTunes, Adobe Photoshop, Google Chrome, whatever—directly on the system, unchanged."

I suspect that MS probably would have very much preferred not to have to use emulation, which is always a tricky business, for Continuum on the Surface Phone. Curbing resource intensive apps is a vastly less complex engineering problem.

You appear to have overlooked the fact that OEMs can already make Intel-based smartphones and tablets, using Windows 10 for free. One smartphone example is the Asus ZenPhone, and there are plenty of tablets.

How many have you bought? How many has anyone bought?

> The ability to run 32-bit Win32/x86 desktop applications—Apple iTunes, Adobe Photoshop, Google Chrome, whatever—directly on the system, unchanged."

True, but they're in an emulator. Pretty sure they don't have access to the whole system, which they would on a standard Windows 10 device.

Extra info: there may be some confusion here because the above announcement is about tablets/2-in-1s/laptops NOT smartphones. The headline is (with my emphasis):

"ARM-Based Windows 10 Portable PCs!? Hell Yes!"

So if you recompile Win32 programs to run on this version of Windows 10 on ARM, they will be able to do all the (good and) bad things they can do on the x86 version....

I tried a surface pro as a replacement for an ipad, but I found it to be extremely frustrating. Beyond the bugs and blue screens, I found the battery life to be way shorter, and the surface to take a long time to wake up, not an instantaneous experience like an ipad, where you can forget it in a bag for 10h and use it straight away. More like a laptop.

Would an ARM based windows device achieve an ipad style battery life and instantaneous experience? Or is it more linked to the architecture of the system?

which version of Surface Pro? 2 / 3 / 4 ?

Thanks. I'm thinking of replacing my MBP for a Surface Pro 4.

I'd heard the battery life wasn't great but didn't know about it taking a long time to wake up.

Well, compared to a smartphone or an ipad. It's a normal wake up time for a laptop.

This is exactly what I just did and it's been great so far. The battery life isn't spectacular for todays standards, but it lasts longer than my 2012 rMBP 15" does now. Quick, light (way lighter than the MBP) and has been fun to draw on. Getting use to windows again takes a bit of time, but with the new Bash integration, my workflow is just about the same.

They mention in the article that battery life, while not in use, is one of the key advantages.

Photoshop x86 running on Windows 10 ARM https://www.neowin.net/news/watch-microsoft-shows-off-photos...

Even assuming they can hit performance targets with this, which sounds hard but not impossible, what's the major use case?

Continuum? Windows laptops with better battery life?

Most win32 software is going to suck on a touch screen, so I'm not really seeing this help them in mobile.

>"Windows laptops with better battery life?"

Not going to happen. There's a performance hit that almost certainly comes along with emulation. Battery life is likely to get worse with x86 Windows emulation on ARM.

Also, by the time Intel stopped pushing x86 in mobile devices they were producing chips that were competitive with ARM chips when it came to power draw.

> Also, by the time Intel stopped pushing x86 in mobile devices they were producing chips that were competitive with ARM chips when it came to power draw.

People forgot this. It was price that killed Intel in this space. They couldn't get the price down to ARM chips. They subsidized hard to get even close, but it ended up just costing them too much just to have even a presence.

Does your comment still stand for the cheap end of things? If Intel struggles to compete on price, then low end ARM may have better perf characteristics.

From what I read, doing binary translation from x86 to ARM is actually not that hard since ARM has many more registers, so I'm sort of hopeful they get decent perf from it.

> "If Intel struggles to compete on price, then low end ARM may have better perf characteristics."

I'd suggest it has more to do with the size of the silicon wafer rather than the performance.

Maybe, though their partnering with Qualcomm is suggestive: perhaps they're doing hardware-accelerated binary translation? That _might_ be fast and power efficient, who knows...

In any case, many users may just be wanting to run older enterprise apps, and so even then, with the translation penalty, they'll probably be quite snappy.

> "That _might_ be fast and power efficient"

My argument is that it's not going to be as power efficient as using x86 natively. There's no getting around that.

Maybe this makes sense for a better continuum experience?

Phone mode = UWP touch apps

Docked continuum = Full desktop x86 apps (and UWP)

This is one of the few things that makes sense, but as much as I liked my windows phone 7, the lack of apps was a disaster.

People have been speculating for the past year if Apple could switch their Macs to ARM, and keep compatibility with a emulation layer like they did during the PowerPC->Intel transition. I guess Microsoft beat them to the point... Will be interesting to see how well it performs in real life.

I think Linux beat them both to the point... many years ago.

No way. Linux has never had any sort of cross-architecture binary compatibility story. Certainly nothing that worked as well as Apple's Mixed Mode Manager or Rosetta.

> Linux has never had any sort of cross-architecture binary compatibility story.

You mean like qemu?

> Certainly nothing that worked as well as Apple's Mixed Mode Manager or Rosetta.

I think the parent was alluding to the fact that with GNU/Linux and/or free software in general there isn't the same kinds of requirement to get binary lumps of code running on alien architecture.

> You mean like qemu?

No.

> there isn't the same kinds of requirement to get binary lumps of code running on alien architecture.

Are you implying that this has something to do with the software being free?

In 2006, I used Time Machine to back up my G5, and then restore it onto my new Intel Core Duo (both iMacs!). The migrated apps just worked, regardless of whether they were free software or binary blobs.

This has nothing to do with software freedom. It's about having a good user experience: when your users migrate from an old machine to a new one, it just works, period.

Linux doesn't have this requirement because it prioritizes developers over end users. I'm not bashing Linux here, I use it often and appreciate it for what it is. But an honest assessment tells us it has never come close to Apple-level smoothness in architectural transitions.

Maybe he just meant that there have been arm based linux distros for quite sometime while windowsRT got canned

You sure you don't mean like qemu - that lets you run different architecture binaries.

Perhaps I have misunderstood the use of the word 'story' in your first post.

> Are you implying that this has something to do with the software being free?

No, but I am asserting that I typically don't need to run non-native code on my computers because I can obtain or generate native code for any given architecture [1] I happen to be using.

I expect that where people are beholden to others, say if they are using non-free software, to create binaries that they can use on specific pieces of hardware, then yes in that case it will have 'something to do with software being free'.

> In 2006, I used Time Machine to back up my G5, and then restore it onto my new Intel Core Duo (both iMacs!). The migrated apps just worked, regardless of whether they were free software or binary blobs.

I'm not sure I appreciate the usefulness of this feature as much as you do -- you were obliged to run that software, in both instances, on hardware available exclusively a single vendor. In that scenario I would have expected to be able to run native code on both platforms.

[1] https://www.debian.org/ports/

First off, I run Linux ARM code on x86 quite often, using qemu-system-arm and chroots.

Secondly, you only rarely need to because everything you use is in the package management system, thus compiled for the platform you are on (and against the same versions of the libs as everything else, thus only one, up to date, version of each lib and only the libs you need).

The only reason I've sometimes do qemu-system-arm and chroots is I'm a software developer often working on ARM Linux (from x86 Linux).

Third, I will also point you to: https://wiki.debian.org/Multiarch

But normally, you use a pure system. All 32bit, all 64bit or all ARM, etc etc. Closed crap can muddy your system, for instance requiring (normally old) versions of 32bit libs on a 64 bit system, but the solution to that is to not use closed crap.

Source code availability is the best cross platform compatibility story.

> I think Linux beat them both to the point... many years ago.

Nope. Windows NT was written to be cross-platform. It wasn't even developed on an x86 processor.

And NT development started at the end of the 1980s, before Linus even thought of writing his x86-specific operating system. (Because he only had x86.)

Windows NT ran on ARM? That is the platform being referenced. Not just cross-platform in general.

Initial development was on the Intel i860XR RISC processor, switching to the MIPS R3000 in late 1989, and then the Intel i386 in 1990. Later it ran on DEC Alpha, PowerPC, Itanium, x86-64 and ARM. (Wikipedia)

If you have developed a portable OS, it really doesn't matter whether ARM was first or last or inbetween.

Presumably these will all have Secure Boot enabled with no option for the user to disable it. >sigh<

If this works out, this is the final piece of the puzzle for Apple moving to ARM chips in their Macs. Windows emulation is too big of a feature to leave out. Then again, who knows with Apple of late. Either way, very interesting news!

The last time we had ARM Windows machines, we got the Surface RT. I still have one of these that I occasionally bring to meetings to fool around and maybe put a ticket in with. It is not a great piece of equipment...

It generally takes Microsoft 3 tries to get something right. Unfortunately their next ARM device will only be #2.

I'd say Windows CE on ARM devices was attempt #1.

Lumia and Surface 1 and 2 were #2.

1. Windows CE on ARM

2. Xbox 360

3. Windows Phone 7 (on leftover chunks of Windows CE) on ARM

4. Windows Phone 8/Windows RT

5. Windows 10 on ARM

So, by my count, this might be iteration 6? (Though maybe more like 5 Part 2.)

I'm thinking specifically of the Windows desktop experience on ARM, so things like phones and Xbox don't count. But I didn't realize the Surface went through 2 iterations of ARM, so maybe this counts as #3? Or maybe it doesn't count at all since it was a watered-down version of Windows that couldn't run most apps.

Xbox 360 was PowerPC, not ARM

Are you speaking just of the software or does the hardware have issues as well?

Both, in my experience. The touch screen sometimes works with the keyboard attached, and sometimes doesn't. The keyboard often doesn't work if it has been disconnected without the old-school "splatter chicken blood and livers about" kind of computermancy.

Of course, the software is a mess, because nobody has bothered to build versions for RT in years, and none of the regular x86/x64 Windows software is compatible with RT.

It's not that bad. Win 8 inside was terrible. The hardware was OK. Not a big fan of the sharp edges when holding it.

But to me the main problem was having built an iOS style environment, completely locked down, with no way to install anything unless you pay money to microsoft through the windows store (and redevelop your app). There was no technical reason to prevent regular .net apps from running directly on windows RT.

So it was a subpar experience compared to iOS without the power and flexibility of windows.

For me it is more like hell no. I am having a hard time getting over stuff like, you know, waking up one day and Chrome is no longer my default browser.

How the hell does this happen. Seriously, I've ran Windows for like over 10 years now. It's happened a grand total of 3 times, ever, and 2 of those were back in the Windows 9x days, and the last one was between W8 and 8.1 (a major service pack).

Never since then. Oh, I'm even in the fast update pool. What do you people _do_?

It happens after every Windows update. I'll log in, and have a message about the update, then see that Edge is my browser and VLC is no longer my default music player. Maybe it is because I have so many of the "features" of Windows 10 turned off? I dunno, but some people seem to not have the same experience.

> First, Qualcomm’s System on a Chip (Soc) designs have improved so dramatically in the past four years that their performance rivals that of mainstream Intel Core chipsets for PCs.

Hah!

> And even better, Microsoft has developed an emulation technology that allows Win32 applications to launch and run unmodified on ARM-based PCs. And to do so with what I am assured is excellent performance.

I don't believe it.

Not many CPU bound apps running on an ordinary laptop.

> I don't believe it.

My understanding is Microsoft actually has some pretty cool and fast tech for this already: the Xbox 360 emulation on Xbox One.

No matter how good it gets, binary recompilation will always be slower than native code. And when the host CPU is already a very slow model like Qualcomm ARM, those effects stack.

That was PPC-on-amd64 emulation. I don't know much about hardware-assisted virtualization, but I guess that was easier than x86-on-ARM64?

Why are you laughing? Last's year's Apple chip was as powerful as the chip in the Macbook Air:

https://www.extremetech.com/mobile/221881-apples-a9x-goes-he...

This year's chip is even more powerful:

http://www.theverge.com/2016/9/16/12939310/iphone-7-a10-fusi...

I'm also a bit skeptical about the emulation part, but if it's less than 10% overhead out of the gate, it should be okay, and I assume Microsoft could continue to optimize it over the years.

Apple's chip. Not Qualcomm's. That's what he/she is laughing about.

I am skeptical that the emulation can achieve reasonable speeds. I would like to see first that Qualcomm’s chips are even up to par with Intel's. Secondly, can a heavy duty Win32 app like iTunes or TurboTax or Photoshop could run reasonably fast via emulation, something that has historically been a problem.

I'll believe it when I see some benchmarks.

They are, at least with the mainstream Macbook Air-type/older Mac Pro type chips, not the latest and most expensive Core i7's, obviously. But they don't need to reach that high, either. Even taking over the Celeron/Pentium market from Intel would probably make Qualcomm bigger than AMD is in the PC chip market.

https://www.extremetech.com/mobile/221881-apples-a9x-goes-he...

http://www.theverge.com/2016/9/16/12939310/iphone-7-a10-fusi...

Call me cynical but this feels like another platform to be abandoned when no one buys them as per the old Windows ARM tablets. Those who bought them abandoned quickly.

There will probably be a crazy restriction like App Store only.

Oh and the whole MSI 32/64/ARM pile of crap as well.

Well, that would be repeating the Surface RT failure. I can only assume they are not going to make the same mistake twice, so I doubt it will be locked down like Windows RT was.

We'll see. Full Windows x86 emulation will likely be slow.

It will be a harder sell the second time around, too as Windows RT burned a lot of people, and fewer trust Microsoft than before.

This is not full x86 emulation, it only emulates x86 when you are running x86 apps. Windows/Office and other apps are running in native mode.

Nearly all of their target market would be unfamiliar with Windows RT.

It's native ARM version of Windows 10 and for UWP apps, as well as any x86 apps recompiled for ARM. The rest of the classic x86 32-bit apps will run via the emulation, like Rosetta on macOS in the past when running PPC apps on Intel.

That means unlike WinRT, almost all of your apps will be usable, no confusion about it like what befell the WindowsRT.

I'd assume the .net framework would run natively

Doesn't seem like any reason that it wouldn't be native.

Agree. But it is a big deal. If the CLR is ported to ARM then any c#/vb code will run very efficiently on ARM without even needing to be recompiled or making use of the x86 emulation. That's a big deal for a corporate environment.

I just have a tough time imagining that Microsoft wouldn't (or hasn't given RT) the CLR to ARM. It would be news if it wasn't ported.

It has been, I'm running one such example on my Raspberry Pi 2 right now. It's just a DynDNS updater. Written in UWP.

I have tried it in CLR and native (machine code via .NET Native) modes. Both work great.

I'm pretty sure my Pi runs on an ARM chip, anyway

An interesting development, but it is a shame that this will require a new chip from Qualcomm, while there have been full desktop Linux distributions for several ARM chips and boards for quite a while now. Microsoft's software is really full of bloat.

It probably doesn't require the chip... I'm thinking they are using some form of hardware accelerated binary translation.

Re: Windows on ARM, I run Windows IoT on a Raspberry Pi. Shows they have a good lot of it running, eg the full UWP UI system, kernel etc. Imagine it's the translation part that's deleted things.

Reply on news.ycombinator.com