Skip to content
Thoughtful, detailed coverage of everything Apple for 31 years
and the TidBITS Content Network for Apple professionals
8 comments

Emulation, Virtualization, and Rosetta 2: A Blend of Old, New, and Yet To Come

Over the decades, Apple has managed several successful processor and operating system migrations with a combination of emulation and virtualization. Emulation lets a computer run code intended for a different CPU, like a Mac with an Intel processor running code written for a Motorola chip. Virtualization lets Apple (and other companies) keep older operating systems alive for a while, or even indefinitely, by creating a bubble in which older code can run natively, without realizing it’s not controlling a hardware computer.

Apple’s latest entrant in the emulation field is Rosetta 2, which enables Intel-based apps to run on Apple’s M1 chips. But there’s more to come that could improve the transition from Intel to Apple silicon for Mac users—like a virtualization app that would let us launch 10.15 Catalina or previous Intel-only versions of macOS, or Intel flavors of Windows, Linux, and other operating systems. What stands in the way?

Though they may seem to carry out a very similar function, there’s a wide gulf between emulation and virtualization. Apple’s limited Rosetta 2 emulator provides one of those Indiana Jones rope bridges across the chasm. Will someone build a trestle highway? Let’s explore the concepts first.

Crossing the Chasm: Emulation and Virtualization

Both emulation and virtualization let you run one or more apps or entire operating systems within a distinctly separate operating system from the one that manages the host computer—the actual computing hardware. Such an approach can give you the best of both worlds, where you can use the latest hardware and operating system while still having access to previously purchased apps that run only in unavailable machine configurations. It’s also incredibly useful for app developers and technical support staff, who often need an array of operating system versions for testing and troubleshooting.

Emulation generally works at an instruction level. Emulators usually simulate most or all of the functions of a computer processor, although they may handle only a subset of all possible instructions the real CPU can execute. When an app or operating system loads within an emulator, the emulator transforms its instructions into a version that works natively on the processor on which the emulator is running. (There are even emulators nested inside other emulators, notably in the telephone network and other long-running systems. And there are hardware emulators, including chips that can be programmed to reconfigure themselves to emulate other chips!)

Because emulation works at such a fundamental level, it can be quite slow if its host processor isn’t significantly faster than the one it imitates. Rosetta 2 has the advantage of converting Intel processor code to Apple silicon instructions on the M1 chip, which is both optimized to macOS’s needs and substantially faster than previous Intel CPUs.

Emulation can be used for serious purposes, such as allowing vital business software to keep running even as the hardware it requires becomes obsolete and unavailable. It can preserve an investment in software for individuals or globe-spanning corporations that continues to meet a need, especially when nothing newer is available at all or for a reasonable upgrade fee. It’s also a boon for computer archivists and people who love historic machines and games. The Internet Archive has early Mac emulators that let you, for example, launch the Mac version of the Oregon Trail game, and even emulators that keep Adobe Flash alive for preserved animations and interactive games. All of these emulators run in a Web browser, remarkably.

In contrast, virtualization works at a higher level. A virtualization app creates virtual machines that provide a framework to execute app or operating system code natively with the same processor that runs the host computer’s operating system. These apps or operating systems believe they are running on a bare-metal processor—they’re the proverbial “brain in a jar”—and there’s only a modest bit of overhead that makes them run more slowly in that environment.

Parallels Desktop and VMware Fusion for Intel-based Macs, for instance, are virtualization apps that rely on a hypervisor to run other Intel-based operating systems inside their virtual machines. (Parallels even offers a choice of its own hypervisor or one built by Apple, and recommends Apple’s with Big Sur.) Virtualization allows you to keep old versions of macOS alive, as well as versions of Windows, Linux, and other operating systems that use Intel x86 code, and 32-bit applications that predates the Catalina requirement for 64-bit apps in macOS. You can set up multiple virtual machines with a single app and run them side by side.

(Boot Camp, by the way, is not virtualization. Instead, it’s a way to install and boot natively into Windows on an Intel-based Mac, where Windows is the host computer’s controlling operating system.)

Hypervisors are also used in data centers and by businesses to extract the maximum value from hardware by running multiple virtual machines simultaneously in a single high-performance server. I run a virtual private server, a slice of a machine running under a hypervisor, that is nearly the same as—but far cheaper than—having my own server in a rack somewhere. If the host hardware were to die, my provider could migrate a disk-image backup onto a new host in minutes. And, realistically, many data center hardware components are designed to be hot-swappable, reducing the likelihood of downtime even further.

