The reason for the different experience is that you were dealing with Unix systems which had proper ulimits set up. The available types of restrictions are appropriate for a multi-user server machine. They are not well suited to the needs of a dedicated server (where one server is expected to take up all available resources) or for a desktop (ditto).

Given that most Linux systems fall into the latter two categories, the default install of virtually every distro that I have encountered sets up no resource limits. Therefore even a simple fork bomb will utterly crush your typical Linux machine. BSD fanatics take note, the same is true for your average BSD install. To test whether it is true on a command prompt type ulimit, if it comes back with "unlimited" then this applies to you!

As for memory starvation, my experience runs like this. NT wants a whole process to be in memory at once. So once you begin running low on memory, you feel it almost immediately because switching processes becomes painfully slow. By contrast any modern *nix has demand paging, you may have most of your processes paged to disk without even noticing. But the second the active pages you are constantly hitting exceed RAM, the system hits a wall and suddenly starts grinding. (With proper ulimits you would be very unlikely to hit this point in regular usage.) When you finally run out of memory, processes start dying. :-(Linux in particular has a very stupid process killing algorithm, it is not rare to see key processes like klogd and autofs go down.)-: NT starts degrading much earlier but seems to degrade more smoothly.

As for serious and nasty NT problems, try right-clicking on the status bar and bring up the task manager. Killing the offending process in the task manager is likely to be much faster than an orderly shut-down. (At least it has been in my experience.)

And yes, I have heard that those really nasty slow-downs are actually problems within the kernel. Microsoft has a habit of improving the performance of key stuff (eg video) by "integrating" it into the kernel. Every time they do this, the whole system winds up vulnerable to bugs in that system. (The video subsystem in particular is the reason that Ed Curry, mentioned on my home node, told Microsoft that NT 4.0 would be unable to get C2 certification.)

Ironically this means that not only is it the applications that cause Windows to be unstable, but it is very specifically Microsoft applications that tend to be the worst offenders! (Because they have the know-how to play kernel games to give themselves a speed boost.)