Like many people, I have started toy OSes, and like most such projects, all of them but my current one did not make it far past the booting stage.
The problem was that there was just too much to do: Booting, memory management, interrupt/exception handling, video output, keyboard, disc access, file systems, scheduling... most of those things are potentially interesting, but not all at once, and yet they are all pretty much necessary to get your OS to the "critical mass" where working on individual aspects starts being fun.
Until I had the idea to not just boot using plain old 16bit DOS, but too also keep DOS running in my OS, as a task. The thing about DOS is that it is barely an "operating system" in the modern sense. Instead, it is more a crude collection of 16bit x86 routines that do most of the aforementioned things: Console input/output, file system access, crude memory management, a whole shell actually (COMMAND.COM)... and you can even load drivers for networking, sound, and almost everything else, provided for form of it already existed about 15 years ago.
My current toy OS is a modern message passing microkernel, but for everything that I did not feel like implementing yet, I call into the DOS task. The task runs as a vm86 task, essentially within a hypervisor (called the "vm86 monitor"), but specifically for 16 bit real mode code. (64bit x86 got rid of the now obsolete vm86 mode, so there you would have to actually implement something much closer to a modern hypervisor.) This is done using using a shim layer that receives messages using the message passing system of my OS and translates them into the (usually) soft-interrupt driven DOS/BIOS function calls.
This is possible with DOS, unlike modern OSes, because it's such a crude and conceptually simple OS, centered around direct hardware access and with essentially no own memory protection/address space separation, that it just does not get in the way of implementing my own OS.
Throughout my career I always had this niggling feeling that I don't really understand what's going on inside the operating system. Like many geeks I dislike magic tools and have to have at least a basic understanding of how I might implement it myself.
But I found that I was able to play with individual elements before having a system that's even remotely useful. I recommend the Xinu book. After only a few weeks' work (which was mostly research and reading, not programming) I had a system that could do a context switch. This was always the most magical part of an OS for me. After that I started to implement memory management, but it just got too hard to be fun (ARM64).
The problem was that there was just too much to do: Booting, memory management, interrupt/exception handling, video output, keyboard, disc access, file systems, scheduling... most of those things are potentially interesting, but not all at once, and yet they are all pretty much necessary to get your OS to the "critical mass" where working on individual aspects starts being fun.
Until I had the idea to not just boot using plain old 16bit DOS, but too also keep DOS running in my OS, as a task. The thing about DOS is that it is barely an "operating system" in the modern sense. Instead, it is more a crude collection of 16bit x86 routines that do most of the aforementioned things: Console input/output, file system access, crude memory management, a whole shell actually (COMMAND.COM)... and you can even load drivers for networking, sound, and almost everything else, provided for form of it already existed about 15 years ago.
My current toy OS is a modern message passing microkernel, but for everything that I did not feel like implementing yet, I call into the DOS task. The task runs as a vm86 task, essentially within a hypervisor (called the "vm86 monitor"), but specifically for 16 bit real mode code. (64bit x86 got rid of the now obsolete vm86 mode, so there you would have to actually implement something much closer to a modern hypervisor.) This is done using using a shim layer that receives messages using the message passing system of my OS and translates them into the (usually) soft-interrupt driven DOS/BIOS function calls.
This is possible with DOS, unlike modern OSes, because it's such a crude and conceptually simple OS, centered around direct hardware access and with essentially no own memory protection/address space separation, that it just does not get in the way of implementing my own OS.