Apple’s solution for the transition from Intel processors to Apple silicon is to leverage emulation, albeit in a way that doesn’t offer virtualization on top. Rosetta 2 is a 64-bit Intel x86 emulator for Apple’s M-series Macs, but it’s not a full emulation environment and doesn’t support 32-bit apps. Virtualization app makers will eventually offer their apps for Apple silicon to run operating systems designed for ARM chips that are compatible with Apple’s ARM-based M1 (and putative later M-series chips). Parallels already has a Parallels Desktop beta out for M1-based Macs that allows Microsoft’s ARM-native Windows preview to run natively, as it’s compatible with Apple’s ARM implementation. (You can sign up for both the Parallels Desktop beta and the Windows Insider program that lets you download the Windows preview for free.)

To make your head explode slightly, if you run Windows for ARM within Parallels Desktop for M1, Microsoft provides an Intel emulator that can run both 32-bit and 64-bit apps written for Intel versions of Windows! (Microsoft released the 64-bit update in December 2020; the 32-bit version has been around since 2017.)

With those differences between emulation and virtualization in mind, let’s look at Apple’s path to the present and where the future might still lead in its transition to Apple silicon for all Macs.

Apple’s Emulation and Virtualization Journey

I’ve long been impressed by how effectively Apple has provided transitions across generations of its hardware and operating systems. Under Michael Spindler, Steve Jobs, and Tim Cook, Apple has been unsentimental and forward-thinking.

Apple’s timeline of emulation and virtualization looks like this, although there are a few tiny steps and extra nuances that could (and do) fill Wikipedia pages:

  • Motorola 68040 to PowerPC: Apple built a “68K” emulator to allow software written for the late-generation 68040 processor to run on PowerPC-based Macs starting in 1994 and lasting through Mac OS 9.2 in 2001.
  • Mac OS 9 to Mac OS X: Classic Mac software from Mac OS 9.04 and later ran within a virtual machine provided with Mac OS X. The “Classic environment” was available from the public beta of Mac OS X around 2000 through 10.4.11 Tiger in 2007.
  • PowerPC to Intel: The original Rosetta emulator allowed most PowerPC software to function on Intel-based Macs. It was available from 10.4.4 Tiger through 10.6.8 Snow Leopard.
  • Intel to M-series: The Rosetta 2 emulator allows most 64-bit Intel software to work on the M-series processors. Its end date hasn’t been announced, although it will likely be available for at least 3–5 years.
  • iOS/iPadOS within M-series: Arguably, the ability to run iOS and iPadOS apps within macOS on an M1-based Mac is a kind of virtualization, even though these apps seemingly run like regular macOS apps. But because they don’t use the same operating system, it’s fair to label it that way.

Rosetta 2 launches automatically behind the scenes whenever you run a 64-bit Intel Mac app. (The very first time you run such an app, you may be prompted to download and install Rosetta 2, though some people say they didn’t see that prompt.) The first time an app launches, the emulator performs a one-time translation process and caches native converted code. Subsequent launches happen faster, though the translation caching occurs again whenever you update an Intel app.

Developers can also release universal apps that contain both Intel and M1-native code in one bundle, and you can use Get Info in the Finder to force a universal app to launch with Rosetta 2. That option is useful because some developers have released universal apps that lack feature parity with their Intel versions. For instance, Adobe’s initial Photoshop for M1 release omits a few features found in the Intel implementation. You might also have apps with an extensible architecture, and plug-ins you own for those apps may not yet be M1-native.

Some companies are releasing separate Intel and M1-native versions of their apps; I noticed Zoom and Cisco WebEx automatically downloaded M1 versions of their apps on my M1-based MacBook Air, while Google Chrome lets you pick.

Parallels Desktop, and ostensibly VMware Fusion in the future, will be able to run other ARM-based operating systems natively, just as they can run Intel-based operating systems on Intel-based Macs now. That includes variants of Unix and Linux and Windows. But you won’t be able to virtualize Catalina or earlier versions of macOS because there’s no way yet to both emulate and virtualize Intel operating systems on M1-based Macs. That might change.

Beyond Rosetta 2 to Full Emulation?

