Ttdfjt

You are comparing apples to motorcycles.

Windows 95 traces its lineage back through Windows 3.x all the way to Windows 1.x and MS-DOS/PC-DOS, themselves inspired by CP/M. It was conceived and designed as a single-user, cooperatively multitasking environment in which applications have a large degree of freedom in what to do. Windows 95 moved towards a preemptive multitasking design, but still had significant cooperative elements built-in.

The fact that it was intended as a consumer OS replacement for the combination of MS-DOS and Windows 3.1/3.11, and was to work (not necessarily provide a great user experience, but boot and allow starting applications) on as low end a system as any 386DX with 4 MB RAM and around 50 MB of hard disk space, also put huge limitations on what Microsoft could do. Not least of this is its ability to use old MS-DOS device drivers to allow interoperability with hardware which did not have native Windows 95 drivers.

So while Windows 95 provided a hugely revamped UI compared to Windows 3.x, many technical improvements and paved the way for more advanced features, a lot of it had compatibility restraints based on choices, and to support limitations in hardware, dating back over a decade. (The 386 itself was introduced in 1985.)

Now compare this to modern versions of Windows, which don't trace their lineage back to MS-DOS at all. Rather, modern versions of Windows are based on Windows NT which was basically a complete redesign, originally dubbed NT OS/2 and named Windows NT prior to release.

Windows NT was basically designed and written from the beginning with such things as user isolation (multiuser support), process isolation, kernel/userspace isolation (*), and no regard for driver compatibility with MS-DOS.

For a contemporary version, Windows NT 3.51 was released three months before Windows 95, and required at a minimum a 386 at 25 MHz, 12 MB RAM, and 90 MB hard disk space. That's quite a step up from the requirements of Windows 95; three times the RAM, twice the disk space, and quite possibly a faster CPU (the 386 came in versions clocked at 12-40 MHz over its product lifetime), and again, that's just to boot the operating system.

Keep in mind that at the time, a 486 with 8-12 MB RAM and 500 MB hard disk was a reasonably high end system. Compare Multimedia PC level 2 (1993) and level 3 (1996), only the latter of which went beyond a minimum of 4 MB RAM. Even a MPC Level 3 PC in 1996 wouldn't meet the hardware requirements of the 1995 Windows NT 3.51, as MPC 3 only required 8 MB RAM.

From a stability point of view, even Windows NT 3.51 was vastly better than Windows 95 could ever hope to be. It achieved this, however, by sacrificing a lot of things that home users would care about; the ability to run well on at the time reasonably affordable hardware, the ability to run DOS software that accessed hardware directly (as far as I know, while basic MS-DOS application compatibility was provided, there was no way other than dual-boot to run most DOS games on a Windows NT system), plug-and-play, and the ability to use hardware that lacked dedicated Windows NT drivers.

And that's what Microsoft has been building on for the last about two decades to create what we now know as Windows 10, by way of Windows NT 4.0, Windows 2000, XP, Vista, 7 and 8. (The DOS/Windows lineage ended with Windows ME.)

As another-dave said in another answer, process isolation (which is a cornerstone for, but on its own not sufficient to ensure, system stability) isn't a bolt-on; it pretty much needs to be designed in from the beginning as, if it isn't there, programmers (especially back in the day, when squeezing every bit of performance out of a system was basically a requirement) will take shortcuts which will break if you add such isolation later on. (Compare all the trouble Apple had adding even basic protections to classic Mac OS; they, too, ended up doing a complete redesign of the OS that, among other things, added such protections.) Windows 95 didn't have it, nor was the desire from Microsoft to do the work needed to add it there; Windows NT did have such isolation (as well as paid the cost for having it). So even though Windows NT was far from uncrashable, this difference in the level of process isolation provided by the operating system shows in their stability when compared to each other, even when comparing contemporary versions.

