There’s the kernel, and there’s kernel mode – confusing historical terminology


A few weeks ago, I mentioned that the kernel folks decided not to expose bonus bytes to applications. Some people were confused by this statement, not for what it said, but for what it implied. “Wait, you’re telling me that the heap is implemented in kernel mode?”

Let’s turn the clock back to 1983.

The core components of Windows fell into three categories:

  • The window manager, known as user, because it handled the user interface.
  • The graphics engine, known as GDI, short for Graphics Device Interface.
  • File I/O, the scheduler, memory management, and other low-level bits, known as kernel.

Windows 1.0 ran on the 8086, which had no concept of CPU modes or memory protection or any stuff we take for granted nowadays. Everything ran in a single mode, and since there was only one mode, it didn’t have a name.

Although future versions of Windows distinguished between kernel mode and user mode (in the CPU mode sense), the old terminology stuck around. The “kernel” was anything related to file I/O, the scheduler, memory management, and other low-level operations, even if they were implemented in user mode.

For a time, there was an effort to use the term “base” to refer to all of these low-level operations and thereby avoid the confusing term “kernel.” As you can tell, the attempt was largely unsuccessful. People continued to call low-level stuff “kernel” out of habit.

Comments (15)
  1. DWalker59 says:

    I like these stories that start with "Let's turn the clock back…".

  2. dave says:

    … and not everything that runs in 'kernel mode' is 'the kernel'.  Most of the kernel-mode stuff is part of the exec.

  3. Joshua says:

    In order to remove the confusion you'd have to rename kernel32.dll.

    Calling kernel32.dll kernel just might keep people from looking up the system call numbers and trying to use them directly (they can change between patch versions of Windows so that is a bad idea).

  4. Cesar says:

    Why not call it "the kernel32 folks" instead of "the kernel folks" then? Everyone (at least everyone who reads this blog) when reading "kernel32" will think "the user-mode kernel32.dll, which is implemented on top of ntdll.dll, which is what calls the real kernel". There is no confusion that way.

    [And then people will say, "Wait, I thought XYZ was handled in ntdll, not kernel32." And you may have noticed that in Windows 7, a lot of stuff that used to be in kernel32 was moved to kernelbase. -Raymond]
  5. AC says:

    If ntdll just calls the kernel, where does the kernel actually reside in?

  6. Gabe says:

    Cesar: There's still plenty of confusion. NTDLL actually calls into the Executive (which handles graphics, I/O, VM, IPC, and most everything else), not the kernel. The kernel schedules threads, manages interrupts, performs synchronization, and handles exceptions. Nearly everything else in kernel mode is either done by the HAL, the Executive, and drivers.

  7. Maurits says:

    @AC: ntkrnlmp.exe, usually; the MP I believe stands for multi-processor.

  8. Joshua says:

    [And then people will say, "Wait, I thought XYZ was handled in ntdll, not kernel32." And you may have noticed that in Windows 7, a lot of stuff that used to be in kernel32 was moved to kernelbase. -Raymond]

    Personally I'm surprised that didn't break too much. I've seen software before the depended on kernel32 being the second dll loaded (it used to always go *.EXE, NTDLL.DLL, KERENEL32.DLL, … on NT based systems).

  9. Joshua:

    Why would this break anything since kernel32.dll would still be the second one to load anyway. Ntdll.dll is special, it is forced in by the Windows executable loader. But after that the executable loader loads in dependencies in order, and kernel32.dll is always the first. Don't forget, dependencies always load after the module that depends on it. If it was the other way around then the executable itself would always be the last to load. Anyway, the Windows loader would have to be in the process of loading kernel32.dll to know that it depends on kernelbase.dll, so by that time, the DLL would have been loaded into memory.

  10. Oh, and as a bit of an ammendment to my previous comment. For WoW64, kernel32.dll is also never the second DLL loaded. The WoW layer DLLs always load in before kernel32.dll. So if there is an application that depends on kernel32.dll being the second one loaded, then it will break badly on WoW64 on any x64 version of Windows.

  11. Drak says:

    @Cesar: not everyone who reads this blog. I don't actually do any direct windows api programming, but I still read every article in the log because it's interesting to see how stuff works :)

  12. RP says:

    Whether the kernel folks could be called the kernel32 folks would also depend on whether kernel32.dll was the file in use when that version of Windows was released.  It used to be 16-bit kernel.exe and 32-bit krnl386.exe.

  13. Neil says:

    @RP: Or both kernel32.dll and krnl386.exe "at once" in the case of Windows 9x. And not forgetting krnl286.exe which was used either on the 80286 or to run Standard Mode depending on Windows version.

  14. DMS says:

    @RP: kernel.exe, krnl286.exe, and krnl386.exe were all 16-bit (kernel.exe was for real mode, krnl286 was for protected mode, and krnl386 differed from only krnl286 by utilizing some of the 386 instruction set extensions). Until Chicago (Win95), there was no 32-bit kernel DLL in Windows (there was a 32-bit 'microkernel' (WIN386 / VMM32), but that's another story).

  15. R{ says:

    Thanks DMS, that sounds familiar(ish) now that you've reminded me…

Comments are closed.