Re: Why does coroutine.create return a thread?

[Sean Conner <sean@...>]

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.