• Please review our updated Terms and Rules here

real mode "time sharing" multitasking... what is involved in this?

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
it's something i've been pondering lately. i mean like an interface that can work in x86 real mode, and basically "multitask" DOS sessions.

i would think that with a bit of clever programming, and sort of "dynamic recompilation" of existing machine code in memory... i.e. parse jumping and memory access operations to sort of reroute the data to where i want it. BIOS calls would also need to be intercepted and dealt with by the multitasker. this is possible, yes? it would get complicated allowing hardware to be shared between sessions. you'd need to handle some hardware "emulation" of sorts too so that each session instance thinks it's seeing it's own private piece of hardware and then the multitasking software needs to deal with the real transfer of info to and from real hardware.

obviously, if you only have 640 KB of you're going to need a swap file or something similar. i know this would be hideously slow on an old 8088 or 286, but still possible, i believe.

each DOS "session" could be given it's own chunk of 640 KB to work with, and of course there be a graphical or even text mode interface to reroute data from each session's 0xB800 segment where the video display data is. maybe via using Alt+F-key to switch between the sessions like on a linux console.

i know there's more to it, but i don't see why this couldn't be done. or maybe some of you guys who are real assembly experts can tell me why this WON'T work? lol.

it would be painfully slow on a vintage computer, but still do-able i'd think.
 
Last edited:
yes? it would get complicated allowing hardware to be shared between sessions. you'd need to handle some hardware "emulation" of sorts too so that each session instance thinks it's seeing it's own private piece of hardware and then the multitasking software needs to deal with the real transfer of info to and from real hardware.

Code:
Software = driver
Hardware = motor car

+-------------+  +-------------+
|  Driver #1  |  |  Driver #2  |
+-------------+  +-------------+
| Multitasker |  | Multitasker |
| private     |  | private     |
| view of car |  | view of car |
+------------------------------+
|         Motor car            |
+------------------------------+

Sequence:

1. Driver #1 steers left.
2. Multitasker alters driver #1's view of car to be making a left turn.
3. Multitasker puts car (hardware) into left-hand turn.
4. Driver #2's turn. Driver #2 (who by the way has a private view of the car that shows the car driving straight), decides to steer right, and does so.

What does the multitasker do?
 
Code:
Software = driver
Hardware = motor car

+-------------+  +-------------+
|  Driver #1  |  |  Driver #2  |
+-------------+  +-------------+
| Multitasker |  | Multitasker |
| private     |  | private     |
| view of car |  | view of car |
+------------------------------+
|         Motor car            |
+------------------------------+

Sequence:

1. Driver #1 steers left.
2. Multitasker alters driver #1's view of car to be making a left turn.
3. Multitasker puts car (hardware) into left-hand turn.
4. Driver #2's turn. Driver #2 (who by the way has a private view of the car that shows the car driving straight), decides to steer right, and does so.

What does the multitasker do?

lol. well in a situation like that, it all comes down to hardware emulation being able to look exactly like the real thing to the to the programs. this would work just fine for software that only does output to hardware.

a printer for example, would be controlled by a single print spooler that accepts data that the program thinks it's sending to a real printer. it saves that as a raw binary file on the hard drive, and if there are existing jobs that are not yet complete it will add the new job to the queue. first come first serve!

but of course that wouldn't work well for all programs because depending on the device they may have to have incoming data along with outgoing. obviously there will be situations where some programs have issues with that

there are 2 ways you can go about that. the most reliable being that the session's execution is halted until the hardware is available for it. the other way is using a "dummy device" that just drops all data passed through it.

that's about the most you could do i think. if i'm wrong about something, let me know.
 
Wouldn't you need to have devices such as the parallel port intercepted to prevent that problem. The program would think it's reading or writing to the correct port, but would instead be reading and writing to a buffer, and when it's active, the buffer contents go to or from the correct port?

That or just a device lock, so no two programs can access the same thing at once?

I did a bit of work on making something like this many years ago, never got beyond the planning stages.
 
Wouldn't you need to have devices such as the parallel port intercepted to prevent that problem. The program would think it's reading or writing to the correct port, but would instead be reading and writing to a buffer, and when it's active, the buffer contents go to or from the correct port?

That or just a device lock, so no two programs can access the same thing at once?

I did a bit of work on making something like this many years ago, never got beyond the planning stages.

yes, exactly. that's like the print queue spooler i was talking about. i think this would be very do-able. SLOWWWwww but do-able.
 
Are you talking something like DesqView on an 8088? It's been done already.

'Software Carousel' was another program that did this.
 
it seems like i'm behind the times here... i didn't know about desqview, sounds nice - i'm going to go look it up.
 
There were lots of multitasking applications. Heck, I even wrote a background floppy formatter called ConFormat. Worked just fine.

