Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Emulation (Games) Microsoft Software Windows

Windows 10 On ARM Will Support x86 Apps From Outside the Store (liliputing.com) 115

Posted by BeauHD from the emulation-at-its-finest dept.
An anonymous reader quotes a report from Liliputing: First announced last year, Microsoft provided an update on Windows 10 ARM at the MS Build developer conference today. And the company confirmed that not only would Windows 10 ARM be able to run legacy apps developed for computers with x86 processors but you'd be able to just download any old Win32 app from the internet, install it, and run it on a computer running Windows 10 ARM. In other words, Windows 10 S runs on devices with ARM or x86 processors, but only supports Windows Store apps. Windows 10 ARM only runs on devices with ARM chips... but supports apps from pretty much any source. Developers don't need to convert their software in any way, because Windows 10 ARM includes a built-in emulation layer that allows Win32 apps to run on an ARM-powered system. But Microsoft demonstrated how you could download a common program like 7zip from the internet and simply install it on a device with a Qualcomm Snapdragon 835 processor. Of course, developers can also package software optimized for ARM as Universal Windows Platform apps for distribution in the Windows Store. But they don't necessarily have to.
This discussion has been archived. No new comments can be posted.

Windows 10 On ARM Will Support x86 Apps From Outside the Store More

Windows 10 On ARM Will Support x86 Apps From Outside the Store

