I would like to state that it is the CPU and only the CPU that manipulates or moves data and this is done under the control of the program or code. There is the state of data before the CPU is involved and the state afterwords. I did study the Allen Turing State Machines "thing"at one time. The driver "thing" puts a big hole in the abstracted definition of a MV/Emulator because the driver is software. If there is a driver for a specific piece of hardware there must be one also for a specific O.S. It is a two way street and could be reversible.

So what I'm sure of is the CPU can only manipulate data and hardware is hardware. We are not swapping drives or monitors in and out with a program. A CPU and any other hardware can not be emulated by anything But another piece of hardware. If I throw code in a file , we will call it " theKbStockpilers sorry excuse for a V-M/Emulator" it is still code (commands) that the hardware "CPU "would manipulate and or move. I can however "convert" code that the native CPU will not execute to code that the CPU will be able to execute. Any interaction with the hardware such as a monitor Must be done with the host operating system otherwise you could not view output on a monitor. The V-M/Emulator could send data to a file that would/could be in the form that only the guest application could use but there would be no way possible for the host to use it. The Virtual machine would stay Virtual because it would be output ;for example, to the monitor that could not be viewed.



More on the "file" thing.

An Application in a file that is designed for MS, "Atari Classics"
A V-M/Emulator application stored in a ELF file
The files that a V-M/Emulator uses when it is executing.

I suspect that the term "Virtual and Emulator" are not used correctly like virtual memory so hence my lack of making the connection.

Having a guest O.S use the host O.S for input and out put is Actually allowing the guest O.S to execute as an application. The guest O.S treats the Host O.S as its hardware so I guess from the host O.S to the guest application ,this area could be loosely and very inarticulately be referred to a machine.

Emulator: A piece of code that copies the inner workings of a CPU. No part of the guest runs on bare hardware.

Emulators have no concept of an OS, nor do they even expect the software running on the CPU to be an OS.

VM: the guest runs on the bare hardware, and the VM keeps it from interfering from the host.

VMs also don't care what runs inside and whether it's an OS or not, but it works with the host OS to let the guest software run on the real CPU.

VMs and Emulators are completely different things that work in very different ways.

Also, neither VMs nor Emulators run ELF executables (they're an OS concept, not a hardware concept. Does your computer somehow run an ELF file with no OS installed?). Some emulators pre-load the RAM with raw machine code taken from a file (examples of this include bytecode interpreters from programming languages and emulators of cartridge-based game consoles), while some emulate a hard drave and take its contents from and image file. The emulated BIOS then takes over just like in a real PC (examples of this include PC emulators).

1 members found this post helpful.

Recent versions of Intel's x86 chips have built-in hardware support for virtual machines ... and, this is essential, because this is how "virtual machines" actually work.

When operating in virtual-machine mode, a so-called "hypervisor" (a "super supervisor") is responsible for selecting when to run a virtual machine, which one and for how long, but the actual environment that each VM "sees" is created by the CPU itself. Each VM has its own complete set of hardware registers, etc, courtesy of Intel Corporation.

"Emulators" work in a software environment that, generally speaking, does not rely upon hardware features of this kind.

1 members found this post helpful.