|
It was thus said that the Great Coda Highland once stated:
> On Tue, Jun 21, 2016 at 1:37 PM, Gregg Reynolds <dev@mobileink.com> wrote:
> >
> > MS-DOS: the Original Embedded System.
>
> MS-DOS wasn't even cooperatively multitasked. It was TECHNICALLY
> preemptively multitasked, in that triggering a TSR through an
> interrupt routine could happen at effectively arbitrary times in
> program flow, but there was no timesharing and the TSR would have to
> clean itself up and return control to the original program on its own.
Technically, MS-DOS is a single user, non-reentrant interrupt handler that
just happens to have a few file system calls bolted onto the side. There
was no multitasking in the modern sense (or even in the not-so-modern
sense). Getting MS-DOS to multitask was not an easy task. Sure, you could
have a program that multitasks within itself (modern jargon: multithreaded)
but running two arbitrary MS-DOS programs at the same time? Nope [1].
It wasn't until the 80386 [2] could you even hope to have a snowball's
chance in Lower Sheol [3] of multitasking MS-DOS, since the 80386 introduced
a virtual 8086 mode. And yes, I've been there, done that too [4] (rather
recently actually).
-spc (Then there's the issue with the A20 gate ... )
[1] TSRs are not a "program" in the conventional sense and if they
needed to call into MS-DOS, great care needed to be done to ensure
that the main program running isn't using MS-DOS at the time. I did
write a TSR, but it was mainly a keyboard macro type program that
trapped the keyboard IRQ---it never dealt with MS-DOS itself and
thus, was "easy" to write.
[2] Yes, the 80286 had a protected mode, but the segment registers [5]
work very differently than in real mode. It would have been quite a
bit of work to get an unmodified MS-DOS to run in the 80286
protected mode as a real mode program.
I'm not saying it's impossible, just improbable.
[3] South Florida.
[4] https://github.com/spc476/NaNoGenMo-2015
[5] I rather not talk about those.