By Apple’s design, Rosetta 2 doesn’t handle every feature and operation on an Intel processor: it supports only those tasks that Mac software executes within macOS. Because Apple controls the entire environment in which Mac software is designed and compiled, the company built Rosetta 2 to emulate just what it allows developers to do within that environment, which relies on a limited set of Intel CPU instructions.

In order to emulate versions of macOS prior to Big Sur, any Intel version of Windows, or other operating systems designed to run on Intel x86 chips, some group or company will have to build a processor emulator that’s resilient and complete.

That appears to be the rub. There’s no technical reason a company couldn’t create a full x86 emulator for an ARM chip. Both Apple and Microsoft have created partial ones for their respective operating systems already. Ironically, once one has created a general x86 emulator, it wouldn’t be much harder to allow pre-Catalina versions of macOS so you could run 32-bit apps, letting you carry on using these older apps in a combination of emulation and virtualization on an M-series Mac.

We don’t know Apple’s exact motivation for not creating a full processor emulator. We can surmise that Apple chose to cut off 32-bit compatibility with Catalina, likely because of the performance and testing burden it would add to Rosetta 2 running on M-series Macs, all without providing a significant benefit to most of its customers. Apple has spent years trying to wean developers and Mac users off 32-bit apps. Plus, the company’s transitions usually aim to shift everyone to the latest technologies as quickly as possible.

There could also be legal concerns. Intel made some digs at Microsoft and Qualcomm in 2017 that seemed to imply that any ARM-based version of Windows for Qualcomm chips that emulated some x86 instructions could face legal action. Because Intel has developed instruction sets over many decades and generations of chips, some x86 instructions remain under patent protection, while others are no longer covered. The particulars would have to be litigated in what would undoubtedly be extremely tedious and drawn-out civil suits. (As an example, Oracle recently lost an 11-year-long intellectual property lawsuit against Google over Google’s use of a compatible version of Java in Android. It went all the way to the Supreme Court.)

But no lawsuit followed Intel’s throat-clearing. Microsoft released its 32-bit x86 emulator with Windows for ARM and then added a 64-bit x86 emulator in December 2020. Intel’s implied threats might deter smaller companies or open-source efforts that don’t want to run afoul of a multibillion-dollar firm, but there’s no evidence of that, either. Open-source developers are not shy about sounding alarms if they face these kinds of threats, so I expect we will hear about them if they arise.

For now, if you need an Intel-only operating system, you have to keep Intel hardware running, which might include virtualization software that powers operating systems other than the host operating system. In the past, wherever there’s been an interest in reviving older hardware, there has been sufficient will to make an emulator happen, whether commercial, open-source, or both. We’ll see if that happens again.

Glenn recently wrote a book specifically about Apple silicon Macs, Take Control of Your M-Series Mac, to explain the substantial differences in macOS, recovery mode, and running non-Mac apps within macOS.

Your M-Series Mac cover

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For 29 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

Comments About Emulation, Virtualization, and Rosetta 2: A Blend of Old, New, and Yet To Come

