Why? 3.x in 386 enhanced mode was practically the same design (well, maybe no ConfigMG) and people there would have no problem saying it was "DOS based".

Win9x didn't use MS-DOS for filesystem access, while all versions of Win3 except for 3.11 for Workgroups did use MS-DOS for filesystem access. As a result, when you booted up Win95, MS-DOS didn't matter at all except as the second stage boot loader.

As you yourself are saying, 3.11 did exactly the same. So one must find another criteria.

It's more complicated than that, Windows 95 would also check for programs intercepting INT 21h, sandwich its filesystem access routines in between and possibly call the old interrupt handler even when running from 32-bit programs.

It's more optimized and more polished but it's still Win386 at its heart, and it actually makes sense a lot. The book "Unauthorized Windows 95" talks in detail about how it works.

You mean its based on a massively successful operating system that was used by millions?

Nothing wrong with DOS (and I mean that sincerely), just Windows 9x was much more than it.

No worries, I got the point you were trying to make, my comment was directed more at people who snipe at successful products - when the reality is a lot more nuanced/complicated. There is complete freedom to criticize, but then (I believe) there is also a responsibility to contextualize the criticism.

You had to be around to understand the sentiment behind the "DOS based" issue. It's what many non PC users said about windows when discussing its instability and use of legacy code.

I didn't find DOS or Windows to be any less stable than other consumer operating systems. But regardless of which code-base is more/less stable, niche code-bases don't get stressed in the same way as a mainstream consumer OS.

Windows 95 has a monolithic kernel, which supports much, but not all, of the 32-bit NT API. It provides NT-style processes and 32-bit memory management (sort of), NT-style APIs for long file names (sort of), etc. There's also a lot of hacks, and no real kernel/userspace separation, for the extensive 16-bit compatibility. While most of the kernel itself runs in 32-bit protected mode, much of the OS was still 16-bit. That code runs in a 16-bit VM86 virtual machine, which is shared with 16-bit user application code, in a common address space. Sort of how Windows 3.x worked in 386 mode. There were procedures to call between 16 and 32 bit code, both in the kernel and in user applications. That shared address space with all the 16-bit code, is the source of a lot of the infamous instability. That dependency on that 16-bit mode is why it got called "DOS-based", similar to how Win 3.x worked in 386 mode. Part of the OS was still running in 16-bit mode, even if that 16-bit mode was being virtualized by a 32-bit protected mode kernel.

There are some pretty decent guides for VxD programming still floating around on the web that give a pretty good overview of how VMM32 worked.