Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM-Based Windows 10 Portable PCs? Hell Yes

thurrott.com

Post reply on HN
Print view View original

81–90 of 121 posts

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#81

Post by loeg »

taspeotis wrote: post #31
loeg wrote: post #12

> 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.

> 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.

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#82

Post by Jedd »

millstone wrote: post #75
Jedd wrote: post #74

Earlier quoted context omitted.

> 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 no…

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/

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#83

Post by jabjoe »

millstone wrote: post #72
eikenberry wrote: post #70

Earlier quoted context omitted.

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.

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.

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#84

Post by jabjoe »

ZenoArrow wrote: post #35
Eridrus wrote: post #26

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.

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#85

Post by cm2187 »

protomyth wrote: post #45
cm2187 wrote: post #18

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.

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#86

Post by SyneRyder »

ac29 wrote: post #65
nikanj wrote: post #63

Earlier quoted context omitted.

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

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.)

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#87

Post by skrebbel »

felixrieseberg wrote: post #42
skrebbel wrote: post #38

Earlier quoted context omitted.

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?

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#88

Post by Eridrus »

ZenoArrow wrote: post #35
Eridrus wrote: post #26

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.

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.

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#89

Post by Eridrus »

Splines wrote: post #41
Eridrus wrote: post #26

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.

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.

Re: ARM-Based Windows 10 Portable PCs? Hell Yes

#90

Post by witty_username »

rossy wrote: post #62
skrebbel wrote: post #19

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, c…

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 th…

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