On the one hand, it is certainly possible to write a
Microkernel for real mode x86 on the PC, in the sense that it could be done: back in the day there were several, including Minix 1.x/2.x, Coherent OS, PCix, and early versions of QnX. There may have been a PC port of TriPOS (the micro-kernel developed at Cambridge which went on to become Amiga Exec) but I am not sure. I am not sure if MultiDOS (or 4DOS, which I
think might have been another name for it but might have been something separate, I am not sure) would be considered a microkernel or not, as I know next to nothing about them, but I doubt it.
You will note two things here. First, MS-DOS/PC-DOS isn't on that list, and I will explain why momentarily. Second, most of them are loosely based on Unix, or at least heavily influenced by it in terms of API, IPC, shell interface, etc., despite being (in terms of design approach) diametrically opposed to the Unix of the time, which was a genuine monolithic kernel which would need to be re-compiled even just to add a new driver. The latter was mostly for the sake of what some would call simplicity, and others would call laziness: by the mid-1980s, most new programmers would at least have used Unix at college, so it stuck with what people knew¹.
The former is more relevant here, as MS-DOS was neither a microkernel nor a monolithic kernel - in fact, it wasn't a kernel-based design at all, being what is technically known as an 'execution monitor'. An exec monitor is a type of monotasking system which basically has two jobs: launch programs, and provide an ABI that programs can call for basic system services. Exec monitors were common for minicomputers² in the early 1960s, when systems design was in its infancy and the systems were both too slow and too limited in memory to really do two things at a time, with some being basically just loaders for punched cards and/or paper tape. Some of the earliest interactive systems, such as the TX-0, Linc, PDP-1, and PDP-8, had somewhat more elaborate exec monitors, but they were still the same sort of thing. They often contained a
machine code monitor as part of or even the whole of the user interface, both for coding and debugging. This was before the abstraction of a 'kernel' had even been invented yet (which was a few years later in 1965 or so, with the 'microkernel' design arising in 1967), and none of them would really be considered kernel systems today.
They vanished for a time, but saw a revival when the microcomputer boom hit, as the early micros were comparable - or a little below - the performance of the first-gen minis, so systems such as CP/M, TRS-DOS, and QDOS³ adopted the approach, while others such as Apple and Commodore went with a hybrid approach in which they used a BASIC interpreter in the role of the exec monitor (with some systems, including the Commodore PET and its successors, putting the BASIC in ROM so that they wouldn't require the use of a then-expensive floppy disk drive; Apple had a simpler BASIC, called Integer BASIC, in ROM, but the familiar Applesoft BASIC was part of the disk-based AppleDOS).
OK, so the point is, they were all
Monotasking Systems which didn't have kernels at all. So what?
Well, the 'so what' here is that microkernels by definition are
all about securely
multi-tasking without hardware memory protection, because up until the late 1980s, hardware memory management was considered an expensive luxury for a small computer to have, and few microprocessor CPUs of the time supported it.⁴ The main goal of the micro-kernel design was to allow a multitasking kernel to remain stable even if a driver or other system facility went off the rails, so long as the kernel scheduler itself remained healthy. The 'micro' name is misleading, because it isn't really about size at all, but about the separation of core system functions from anything not absolutely necessary for the kernel to function.
But all of this is moot, at least with regards to newer systems, because not only is the Legacy BIOS going away at the end of this year, real mode itself (and 16-bit protected mode, and possibly even 32-bit protected mode eventually) is probably going away in the next five years. After 2020, you won't readily be able to go into real mode, even if the CPU still has it, as the UEFI BIOS⁵ won't support booting into it - you could drop down into real mode somehow, I suppose, but it would require you to have all the facilities of a protected mode or long mode OS in place in order to even do that.
Footnotes
- Though older programmers would have probably preferred something more like Tenex, RTX, or maybe IBM's CMS - not to be confused with VAX VMS, which was still relatively new itself, but I digress.
- 'Mini' in the sense that they were the size of a large refrigerator, rather than a small building as with most mainframes of the day.
- Also called, 86-DOS but better known as SCP-DOS, which became PC-DOS/MS-DOS after Microsoft bought the failing Seattle Computer Products.
- Those which did usually did so with a co-processor, as with the Motorola 68000 and the early MIPS and ARM microprocessors.
- Don't give me grief over this - 'BIOS' ("Basic Input/Output System", that is to say, the set of firmware needed to boot the system and support a running OS) is a generic term, predating the PC by decades. UEFI is a BIOS, even if it isn't the Legacy BIOS.