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

 



Forgot your password?
typodupeerror
×
Operating Systems Desktops (Apple) Windows Linux

Parallels Can Now Run x86 Windows and Linux On Apple Silicon Mac (howtogeek.com) 52

Parallels Desktop now supports running 64-bit x86 operating systems on Apple Silicon Macs through its proprietary emulation engine, enabling users to run traditional Windows and Linux distributions. However, performance is said to be "really slow." How-To Geek reports: The latest Parallels Desktop 20.2 update adds early support for x86 emulation on Apple Silicon, allowing traditional x86 PC operating systems to work on newer Mac computers. There were already apps like UTM that could do it (most of them are based on QEMU), but this feature uses Parallels' "proprietary emulation engine" paired with Apple's built-in hypervisor. [...] Parallels on Apple Silicon can now "run existing x86_64 Windows 10, Windows 11*, Windows Server 2019/2022, and some Linux distributives with UEFI BIOS via Parallels Emulator." You can also create new Windows 10 21H2 and Windows Server 2022 virtual machines if needed.

There are some big limitations. You can only run 64-bit x86 operating systems -- sorry, FreeDOS fans -- but those 64-bit operating systems can run 32-bit applications. There's also no support for USB devices, nested virtualization (so WSL2 won't work), or the Parallels hypervisor. Performance will also be "really slow," since x86 instructions have to be translated to ARM. The company said, "Windows boot time is about 2-7 minutes, depending on your hardware. Windows operating system responsiveness is also low."

This discussion has been archived. No new comments can be posted.

Parallels Can Now Run x86 Windows and Linux On Apple Silicon Mac

