Timeline for How did DoubleDOS work?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 15 at 4:14 | answer | added | Louise Mainella | timeline score: 11 | |
| Feb 14 at 13:21 | vote | accept | bjb | ||
| Feb 13 at 20:38 | comment | converted from answer | Igor K. | I wrote small multitasker for msdos in 1990-1992. It was able to run two msdos shells and start pograms as if you have two separate MSDOS instances on the same machine. It was under heavy use on our machine runnig BBS and mail tosser. You can look sources on github: github.com/ikod/mscreen I even can run it today under VirtuallBox (see screencast on github) | |
| Feb 3, 2018 at 1:53 | comment | added | Rowan Hawkins | @Spektre I am well aware of tsr's this was not a tsr, it wasn't a driver and it didn't terminate. It was an application that loaded itself into EMM and then forked an instance of command.com in low 640k. It didn't terminate thought it was still residenti, playing music as I ran Kermit to dial in to college for the timeshare system. When the buffer would empty, I would have to logoff, quit the shell, queue more music, and then repeat the process again. | |
| Jan 28, 2018 at 14:54 | answer | added | Raffzahn | timeline score: 10 | |
| Jan 28, 2018 at 13:44 | answer | added | tofro | timeline score: 7 | |
| Jan 28, 2018 at 12:15 | answer | added | jwzumwalt | timeline score: 6 | |
| Jan 25, 2018 at 15:08 | comment | added | Spektre | @RowanHawkins that was called TSR programs (Terminate and Stay Resident) all the mouse drivers, keyboard layout changers and viruses did work like that. They usually hoked up on some interrupt (like PIT) and did what they wanted for small time and then returned the CPU back to OS (waiting for next interrupt) so the other stuff was working too ... | |
| Jan 5, 2018 at 2:37 | comment | added | Rowan Hawkins | Proably an aside, but I had a MOD music player that basically loaded itself into the full himem/extended memory area with a queued list of music loaded into memory and then it shelled itself out releasing the low 640k area to another application. As @AProgrammer mentions there was no way to enforce device access. Both the player and the application could write to the speaker at the same time for instance. When the play buffer ended, you needed to quit the shelled program to allow the player to refill the buffer. I used this to have background music while dialed in to college. | |
| Jul 5, 2017 at 8:36 | comment | added | Igor Skochinsky | @BrianH Later DOS versions used MCBs to track memory usage | |
| Jun 29, 2017 at 18:14 | comment | added | user722 | @BrianH MS-DOS 2 and later allowed programs to allocate and deallocate memory. It also allowed multiple programs to be loaded at once, a program could execute another program. This was all single-tasking however, the first program had to wait until the second terminated. (In MS-DOS 1 programs owned everything from start of their program to end of memory and pretty much had to load and execute other programs itself if it wanted to do that.) | |
| Jun 29, 2017 at 14:35 | comment | added | AProgrammer | @BrianH, DOS had some kind of memory manager, but it was honor based (the hardware couldn't prevent misuse). TSO for instance played trick with that API, DoubleDOS could easily have done the same. | |
| Jun 29, 2017 at 0:08 | comment | added | Brian H | I'm curious how the memory management would have been done. Did DOS programs respect some kind of system heap manager or memory allocator that could be used to load two programs simultaneously and ensure they don't try to use the same memory space? IIRC, some DOS task switchers worked by snap-shotting RAM to disk while switching contexts. Not sure how it knew which chunks of RAM needed to be swapped. | |
| Jun 28, 2017 at 19:43 | comment | added | Cody Gray | Interesting question! This would actually be fun to disassemble as a weekend project, if only I had a copy! Problem is, the resulting analysis would more likely be book-length than answer-length. The concise answer is basically what Ross has already said, which we can get by pure speculation. | |
| Jun 28, 2017 at 18:53 | comment | added | Omar and Lorraine | I am just hypothesising here, but maybe every so often is just saves/restores the CPU registers including the segment registers? If the two programs are short enough that should do the trick (unless I'm forgetting something; I'm not too familiar with MS-DOS) | |
| Jun 28, 2017 at 18:34 | comment | added | manassehkatz-Moving 2 Codidact | Plenty of context switching on any PC for hardware interrupts. But video and plenty of other issues as @RossRidge notes. I suspect it relied on bank-switched memory > 640k, which few programs (except Lotus 1-2-3) could do much with in the early days, so even limited multitasking was a good way to make use of extra memory. | |
| Jun 28, 2017 at 17:44 | comment | added | user722 | Context switching at its heart is a very basic operation, it just requires saving the current CPU register state for the current task and restoring the CPU state for the new task. So an 8086 CPU was capable of that, just like you describe with interrupts. What it wasn't capable of was enforcing a partition between tasks, or creating an environment where each task would appear to have machine to itself. So if two programs tried to write to video memory at the same time they be writing to the same screen and overwriting each other. | |
| Jun 28, 2017 at 16:55 | history | asked | bjb | CC BY-SA 3.0 |