*) The idea behind kernel/userspace isolation (usually referred to as "ring 0" and "ring 3" respectively in an Intel environment) is that while the operating system kernel has full access to the entire system (it needs to, in order to do its job properly; a possible exception could perhaps be argued for a true microkernel design, but even there, some part of the operating system needs to perform the lowest-level operations; there's just less of it), normal applications generally don't need to have that level of access. In a multitasking environment, for just any application to be able to write to just any memory location, or access any hardware device directly, and so on, comes with the completely unnecessary risk of doing harm to the operating system and/or other running applications.

This isn't anywhere near as much of a problem in a single-tasking environment such as MS-DOS, where the running application is basically assumed to be in complete control of the computer anyway.

Usually, the only code (other than the operating system kernel proper) that actually needs to have such a level of access in a multitasking environment is hardware drivers. With good design, even those can usually be restricted only to the portions of the system they actually need to work with, though that does increase complexity further, and absent separate controls, a driver can always claim to need more than it strictly speaking would need.

Windows 95 did have rudimentary kernel/userspace and process/process separation, but it was pretty much trivial to bypass if you wanted to, and drivers (even old DOS drivers) basically bypassed it by design. Windows NT fully enforced such separation right from the beginning. The latter makes it much easier to isolate a fault to a single process, thereby greatly reducing the risk of an errant userspace process causing damage that cannot be known to be restricted only to that process.

Even with Windows NT, back then as well as today, if something went/goes wrong in kernel mode, it would generally cause the OS to crash. It was just a lot harder to, in software, cause something to go sufficiently wrong in kernel mode in Windows NT than in Windows 95, and therefore, it was correspondingly harder to cause the entire operating system to crash. Not impossible, just harder.

The decision about whether to kill a process or crash the OS generally depends on whether the problem can be isolated to the process.

For example, if a running process in user mode attempts to read from an address that's not present in its address space, that's not going to affect anything else. The process can be terminated cleanly.

At the other extreme, if the file system running in kernel mode discovers that some data structure is not as expected, then it is wise to crash the entire system immediately, because the consequence of corrupt in-memory control structures could be loss of disk data, and that's the worst thing that could happen.

With specific respect to the Windows NT (-2000, -XP, -7) family: the OS was designed with good process isolation from the beginning. For Windows 9x, the heritage of Windows up through 3.x required some compromises in the name of compatibility. In particular, the first megabyte of address space is common to all processes: corruption there can kill the whole system.

TL;DR - process isolation is a day-0 design issue.

Although Windows 95 introduced support for 32 bit applications with memory protection, it was still somewhat reliant on MS DOS. For example, where native 32 bit drivers were not available, it used 16 bit DOS drivers instead. Even 32 bit applications had to be synchronized with the 16 bit DOS environment.

A fault in the DOS part of the system would bring the whole thing crashing down. 16 bit DOS applications do not have any meaningful memory protection or resource management and a crash cannot be recovered in most instances. And since even 32 bit applications had to interact with DOS components, they were not entirely immune either.

Another major cause of instability was that 32 bit drivers ran inside the Windows kernel (the core of the system). That reduced the amount of memory protection they had, and meant bugs would crash or corrupt the kernel too.

By the time Windows 7 came around drivers had mostly been moved out of the kernel and faults could be recovered from similar to an application crashing. There are some exceptions such as low level storage drivers.

Addendum:

Some special memory areas (eg the infamous "GDI resources") that all applications needed were extremely limited in size (due to being shared with 16-bit APIs, which needed segment size limits respected) - and very easily ran into exhaustion, with no effective safeguards present.

A lot of essential system APIs did not sanity check their parameters well - if you accidentally fed them invalid pointers or pointers to resources of a different type of resource than expected, all kinds of unwanted behaviour could happen - especially when involving something in a 16-bit-shared area. Getting GDI object handles in a twist ... ouch.

Also, the system was trusting the responses to certain messages too much. I remember you could make Windows 9x extremely hard to shut down properly by simply installing a WM_QUERYENDSESSION handler that silently FALSE'd out everytime...

16-bit apps were run with A LOT of gratuitous privileges for compatibility reasons - enough to directly access ... and in the worst case crash! ... some of the hardware.

Everyone is talking about the improvements in software between Windows 95 and Windows 7, but in those 15 years there were huge advancements in hardware as well. You can run an identical copy of Linux on some consumer-grade hardware from 1996 and some hardware from 2016 and you will find a world of difference in system stability.

Older hardware simply crashed more often, and it was only really around 2003-2004 that things really changed. Manufacturers of motherboards, CPUs, RAM and various other hardware upped their game significantly as businesses and home users demanded better stability.

One of the most popular motherboard manufacturers in the 90s was a company named "PC Chips", who also traded under about 20 other names. They produced these shonky, poorly-soldered, barely-shielded motherboards at rock bottom prices. A lot of the system crashes back then were due to people running those motherboards, and not Windows.

That said, Win95 was horribly crash prone itself, and it was always a guessing game as to whether your crashes were hardware or software related.