Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Windows Microsoft

Microsoft's x86 on ARM64 Emulation: A Windows 10 Redstone 3 Fall 2017 Feature (zdnet.com) 123

Posted by msmash from the emulation-love dept.
Mary Jo Foley, reporting for ZDNet:Since January 2016 (and maybe before), there's been talk that Microsoft was working on bringing x86 emulation to ARM processors. Sources of mine are now saying that this capability is coming to Windows 10, though not until "Redstone 3" in the Fall of 2017. Here's why this matters: Microsoft officials continue to claim that Continuum -- the capability that will allow Windows 10 Mobile devices to connect to external displays and keyboards -- is going to be a key for the company, its partners and its customers. There's been one very big limitation to Continuum so far, however: It only allows users to run Universal Windows Platform (UWP), and not full-fledged x86 apps. What if an ARM64-based device could run x86 apps via emulation, the same way that the WOW (Windows on Windows) emulator allowed 32-bit apps to run on 64-bit Windows? That would make Windows 10 Mobile, which as of now, continues to support ARM only, and Continuum a lot more interesting, especially to business users who need certain Win32/line-of-business apps.
This discussion has been archived. No new comments can be posted.

Microsoft's x86 on ARM64 Emulation: A Windows 10 Redstone 3 Fall 2017 Feature More

Microsoft's x86 on ARM64 Emulation: A Windows 10 Redstone 3 Fall 2017 Feature