Notable Replies

  1. IANAL, but I bet a lawyer could argue that, per the recent Supreme Court decision in Oracle v Google, that reusing and reimplementing (in emulation) the copyright parts of an Instruction Set Architecture would constitute “fair use”. (For what it’s worth, I think the Supreme Court got that one exactly right. Justice Thomas’ dissent was not founded in a reasonable understanding of the difference between ‘interface’ and ‘implementation.’)

  2. The Oracle suit was reduced to copyright (Oracle originally attempted to include patent claims), while Intel has been able to defend on patents at times. So AMD and others built compatible chips in clean-room reverse-engineering implementations, but also with expired x86 patents. Intel continues to add proprietary instructions. The level to which Apple has deployed code that uses these instructions would be a fascinating exploration.

  3. Regarding running iOS apps on macOS, I would argue that this is neither emulation nor virtualization, but a kind of “comtainer” environment.

    For those unfamiliar with the term, a “container” is a sub-environment within a host operating system. Apps running in it share the same OS kernel as the host environment, but they (usually) have separate resource partitions for RAM, I/O, storage, etc. The result is like a lightweight VM - it uses less resources because it is sharing the host OS kernel, but offers much of the resource isolation that a proper VM environment offers. The downside to containers is, of course, that apps in a container must be compatible with the host OS - if a different OS is required, then a full VM is necessary.

    In the case of iOS apps running on macOS, it’s the same kernel (maybe with some different configuration parameters, but pretty much the same). And many system frameworks are the same, but with other frameworks (e.g. UI stuff) being completely different. Which is exactly the kind of thing containers excel at.

    The fact that macOS has been using a container-like technology for “sandboxing” apps for quite some time is additional evidence to support my analysis.

  4. This is fair! I’m not sure the extent of the kernel changes, so a container is a reasonable description, though I think it’s hovering between virtualization and containerization. Parallels has that Coherence mode in which the OS portion of a virtual machine largely disappears in favor of each app seemingly being available in the current host version of macOS. I think the way that iOS/iPadOS app compatibility is enabled in Big Sur under M1 Macs is more like that, in that a special environment is set up that allows the apps to appear like first-class citizens. Maybe we are saying the same thing here, but we certainly aren’t far apart. It’s clever as all get out.

  5. Interesting to see a trial on whether this would constitute a ‘software patent’, particularly if it’s just the instruction set specification, versus the silicon implementation.

  6. Is this what Docker is? I’ve never quite understood Docker.

  7. Containers, VMs and emulators can all share the host OS’s GUI. It’s all a matter of developing a pair of cooperating display device drivers - one for the host and one for the guest - that can map drawing API calls from the guest onto a window owned by the host.

    The way to tell what is going on with iOS-on-macOS is to look below the covers.

    • If the environment is just running the app and it’s shared libraries/frameworks, sharing the host OS’s kernel, then it’s a container (or a container-like envionment).
    • If the environment is running its own kernel, whether another instance of the host’s kernel or a different kernel, then it’s a VM.
    • If the environment is a different CPU architecture (e.g. ARM on x86), then it’s an emulator of some kind.

    Rosetta is a hybrid of these. The part that compiles the foreign architecture app into the native architecture is emulation technology. The part that runs the re-compiled app along with ported versions of the system frameworks is probably container technology (assuming that Apple sandboxes these apps). It could, however, run them as ordinary processes in the host environment as well.

    Pretty much. Modern operating systems have the ability to partition resources within a single running instance of the kernel. Sort of like protected memory, but extended to many different kinds of resources. The specific mechanism varies from OS to OS (Linux uses something called “namespaces”), but the general idea is that you can create a child process with its own partition of system resources, including:

    • RAM (very similar to normal memory protection)
    • File system (e.g. chroot to make a specific directory the root directory for the child process and union mounting to combine file system fragments together for a process).
    • Network. Assign specific network interfaces (physical and/or virtual) for exclusive use by a process. Also permit creation of separate instances of routing tables and related structures.
    • Processes. The process can see itself and its child processes, but other processes are invisible and inaaccessible.

    These mechanisms (along with others) are used to implement sandbox environments, to keep untrusted processes isolated from the rest of the system.

    They can be used in other ways to create what is effectively a lightweight VM. The process and its children are isolated from the rest of the system, but without needing to run another copy of the kernel and system processes. This, when combined with a set of tools for convenient maintenance and administration, is pretty much what containers are.

    Docker is one of the most popular suite of container-management tools. You can specify a set of file system fragments to comprise the container’s file system, a set of software packages (typically your app and what it depends on), and network interfaces for the outside world to communicate with the software in the container. You then compile this specification to create a convenient self-contained “container” object which you can launch and terminate at will in order to start and stop the software, along with the entire OS environment it depends on.

    Docker also include a large repository of containerized software packages that you can combine together when making your own containers. So you can tell Docker that you need a container including an Ubuntu Linux environment, the Apache web server, the MySQL database server and PHP scripting (the so-called “LAMP” environment) and let the Docker tools build all that for you, so you only need to add your app and a place to store its files.

    With a system like this, you can also create multiple instances of a container. You can also copy it to other compatible computers, running the app and its environment remotely. This makes for easy replication/distribution of software - which is great for developing cloud-based software. Docker includes tools like “Compose” for making apps that are composed of multiple containers and “Swarm” which allows dynamically creating and destroying container instances across a cluster of linked servers, as needed in order to keep up with requests from elsewhere on the network.

    Another popular container-management infrastructure is Kubernetes. It provides facilities (typically built over Docker, but can also use other container systems) that many cloud app developers like to use for container infrastructure. It has been integrated in to nearly every cloud infrastructure (AWS, Google, Microsoft, IBM, etc.) these days.

  8. I didn’t see any mention of this rumour on here. I do hope I won’t be affected (in the UK). Anyway, it certainly suggests something legal.

Join the discussion in the TidBITS Discourse forum

Participants