Without getting too technical UNIX OS's give applications a defined memory space to operate in. The UNIX OS doesn't care what the app does AS LONG AS IT STAYS IN ITS RUN-TIME AREA. There is a wall between the OS and the app. I am not so sure it is like that in Windows.
Moreover if the app crashes and it is mission critical, automation(cron) scripts can take over and re-spawn the app, thereby minimizing down time. This is what I do for a living....
I do this for a living too. While it’s true that it’s difficult for a typical application to crash a UNIX system, it still happens if the app trips over problems in the OS itself:
( SR:8606361473 CR:JAGaf22163 )
While performing an inode truncation operation on a VxFS filesystem, the number of subfunctions generated for the transaction overflows the internal transaction table [i.e., kernel stack overflow]. This overflow corrupts the information in the common transaction area. In particular, the inode information is corrupted which results in a panic.
( QX:QXCR1000557861 SR:8606427857 CR:JAGaf87338 )
An NFS client panics with the panic string “Data page fault” while performing an nfsreaddirplus operation.
( SR:8606392946 CR:JAGaf53027 )
The system panics during I/O on an NFS mounted file. The panic string is “crfree: freeing free credential struct”. The panic may also occur in crhold().
( QX:QXCR1000544021 SR:8606390486 CR:JAGaf50632 )
An NFS client panics when control messages from the TCP transport are received in the wrong sequence.
While the above are all straightened out now, this sort of thing is why you sometimes hear of unfortunate sysadmins at companies still running HP-UX 9.05 or 10.20. Nobody was willing to take the risk of upgrading the control systems and becoming the first ones to identify a new bug in the OS.