When DSL is first invoked at the command line it boots up the Linux kernel which takes over control of the computer from DOS.
Now here’s the trick: DSL makes use of a processor feature called VM8086 which allows for a 32 bit operating system to run legacy 16 bit code mostly natively. This feature is how early Windows, DOS extenders, etc worked. The Linux kernel also supports VM86, although it is largely undocumented and not really used these days. I think dosemu is the only major user of VM86 on Linux.
DSL then returns to DOS, which has essentially been flipped inside out and is now unknowingly running inside a VM8086 task. Helpfully Linux does not appear to clobber DOS’s memory during its own boot process.
DSL does just enough emulation of hardware like the keyboard to make things work, allowing DOS raw hardware access for everything else. This situation of running two operating systems at the same time on the same hardware is extremely fragile and unsafe of course, but it does seem to work surprisingly well anyway!
Would be really cool if someone contributed a proper man page, I bet it would be a fascinating read.
Is that just a coincidence or intentional somehow?
I guess DOS can only access the first 1MB (err... plus 65520 HMA bytes?), so if Linux just avoids using that space then DOS can keep running happily... I was curious if there's actually a mechanism to tell Linux to avoid that space.
DOS memory management fascinates me in its absurdity.
This is nice. It reminds me of the IPL sequence of some mainframe OS I sadly can't remember right now (might be System/i?) where the bootloader that launched the kernel was a first-class OS process that went from running the entire system to being promoted to an OS task as the kernel started up. Except in this case you're promoting the entire
OS to a kernel task, while the promoted OS continues to run :D
I wonder if you could extend this to turn Linux into a replacement for HIMEM.SYS, to "properly" support the fact that HIMEM has to be disabled. :D
(Immediately after reading that I thought "wait; the two OSes are running independently, of course that won't work..." but then I realized, no, HIMEM works by trapping interrupts... so this is not only possible, but vm86 of course works by handing you interrupts to deal with.)
The extremely-confusing-but-still-positive benefit of this would be to allow you to elevate DOS to have demand-paged virtual memory, complete with swapfile.
It might be interesting to identify the oldest kernel version(s) you're prepared to put up with, to realize the smallest _in-memory_ kernel size possible, and _possibly_ enable running multi-MB applications on real systems with only 640KB of RAM (with the proviso that using an SSD via a SATA-IDE adapter would give the best results - and the rationale that both of those items will soon be cheaper than old DIMMs). The issue suggesting 2.4 is maybe a bit of a stretch, but the early 2.6 trees might be interesting.
Another idea I had after reading the dosemu source is implementing a DPMI server to allow protected mode DOS apps to run. It might even be possible to run an early version of Windows this way too.
That would make the whole system fully robust and safe, and also support running XMS/EMS managers, DOS extenders, Windows and other bootloaders from the DOS VM.
I'm not sure however whether you would need to modify qemu to make it work and how hard that would be (also I guess that would have less hacky fun factor).