What you're describing sounds a lot like what a lot of embedded kernels do. In the magical world of embedded (which is what I do professionally), we seldom use proper OSes per se, but instead use tiny little kernels that implement multitasking, semaphores, channels, and that's it. Most embedded architectures don't have a sophisticated virtual memory feature (in fact, most older embedded architectures don't really have a user mode at all), so they typically just set up different stacks in memory, then set the stack pointer to the correct stack when starting a task. These kernels (FreeRTOS and Contiki are good examples) get compiled together with all of your application code, then you have a main function somewhere where you just tell the scheduler where each task is. Most of them just run user tasks run in kernel mode, since you're constantly reading and writing hardware peripheral registers anyway.saltlamp wrote: ...
Maybe it's worth looking at how embedded kernels work. I can't think of one that supports x86 in any form, but the general idea would be the same, more or less.
I don't have the same perspective but, as an interested amateur, I think they implement most of the things you mentioned under DOS because, whenever I looked at embedded x86 a few years ago, DOS always seemed to go along with it. In using FreeDOS off and on for a few years, I only heard scheduling mentioned once, so perhaps most embedded DOS systems consist of interrupt-triggered TSR (terminate and stay resident) programs. There are a few multi-tasking DOSes, perhaps those are used in some circles. I imagine a good combination might be a multitasking DOS scheduling non-critical tasks with TSRs for time-critical tasks. I don't think there are any free multitasking DOSs though. That together with Micro$oft's competition-destroying policies may be why multitasking seems to rare in the DOS world. Ironically for this thread, "DOS extenders" to escape real mode seem to be much more popular. 