Comments Filter:

  • So much for "one Windows"... (Score:2, Insightful)

    by Anonymous Coward

    The Windows 10 nightmare continues. I haven't read one single good news about that damn OS ever since it was released. Prior to it, everyone was saying how it was finally gonna bring back the real Windows, but what we got was pure sadism in software form. And it keeps changing around. It's surreal.

    • Re: (Score:3, Funny)

      by roc97007 ( 608802 )

      Ok, here. Read one single good news about that damned OS:

      It's better than Windows 8.

    • Re:So much for "one Windows"... (Score:4, Informative)

      by ArhcAngel ( 247594 ) on Thursday May 11, 2017 @09:08PM (#54403403)
      Well they screwed up by giving it an even number. Everyone knows only the odd numbered Windows are any good.

    • It sounds like you've never used it. I run it on my gaming rig because, games. It's not bad at all. Far better than Win 8.x and I'd also go so far as to say better than XP or 7.

      • Re: (Score:1)

        by Anonymous Coward

        So it's an excellent Toy OS?

        sad.

    • run legacy apps developed for computers with x86 processors

      To understand this sort of stuff you need to translate it from Redmond Newspeak. In this case they're referring to "mainstream apps that everyone uses every day". Contrast with "Windows 10 ARM apps that will be as popular and wildly successful as Windows RT ARM apps were".

    • Re:So much for "one Windows"... (Score:4, Funny)

      by Immerman ( 2627577 ) on Friday May 12, 2017 @02:54AM (#54404299)

      >what we got was pure sadism in software form.

      Exactly! It brought back the real Windows!

  • So, W10ARM runs on ARM and runs ARM and Win32 apps from anywhere; mobile devices have a dock for large screen, kb & mouse; and ARM devices are pretty much mobile phones and tablets.
    Is this the converged device businesses have been looking for?
    I'm in software licence management, so converging devices can simplify management effort considerably...

    • I'd say only if it runs native ARM apps and has an unlockable bootloader so you can install third party security software.

    • Re: (Score:1)

      by Anonymous Coward

      This is a mistake.

      Allowing x86 apps to run on ARM means you get all the x86 malware. Whatever software emualation is invoked is also going to be WORSE than the PPC to x86 rosetta that Apple had. Rosetta basically ran PPC software at 25% the performance of cross-compiled software. x86 to ARM is likely on the factor of 12. ARM to x86 is already about 8-12X slower.

      Like, the smart thing would be for x86-64 hardware to have an FPGA core that can be reprogrammed as ARM or reprogrammed as h.264/h.265/whatever oth

      • Re:Is this it? (Score:4, Interesting)

        by K. S. Kyosuke ( 729550 ) on Friday May 12, 2017 @04:44AM (#54404543)

        Whatever software emualation is invoked is also going to be WORSE than the PPC to x86 rosetta that Apple had.

        ...why? Because dynamic translation technology is getting worse in time? Unlike compilers in general? For what reason would that be?

        • Re: (Score:2)

          by Megane ( 129182 )
          Not to mention that the whole point of emulating apps for the same OS with a different instruction set is that most of the time is taken up inside the OS and its libraries anyhow. If 5% of your time is spent running at 25% of the speed, you don't lose much.

        • Re: (Score:3)

          by c ( 8461 )

          ...why? Because dynamic translation technology is getting worse in time?

          I'd imagine it's got to do more with the relative performance difference between the two architectures. x86 emulating PPC worked because the x86's they were shipping were more powerful than the PPC's they replaced. Ditto for the PPC's emulating 68k. x86 emulates ARM without breaking a sweat.

          ARM trying to handle the x86 instruction set... yes, it can be done, but whether it can be done well or run enough of the Windows application ecosys

          • The x86s were not massively faster than the PPCs. They were somewhat faster.

            ARM trying to handle the x86 instruction set... yes, it can be done, but whether it can be done well or run enough of the Windows application ecosystem to be worthwhile/marketable is questionable.

            It doesn't matter for a lot of legacy applications of interest. They used to be run at much slower PCs anyway.

  • 1 step forward, 2 steps back (Score:3, Insightful)

    by marcle ( 1575627 ) on Thursday May 11, 2017 @07:24PM (#54402985)

    Advances in interoperability, but still a horror show in privacy or autonomy.

  • Wow, Deja-Fu. (Score:2, Insightful)

    by roc97007 ( 608802 )

    ...that's like Deja-Vu, but what you're remembering was getting kicked in the head some time ago.

    ...I remember an IBM salescreature, telling me sometime in the nineties about an upcoming operating system that would run AIX or MacOS binaries, interchangably, on either the RS6000 or Mac platform. And they weren't even talking (at the time) about running on different architectures.

    On the other hand, virtualization has made giant strides since then, and Microsoft has needed for some time a viable presence in

    • Re: (Score:2)

      by DaHat ( 247651 )

      I remember those sales pitches too, though they weren't talking virtualization, only a common hardware platform to rule/replace them all which each os had to target and bring full support for: https://en.wikipedia.org/wiki/... [wikipedia.org]

      This new world of virtualization all the things is certainly going to create some fun debugging problems in the future, assuming anyone cares to run multiple levels on top of each other in another decade.

      • I think it's already happening. There's already people running apps in a sandbox inside a virtual container that's running inside another sandbox running on a vmware server instance. They're talking about an app that'll magically set all of that up. I wonder if we'll see bugs that cause infinite recursion, like two mirrors reflecting each other.

        • Re: (Score:2)

          by swb ( 14022 )

          I had a conversation just the other day with someone who has managed to automate deployment of an entire VMware cluster as nested virtual machines on VMware.

          We've considered nested virtualization at work for both production and proof of concept and demonstration where the actual physical hardware is irrelevant or where we'd prefer to keep the top level hardware/virtualization config in a given state for other purposes.

          As an experiment, I built a 4 node vSAN cluster as a single VM (nested virtualization). I

  • MacOS redux (Score:3)

    by mnmn ( 145599 ) on Thursday May 11, 2017 @07:43PM (#54403041) Homepage
    Reminds me of MacOS emulation for powerpc/m68k. Sounds good in theory but becomes extremely slow in practice.

    This is not just emulating API calls like Wine or containing supervisor mode like most virtualization systems, this is machine language translation on the fly (mame).

    Binary translation has always been slow and unreliable, with the sole exception of arcade games in mame.

    Now if they were trying to emulate ARM on Intel, that would be much more interesting, especially if Intel got involved and provided microcode to directly run ARM machine code..... can't do that in ARM.

    • Re: (Score:2)

      by imgod2u ( 812837 )

      I would imagine the vast majority of software downloaded for Win32 isn't very demanding performance wise. The only major exception to that statement I can think of is Chrome. Which probably won't offer a Windows universal app and also be very resource intensive.

      Then again, Microsoft is actively trying to push people away from Chrome and onto Edge so from their perspective, it's a non-issue.

      Professional apps that are performance intensive but not ported to ARM usually have very regular and non-exotic instruc

      • The 90s called. DEC would like a word w/ you re: Windows NT running win32 applications on the Alpha
      • Comment removed based on user account deletion

        • Re: (Score:2)

          by caseih ( 160668 )

          Think you're confused about the "win32" moniker. When people say "win32" that's shorthand for traditional Windows apps, using the traditional Win32 API, be they 64-bit or 32-bit, written in C++, compiled to a PE executable. The term has nothing to do with being only 32-bit. There is no Win64. It's just Win32, and there are 32-bit and 64-bit flavors. I'm sure many games probably are full 64-bit now.

          Chrome is now 64-bit only, but it's a traditional app built on the Win32 api.

          I'm not sure if this emulation

          • Chrome on x86 is not yet 64 bit only, and won't be for some time - there are still too many machines running the 32 bit version of Windows. What changed recently is that they automatically install the 64 bit version on compatible systems, rather than people specifically having to download it, and have also started to offer to upgrade installations of 32-bit Chrome to the 64 bit version. It probably won't be long until they REQUIRE the upgrade to 64 bit on 64 bit Windows and only allow you to run the 32 bit

      • Re: (Score:3)

        by jonwil ( 467024 )

        Clearly you are not a video gamer if you think the "vast majority" of win32 software isn't demanding performance wise.
        Good luck writing a translation later, emulator, dynamic recompiler or other technology that can run, say, Fallout 4 on a W10ARM device. Or even something older or less resource demanding like Red Alert 3.

    • Reminds me of MacOS emulation for powerpc/m68k. Sounds good in theory but becomes extremely slow in practice. This is not just emulating API calls like Wine or containing supervisor mode like most virtualization systems, this is machine language translation on the fly (mame). Binary translation has always been slow and unreliable, with the sole exception of arcade games in mame. Now if they were trying to emulate ARM on Intel, that would be much more interesting, especially if Intel got involved and provided microcode to directly run ARM machine code..... can't do that in ARM.

      MacOS emulation was a temporary solution, while Apple's engineers continued porting as much of the OS as possible to PowerPC. It was never something meant to last forever. And once OS-X was out (before the 'next' (pun intended) migration to x86), PowerMacs had their completely native OS.

      That's different from this saga. We had Windows RT, which ran only native apps. Unfortunately, Microsoft never allowed developers to make apps available for this platform outside their Windows Store, which was why it

      • Re: (Score:2)

        by xvan ( 2935999 )
        The price difference for low end devices is huge between ARM and Intel. The cheapest android tablet is less than half the price the cheapest windows tablet.
        • That's b'cos the typical x64 configuration has several times more memory, CPU, storage than the typical ARM configuration.

      • The best example of how emulation works w/ Windows can be seen w/ Windows NT on RISC, such as the Alpha or the MIPS. DEC had fx!32, which was supposed to emulate and dynamically translate software, making things faster every time they were run. But emulation just sapped the legendary performance of the Alpha. Had Microsoft seriously supported Windows NT on RISC in the 90s, they'd have had not just an OS as portable as Linux or NetBSD, but also a 64 bit OS long before x64 came along.

        fx!32 didn't just dynamically translate, it also cached bits of native code translations for subsequent runs. We had some alphas on demo at the time and they were beautiful machines, didn't notice much, if any, performance hit from fx!32 - in fact I think we stopped bothering to recompile our applications and just ran the x86 versions because there was no benefit in it.

        The real problem was that Alpha (sadly) failed as a platform. The issue has never been that MS doesn't have a portable OS, the issue has a

    • Now if they were trying to emulate ARM on Intel, that would be much more interesting, especially if Intel got involved and provided microcode to directly run ARM machine code..... can't do that in ARM.

      Seems to me like what's really wanted here is a system with both x86 and ARM processors in the same box, whether they're on the same chip or not. I can imagine power saving advantages to either approach, and don't really know which would actually be lower-power (x86 and ARM in the same CPU package, or not.) The ARM stuff should be a cost afterthought compared to x86, especially if it's integrated either into the CPU or into the NB.

      • Re: (Score:2)

        by sad_ ( 7868 )

        Seems to me like what's really wanted here is a system with both x86 and ARM processors in the same box

        I think Apple is working towards this, their main OS will be iOS and the x86 CPU will be something similar to a 'high performance' CPU in the system you can offload certain tasks to, much like you can do now with your GPU.

    • Re: (Score:2)

      by gwolf ( 26339 )

      Reminds me of MacOS emulation for powerpc/m68k. Sounds good in theory but becomes extremely slow in practice.

      This is not just emulating API calls like Wine or containing supervisor mode like most virtualization systems, this is machine language translation on the fly (mame).

      Worse than slow. At least, the reason to migrate from m68k to Power was better performance, and a cleaner architecture for the future of the platform. And while ARM is much cleaner than Intel... The fastest ARMs now are way slower than their x86 counterparts — And that won't change, because they were _designed_ to be so. ARM is a clean-RISC architecture, oriented to low electrical consumption (and low heat dissipation). Not intended to be a match performance-wise for x86 behemoths.

    • Re: (Score:1)

      by qaz123 ( 2841887 )
      They can translate it once, then reuse the result. How is it different than compiling from other languages or bytecodes? You take the program written in the language that is not understood by the processor and translate it to the language that is understood by the processor. (Of course I understand that not all software can be translated like that)
    • Modern binary translation is very fast. MAMBO, for example, translates AArch32 to AArch64 and performs better than native on the same chip. The main problem is that it consumes extra RAM. The approach taken by Transitive Technologies (which Apple licensed and branded as Rosetta) involves generating small trampolines to allow calling native code. Rosetta's emulation wasn't very good in comparison to the state of the art, but it didn't matter because most desktop apps spend 50-90% of their CPU time in sys

      • I had around 2004 a 17" PowerBook, running Mac OS X 10.4 (Panther).
        I played Diablo on it, not sure if it was Diablo II, that was an 68k game running under Rosetta.
        I did not notice any performance problems.

    • Re: (Score:2)

      by Megane ( 129182 )
      The reason the original PowerPC transition had such bad performance was that 7.5.x (and I think 8.x as well) still had most of the OS written in 68K code. Microsoft has been doing the ARM thing long enough that they don't have legacy binaries to deal with.

    • The Common Intermediate Language is an ISA [wikipedia.org]. For certain common operations, CIL is faster than C++; for others, it's been variable across runtime versions. Linked list and array iterations are one area that gets batted back and forth, with various implementations shown faster in C++ or in C#. Some problems are just faster to solve in C# than C++ because the runtime profiling in the CLR constantly adjusts the expected likely branch in a loop or whatnot, and so it keeps tweaking itself to run as fast as po

    • Re: (Score:2)

      by Jeremi ( 14640 )

      Binary translation has always been slow and unreliable, with the sole exception of arcade games in mame.

      Hmm, I always thought Apple's Rosetta (PowerPC->x86) translator did a very good job. I'm not sure what their secret sauce was -- maybe it was just that Intel chips at the time were sufficiently faster than PowerPC chips that any program that ran well on PowerPC would also run well on a faster Intel chip, even with the translation overhead.

  • Having been through the OSX transition from PPC to x86 this sounds very much like they've bought in Transitive's technology to allow them to dynamically recompile x86 native applications (I refuse to call them 'apps') to run on ARM. Apple handled this pretty well and there was very little that didn't work. We lost MacOS9 support, but we gained performance for native applications and PPC binaries actually ran surprisingly well if they were mostly GUI based. I did compile a few command line tools and run them

  • I give you half a clap, for being too late at adding this in Windows RT and basically everything Microsoft did to chase Google/Apple in the mobile ecosystem.

    Part of the reason Windows 7 became the successor to windows xp and windows vista is the "xp mode". A VM designed to be well integrated lay for previous software compatibility.

    This ARM emulator layer might not be prefect or even fully feasible, but it should be good enough to actually put consumers on ARM windows. It will also retain some windows devel

  • I'm wondering how software with in-process code generation (such as LuaJIT, Smalltalk VMs, Lisps etc.) is going to fare.

  • Got to start somewhere (Score:5, Insightful)

    by mccalli ( 323026 ) on Friday May 12, 2017 @02:52AM (#54404295) Homepage
    This is a good thing. Like the 68k->PowerPC, and then the PowerPC->Intel transition - you've got to start somewhere, or you're stuck on one architecture forever.

    I see the negativity in many of the posts. I don't understand it. You have to make a start somehow, and this is a good one. If you then allow cross compilation in Visual Studio, then you're essentially taking the same approach Apple did to manage its transitions, and those transitions were damned near seamless. Thanks Microsoft for trying to move and do something different. And yes, I really mean that.

    • Yea soon we will be able to get rid of this old ARM crap and get everything on a propper x86 architecture.

  • Windows 10 becoming splintered (Score:1)

    by Anonymous Coward

    Microsoft seems determined to splinter Windows into multiple versions with variable types of app support. Its going to seriously confuse the average user. I do not know what choice many will have to move beyond Windows, but I am certain this is a opportunity for other operating systems to take advantage. At this point, if I am going to be locked into a wall garden I think I will choose Apple or Google over Microsoft.

  • I wish all modern OS's would do this. There is a lot of legacy software out there that we still need and far more that would just be nice to have access to such as children's educational software that was never remade for the new OSs. Right now a lot of businesses, and families, end up having to maintain old computers to access that older software, some of which is mission critical. The modern hardware has plenty of computing power to do the emulation and modern security methods means it can be sandboxed to

    • Backwards compatibility for software is easy. Backwards compatibility for hardware is not so easy. Often, we have to maintain old computers to access old hardware.

      • Re: (Score:2)

        by pubwvj ( 1045960 )

        Correct. And having the new OS's support legacy software would solve more than half the problem. In my experience the legacy software problem is larger than the legacy hardware problem. It would be great to have both but as you point out, the software end is easier. There is no good excuse for Apple and Microsoft creating this problem.

  • and Chromebooks aren't quite giving it.

Slashdot Top Deals

Life is a whim of several billion cells to be you for a while.

Close