INTRODUCTION IN OCCASIONAL PROGRESS: There always seem to be more interesting things to do than write introductions.

Kernel-Mode Windows

As with many who start programming but are soon drawn to study the operating system that they’re programming for, my interests have long lain with what happens at the lower levels. It was this way for me immediately that I first started looking at programming as more than a tool that a mathematician may occasionally want for numerical analysis. Before I fully appreciated that my diversion from mathematics might be the start of my life’s achievement in something else entirely, I was picking apart the IO.SYS and MSDOS.SYS from MS-DOS 3.30, all as a theoretical exercise in deduction, working from debug output printed to continuous-feed paper and marked up with ruler and pencil. As DOS moved to protected mode and the Windows that runs on DOS gave way to the Windows we have today, I have always felt it the most rewarding to study what these operating systems do with memory, files and storage devices, and how they support the generality of code written by unknown programmers who may each write as if their code more or less owns the machine.

For the Windows that we have today, the management of memory, files and processes and such is ultimately the business of a multi-megabyte kernel, highly modularised internally but distributed as one executable, supported by a handful of other essential executables, most notably the HAL, which all together support an extensible scheme of drivers to complete what Windows applications have to take for granted as the system. Although the present Windows has from its beginning as Windows NT had vastly better system-level documentation than did the earlier Windows that ran on DOS, the difference was more in depth and reliability than in coverage: as with the Windows that ran on DOS, there has always been much about system-level Windows NT that Microsoft leaves undocumented.

When I speak of this level of Windows as the most rewarding to study, I should like to mean intellectually rewarding, but I cannot ignore that the wider research presented at this website has been possible for so many years only because kernel-mode programming is, or at least has been, financially rewarding. As will be known all too well to any software manufacturer that has ever needed any sort of kernel-mode driver, kernel-mode programming is expensive. Why is that?

There is of course some expense to expect of any highly specialised work. Another reason, at least in the private thoughts of anyone who calls himself a kernel-mode programmer, is that the work actually does require more skill than does most programming. But I have long wondered if there is more to it. Because so much functionality is undocumented, and much of the rest took years to get documented, there is a substantial element of “black art” to kernel-mode programming.