There are extensions in most 286-and-up BIOSes that make multitasking easier for the programmer. Most involve extensions to INT 15H services. MS-DOS after about 3.30 has hooks for multitasking (c.f. the InDOS flag). And there was Concurrent CP/M and Concurrent DOS from DRI very early on.

Didn't MS-DOS 5.0 come with a task-switching shell?
 
Last edited:
Are you talking something like DesqView on an 8088? It's been done already.

'Software Carousel' was another program that did this.

mike, this has me thinking... before we were talking about the development of a new DOS-based telnet BBS application. something like this could be implemented to allow the use of door programs originally designed to work on a serial port or modem.

some TSR-like hook code could be implemented on the timer interrupt before control is given to the door, which would either monitor the data on the screen and send updates using ANSI escape location codes or it could intercept everything it tried to send out through a serial I/O address.

similarly, data coming from the telnet could be make to look to the door like it's coming in over the serial port or manually injected into the keyboard buffer address in memory.

or if for some reason i'm wrong and this can't be done... a "ghetto" way of doing it could just be as simple as having two real RS-232 ports on the machine, and they could be connected together with a null modem cable. then you could just tell the door to use a serial port like it normally would and the BBS hook's code could communicate with it by accessing the other port it's connected to.

when this IRC server is "done" (as in, i can feel comfortable putting it up for download when it's stable and not missing anything :eek:) i would love to start work on something like this.
 
There were lots of multitasking applications. Heck, I even wrote a background floppy formatter called ConFormat. Worked just fine.

There are extensions in most 286-and-up BIOSes that make multitasking easier for the programmer. Most involve extensions to INT 15H services. MS-DOS after about 3.30 has hooks for multitasking (c.f. the InDOS flag). And there was Concurrent CP/M and Concurrent DOS from DRI very early on.

Didn't MS-DOS 5.0 come with a task-switching shell?

interesting. i don't recall if it came with one, i was a young'un back then. i do seem to recall a couple new CPU instructions that they put into the 80186 and later chips, where you could store all the CPU registers to a memory location (i think anyway) with one op code, and another one to restore the registers.

that could be useful for multitasking, for sure. :)

EDIT: on the subject of the IRC server... i am very happy today, i woke up and there are a handful of the vc guys in there chatting, it seems without any issues! :)

great news for me, it tells me that the code seems to be stable. before i'm ready to release the whole thing publically, i was going to have it running on the slowest machine in the house here (the 8088 obviously) and set up a good 10 or more eggdrop bots that will all talk amongst themselves to connect and join a channel from various machines around the house here on the LAN...

if it handles that error-free for 2+ days, i'm going to assume it's in good shape.
 
Last edited:
mike, this has me thinking... before we were talking about the development of a new DOS-based telnet BBS application. something like this could be implemented to allow the use of door programs originally designed to work on a serial port or modem.

Yes, for those, research Fossil drivers. :) Desqview and fossil (or OS/2 and fossil) was used to run many a BBS...
 
wow i'm a lot stupider than i thought i was.

i have heard of FOSSIL before, i didn't really know what it was used for. it's been a long time since i've dealt with BBS stuff, so i haven't really looked into it.
 
-------
You're probably thinking of DOSSHELL, which was part of DOS from 4.0 on IIRC. Software Carousel was better though...

Yeah, that was it. I try to blot DOS 4.00 out of my mind--it was sooo bad... 4.01 was much better, but by then, my trust had been damaged.
 
Sorry to revive what looks like a dead thread. I've been overseas. I'm trying to get caught up on all the fun stuff I missed here while I was away.

I wrote a DOS based multitasker in 8088 assembly language. It was the final project in my assembly language class back almost 20 years ago, and one of the more challenging projects I did as an undergrad: conceptually easy, but terrible to debug. Simultaneously the program wrote characters to the screen, responded to the keyboard, and wrote characters to the printer. I remember how to do it, and I could probably do it again armed with just an assembly book and a BIOS map. I still have the source code, and I can send it if you want it.

In fact there does not *need* to be buffering, or any kind of resource management: it all depends on what you're trying to accomplish. OTOH, a message passing architecture can solve some of these problems. However, my program did none of this and it ran fine for what it was intended to do. Just remember that there's a reason why there is a lack of multitasking software for DOS: the operating system is mostly non-reentrant. These are design choices that were made that render it a single-tasking OS.

However, if you're willing to live without the benefits of DOS (i.e., all the DOS interrupt functions that do things like disk I/O) and have your program spend its time in BIOS land (although some BIOS calls are also non-reentrant) and on the bare metal, then there's no reason you couldn't write a nifty real-mode multitasker. The 8088's segmentation makes it an (almost) ideal CPU for this. Just don't try to write a *DOS program* multitasker. (1) You will have limited success, and (2) like others in this thread have said, it's been done already. DesqView was probably the best one, but see (1) in the previous sentence.
 
Back
Top