What are the specific differences between an "emulator" and a "virtual machine"?

I see that they are different things but I really can't tell why. Some people say: "emulators are for games; virtual machines are for operating systems" I don't agree with this answers because there are emulators for platforms other than videogame consoles (AMIGA (?) )

Can you help me please?

Virtual machines make use of CPU self-virtualization, to whatever extent it exists, to provide a virtualized interface to the real hardware. Emulators emulate hardware without relying on the CPU being able to run code directly and redirect some operations to a hypervisor controlling the virtual container.

A specific x86 example might help: Bochs is an emulator, emulating an entire processor in software even when it's running on a compatible physical processor; qemu is also an emulator, although with the use of a kernel-side kqemu package it gained some limited virtualization capability when the emulated machine matched the physical hardware — but it could not really take advantage of full x86 self-virtualization, so it was a limited hypervisor; kvm is a virtual machine hypervisor.

A hypervisor could be said to "emulate" protected access; it doesn't emulate the processor, though, and it would be more correct to say that it mediates protected access.

Protected access means things like setting up page tables or reading/writing I/O ports. For the former, a hypervisor validates (and usually modifies, to match the hypervisor's own memory) the page table operation and performs the protected instruction itself; I/O operations are mapped to emulated device hardware instead of emulated CPU.

And just to complicate things, Wine is also more a hypervisor/virtual machine (albeit at a higher ABI level) than an emulator (hence "Wine Is Not an Emulator").

The purpose of a virtual machine is to create an isolated environment.

The purpose of an emulator is to accurately reproduce the behavior of some hardware.

Both aim for some level of independence from the hardware of the host machine, but a virtual machine tends to simulate just enough hardware to make the guest work, and do so with an emphasis on efficiency of the emulation/virtualization. Ultimately the virtual machine may not act like any hardware that really exists, and may need VM-specific drivers, but the set of guest drivers will be consistent across a large number of virtual environments.

An emulator on the other hand tries to exactly reproduce all the behavior, including quirks and bugs, of some real hardware being simulated. Required guest drivers will exactly match the environment being simulated.

Virtualization, paravirtualization, and emulation technology, or some combination may be used for the implementation of virtual machines. Emulators generally can't use virtualization, because that would make the abstraction somewhat leaky.

Dell explained exactly what the difference between emulators and virtual machines is.

Source - https://www.delltechnologies.com/en-us/blog/emulation-or-virtualization-what-s-the-difference/

> Emulation or virtualization: What’s the difference? > > Emulation and virtualization carry many similarities, yet they have > distinct operational differences. If you’re looking to access an older > operating system within a newer architecture, emulation would be your > preferred route. Conversely, virtualized systems act independent of > the underlying hardware. We’ll look to separate these often confused > terms, and describe what each of them mean for business IT operations. > > > What’s the difference? > > Emulation, in short, involves making one system imitate another. For > example, if a piece of software runs on system A and not on system B, > we make system B “emulate” the working of system A. The software then > runs on an emulation of system A. > > In this same example, virtualization would involve taking system A and > splitting it into two servers, B and C. Both of these “virtual” > servers are independent software containers, having their own access > to software based resources – CPU, RAM, storage and networking – and > can be rebooted independently. They behave exactly like real hardware, > and an application or another computer would not be able to tell the > difference. > > Each of these technologies have their own uses, benefits and > shortcomings. > > > Emulation > > In our emulation example, software fills in for hardware – creating an > environment that behaves in a hardware-like manner. This takes a toll > on the processor by allocating cycles to the emulation process – > cycles that would instead be utilized executing calculations. Thus, a > large part of the CPU muscle is expended in creating this environment. > > Interestingly enough, you can run a virtual server in an emulated > environment. So, if emulation is such a waste of resources, why > consider it? > > Emulation can be effectively utilized in the following scenarios: > > • Running an operating system meant for other hardware (e.g., Mac > software on a PC; console-based games on a computer) > > • Running software meant for another operating system (running > Mac-specific software on a PC and vice versa) > > • Running legacy software after comparable hardware become obsolete > > Emulation is also useful when designing software for multiple systems. > The coding can be done on a single machine, and the application can be > run in emulations of multiple operating systems, all running > simultaneously in their own windows. > > Virtualization > > In our virtualization example, we can safely say that it utilizes > computing resources in an efficient, functional manner – independent > of their physical location or layout. A fast machine with ample RAM > and sufficient storage can be split into multiple servers, each with a > pool of resources. That single machine, ordinarily deployed as a > single server, could then host a company’s web and email server. > Computing resources that were previously underutilized can now be used > to full potential. This can help drastically cut down costs. > > While emulated environments require a software bridge to interact with > the hardware, virtualization accesses hardware directly. However, > despite being the overall faster option, virtualization is limited to > running software that was already capable of running on the underlying > hardware. The clearest benefits of virtualization include: > > •Wide compatibility with existing x86 CPU architecture > > •Ability to appear as physical devices to all hardware and software > > •Self-contained in each instance > > Between emulation and virtualization, your business can perform most > virtual systems functions. While both services sound alike, it all > revolves around how you utilize the software. If you want the software > to get out of the way, virtualization allows guest code to run > directly on the CPU. Conversely, emulators will run the guest code > themselves, saving the CPU for other tasks.