Spiroyster did a really good job of this, but I'm going to throw in my explanation as part addendum, part re-stating, such that hopefully any fuzzy bits become more clear. Here goes...
The Windows API has been a lot more stable since Win 2000, and especially XP. When Microsoft brought the consumer and workstation mainline OSes together for good in XP, that meant the entire Windows userbase was pretty much all running on the same NT-based API. So, apps written for 2K/XP and up all "just work" most of the time.
There are exceptions... and that comes down to what dependencies that application has. Does it need particular hardware -- and thus particular drivers? Is there a post-XP driver, or will the XP driver itself work on modern Windows? What about runtime libraries? The C or .NET runtime, Java VM, DIrect X library, etc., must exist and run on the modern Windows environment. If it does, no problem -- the app should just work.
I.e., for XP-era and up, there's a good chance that you don't need any emulation at all. Perhaps at best you need to enable "Compatibility Mode." I confess I don't actually know what this does under the hood -- I've always assumed it's partly lying to the application about what version of Windows this is (like SETVER from back in DOS) and customizing some common APIs to act more like older versions where they may have changed subtly over time. This may or may not be an accurate representation of what's really going on.
So that's "newer than 95" covered. What about older?
Well, as said before, DOS was trying to be the glue that bound applications to lots of different hardware -- and it did this by ensuring the least common denominator of hardware. You get BIOS calls, system routines, and a little housekeeping for free. If that's enough to do what you want to do, then all you really need to do is proxy x86 instructions (handling differences between real and protected mode as necessary), trap those syscalls and emulate them with your own routines, and you're good to go.
As mentioned above, this isn't enough for games, which need to believe there's an AdLib OPL2 chip, or Sound Blaster DSP, MPU-401 interface, VGA card, etc. In this case, DOSBox has to emulate that hardware and translate hardware-level I/O calls meant for that hardware to abstracted bitmap and PCM stream handles on the host OS. Not trivial, but still relatively easy since it's a small list of simple and well-supported hardware.
Win 9x is different. If you take a simple business application, it might run on modern Windows because the subset of API it uses still exists. But, if it starts pulling in 16-bit code (which modern Windows has dropped support for), or needs Direct X version or other runtime libraries that refuse to run on modern Windows, then it can't just run anymore, and you need to look at emulation.
Emulation is a broad term, though. There's API emulation, which just takes function calls from the app, massages them to be compatible with modern equivalents, then passes them on to be handled by the host OS. Then there's instruction proxying and trapping -- which will selectively pass on some instructions to be executed directly (increment, subtract, copy to/from memory, etc.) and consume others (like direct hardware I/O calls, etc.). The latter requires emulating of hardware -- creating virtual registers and I/O ports and IRQs, and acting like that hardware interface to the application.
For Win9x applications to be happy, you either have to emulate the entire API as it existed in Win9x -- which is not something anyone has done, AFAIK. Maybe WINE does this? I'm not sure -- I would've figured it's NT-based, but I don't really know. Someone mentioned SoftWindows -- maybe that did it, but I suspect it's not an option for many people today anyway.
... or you have to emulate the hardware environment of an x86 machine circa late 90s, early 2000s. That is a lot more complex than the minimal hardware you need for DOS support. There's a LOT more variety than just "SB16 and VGA BIOS". And old habits died hard, so there's a lot of software (and of course drivers!) that still wanted to reach past the Windows abstraction to touch the hardware directly.
Really the only way to effectively emulate Win95, for example, is to emulate the entire computer. Certain products do this -- or did. VirtualBox, PCEm, and VMware for example. But the commercial offerings are targeted towards business users that have long since moved on from 9x. So, for example, while you still pick Windows 95 from the list of target OSes in VMware, there's no driver support for it, and it's really low on the list of things VMware cares about so it might or might not work. (I hit some stumbling blocks along the way and gave up for a better alternative.)
Better to not bother with being a translation layer and emulate the raw metal entirely. But, emulating even a Pentium, at the hardware level, is a fairly arduous task still today. It may be a while before this is really feasible with the kind of performance you would get on actual hardware. Not to mention the herculean task of emulating such a variety of hardware devices accurately. With the problems hardware emulation has WRT parallelism, the ideal solution -- for now, at least -- is still FPGA-based. There are projects out there recreating bits and pieces of PCs, and entire older non-PC machines, so this could be reality. It would even be possible for it to be modular, such that the busses actually exist as they did in real life -- allowing you to use real or virtualized ISA or PCI cards for 100% authenticity and a path to authentic recreations over time.
That's my hope. I really want an FPGA 486 and FPGA Pentium MMX. Then REAL DOS / Win3.1 and Win95 emulation will be possible.