Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
In this question:
Why was the DOS kernel discarded?
I was told that DOS is not a kernel. It runs on CPUs that don't even have kernel mode. So how can it be a kernel? So I think this is right.
Now if DOS is not a kernel and the NT kernel comes later (on 2000/XP/Vista...):
What is the Windows 95/98/ME kernel called?
Does the kernel of Windows 95/98/ME have a name?
Other than Kernel? No, not a sharp and distinct one, as it's all about what one calls a kernel, so any naming is usually about mutiple components. If one really wants to point to a single most important file, it'll be KRNL386 and WINDOWS32.
I was told that DOS is not a kernel.
Erm, no. The point of the answer wasn't that DOS isn't a kernel, rather that DOS is not the Kernel of Windows, but an access layer used by Windows.
For a DOS environment, MSDOS-SYS is the kernel - or Supervisor as such entity was originally called (*1).
It runs on CPUs that don't even have kernel mode. So how can it be a kernel? So I think this is right.
No. Something being a kernel is not depending on any hardware support (or mode). Otherwise many classic OS, including early Unix, would not have a kernel
In fact, there is much room argueing what a kernel is. Just note the long section about rather divergent architectures in the Wiki entry for Kernel. In it's original definition, as a Supervisor, it's the component that takes and manages all system calls an application issues.
Taking that definition then we get roughly the following assignments for what could be considered the Kernel:
Of course, there are more parts to Windows which may or may not count as part of a 'kernel', like USER or GDI (2), so it all depends on the context one is looking at the issue. With 32 Bit Windows the whole part gets even more blurry as the API is not only packeaged in its own system library(s), but what this library is changes from a kernel part to a mere interface library in later versions.
Long story short: It's complex :))
*1 - Or as complete picture in terms as they were first structured:
*2 - KERNEL/KRNL286/KRNL386 presents the OS part of Windows. It covers everything (relevant) that without Windows woudl be offered by DOS - if at all. Windowing is provided by USER, while GDI does the same for all drawing on output devices (including the canvas of a window). KERNEL
*3 - Plus all optional runtime loaded drivers.
It is called the kernel; if the context isn’t clear, the “Windows 95 kernel” or whatever version is appropriate. Technical analyses (such as Unauthorized Windows 95) usually distinguish different parts of the operating system kernel, typically the DOS kernel (IO.SYS/MSDOS.SYS or WINBOOT.SYS), the “Win 16” kernel (KRNL386.EXE), the Win32 kernel (KERNEL32), and the Virtual Machine Monitor (which is arguably the “real” operating system in Windows 3.x onwards), but it is all just called the kernel.
Windows’ core services are split up into well-identified components, such as the aforementioned VMM, GDI, USER32, DOSMGR, etc. It’s common for these to be named explicitly in discussions involving them.
As I've said at http://jdebp.info/FGA/operating-system-nut-metaphor.html and at https://superuser.com/a/329479/38062 , this terminology is fairly foreign to the world of MS-DOS, and CP/M before it, in the first place. Always remember: these terms are metaphors. They don't have exact meanings, and arguing whether the "DOS kernel" was discarded or the "DOS part" was discarded or the "DOS foundation" is discarded is really putting too much of a specific meaning into a term that only really means the inner part an operating system when viewed through the analogy of a nut.
The architecture of DOS+Windows 95/98/ME actually has a lot of layers (ROM firmware, DOS layer, virtual machine manager, Win16 layer, Win32 layer, Explorer shell, command processor, and housekeeping utility programs), and how well one can match it up with a simplistic nut metaphor is confounded by how one is viewing it at the time. More realistically, it's more of an onion than a nut, but even that is a simplification, as the layering is not uniform in every aspect.
Some people like to place a single boundary at the Win16 API, and view what is inside that as "the kernel"; but there are at least three boundaries that can be viewed as where the "system calls" are, and which boundary encloses "the kernel" really depends from which boundary one is focussing upon.
Similarly, there are bits actually named "kernel" in their filenames, but that only form parts of the layer at their particular levels.
The KERNEL.DLL is only a part of a layer that also encompasses things like USER.DLL, and SYSTEM.DRV.
And the design heritage goes back as far as CP/M, which didn't really have this terminology in the first place. CP/M was not modelled as a "kernel" and a "shell", and people did not really use that metaphor for its architecture at the time. MS-DOS inherited the CP/M way of viewing an operating system architecture, and the way that MS-DOS evolved into DOS+Windows 95/98/ME did not happen along the lines of an operating-system-as-a-nut metaphor.
People who got hung up on their notion that MS-DOS was not a "kernel", forgot that MS-DOS wasn't the only thing that got set aside. Windows NT not only didn't share the underpinning MS-DOS, it didn't share the VMM architecture, the VxDs, or even the way that the 32-bit system was layered over the 16-bit system. They should have pulled you up on your idea that it was "DOS" that was discarded, whether or not one could view that as a "kernel" of a metaphorical nut. A whole lot more was discarded, and re-architected in a very different way.
Finally: Do not conflate the "kernel" of an operating system with "the part that runs when the processor is in supervisor mode". "kernel" is not that precise a term, and there are operating systems for processors that have user/supervisor mode distinctions where "the bits that are internal to the system call interface" (one way that people sometimes choose to define a "kernel") run partly or even wholly in the processor's user mode. Not only is this is a metaphor, not a precise term with one definite meaning, but also it is not necessarily a metaphor aligned with processor modes, or even one that is limited to operating systems with processor modes.
PRN,AUX, the RTC), manages memory and processes. The only major thing it lacks is concurrency, and even that can be worked around with TSRs and multitaskers like DESQview… and later, in fact, Windows.