I'm interested in a basic to intermediate understanding of these two subjects. Is anyone aware of a decent guide or tutorial on these subjects or maybe a few underlining concepts explained? Emulators don't emulate the CPU, correct?

Thanks................in...............advance!

If you read this you should get it:
http://en.wikipedia.org/wiki/Virtual_machine

In one statement: an emulator is a virtual machine that emulates a non-native architecture.

1 members found this post helpful.

…other way around.

Emulators simulate absolutely everything in software: the CPU, audio/video adapters, I/O, etc.

Virtual machines, on the other hand, try to run as much code "natively" as possible. This is probably implementation dependent, but VirtualBox tries to run guest kernel code in x86 privilege ring 1 (as opposed to ring 0, where host kernel code runs; ring 1 is primarily unused in other contexts), unless hardware virtualization extensions such as Intel VT-x are enabled, in which case the VM gets an entirely new context space with the same four privilege rings as the host (resulting in practically zero raw processing overhead). I/O/device access is still emulated/redirected through the hypervisor, however (we wouldn't want our guest to trash the host's access to hardware ).

This is just my very basic understanding of it I got from reading the VirtualBox tech docs, so I don't claim that it's complete (or even entirely correct).

1 members found this post helpful.

This link will give you a good understanding of Virtual Box.

-->http://www.virtualbox.org/manual/ch01.html

1 members found this post helpful.

I will read the links and see where I am from there. I expected that System calls would have to be intercepted and modified but the guides don't seem to go into that much detail which is strange.

Thanks again!

What system calls? Are you talking about virtual machines that try to run the software on the native hardware or about true emulators?

I was just throwing that one out there but an explanation that is comprehensive must include the frame work of the like. I understand that O.S's have different system calls so that would have to be addressed some how. I will dig a little further myself to refine my questions.

A true emulator doesn't have anything to do with system calls. All it does is implement in software the logic that's normally implemented in silicon and circuit boards. If the logic is the same the same as the hardware supported by an OS, that OS will work in it.

