I’m not familiar enough with 8088 to know… And it doesn’t seem to come up in a search… How the heck did they do (presumably) pre-emptive task scheduling on that chip? Anyone know?
You’d need some kind of timer interrupt that has very high priority to be able to do something like that I would think.
You’re on the right track with the timer interrupt assumption!
One of the key techniques involved the use of the Intel 8253/8254 Programmable Interval Timer (PIT), present in IBM PCs/compatibles at the time. DESQView would reprogram this timer to generate interrupts regularly, and more frequently, than its default setting used by the operating system for clock ticks.
When this timer interrupt fired, DESQView’s interrupt handler would kick in, save the current state of the CPU (registers etc), and then switch the context to another process by loading its saved state. By juggling the CPU time between different programs this way, DESQView could give the illusion of running multiple programs simultaneously on hardware that was originally designed for a single task at a time.
DESQView used other tricks too, like monitoring keyboard and mouse interrupts, to make multitasking smoother. Pressing the Alt key by itself brought up the DESQview menu, and pressing Shift+Alt allowed you to record custom macros. A more interesting thing was how DESQView managed to intercept Ctrl+Alt+Del - pressing it would only terminate and close the window you’re in, instead of rebooting the whole box, which, at the time felt like black magic because normally nothing intercepted Ctrl+Alt+Del - you expected it to just work and reboot the box without question.
You could install interrupt handlers in DOS more or less as if you were in the kernel of a higher-level OS. It was honestly dead simple – just “please run this code on an interrupt,” and that’s exactly what it would do 🙂. There wasn’t any priority or access control; you could request any interrupt, and if you wanted to also have the previous handler run, you had to call it yourself. My guess would be that they just installed a timer interrupt, and every X milliseconds they would just swap the instruction pointer and stack over to a different program, so the programs take turns just like in a memory-protected multitasking OS.
I’m not real familiar with how well you might be able to do memory protection. My guess would be that it all just runs unprotected in the 0-640kb range on an 8088, so your programs had to share and not step on each other, and that some things can be swapped up into 640kb-1mb range on a 286, but I’m not sure on either count. I worked on them but I never really understood the way 8088 and 80286 chips segmented their memory; it was famously fairly bizarre.
I’m not familiar enough with 8088 to know… And it doesn’t seem to come up in a search… How the heck did they do (presumably) pre-emptive task scheduling on that chip? Anyone know?
You’d need some kind of timer interrupt that has very high priority to be able to do something like that I would think.
You’re on the right track with the timer interrupt assumption!
One of the key techniques involved the use of the Intel 8253/8254 Programmable Interval Timer (PIT), present in IBM PCs/compatibles at the time. DESQView would reprogram this timer to generate interrupts regularly, and more frequently, than its default setting used by the operating system for clock ticks.
When this timer interrupt fired, DESQView’s interrupt handler would kick in, save the current state of the CPU (registers etc), and then switch the context to another process by loading its saved state. By juggling the CPU time between different programs this way, DESQView could give the illusion of running multiple programs simultaneously on hardware that was originally designed for a single task at a time.
DESQView used other tricks too, like monitoring keyboard and mouse interrupts, to make multitasking smoother. Pressing the
Altkey by itself brought up the DESQview menu, and pressingShift+Altallowed you to record custom macros. A more interesting thing was how DESQView managed to interceptCtrl+Alt+Del- pressing it would only terminate and close the window you’re in, instead of rebooting the whole box, which, at the time felt like black magic because normally nothing interceptedCtrl+Alt+Del- you expected it to just work and reboot the box without question.cc: @[email protected]
Very cool! I appreciate the detailed explanation. Sounds like the coders behind it really knew their stuff.
You could install interrupt handlers in DOS more or less as if you were in the kernel of a higher-level OS. It was honestly dead simple – just “please run this code on an interrupt,” and that’s exactly what it would do 🙂. There wasn’t any priority or access control; you could request any interrupt, and if you wanted to also have the previous handler run, you had to call it yourself. My guess would be that they just installed a timer interrupt, and every X milliseconds they would just swap the instruction pointer and stack over to a different program, so the programs take turns just like in a memory-protected multitasking OS.
I’m not real familiar with how well you might be able to do memory protection. My guess would be that it all just runs unprotected in the 0-640kb range on an 8088, so your programs had to share and not step on each other, and that some things can be swapped up into 640kb-1mb range on a 286, but I’m not sure on either count. I worked on them but I never really understood the way 8088 and 80286 chips segmented their memory; it was famously fairly bizarre.
But the task scheduling you could absolutely do.
Thanks! I had forgotten about segment registers. Makes more sense now than it did when I first learned about them ages ago.
86Box can emulate the 8088 and WinWorld has the first version of DESQView so I might just try it. As for how they did it…I wouldn’t know.