How did DoubleDOS work?

Question

Back in the MS-DOS days, there was a program DoubleDOS that you could run that would split your machine in half and multitask two separate DOS programs. While it didn't particularly work well for games (as far as I remember), it was popular for system operators of bulletin board systems.

How did DoubleDOS work? I know that I had used it on 8086 machines back in the day which I don't believe had many of the real context switching capabilities that modern CPUs use to support multitasking. Was it simply hooking up to an interrupt and storing session 1's CPU registers, context switching, restoring session 2's registers, running and then running until the next interrupt? Was memory space adjusted accordingly or did programs which didn't go simply through DOS and the BIOS fail to operate?

(it has been a loooong time since I've used it, but another question just ignited an old brain cell :-) )

Answer 1

Jwzumwalt already covered the basic, being not much younger I might add a few minor details still present to me.

While it didn't particularly work well for games (as far as I remember), it was popular for system operators of bulletin board systems.

It was perfect - well, let me rephrase this as rather useful - for well behaving (read no direct hardware access) programs to have two programs at hand. Like a BBS operating in the background while being able to do maintenance tasks at the same time.

How did DoubleDOS work? I know that I had used it on 8086 machines back in the day which I don't believe had many of the real context switching capabilities that modern CPUs use to support multitasking.

In general the process is the same on each and every CPU ever developed. To switch all CPU-states visible to a user task need to be exchanged. Some CPUs may offer special modes for special cases (like the second register set in the Z80) or instructions to store the whole state (or most of it) in a single operation. Still, it has to be done.

Also with a primary single taking BIOS/OS combination, several memory regions need to be swapped - just think of things like cursor position.

Same with screen memory. If there's only one screen adapter, the content needs to be exchanged. Otherwise one would not be able to see the output of the background task when switched up.

Was it simply hooking up to an interrupt and storing session 1's CPU registers, context switching, restoring session 2's registers, running and then running until the next interrupt?

Exactly like that. The basic task switch was done via a timer interrupt. To make it work some additional precaution had to be taken. For example monitoring entry to certain BIOS and DOS interrupts. As well as handling BIOS for I/O related functions. This is necessary since no (at least not many) DOS/BIOS functions are designed for reentry (i.e. two tasks running thru the same code). So DoubleDOS had to keep the tasks from doing so.

For example, if the timer interrupt (08h) fires while the active task issues a DOS function, it will be ignored. Prior to DOS 2.0 DoubleDOS did this by hooking Int 21h and setting a marker of their own, while with DOS 2.0 the InDOS Flag got introduced to sign when it's safe to (re)enter DOS (*1).

Was memory space adjusted accordingly

DoubleDOS was really build around the Idea of splitting a machine into two by partitioning memory. It wasn't really a taking system with dynamic memory assignment. At startup (or if no program was running in either task) available memory was to be split um in two regions and kept that way. Beside being the prime idea, it also avoids hassles wit programs manipulating the memory they assume to be entitled to.

or did programs which didn't go simply through DOS and the BIOS fail to operate?

There are zillion ways to screw operations, and computers really enable them :)) It depends on the way of switching and what kind of 'bypassing' DOS/BIOS had been used. The most important issue here is usually the screen content and keyboard. Programs accessing both directly did only run well in foreground. In background they may at best just screw up the front tasks screen and steal input.

In contrast 'well behaving' programs, using only DOS and BIOS could even continue to produce output in background. Same for Printers and serial lines (*2). In fact, I remember that somehow up to 6 'tasks' could run at the same time. Two real tasks, while the other being specialized like print spoolers.

In reality, many programs 'less than behaving' programs fail due to direct screen access. At the same time the majority do wait for user interaction at some point and don't issue any screen update when switching. So putting them in background won't do damage beside wasting CPU time for an idling application.

Then again DoubleDOS did offer a ways to get around that to a certain degree by setting the background execution to halt. So when foreground and background switch, everything gets saved and the program stops operation (*3).

---

Addendum 1: Time slice handling

It might be interesting to add the ways of handling time attribution to each task.

• 2:1 Foreground/Background
• 1:2 Foreground/Background
• 1:1 (equal time)
• 2:1 Upper/Lower Program
• 1:2 Upper/Lower Program
• Full time for Foreground

---

Addendum 2: Multitasking (and TSR) hooks

With DOS 2 a lot of hooks where designed into DOS to enable multitasking - much the same way as the AT BIOS introduced similar measures. From there on it was rather straightforward to build a tasking layer above DOS/BIOS. And Windows is maybe not the least example to do so.

On BIOS side this includes several functions to allow an OS independent protocol to detect and handle critical sections and process task swap. With the SysReq-Key even an OS independent user interaction was designed.

DOS added not only InDOS via Int 21h Function 34h (?), but also INT 28 to give a switching point/activity entry during idle. Beside InDOS function 34h also introduced an error flag which could be used to make the active DOS function fail in a (somewhat) orderly fashion. This again could be used in conjunction with the Error Handler at Int 24h(*4). To speed up the process. Int 23H also added the CTRL-BREAK handling as an entry point for task switchers/OSes due user request.