Comments Filter:
  • I hope they don't cripple it like they did Windows RT. People ported some desktop applications to the ARM architecture, but it wouldn't run any applications not signed by Microsoft.

    • Re: (Score:2, Insightful)

      by Dunbal ( 464142 ) *
      This is Microsoft. Crippling it is part of the plan.

    • Re: (Score:2)

      by Rob Y. ( 110975 )

      If they're planning to let you run arbitrary win32 exe's on ARM, why don't they just provide you with the tools to port your win32 exe instead of relying on X86 emulation? Or do they think their emulator works as a sandbox to mitigate the security issues in win32 code?

  • Why Stop There? (Score:3, Funny)

    by Bruce Perens ( 3872 ) <bruce@perens.com> on Monday November 21, 2016 @01:09PM (#53332953) Homepage Journal

    Rather than just provide x86 emulation on ARM, we can use x86 emulation on ARM to run Oracle's x86 Java implementation. We can run the jRuby interpreter in that. And we can use jRuby to run this ATARI 2600 emulator [github.com].

    I bet a lot of you folks can suggest a more absurd one than that.

  • fallacy, poindexter (Score:3)

    by iggymanz ( 596061 ) on Monday November 21, 2016 @01:10PM (#53332963)

    emulation of x86 for apps not sufficient, that doesn't make drivers work.

  • FX!32 on WinNT Alpha (Score:1)

    by Anonymous Coward

    Microsoft had the same basic thing on Windows NT 4 for Alpha. It had the FX!32 x86 emulator. IIRC it was a dynamic recompiler that saved off the recompiled code for faster operation the next time the app was run. Doesn't .Net also do this?

    • it worked, but it was primarily a DEC effort, not an MS one. DEC did the heavy lifting in cooperation with MS in an effort to get mainstream adoption of Alpha processors.

    • From what I recall, it was a bit different. It intercepted x86 win32 system calls, substituted them w/ Alpha win32 system calls, and the rest of the stuff was the raw x86 to Alpha translations. Sun used a similar concept in Wabi emulation of Windows on their SunOS workstations

      This one seems to be purely a raw translation of x86 to ARM, since the goal here is to support legacy Windows applications (written for XP, 7) on Windows 10 Mobile.

    • Re: (Score:1)

      by movdqa ( 1122661 )
      I ran this on an Alphastation 400 while working at DEC. FX!32 did on-the-fly code translation (no compilation as there was no source code involved) but it would store the translation for use later on if you ran the code (executable, shared libraries) again. You could also schedule translation to run when you weren't using the system so it would go around translating your applications without any performance penalties when you were around. It worked but I ran into crashes with some applications and updated

      • The Alpha CPU wasn't slow, even for then, but what was different then was that multiprocessing and multithreading applications weren't common, especially as mainstream Windows at the time was Windows 98, which didn't support SMP. That coupled w/ the fact that uniprocessing Alphastations and Alphaservers were expensive enough that Alpha based SMP workstations were out of the question.

        What changed was after Windows XP merged the codebases of both 2000 and ME, mainstream Windows supported SMP. Intel took a

        • Re: (Score:1)

          by movdqa ( 1122661 )
          I said that CPUs back then were pretty slow; not specifically Alpha CPUs. We did development work on NT, Unix and VMS on AlphaServer 8000 series. We did some work on some pretty early development hardware too. Our software was supported multiprocessing and clustering from the mid-1980s (might be the late 1980s - it was a long time ago) on the VAX 6000 series systems. I just used the Alphaserver to connect into the appropriate system or cluster to do development on. I do not recall when we added multithreadi

        • The Alpha CPU wasn't slow, even for then,

          The Alpha was not slow for then, but by modern standards the 400MHz Alphas that were common in Windows NT Alpha machines are slow: my low-end smartphone is faster. The speed of the Alpha was part of the reason FX32! worked so well: a typical Alpha was about twice the speed of the fastet processor Intel sold, so even paying a pretty high emulation penalty let you run things very fast.

          This isn't the case with ARM, and especially the kinds of ARM cores that you're likely to find in mobile devices. They're n

  • ... that you had enough memory in your phone.

    • Did you ever hear of the x86 emulator which exists for ARM since July 1987?

      1988 Review in PCW [computinghistory.org.uk]

      1991 Edition of the manual [computinghistory.org.uk]
  • Only one more year to wait to see how well, or poorly. x86 programs run on Windows Mobile devices. The problem will be that, I presume, that only 0.1 percent of Windows Mobile will have the horsepower to actually make this a useful thing to do. Looks to me like a Surface Phone could come out at the end of 2017 that will do the job with outstanding hardware, a high price, and will sell very well. Anything else will be ignored.

    • Re: (Score:2)

      by swb ( 14022 )

      Is there anything about this better than an RDP solution now?

      Or are they holding back on the external KVM part of the solution until they can run x86 binaries? I would think with external KVM and an RDP app would be all you would need in a corporate context to run RDP apps.

      I have a hard time seeing emulated x86 running well, especially in mobile phone hardware footprints.

      • Is there anything about this better than an RDP solution now?

        You mean other than not having to pay hundreds of dollars per year to a cellular carrier for a data plan so that you can run RDP while riding the city bus or otherwise out of range of Wi-Fi?

        • Re: (Score:2)

          by swb ( 14022 )

          I'm guessing the use of an external KVM eliminates that kind of mobile phone use scenario, unless you carry a KVM setup on the bus with you.

    • I recently made the move to Android myself.

      Funny thing is, since that time, I have been more interested in looking to see what other people are using and I have seen more Windows Mobile devices in people's hands than I would have thought. My rough estimate is 1-2% of the people I have seen on public transportation have Windows Mobile devices.

    • Not sure it would require a lot of resources if you run e.g. an average 15-year-old Windows application. Back then PC came out with 128MB RAM, I also had one with 80MB RAM (Windows 98SE) which I upgraded a bit and wow the most ridiculous thing is we could do everything back then we can do today (web browsing, IM, playing movies and music on the computer, video games). Well, there was MSN chat and the video games were better.

    • Only one more year to wait to see how well, or poorly. x86 programs run on Windows Mobile devices. The problem will be that, I presume, that only 0.1 percent of Windows Mobile will have the horsepower to actually make this a useful thing to do. Looks to me like a Surface Phone could come out at the end of 2017 that will do the job with outstanding hardware, a high price, and will sell very well. Anything else will be ignored.

      As someone who owns a Lumia 550 - the low end of Windows 10 Mobile phones, I quite agree, even though I like the phone.

      For starters, Windows 10 Mobile already has support for Microsoft Office and Edge so I hardly see what are the desktop applications it needs to run. People don't usually use phones for content creation. If Microsoft was doing something like their erstwhile ARM based Surface, I'd see the point, but for this phone, I just don't. OneNote is particularly great on this phone.

      While Windows

  • I was worried that I wouldn't be able to play minesweeper on the new ARM processors.
    • Uh, I know you're being facetious, but actually, Minesweeper is available from their mobile app store

  • Why not Windows 10 Mobile on x86? (Score:4, Interesting)

    by LocoBurger ( 18797 ) on Monday November 21, 2016 @01:34PM (#53333181) Homepage

    Is there some reason to not go this route? It seems a lot more obvious to me; no emulation needed. Continuum on Windows 10 Mobile on x86 solves most of these problems. I think Microsoft's last best chance for Windows Mobile to be anything other than a footnote is to support corporate desktops, and x86 phones that are also a corporate workers desktop seems like something they can manage in short order. At that point, good old-fashioned Microsoft inertia takes over and plenty of people start using their work platform as their personal device as well.

    I don't see it conquering the world, but it's probably a profitable niche at least.

    • Re:Why not Windows 10 Mobile on x86? (Score:5, Interesting)

      by slew ( 2918 ) on Monday November 21, 2016 @01:47PM (#53333285)

      Is there some reason to not go this route? It seems a lot more obvious to me; no emulation needed. Continuum on Windows 10 Mobile on x86 solves most of these problems. I think Microsoft's last best chance for Windows Mobile to be anything other than a footnote is to support corporate desktops, and x86 phones that are also a corporate workers desktop seems like something they can manage in short order. At that point, good old-fashioned Microsoft inertia takes over and plenty of people start using their work platform as their personal device as well.

      I don't see it conquering the world, but it's probably a profitable niche at least.

      Since Intel gave up on mobile [recode.net] (and AMD never was on mobile and doesn't have the money to invest in this anyhow), going forward, why would anyone attempt to build an phone with x86 hardware? How could it possibly be a profitable niche?

      You just have to face the facts, on mobile, it's ARM or nothing for the forseeable future...

      • I think MIPS has a fair chance in the market as well, but you are right that x86 won't cut it

        • Re: (Score:2)

          by slew ( 2918 )

          I think MIPS has a fair chance in the market as well, but you are right that x86 won't cut it

          Imagination Technologies purchased MIPS for only $60M and attempted to entice SoC manufacturers to use their cores for mobile. But mobile never played out for them and the company started losing money with that strategy so now Imagination is also retreating to the embedded space [fool.com] from mobile like Intel. So we are back to ARM being the only realistic choice.

        • MIPS is a horrible ISA (and I say this as someone who works on a MIPS compiler). Branch delay slots haven't made much sense since pipelines grew to be longer than three stages (and the branch likely instructions with their delay slots that are only used sometimes are a pain to model). The lack of complex addressing modes makes low-power designs hard (putting an add and a shift into your load pipeline is cheap, adding an extra instruction or two for every load or store is not). The ABIs are all horrible;

    • Because Intel's mobile SOCs are getting into budget devices and little else.

      None of the phone vendors has much interest in moving away from ARM, and Microsoft isn't big enough in mobile to make them do it.

      So, Microsoft can either play nice with ARM hardware or wither further into irrelevance (in the mobile market).

      Most workstations have ample CPU power to emulate ARM apps---it makes sense to extend cross-platform support in this manner rather than trying to shoehorn a new ISA into a market where they have m

      • Re: (Score:2)

        by slew ( 2918 )

        Because Intel's mobile SOCs are getting into budget devices and little else.

        None of the phone vendors has much interest in moving away from ARM, and Microsoft isn't big enough in mobile to make them do it.

        So, Microsoft can either play nice with ARM hardware or wither further into irrelevance (in the mobile market).

        Most workstations have ample CPU power to emulate ARM apps---it makes sense to extend cross-platform support in this manner rather than trying to shoehorn a new ISA into a market where they have minimal presence.

        To this day, Windows has a hardware abstraction layer below the kernel from back when they wanted to run on Alpha CPUs. Native ARM support is possible if they ever decide it's worthwhile.

        Microsoft already decided to pull the lever on native ARM support as this was required to make Windows RT (which ran on ARM SoCs). In addition to the windows kernel, Office** on RT was a native ARM app that used the WinAPI. However, in typical Microsoft fashion, they decided it was only worthwhile to support native ARM for their own apps (after allowing others to beta this feature, they turned it off support for non Microsoft ARM-apps in the production release of RT).

        **apparently visual basic was too hard

    • Re: (Score:2)

      by Kjella ( 173770 )

      Why not Windows 10 Mobile on x86?

      I bet they wanted to, they must have known Windows RT was a bad deal but it took them quite a while to get an Intel CPU in a non-"pro" tablet. With Intel cancelling their Broxton SoC in April, I don't think there's any suitable x86 hardware platform in production or on the roadmap. And with Qualcomm announcing the Snapdragon 835 on 10nm any process lead Intel had is caught up and possibly overtaken and Android/iPhone owns the market so Intel bailed. So now Microsoft has to bet on ARM and the unified windows

    • If you did have a phone made of x86, how exactly would that salvage the Windows Mobile platform? As it is, the current ARM based Lumias do run Microsoft Office: you can see and even edit the Word document or Excel spreadsheet that you created on the laptop (assuming it's either stored on OneDrive or transferred to your phone). In fact, the phone is great w/ OneNote: I've used it for things like Shopping lists, travel plans and so on.

      The main shortcomings of this platform is that in the US, they often

      • Re: (Score:1)

        by jezwel ( 2451108 )
        The idea is that x86 mobile with Continuum would allow single device convergence, though it could cannibalise existing Windows OS licensing & SA in the enterprise. There has been a movement towards Windows user licensing, so theoretically an x86 mobile phone that hooks up to an enterprise domain could require Windows SA and retain that income stream for MS. Would need a good dock for external monitors & peripherals. Useful also if they have voice smart switching between 4G, wifi, and ethernet via d

  • I can't even get qemu to emulate a raspberry pi faster than the pi itself on a Core i7 processor. I don't suppose going the other direction would work any better.

  • I remember way back when, when Apple shifted Macs from 68000-based processors to the Power PC. Instantly, the fastest 68000-based Mac was the 68000 emulation mode of the Power PC. And native was faster still.

    • Re: (Score:2)

      by Bert64 ( 520050 )

      Native apps were faster, but apps under emulation were always pretty slow, especially on the early ppc models.
      The fastest 68k based mac was actually an amiga with a 68060 processor (apple never moved beyond the 68040) running an emulator.

    • Re: (Score:2)

      by Agripa ( 139780 )

      I remember way back when, when Apple shifted Macs from 68000-based processors to the Power PC. Instantly, the fastest 68000-based Mac was the 68000 emulation mode of the Power PC. And native was faster still.

      As with a lot of semiconductor products they produced, Motorola did not make the effort necessary to compete using the later 68k processors so it is not surprising that emulation on a faster processor would yield good results. To be fair to Motorola, the 68k ISA was even less friendly to high performance designs than x86.

  • Is there much need for this, even in the corporate world?

    I think what's much more useful in the corporate world is screencasting, so that the screen is essentially agnostic and you can project any video source on it, not be limited to x86 phone apps. That way if you want to use a windows mobile app with attachable keyboard, that's fine. If on the other hand you use an iPhone or Android app, it will still work just fine.

    Microsoft has to face facts: They've lost the mobile market and have to create standard

  • Normaly, the less powerfull architecture is virtualized/emulated in the more powerful one.

    That's why you could run (whay back when) X86 on alpha, but not the other way around.

    If we asume ARM64 in Mobiles, X86 in Workstations, Desktops and Laptops, and a mix of both in tablets, we see that ARM64 is the weaker architecture, NOT BECAUSE OF THE ARCHITECTURE ITSELF (that's open to debate), but because of thermal disipation limits and power (battery) limitations.

    Therefore, the emulation will probably be ARM64 emu

  • ...no one will buy one.
  • Continuum is a good concept - a phone that becomes a desktop. But hobbling that concept by making it only run Windows universal apps makes it still born. A good idea becomes an absolutely terrible idea. It MUST run native software or it will not take off.

    Microsoft would have been better off to choose an Intel mobile chipset and worked on this other stuff. Then when it was ready they could switch to ARM if they liked. However, chances are that even if ARM does get x86 emulation it will be terrible. It'll e

Slashdot Top Deals

"Oh what wouldn't I give to be spat at in the face..." -- a prisoner in "Life of Brian"

Close