Essentially, each task runs in its own memory space. If you need it, there is a phenomenal amount of customizaton you can do. Here, for example, is a screenshot of the memory customisation setings notebook for my beloved old spreadsheet of choice, Quattro Pro. Notice that I've given it 128MB of DPMI (DOS Protected Mode Interface) memory, which is vastly more than it really needs, but what the hell - it only gets allocated if it's needed, but no EMS and no XMS - because seeing as QPW is a DPMI-aware app, DPMI is the most efficient sort of memory you can give it.
Notice also the "seperate session" tick-box. Quattro is one of my most vital apps, so it gets an entire virtual X86 computer all to itself. I can crash anything else, even another Windows 3.1 app or Windows itself, and the Quattro session is completely untouched. In the old days, this was something you only did for really vital apps, as each seperate session consumed about 4 to 8MB of RAM, and in a 16MB or 32MB system, you could start some heavy swap-file hitting all too easily.
These days, of course, hitting the swap file is a non-issue, (a) because I have 512MB of physical RAM, and (b) because the X15 the swap file lives on is probably damn near as quick as the 30-pin fast page RAM in my old 386DX-40 used to be. (Well, not quite, but it's getting on for the same order of magnitude now. By the time you allow for the massive improvement in CPU speeds and main board data transfer rates since 386 days, it's probably faster to swap from the X15 than it used to be to page through RAM.)
But you are all yawning! "Hey", you say, "Windows 2000 can do about 60-80% of that stuff.", Quite right. But I was doing this stufff in
1992. And thanks to the hard yards that IBM put in back around the start of the 1990s, I can
still do it better than any Windows user can.
</soapbox>
(And don't blame me for the rant - blame Cliptin for asking!)