My way of thinking: When I wrote my minicomputer emulator I
emulated the CPU, but I
simulate the operating system. My CPU emulator can execute all (user) programs. But those programs are constantly calling operating system services, and my CPU emulator does not execute the operating system. Instead I
simulate the operating system so that it looks to the executing applications that there's actually an OS there. But my simulation only maps *nix files etc. via various tricks and configuration files so that the application is satisfied. When the application thinks it's manipulating directory entries, for example, nothing of that really happens.
There is another person writing an emulator for the same minicomputer though. His emulator is intended to be able to execute the actual operating system too. So no operating system simulation. Peripherals will be simulated though (to start with, at least).
In some ways this way of thinking is the exact opposite of some definitions I have read (also in this forum), where a 'simulator' is supposed to be more 'accurate' than an 'emulator'. In may way of thinking, however, for software I think of emulators as doing the right thing as much as possible, while simulators are just going through the motions to simulate (but not actually do) what it looks like it's doing from the outside. Smoke screens and handwaving.. as my OS simulator.
That doesn't mean that my definition is 'correct', but at least enough other people are thinking the same way to make us able to communicate!
(I imagine this way of thinking about 'simulation' came out of e.g. when someone drafted to military service tried to simulate being insane, ill or blind, but it doesn't hold up to scrutiny)
-Tor