One thing that I think you're confused about is that the emulator somehow controls the OS inside it. This is not true. It doesn't need to even have an OS in it, just any machine code for the emulated CPU (for example, virtual machines for programming languages and game console emulators don't run an OS). And it doesn't have to emulate a physical piece of hardware, you can think of any hypothetical machine you like and implement it as an emulator.

That only really applies to VMs (not emulators). As I said in my post above, with VirtualBox, system calls (which consist of instructions that would normally be run in privilege ring 0 natively) are actually redirected/made to run in ring 1 (otherwise unused) instead. User mode code (ring 3) still runs in ring 3, though. Everything still runs "natively", in a sense, but it's still subject to the limitation of being run under another OS (and hence can only take so much CPU time, among other restrictions).

Emulators, on the other hand, simulate executing individual instructions. As MTK said above, all an emulator does is implement a CPU's register/instruction set/cache(s)(?)/other components completely in software (possibly along with other peripherals, such as audio/video controllers).

From a user's standpoint, the main difference between them is that a) emulators are typically slower than "semi-native" virtual machines, and b) since an emulator completely emulates an instruction set, you can run any program written/compiled into that instruction set in it as if it's absolutely no different from the actual, physical hardware. VMs have the restriction of being limited to the architecture the hypervisor runs on, whereas emulators don't, because they don't really have a "hypervisor" concept; they're "running" code in their own completely isolated environment, so to speak.

I hope I'm making some kind of sense here, and I hope I'm not majorly butchering the concepts.

EDIT: I suppose I should add that with virtual machines, if the CPU has hardware virtualization extensions, and they're enabled in the hypervisor's settings, then that provides the VM a new context space which (with Intel VT-x, anyway) is called "VMX non-root mode" (as opposed to "VMX root mode" where host code runs). This is essentially a new "space" where VM guest code runs that has the same four code privilege levels as root mode, but has an additional control structure to intercept certain instructions (such as I/O requests) and redirect them to the hypervisor. (AFAIK )

Lets say I have code for MS sitting in a file.For it to be executed on Linux something would have to present it to the kernel (loose interpretation) in the Elf format. The CPU is fed the code that it is not written for it. I assume the machine code is different from MS to Linux. The CPU could have a different instruction set also. I don't see a big problem with the hardware because this is where drivers come in and we all know this is a black art. If there was a way around the driver issue with an emulator I would think that drivers would not be such an issue and WINE could execute a game without crashing the O.S. on a regular basis.

So to reiterate from the paragraph above ,I really don't have an overview of what goes on with a emulator or a v.machine, the process of it executing.

Thanks again!

Running Windows apps on Linux has nothing to do with emulators and VMs. Do you know what WINE stands for?

Also, the CPU architecture is the same for Windows and Linux. After all, it's called the CPU architecture, not the OS architecture.

The reason Windows apps don't work on Linux is becasue they are in a different format that the Linux kernel doesn't understand, and it has different system calls that Linux doesn't understand. Also, Linux has a totally different design and is missing many concepts that Windows program assume.

Basically, FORGET ABOUT THE OS. IT HAS NOTHING TO DO WITH THIS SUBJECT.

1 members found this post helpful.

I think you are confusing the deal.

Your "code" has nothing to do with a VM for this discussion.

A VM of any kind is a computer, just like one you buy at the store. Forget everything else. It is a computer to you and your OS.

Now your "code" has to have an OS to run, with one exception. That exception is a special program that adapts Windows programs to run in linux. Wine and crossover products and a few others use software to basically fool the code into thinking it is running in windows.

In all other cases you install Windows into a virtual machine (remember it is a real machine for this discussion) and then install the code and run. You would have two computers running at the same time sharing one real computer.

As to how the sharing is done is the emulate and virtual both hardware and software supported.


Suffice it to say that a modern good desktop can fully support a virtual machine in hardware and the software program to create almost a real computer.

1 members found this post helpful.

The hardware is obviously "the hardware" so it is absurd to imagine that the physical makeup of the computer would change. Hardware must be implemented through the host O.S. and then ultimately with the use of drivers. The guest applications code must be "converted" or possible implemented in an inverted concept so the host CPU and manipulate the code. I intuitively believe the the guest application would fill in arguments of the VM/Emulators code and than this code would be executed by the host CPU/O.S.

This software that the guest application is treating as hardware, are there files that take the place of the hardware or is the guest application data being used to altering the original code? So instead of a CPU or a input/output means the guest sends data to a file. The VM/Emulator does something and then this new modified data is nativity executed by the host CPU. I would think that the VM/Emulator would inspect code of the guest , convert it and then hand it over to the host. I do understand the abstractions but they operate as magic. I apologize for being redundant but this is an important concept with "virtually" no info on the web about it. If I could find an explanation that uses processes and files and who they belong to it would not be abstracted. A Virtual Machine process must include,

Host hardware
Host and or guest O.S
Host storage for Files.(no hardware no files.)
Process must not belong to guest
Separation of host OS to guest application via the Virtual machine/Emulator

In other words does anyone know the anatomy of an Emulator/Virtual Machine and the other files that it creates and or uses?

Not quite…put simply, what happens is that at the instruction level (think assembly), those instructions that the guest runs which would normally trigger some kind of hardware action (I/O, IRQ servicing, etc.) are actually routed to what's called the "hypervisor" (which is a part of the actual VM software), which then safely performs the intended action in a "virtual" context on the host. For example, if a guest requests I/O to/from its virtual "disk", that request is redirected to the hypervisor so that it can read/write to/from the disk image in the host filesystem instead. The same thing applies to other hardware: audio, video, HIDs, and other devices.

With an emulator, everything is simulated completely in software, including the individual CPU instructions. So, there's no real risk of something going wrong with the host, since none of the code is actually running natively; every instruction is simulated by the emulation software, including those that would normally trigger hardware actions.

Again, hopefully I didn't butcher something up there; my own understanding of the differences is somewhat fuzzy, but hopefully you can see my point here… :-\

I don't understand what you mean at all here, especially the "file" thing.