And then there was Int 2Fh, the MUX-Services. A collection of hooks mainly added by TSR utilities like PRINT, but also various versions of DOS (and various DOSes). There where functions from ASSIGN to PRINT over network and CD handling to a countless number of services provided by Windows, VM-Ware and alike. COMMAND.COM's command line handling being not the least :))

---

*1 - There are some function, especial the Character I/O which are usually safe to be used while InDOS is set.

*2 - Ofc. only if both tasks are not trying to access the same device on a character base - that is single byte (or line) output via DOS/BIOS. As soon a utility like PRINT was used even sharing a printer on job base was possible.

*3 - Not really desirable for a BBS, isn't it :))

*4 - Right, that's the one where the infamous Abort/Retry/Ignore/FAIL is displayed.

Answer 2

My deceased husband, Ed Tolson, was the owner and President of SoftLogic Solutions in Manchester, N.H. I wrote DoubleDOS and Carousel. The Doubledos program created a copy of the DOS operating system and switched between the two by hooking into the timer interrupt. Louise Duperron Tolson Mainella

Answer 3

Multitasking is absolutely not depending on modern CPUs like the 386 or anything - Those CPUs go one step beyond and protect multiple tasks from each other, while earlier MT OSs had to rely on behaving applications.

I co-wrote a multitasking system for x86 based on Turbo Pascal 5 and running from DOS for industrial control applications back in 1990. You "simply" set up a scheduler that was driven by one of the PC's system timers and interrupted the running task, stored all of that task's register contents onto the task's stack and restored another task for some time slices. I think we needed only one single assembler file and wrote all the rest in TP. Last time I looked they still had some machines running that OS.

Answer 4

I'm 61yrs old and my memory no longer serves me well but I do remember a few things about DOS. I purchased a book in the late 80's that contained a less optimized free version of DOS. That version of DOS (I can't remember for sure but I think it was MX-Dos) was very close to Caldera/DR-DOS and somewhat like FreeDos. (I suspect FreeDos is based on it) It included multi-user login, task switching, and several tools similar to QDos (cpm variant), DoubleDos, and QEMM. The book provided a short summary of every Dos C procedure.

There were also several excellent asm books written by Tom (edited) Swan on how task switching was accomplished. I eventually purchased about 15 of his books and he regularly contributed to Byte magazine. He wrote about 150 asm utilities that where published and given to Byte readers for free.

(As has all ready been pointed out, a TSR is a crude form of task switching - most lacked time slicing and live independent video support.) Exactly how the task switch was handled depended on the CPU mfg. Machine state was saved for the task switching but the details were different.

As mentioned by several folks above, all computers used TSR's for all BIOS i.e i/o intercept. For Intel CPU, the 80xx memory segment pointers would be saved and loaded appropriately for each task switch. The 80xx has extra hardware clock registers and software timer interrupts would trigger the task switch according to time slices. The 80286 and later chips supported better multitasking with specific registers designed for task switching.

The Z80 machines where even easier (I owned several), the Z-80 has two complete sets of registers and a single asm command will swap between them which made handling two OS environments a breeze. The Z80 has a dedicated external timer chip with 4 "counter/timer channels" (CTC) attached that could be software programmed for a software interrupt task switch - time slices.

An interesting bit of Z80 history... The two register sets where specifically provided to assist in easy interrupt handling but most programmers were scared of getting the wrong register set mixed so the mirror register set was almost never used.

I have no idea how the 6502 & 6800 CPU was handled. Now, back to DoubleDos. Programs could be run in two modes, with or without i/o and screen support. The video was a challenge because DOS machines lacked extra memory so switching video in and out was very slow and consumed a big chunk of the limited 64k program memory block (later extended XMS memory drivers got quite good at freeing lower program memory). There was not any virtual video memory (frame buffers) so all video had to be done on the actual physical video memory. Also, the video chip was accessing video memory live and any DMA had to be halted during the video read cycles.

Programs set to run without screen support ran almost transparently. Both the Z80 and 80xx had DMA but copying large blocks of memory at 4-8mhz caused significant flickering.

I do not remember the task switching rate, it seems to me that was user selectable to some degree. But, flicker was noticeable because everything had to swap live physical memory. The background program had to save the foreground video, load the background video, allow the background program to access physical screen memory, save it, and reload the foreground program video again. That was asking a lot from a 16bit CPU. Later, larger capacity video cards had "bit blasting" capability which was optimized DMA video memory manipulation and that almost eliminated the flicker.

It did not have resource tokens or arbitration so two programs sending output to a i/o device like the com port or printer would end up with gobbledygook. There where some clever folks that made add on print spool drivers, but DoubleDos did not manage it internally; or at least the early versions did not support it. Because there were no resource tokens there could never be deadlock. It was pretty much bullet proof except for an occasional TSR locking up. There was significant development between versions but MS deliberately killed it with pseudo task switching and a more powerful XMS manager in Dos 5 & 6.

Quarterdeck Deskview arrived and immediately surpassed it. DoubleDos died a very quick death shortly after the first DeskView release. Deskview had pretty much unlimited task switching, print and com spoolers, the best virtual memory manager, and 20 or 30 utilities; all for slightly more money than DoubleDos. Third party developers immediately wrote compatible games and utilities for it. For some reason DoubleDos never received third party support.