Comments Filter:
  • It can run Windows apps, at least - and it can run 32-bit ones. Application launch time can be very, very slow... but, aside from the initial startup time, the apps seem to run pretty well.

    • Use the Turbo button to speed up your 32-bit apps, that's what it's there for:)
    • by dhjdhj ( 1355079 ) on Wednesday January 15, 2025 @07:05AM (#65090165)
      Meh, it looked so promising but, I tried it last year on a couple of regular windows apps and it seemed to work fine so I bought it. Found out pretty quickly that it’s not really that reliable beyond the few standard apps and a bunch of games. It failed miserably when I threw some real apps that I really needed, even after all the configuration options I tweaked wguided by their support. Given the price of Crossover, it would have been significantly cheaper to just buy an Intel NUC and access it remotely.
      • by dbialac ( 320955 )
        Crossover stopped focusing on applications and has instead focused on gaming on Linux because I think that's where they find the most sales. I stopped using it for that reason.
      • It's no different than the PowerPC days of VirtualPC and such. Any time you have to translate each and every instruction from one architecture to another, shit's gonna get slow.

        • by dhjdhj ( 1355079 )

          It's no different than the PowerPC days of VirtualPC and such. Any time you have to translate each and every instruction from one architecture to another, shit's gonna get slow.

          First of all, I was referring to the use of CodeWeaver to run Windows apps on non-Windows OS but still with Intel processor. No instruction translation involved. Secondly, in terms of translating, clearly you have not used systems like Apple's Rosetta. It does translation ahead of time (AOT) and Intel apps can run at almost native speeds on Apple Silicon. They did quite a remarkable job.

          • Could Parallels, in principle, apply Rosetta (or Rosetta-like techniques) to speed up their Windows/x86 performance on MacOS/ARM?

            • Could Parallels, in principle, apply Rosetta (or Rosetta-like techniques) to speed up their Windows/x86 performance on MacOS/ARM?

              I was wondering the same thing.

              Does Apple not allow Third-Party Apps to Call Rosetta's First-Run Cross-Compiling?

    • by ls671 ( 1122017 )

      Of course it's slow if what follows is correct:

      Not sure this is done in hypervisor mode. How could it be? How could modern Apple CPU hypervise a amd64/intel? Hypervisor mode has to be build in the CPU. qemu is slow too when emulating CPUs different than the host CPU architecture thus, without hypervisor mode on the physical CPU crunching the data. Hypervisor mode only provides gains with the same CPU architectures and are not used otherwise. It provides gains by sending instructions directly to the physical

    • Codeweavers Crossover can do nothing of the sort. You seem to not understand the difference between providing a app level compatibility layer (Crossover) and a VM hosted in a hypervisor.

      They are fundamentally different in virtually every way and the existence or capabilities of one do not in any way have any influence on the existence and capabilities of the other.

      • You apparently read only subject lines and not the posts themselves.

        • No I read the content. Maybe you imagined adding more than there was, but you didn't. What you wrote does not mean Crossover is doing what this is doing, or that it is a substitute method of achieving something.

    • by tlhIngan ( 30335 )

      It can run Windows apps, at least - and it can run 32-bit ones. Application launch time can be very, very slow... but, aside from the initial startup time, the apps seem to run pretty well.

      Wrong, Crossover (which is really a paid support version of WINE - CodeWeavers is how you can support the WINE project) only runs on x86 processors.

      What Parallels has done is nothing special, true, because even on the 68K days, we had VirtualPC that let us run DOS and Windows 3.1 on our 68K, and later on Windows XP on Pow

      • Wrong, Crossover (which is really a paid support version of WINE - CodeWeavers is how you can support the WINE project) only runs on x86 processors.

        I've been a Codeweavers subscriber for many years. On Apple Silicon Crossover currently runs via Rosetta 2. It even manages to run 32-bit apps, which Rosetta 2 does not support (apparently that was a significant engineering effort to solve).

        They have said they have a functional-but-not-yet-acceptably-fast ARM-native version of Crossover; I haven't heard anything about that recently.

        • Wrong, Crossover (which is really a paid support version of WINE - CodeWeavers is how you can support the WINE project) only runs on x86 processors.

          I've been a Codeweavers subscriber for many years. On Apple Silicon Crossover currently runs via Rosetta 2. It even manages to run 32-bit apps, which Rosetta 2 does not support (apparently that was a significant engineering effort to solve).

          They have said they have a functional-but-not-yet-acceptably-fast ARM-native version of Crossover; I haven't heard anything about that recently.

          That's promising; Rosetta 2 Rocks!

  • What does this provide that UTM/Qemu do not?
    Qemu can run 32bit operating systems, and can also emulate platforms other than amd64 (there is a demo of sparc solaris on the utm site).

    • Re: (Score:3, Interesting)

      It seems UTM will not do GPU emulation and therefore no 3D acceleration (DirectX/OpenGL) and that's the only reason i am still stuck on Parallels.

      Though i don't need games, I assume that means slower apps as most use GPU these days and parallels runs windows even faster than any win laptop i have tried (maybe snapdragon elite x will be good enough. i hope) and integrates so well into macOS that i even ditched vmware fusion.

      Anyone has recent experience with both UTM & Parallels?

      • by Bert64 ( 520050 )

        UTM has GPU support, but drivers for windows are still a work in progress. Linux should be working already.

        I'm not sure if GPU support in parallels would extend to emulated amd64 instances of windows?

  • The original Parallels would run on a PowerPC Mac and emulate x86 hardware. It also was excruciatingly slow.

    • The original Parallels would run on a PowerPC Mac and emulate x86 hardware. It also was excruciatingly slow.

      Are you sure? I only remember it doing virtualization, and this forum discussion [parallels.com] on their site suggests the same. (Maybe you're thinking of Microsoft Virtual PC?)

      • Microsoft bought VirtualPC from Connectix way back when. Previous to that, VirtualPC was specifically an x86 virtual machine hypervisor that mainly had a market for running Windows apps very slowly on MacOS.

        • Microsoft bought VirtualPC from Connectix way back when. Previous to that, VirtualPC was specifically an x86 virtual machine hypervisor that mainly had a market for running Windows apps very slowly on MacOS.

          Yeah; that's a sad story.

          Connectix was a really forward-thinking Corporation, who just happened to be ridiculously-talented PowerPC and Mac Developers. Their final Product, VirtualPC, was a bare-metal Emulation of a 486-based DOS/Windows PC. Reliable; but quite slow. . .

          But it did have this Bitchin' VM Containerization and Management System. . .

          So, Then MS came along and acquired Connectix.

          The irony of it all is that, with their Insider Knowledge of Windows (and ability to "Patch" same), Microsoft was able

      • The original Parallels would run on a PowerPC Mac and emulate x86 hardware. It also was excruciatingly slow.

        Are you sure?

        A friend ran Win9x on his PowerPC iMac G3. I'm not sure if the emulator was Parallels or not. It was slow, but it was usable for short infrequent Windows based tasks.

        • The original Parallels would run on a PowerPC Mac and emulate x86 hardware. It also was excruciatingly slow.

          Are you sure?

          A friend ran Win9x on his PowerPC iMac G3. I'm not sure if the emulator was Parallels or not. It was slow, but it was usable for short infrequent Windows based tasks.

          I used it for the typical, Windows-Trapped Embedded Dev. Toolchains. It wasn't unusable; just "stately". In-Circuit Emulation and Debugging Tools were another matter!

    • by antdude ( 79039 )

      Any virtualizations would be slow like from VMware Fusion, VirtualBox, etc. :(

  • x86 Windows and Linux Can Now Crawl in Parallels On Apple Silicon Mac.

  • supports running 64-bit x86 operating systems on Apple Silicon Macs

    Does it support Windows XP x86-64? I very much doubt this.

    (No, I didn't mean Itanium).

    • by KlomDark ( 6370 )
      Why wouldn't it? Might be some driver issues, but I don't see why it wouldn't work. Why you would want this these days, not sure, but I did run that back in the day. It was a good, but incomplete attempt to move up to 64 bit.
  • You can build a CPU in minecraft too, but it might not be super useful in the real world.

  • Wow, I can spend three times as much and get a slower way of running the apps I need. Apple is so brave, I think I just wet my pants!
    • Re:Ooohhh Boyyyy!! (Score:4, Insightful)

      by Bert64 ( 520050 ) <`moc.eeznerif.todhsals' `ta' `treb'> on Wednesday January 15, 2025 @01:13PM (#65091043) Homepage

      The point of emulation is a temporary transition mechanism until software can be ported...
      Once software is ported, native software runs extremely well on the ARM chips.

      The only ongoing use for emulation is for ancient legacy software that's no longer maintained and will never be ported. Such old software tended to run on much slower hardware anyway, so the emulation overhead doesn't cause a problem, and in some cases even the emulated system is much faster than any real hardware the original software ran on.

      • by KlomDark ( 6370 )
        What if you need to run something like (real) Visual Studio. (Not VSCode, and not that horrid abortion of Visual Studio for Mac) Or any other Windows software that don't run on a shitty Mac? What if you want to post on /. without all the extra %%%% showing up, All junk shit. Stop deluding people already.
        • by Bert64 ( 520050 )

          Windows (and visual studio) already runs natively on arm, no need to emulate amd64 for that.

      • The point of emulation is a temporary transition mechanism until software can be ported...
        Once software is ported, native software runs extremely well on the ARM chips.

        The only ongoing use for emulation is for ancient legacy software that's no longer maintained and will never be ported. Such old software tended to run on much slower hardware anyway, so the emulation overhead doesn't cause a problem, and in some cases even the emulated system is much faster than any real hardware the original software ran on.

        Very valid Point, for hardware up to the early 2000s. After that, you should be Translating; not Emulating!

    • Wow, I can spend three times as much and get a slower way of running the apps I need. Apple is so brave, I think I just wet my pants!

      Hey moron!

      This is Parallels; not Apple.

  • Base spec Apple Silicon devices don't come with enough storage to hold both MacOS and Windows, so you'll never have to worry about Windows running slowly.

  • do they emulate each instruction as they get to it? or do they JIT compile and run the pre-translated software? i'd think they'd get pretty decent performance if they JIT compiled it.... ?

    • do they emulate each instruction as they get to it? or do they JIT compile and run the pre-translated software? i'd think they'd get pretty decent performance if they JIT compiled it.... ?

      This unfortunately sounds like Emulation; not Install-Time nor First-Run-Time Translation, like Rosetta 2 does.

"You must have an IQ of at least half a million." -- Popeye

Working...