You're right, it's not fair. Why? Because at the core of Windows/386 (as it was called in Windows 2.0 days), is a real 32-bit kernel that gradually took more and more OS duties from the MS-DOS 'bootloader' and eventually, as of Windows for Workgroups 3.11, ran no real-mode code at all: real mode INT calls 'thunked' into 32-bit handlers. Windows 95 added more, and removed the visibility of DOS as the bootloader.

The book "Unauthorized Windows 95" by Andrew Schulman takes a deep dive into how the VMM386.VXD 'kernel' works and how it progressively takes over the role of an operating system, beginning from managing memory, through video, through keyboard and mouse, through printing, through disk access, through file access and long filenames, through multiple versions of Windows. Schulman even guides the reader through creating a 32-bit protected mode OS running COMMAND.COM on top, with 3-bit memory (DPMI), 32-bit disk, and 32-bit file with long filenames using pieces of Windows; 32-bit code via INT21H. Here's a link to OS/2 Museum's review: https://www.os2museum.com/wp/book-review-unauthorized-windows-95/

This mechanism that allows real mode code to call 32-bit routines is a form of thunking (https://en.m.wikipedia.org/wiki/Thunk ). Windows on Windows64 does the same thing for 64-bit Windows running 32-bit Windows code.

You can read even more about the internals, specifically of Windows 3, at https://www.xtof.info/inside-windows3.html quoting the first paragraph:

Windows 3 is often said to be just an UI on top of DOS. This article presents some of the inner side of Windows 3.x and will show that it is more ambitious than that; especially when running on a 386 computer. Windows 3 gradually added 32-bit capabilities to its 386 only “Enhanced Mode”, progressively paving the road to Windows 95.

The key word is 'progressively' in this paragraph: VMM386.VXD gradually took over as the actual OS by loading more and more VxD's that took over whole sections of the old MSDOS.SYS and IO.SYS real mode OS using thunks to 32-bit code.

It would be more correct to call Windows' Standard and Enhanced modes "a Graphical Operating Environment on top of a protected mode DOS Extender" where both the OE and the Extender are loaded when you execute windows.com. Anyone who else remember the Phar-Lap DOS Extender? Similar concept; Microsoft of course had to roll their own DOS Protected Mode Interface (DPMI) and this is what the core of VMM386.VXD does; it does all the work to set up V86 mode, resides in ring 0 to handle various traps and faults (including the tables for the 32-bit handlers for INT), and loads the rest of the old real mode system into a V86 ring 3. So DOS is running on top of VMM386.VXD, which has taken over memory management, much like EMM386.SYS does.

The most important thing to note is that the INT mechanism used to call DOS routines is no longer handled by DOS, but by ring 0 VMM386.VXD code. This is the way V86 protected mode works. Even without any other VxD loaded, every INT call in the real mode DOS routines calls the VMM386.VXD INT handler, not DOS's.

Other VxD's are then loaded by VMM386.VXD and the MS-DOS death by a thousand cuts begins, as each VxD carves code out of DOS with surgical precision, eventually making it where no more DOS code runs even though it's still resident in its ring 3 V86 container and VMM386.VXD with its army of VxD's is doing everything.

No, Windows the DPMI kernel is not a shell around DOS. Windows the GUI Operating Environment can be (Real Mode Windows 3.0?).

To use Star Trek the Next Generation and Deep Space Nine terminology, Windows 386 Enhanced Mode's DPMI kernel is like a joined Trill: the symbiont is much like the VMM386.VXD kernel with its VxD drivers, and the ring 3 DOS is like the host.