> There is no multitasking for regular programs in DOS: if a program launches another one, the parent is simply paused until the child exits.

Well aware of that fact but my question is could you switch from the subprogram back to the main program without exiting the subprogram? I feel the answer is no but I can't remember.

e.g. I open norton commander and run qbasic. norton commander is paused and qbasic takes control. Is there an interrupt call which allows me to return control to norton commander without exiting qbasic and let qbasic stay paused?

>could you switch from the subprogram back to the main program without exiting the subprogram?

There were TSR task-switcher programs to do that, effectively allowing you to turn normal programs into TSRs. I had a single floppy-drive PC with no hard drive, but I had 640K of RAM. So I would run the task switcher from its floppy, allocate task 1 some RAM and load that program from its floppy, then allocate task 2 some RAM and load that from its floppy, then switch to task 3 and use the rest of the RAM for whatever. Whenever needed, I could switch back to task 1 or task 2, without having to switch floppies or exit the current task. I think it was DOS 3.30 when I used that. It was handy to keep small utilities (like a text editor and unarchiver) loaded and ready to look at the contents of any disk.

The list from Ralf Brown's Interrupt List gives an idea of what some of the task switchers were: http://www.ctyme.com/intr/cat-011.htm

[Topview](https://en.wikipedia.org/wiki/IBM_TopView) appears to have had an interesting story. And of course DESQview followed. I never used either of those.

You could do a lot in DOS with ASM and interrupts, as long as the code was small. But with the hardware limitations, and the way people usually used PCs during DOS's prime years, it didn't really make sense to put too much effort into multitasking. Towards the end we were often rebooting with distinct boot disks, each with a different AUTOEXEC.BAT and CONFIG.SYS customized to get the most out of the hardware for each specific program. Multitasking would be pointless in that case.

You can just hook some interrupt and revive the controlling program. A problem is that the other programs are free to bypass the normal ways to drive the input devices as are not required to accommodate other tasks.