It’s a piece of common knowledge, that MS-DOS wasn’t capable of multitasking. For that, the Microsoft-based PC user would have to wait for the 80386, and usable versions of Windows. But like so many such pieces of received Opinion, this one is full of holes. As [Lunduke] investigates, there were several ways to multitask DOS, and they didn’t all depend on third-party software.
A quick look at DESQview and Concurrent DOS was expected from this article, but of more surprise is that IBM had a multitasking DOS called TopView, or even that Microsoft themselves released the fully multitasking MS-DOS 4.0. We remember DOS 4 as being less than sparkling, but reading the article it’s obvious that we’re thinking of the single-tasking version 4.01.
From 2023 it seems obvious that multitasking is a fundamental requirement of PC use, but surprisingly back in the 1980s a PC was much more a single-application device. On one hand it’s surprising given the number of multitasking DOS products on the market that none of them became mainstream, but perhaps the best evidence of the PC market simply not being ready for it comes in the fact that they didn’t.
If you fancy experimenting with DOS multitasking, at least machines on which to do it can still be found.
Lest ye not forget there was once a multiuser multitasking BASIC operating system for PCs. Yes, someone saw fit to do such a thing, for business users, because BASIC is the only programming language anyone should need to run their business.
Which one do you have in mind?
Several 1970s minicomputer OSes were based around BASIC. Pick was largely driven from BASIC, AFAIK, and its embedding of a RDBMS into the OS itself was startlingly modern.
Pick wasn’t based on a rdbms. The os and the multi-valued database system was monolithic hierarchical file system typeless text database. It was very odd but very powerful on simple hardware
So – the statement that DOS didn’t multitask, even prior to 4.0 and things this article mentions like DESQview, is just incorrect. We had programs called TSR (Terminate-and-Stay-Resident) programs for a long time – Borland’s Sidekick being the 800 lb gorilla, but lots of people made them. They’d load into memory, and were invoked over the top of your normal program via a hotkey and interrupt chaining. Calculators, calendars, and so on – it was quite common. They were fairly limited because trying to cram everything into limited memory and still leave anything left for your main program was a challenge – but they were there. Once the 286 and expanded memory came along, it opened up a lot, and the 386 and memory mapping made multitasking of full-sized programs a reasonable possibility. DESQview/386 was the first widely-used environment (topview was earlier but basically stillborn) to include full pre-emptive multitasking with no special requirements for the software being multitasked, but it certainly existed before then in more limited forms. (Eventually windows/386 came out with proper graphics and a few killer apps like Adobe Pagemaker and Excel and kinda took over…)
Source: I worked for Quarterdeck Office Systems back in the day, supporting DESQview, QEMM, and the other utilities we sold, at the time running on DOS 3.3. I frequently switched between 5 or 6 different programs running in a text windowed environment simultaneously.
TSRs are (were) not multitasking, they were multiprogramming.
Multiprogramming: having >1 program loaded into the same memory space at the same time. Only 1 at a time can run.
Multitasking: having >1 program in memory _and time switching between them_ under OS control.
But TSRs or add-ons like DESQview (of which I was a big fan, especially DV/X, and I wish its source code had survived!) are not part of DOS itself.
Not necessarily, the trick is whether the “backgrounded” program has anything useful to be doing or not – a calculator you’re not using likely don’t, for instance. I seem remember some silly TSRs like putting a small (text-only) clock on the corner of your display or similar things.
Your TSR would stay inactive until some interrupt triggered it, at which time it would do some work and then pass control to the next interrupt handler in the chain. A keyboard interrupt and watching for a hotkey was an obvious and very useful way to get the TST to wake-up, but you could also attach the program to a timer interrupt, I/O, etc.
I used to know that stuff, wrote a couple TSRs way back when, but those memory pages have long since been reclaimed for more current knowledge. It’s a pity, that stuff was fun, I’d gladly store a bit less cat videos in my brain in exchange to remembering old DOS assembly programming :)
TSR: Terminate and Stay Resident. It means program stops running (reach an expected exit point) and should remain available for and if the user (or other program) invokes it again. That’s not multitasking but task-switching, a common term at the time. Switching was mostly a manual thing and the rare background utilities intercepting app function calls weren’t really running in parallel to the front app.
Multiprogramming could switch between tasks but it would only do so when it reached a point where it was waiting for an interrupt (e.g. keyboard input). Mulitasking is when a controlling program (e.g. kernel) would interrupt execution at any giving point, typically based on execution time and priority.
What this means is that in a multiprogramming environment, the current executing program rules the day… so long as it’s not waiting for an interrupt. If a program hit an infinite loop then your entire system would hang.
So cooperative multitasking is not multitasking?
Cooperative multitasking is not really multitasking. When only specially written programs will appear to multitask, you have a parlor trick. It’s a fun and useful parlor trick but it’s not so fun or useful when all of the programs you need to run aren’t part of that specially written pack.
The Amiga had true multitasking.
Microsoft finally got around to it with Windows 2000.
It depends on point-of-view, of the definition of what multi-tasking actually is.
At its core, it’s just a different philosophy.
A single CPU with one core can never do “real multitasking” in the sense of simultaneous execution of multiple code.
It’s all just use of a clever time-sharing mechanisms, which makes applications appear to run simultaneous. In reality, all applications are being run in a stop-and-go fashion.
At its core, the difference between cooperative/preemptive multitasking relates to democracy vs dictatorship.
In Cooperative Multitasking, applications are being run in a message-based model. A “system” like Windows 3.1x does create a message loop in which every programs gets its chance to take control/do its job.
After doing it’s stuff, it’s expected to give freely back that control to the system, which in turn lets the next application do its thing.
This design philosophy doesn’t require complex mechanisms, since applications do freely “cooperate”. It’s also very quick if only a handful of applications are active.
Unfortunately, some programs are buggy, badly written or not very diplomatic. Some also “think” that they are top priority themselves and hesitate to give back control to Windows. In such a case, the system appears to react sluggish or hangs.
t’s that the cause, a watchdog of Windows 3.1x is being triggered. A blue screen says that the program nolonger responds. In that case, Windows offers the option to intercept and halt the program.
Preemptive Multitasking, by contrast, has a time-slice or time-slot that’s evenly shared among all applications. Control is being taken away by the system in repeating intervals, forcefully.
Thats not as efficient as it seems at first glance. Programs doing a critical task might be stopped in the middle of their work, without any exceptions to the rule.
That’s why polling-based applications are being better off with DOS or 16-Bit Windows, which don’t get “in the way”.
> If a program hit an infinite loop then your entire system would hang.
This is _only_ true if your cpu has 1 core, as the other cores will work normal.
Even interrupt driven TSRs will function normal, while the busy loop stalls on that core or cpu.
> If a program hit an infinite loop then your entire system would hang.
This is _only_ true if your cpu has 1 core, as the other cores will work normal.
This was true for Windows 9X later on. So two steps forward one step back on that one lol
Yea, windows 9x would lock up if you had a badly made DVD. If the TOC had a loop, windows Media player would loop and nothing would work, but if you already had task manager launched you could kill Media player. But you could not launch task manager. Not even the mouse would work, but you could use the key board to switch to task manager.
Then, from Windows 3.1 and earlier, Windows had no multitasking capanilities, since it was called from DOS (as a program), but with the added feature of running into x86 protected mode?
“Once the 286 and expanded memory came along, it opened up a lot, and the 386 and memory mapping made multitasking of full-sized programs a reasonable possibility. ”
Not wrong, but Expanded Memory Specification was made with PC/XT era PCs with 808x/NEC processors in mind.
That’s why the idea of bank-switching and the page frame was used, after all.
– On a 286 or 386 you could directly address extended memory instead.
The original way of doing it was using an EMS board like AST Rampage or Intel Aboveboard.
Sure, these weren’t cheap. But what was cheap back then, anyway? An EMS board was an useful accessory at the time.
With 286 mainboards came the chipsets (NEAT, HT12 etc) which had MMU like features.
Some of them had EMS support, too. But not seldomly, it was basic EMS 3.2 era EMS in terms of features (64KB page frame). No DMA, no backfilling, no Large Frame EMS (256KB or bigger). And so on. Still, it worked with popular environments like Windows 2.x, in which non-DOS applications couldn’t use XMS yet.
The 386, build upon 286 architecture, had the V86 feature and an enhanced memory management unit with a paging feature. It could simulate multiple x86 sessions without extra hardware.
However, V86 (remember EMM386?) caused a not so insignificant performance penalty on 386 and 486 processors. It wasn’t until late 486 CPUs that VME (Enhanced V86) was introduced. It fixed the performance issues. QEMM 7 and similar memory managers supported VME (see Pentium sticker on big box). You guys may remember it. VME was the one which the AMD Ryzen had totally messed up a few years ago.
“DESQview/386 was the first widely-used environment (topview was earlier but basically stillborn) to include full pre-emptive multitasking with no special requirements for the software being multitasked, but it certainly existed before then in more limited forms [..] ”
The “normal” DESView for PC/XTs wasn’t being unheard of, either, though. With an EEMS/LIM4 capable EMS board w/ 512KB RAM (and up; 2MB ideally) it had all it needs. In fact, I heard (read) about plain DESQView much more than about DESQView /386 or DESQView /X. All the shareware CDs if the 90s and even older magazines had stuff related to normal DESQView.
yeah i came here to basically say this. i *really* wanted something like desqview that would let me run full dos apps side-by-side but there were so many caveats (not the least of which is i didn’t own a copy of desqview), and i only finally achieved that dream with dosemu under linux. but for primitive things, single-purpose programs, it was absolutely possible, bordering on commonplace. TSRs could trap the timer interrupt the same way modern kernel task-switching does. things like audio playback in the background were very achievable (all the processing can happen in the soundblaster IRQ handler), so long as your foreground task didn’t crash everything by trying to talk to your soundblaster.
really, most good programs were structured like this already. all of the sound processing happened in the sound IRQ. all of the Z-modem file transfer happened in the serial IRQ. all that these programs were missing was the UI feature to terminate the UI and let the IRQ run hidden-from-view. of course, then we’d suffer the blocking file I/O but given how little those computers accomplished anyways, that overhead might not have seemed like so much!
i also had a bespoke hack on one of my PCs to be able to read text files on a second monitor without interrupting the primary task — it did all of its work hanging off of the keyboard handler. i got as far as being able to edit single lines of text ‘in the background’ for command functionality before i managed to get a PC with linux and overnight completely lost interest in pushing the limits of DOS.
MS-DOS 4.x and IBM PC DOS 4.x were NOT multi tasking. They were, however, memory hogging buggy messes and were quickly abandoned.
Lots of people tried this:- Desqview 386, Windows386, IBM Topview, IBM PC3270, DOS-386, DR Concurrent DOS and quite a few others
On a 80386 or later CPU, you could, WITH THE CORRECT SOFTWARE, run multiple DOS tasks. The best of these, was IBM’s OS/2 WARP and truly was, a better DOS, than MS-DOS.
https://winworldpc.com/product/os-2-warp-4/os-2-warp-40
It was the Me/Vista of DOS, yes. DOS v4 had an interesting IFS, installable file system, though. If that feature was kept, DOS 5+ could have had ended up supporting external filesystem modules, thus allowing for HPFS and NTFS support.
https://en.wikipedia.org/wiki/Installable_File_System
I forgot to mention, there were two DOS v4. Multitasking DOS v4 of the mid-80s and the ordinary DOS 4.x of late 80s.
Multitasking DOS 4 was a proto-OS/2, so to say.
Also interesting: Concurrent DOS 286 could multi-task certain DOS applications on an 80286, without the need for V86.
https://en.wikipedia.org/wiki/Multiuser_DOS
Also interesting were Double DOS and The Software Carousel.
They allowed to split DOS “into pieces”, to allow for running at least two DOS applications simultaneously.
I ran Software Carousel for years on my HP200LX. I believe the term they used for it was task switching. But still, it was incredibly useful. I had almost ten session reserved for different tasks, like reading, games, C development projects, web browsing, etc. Each one was just a hot key away.
No, you were not “web” browsing
> MS-DOS 4.x and IBM PC DOS 4.x were NOT multi tasking.
You miss the point here.
There were 2 different OSes from MS both called “DOS 4”.
MS’s MS-DOS 4 was a multitasking DOS that *preceded* IBM’s PC DOS 4.
http://www.os2museum.com/wp/multitasking-ms-dos-4-0-lives/
Here’s more detailed background about the fully preemptive “Multitasking MS-DOS 4.00”. It was a derivative of MS-DOS 3.1 unrelated to the retail MS-DOS 4.00 release years later. It operated within the 640K limit. There’s even a copy running in a 5160 emulator on the page! https://www.pcjs.org/software/pcx86/sys/dos/microsoft/4.0M/
Yes! You beat me to the comment. In fact I would run several DOS sessions concurrently in Warp. BASIC programs mostly.
I was waiting for someone to mention os2 warp… That could of been even better, but alone it could multitask. Open two command prompt windows… One with the media version, the other with the os2 command.com and they could both run simutaniously. Impressive at the time for 17 year old me.
I remember that PC-MOS/386 v3 could multi-task on an XT class PC, though a 286 -better 386- was required to take advantage of all the features, especially memory management and so on. The higher processing power really was useful if multiple DOS applications were accessed via physical terminals.
And it is open source now
And is still a steaming, useless pile of bugs, even on a 386.
I suffered through an attempt at using it as a dial in server, just awful.
But on the upside, the docs were incorrect and incomplete.
Joshua is repeating their marketing lies.
IIRC it only worked, at all, with their overpriced 4 serial port card. Which used some bazaar UARTs to handle infrequent service. Between that, the wasted time and the price of terminals it made the whole deal a terrible idea.
“Joshua is repeating their marketing lies.”
Ahem. It’s a known fact that insulting/attacking people on a personal level is an indication for immaturity and the lack of good counter-arguments. And an indication that someone simply can’t cope with facts, or opinions of others. Generally speaking, of course.
PS: A part of my family and me had used PC-MOS/386 decades ago. The original 5,25″ disks are still here. And I don’t see how the printed manual was incorrect in any way (maybe it was at some point, but then I’d like to know about it).
For a ~1987 era product MOS wasn’t bad. We have ancient computer magazines at home featuring both DESQView and MOS in their articles; they’re not lying, either, I think.
That being said, v5 is open source now. Everyone is free to double-check its promises.
“And is still a steaming, useless pile of bugs, even on a 386.
I suffered through an attempt at using it as a dial in server, just awful.
But on the upside, the docs were incorrect and incomplete.”
I suppose that’s because it was an early version of PC-MOS.
When it was young, it was still under development. Well behaved DOS programs ran fine already, but those using magical tricks didn’t. Norton Commander was such an example.
It was running fine with v3 and up, I vaguely remember.
Anyway, I don’t understand the lack of technical competence and the use of gutter language.
DOS programs from mid-80s onwards (-past the day of generic, DOS compatible PCs that weren’t IBM PC compatible-) were not seldomly written in a very hackish way. The polled things, they wrote directly into video buffer, perfored address arithmetics, monitored the keyboard controller etc.
Doing a virtualization of them, without extra hardware, was very difficult. And that’s why I can’t understand why someone with the slightest bit of IT competence can complain about a DOS compatible multi-tasking OS. People should have been grateful that it existed, at all. It wasn’t something to be taken for granted. In my opinion.
Best wishes and good night.
It sucked balls dude. I wasted a few weeks on it in about 1989.
The fact it required a special serial card was not documented, except on their BBS. That was the final deal breaker. There was no way for it to save money (even if it worked as advertised) vs. just setting up a few PCs.
After wasting weeks, they said: ‘Oh, it won’t work with a standard modem, you need to buy our $2000 4 port serial card and use external modems.’ We said: ‘No, you need to accept your steaming pile of software back and we’ll just charge the CC back. Thanks.’
In the end, I spent hours on their BBS. Which was the only way anybody was getting anything working. Like pulling teeth. Bet they didn’t run their own BBS on PC-MOS.
The fact I walked away and you beat on that junk until it sort of worked makes you the one who ‘lacks technical competence’. Nothing more expensive than flakey software.
We just implemented dial up bridges between networks instead.
My recollection from the early 90s is you could toggle back and forth between a couple applications but they did not run at the same time. DOS 5 is the last version I used.
MS-DOS Shell had a basic task-switcher (program-switcher). DR DOS 6 had something similar, I think. It was part of ViewMAX as TaskMAX.
https://en.wikipedia.org/wiki/DOS_Shell
https://en.wikipedia.org/wiki/ViewMAX
You are conflating 3 different things.
[1]
DOSShell could task switch, but this is not multitasking. Background tasks are suspended; only 1 program at a time can run.
[2]
DR-DOS’ TaskMax can do true multitasking: all tasks run at once, timesliced by the OS.
[3]
ViewMax put a simple GUI on TaskMax, but it didn’t do any of the switching or anything. You can run TaskMax without ViewMax, and DR DOS 7 included TaskMax but did not include ViewMax.
DOS and BIOS weren’t reentrant and there were no time sharing or task switching functions in DOS. It didn’t even have the concept of “tasks”. In order to multitask, your multitasking program had to setup its own “big kernel lock”, then setup and maintain the multitasking. Which is what these utilities did.
This was so common that this category of utilities had its own abbreviation: TSR, for “Terminate Stay Resident” (and by staying resident, do extra things in the background).
So in fact, DOS could not, and did not, multitask. Several vendors found ways around this, but this wasn’t a feature of DOS.
The problem, I think, is that DOS is,-at least nowadays-, rather a family of API/ABI compatible operating systems, comparable to CP/M (numerous implementations).
Speaking of, there was MP/M.. :)
I wrote a couple of simple TSR-thingamabobs myself, like e.g. a clock in the upper-right corner that kept updating every second.
For the minimum setup, you’d basically hook into the timer tick handler, redirecting it to your code and then your code would call the original handler once finished. You’d also hook into any other interrupts that would interfere with whatever you were doing, like e.g. you might hook into INT 10h, so you could disable some functionality, if a call to change into graphical 320×240 VGA-mode was made.
For the uninitiated: INT-calls are instructions for the CPU to look up the address of the desired interrupt on the interrupt handler table and then temporarily redirect execution to that address, ie. an interrupt handler, while also setting up return address on the stack. Once the handler was finished, it’d issue a RET, popping the address back from the stack and returning execution to the next instruction after the INT-call.
BIOS provides a number of basic interrupt handlers, which is ostensibly where the name “Basic Input Output System” comes from, see e.g.: https://en.wikipedia.org/wiki/BIOS_interrupt_call — DOS and others would typically hook into some of those, redirecting them. INT 13h was a common one that was replaced with one with extended functionality, like e.g. being able to access addresses within a FAT-filesystem instead of just raw LBA-addresses on the disk. Incidentally, this is basically the same process you’d go through if you were to write your own kernel/OS — been there, done that.
I wrote a Voicemail system completely as a TSR (talking to a Rhetorex [Dialogic clone] board). It powered Voicemail systems in the UK on Mitel phones systems for years… we pulled the plug on the last DOS 6.22 system last year!
Ha! I also wrote one, but mine was implemented as a state machine, and ran multithreaded under that.
It ran up to 4 Rhetorex boards under MSDOS3.0. Or maybe even 2.1.
I went on to create a networked audio node back in 1989 which was 4 cards again in a DOS chassis, and multiple chassis networked to a 386 running Unix. The control computer ran the same program ‘n’ times to handle multiple concurrent callers.
My first “IoT” device!
To run several applications at the same time you need lots more RAM than you need for one, with proper addressability from the processor, and RAM was expensive. And you really need more than a 80×25 screen for it not to be too frustrating to be used.
So even though there might have been technical solutions, there were other reasons why they were not a commercial success.
Yes. That’s why DESQView supported EEMS and LIM4. EMS board features like backfilling and/or Large Frame EMS helped at quickly multitasking DOS programs. It mainly helped blending in and out whole applications. The EMS board was essentially taking the role of an memory management unit, an MMU, by replacing conventional memory physically installed on the motherboard (had to be removed in favor of the memory provided by the EMS board). DESQView /X and QEMM 7+ were a good match, too.
I forgot to mention, DESQView (DOS) and OSes like PC-MOS/386 had the ability to multitask graphical applications, too. VGA applications like Windows 2 or 3 could be multitasked, too. For text-mode applications, windows could be used. They could be resized. If the graphics hardware had EGA or VGA or SVGA capabilities, 80×43, 80×50 or 132×25 or 133×43 or higher text-mode resolutions were possible.
https://www.youtube.com/watch?v=Sf0GDQsvOEQ
And open sourced, pcmos386!
> And you really need more than a 80×25 screen for it not to be too frustrating to be used.
No you didn’t. You make a big assumption: that they are all on the same screen at the same time.
They weren’t.
DR Concurrent CP/M and Concurrent DOS had multitasking with no windowing: you switched between virtual consoles to switch between tasks. You pressed Ctrl+1/2/3/4 on the numeric keypad to switch vconsoles. This still works on Linux today: Alt+F1 through F6 switched through 6 standard virtual consoles, and the programs on each all run at once. (F7 is usually reserved for the GUI. If you are looking at that, press Ctrl+Alt+F1 to get to vconsole #1.)
This even worked on dumb terminals attached to a host PC’s serial ports.
So a standard PC could have 2 serial terminals on COM1: and COM2: and the user on the console *and* the users on the 2 terminals got 4 tasks each: 12 tasks in total.
If you added a serial port card, you could have dozens of terminals, each able to run up to 4 tasks concurrently.
TurboDos was a multiuser, multiprocessor CP/M compatible OS. Each user had a dedicated cpu and memory and shared access to disks and printers
I used to multitask DOS. I’d run several MSDOS emulators on an Amiga :)
I used DESQview back in the day (probably 1992-93?), and from what I recall it was always billed as “task-switching” versus being true “multi-tasking”. It was, nevertheless, a pretty useful and a big leap forward for DOS users.
Everyone fortunate enough to have had an Amiga laughed at it (and Windows up through Win95).
It was quite a popular approach for DOS programs – become a resident, hook on the timer interrupt. Which was, in a way, a primitive multitasking.
I did a year or so in local government from late 1991, they had Concurrent DOS running on PCs with multi-port serial cards, each with 3 or 4 dumb terminals hanging off (WordStar and Lotus mostly). Worked pretty well in that simpler context, although I do now remember a fair amount of problem solving was simply rebooting the PC (so maybe not so perfect!). Windows 3.x then started to come in and replace terminals with a PC for every desk.
Multi-tasking as a concept was easier for people to grasp in the context of machine sharing – but in my next job, even some quite seasoned computing professionals were surprisingly dismissive of, really couldn’t see the benefits to, some proper pre-emptive multi-tasking!
During the early days, much of what was considered ‘multitasking’ was more about the cooperative model. Here, programs essentially took turns using the CPU. When you were actively using one application, the others weren’t running or processing tasks in the background. For many, if it wasn’t preemptive, it wasn’t truly multitasking.
This perspective is why there’s some reluctance to label early DOS environments as ‘multitasking’. It wasn’t until the 386 came along, with its preemptive multitasking capabilities, that we saw the kind of simultaneous task management we’re used to today. With the 386’s features, the OS could effectively manage multiple tasks, ensuring they operated at the same time without interfering with one another.
In the 80s, using DOS when teaching OS theory was a no brainer. I learnt to create a time/task scheduling OS and disk io driver as a lecture hall exercise. These days I expect it’s junior school stuff.
Not sure if that’s entirely correct. To my understanding, DESView and PC-MOS/386 both used preemptive multitasking way back in the 80s. Even on an 8086 without V86. Could it be you may confuse this because MS Windows and MacOS (“System”) being so limited in their early years and their initial use of cooperative multitasking? On other platforms using simple Motorola 68k (Amiga), there’s preemptive multitasking, too, without any need for 32-Bit or V86.
Because disks were expensive, and likely UNIX licenses, UNIX was not widely used nor mentioned back in the day. But a real preemptive multitasking OS on the 286 and 386 was available back when DOS ruled the desktop PC markets. Microport UNIX was one such UNIX port which worked well and C was the default language of choice, not BASIC. If you had a VT100 terminal or two you also got full multi-user capabilities through the 2 RS232 ports built into those old PC AT and PC XT motherboards. https://en.wikipedia.org/wiki/Microport_Systems
Yeah I ran this with IBM PC XT’s running terminal emulators. System V/386.
When anyone did a build is was customary to announce across the office!
As it got a bit slow for everyone. We used an RS232 expander card with 16560 UARTS or else you could drop characters too.
I understand that the topic is DOS, but OS/2 did offer true preemptive multitasking on a single platform back in the 80s. I’m surprised that no one has mentioned that. The bad thing is that IBM didn’t market it correctly which allowed Windows to take over. :)
OS/2 was an actual multitasking os unlike Windows. Version 1.3 ran very nicely on a 32 MHZ 386.
OS/2 v1.00 runs on a 286, it was fun to format disquettes while running other stuff at the same time.
> OS/2 v1.00 runs on a 286, it was fun to format disquettes while running other stuff at the same time.
The Commodore 64 (1982) and Vic-20 (1980) and the PET (1977) could do that too.
I used double dos and ran a two line BBS (RBBS) under dos 3.X. I’d use the other session for admin functions and managing the files.
https://winworldpc.com/product/doubledos/2x
I really loved SideKick back in the day!
Even Microware OS9 L1, could multitask quite well in 1979–1980, and was a time-slicer.
I wish it were open source.
Question. Isn’t any multitasking that involves suspending all other programs except one whether by interupt, time slice, context switching etc. just task switching rather than “multitasking”? It always seemed to me that only a system where 2 or more “program counters” if you will, are advanced on the same clock tic was truly multitasking. It seemed to me that for premptive miltitasking back in the day was MS marketing speak for TSR, which at the time I took to be task switching, but leaving other programs in memory waiting for their time to increment. Is this incorrect?
The same thing has seemed aparent to me in people since “multitasking” started to show up in job descriptions. I have known a small handfull people who would seem to be possible multitaskers, but many excellent task switchers. Far example my grandfather was able to read an article while engaging with one or more conversations and summaraze all (effect of 7 kids maybe :-)
i don’t care to argue semantics but up through roughly 2005 when intel and AMD started making duo / x2 sort of processors (two cores in one chip), that ‘task switching’ is the most that just about anybody had. the ‘multi-tasking’ linux i used in 1995 would task switch 100 times a second, but only one PC would increment at any moment.
i look at it more from a user perspective, dividing each second into 100 slices certainly gave me a near-perfect sensation of multi-tasking — i could run two compute-intensive tasks and they’d each visibly progress in the time it took me to ask “is it done yet?”, and often without starving event-driven processes (like the command shell, which truly only wakes when you type at it), regardless of how you want to split that hair.
There was also a program named Multilink that would do simultaneous execution of multiple programs under DOS. It was a product of The Software Link. It was advertised as allowing multiple users on the same PC through serial consoles but I knew people who used it to run a BBS while still using their PC. A quick google didn’t find much info on it but here’s an advertisement in PC Mag: https://books.google.com/books?id=Udw3QWX2LQ8C&pg=PA40&lpg=PA40&dq=%22dos%22+%22multilink%22&source=bl&ots=v0EQ_eazgp&sig=ACfU3U1RxDgQAlB5SrUpFYIb-1AZQJUgMA&hl=en&sa=X&ved=2ahUKEwjpsuvZvtGAAxXtIkQIHSYJCfU4HhDoAXoECAMQAw#v=onepage&q=%22dos%22%20%22multilink%22&f=false
So what about TSRs? Sounds like multi-tasking to me. If you hook em up to the clock timer you get an 18.2 Hz resolution for context switching. Makes it easy enough to implement stuff that “multitasks”
Hello,
I wrote small multitasker MSCREEN for MSDOS in 1992-1995. We were very limited in RAM, DESQView din’t fit our setup, but we had to handle BBS calls, Fido and UUCP mail handling on the same computer. Everything ran under MS DOS on PC XT, later on PC AT.
I made sources available on github: https://github.com/ikod/mscreen – everything done in ASM for 8086. I hope some day to run in in DOS emulator… :)
It even work under DOS 6 in VirtualBox… I attached screencast with two parallel shells – one continuously list files in root directory, and second run Norton Commander variant.
https://user-images.githubusercontent.com/1273417/261875523-54dc1b96-513c-4ea9-a583-b3fc1aec03c4.mp4
The people who think there was PC multitasking prior to Windows 2000 are the same class that think their PCs or Macs have sprites (surprise! They don’t).
Or they think TSRs are multitasking. Or they think programs specially written to “cooperatively multitask” count as real multitasking (well, the C64 can play music, do fast graphics, load from one drive, while formatting another drive all at the same time).
If you wanted actual multitasking in the 80’s or 90’s, you went Amiga or Unix.
This not to say there were not things like Xenix and Unix that would run on select Intel chips. But if you wanted multitasking, odds are you knew Intel wasn’t a good option.
In the late 70s, there was MP/M, as well.
It was being followed by CPNet and MP/M II soon.
There also was an x86 port.
https://hackaday.io/project/163683-the-thing-fpga-stm32/log/165910-the-mpm-experiment
https://www.youtube.com/watch?v=MXc8Imz-w-A
Sagan…
now. how did unix work? High level it loaded one or more programs in memory. And depending on the interrupts/timers etc, it switched to a different piece of code.
now, replace the timer/interrupt with an interrupt kicked off by a hot key. One program stops (like unix in the past or your game stuff), runs a different program.
The issue is that the only difference is the timing. If you switch tasks a lot of times in a second, it did still perform that only task and nothing else. So basically it’s task switching, just the same as your examples.
Now with the multi-core stuff, things started to become different. Also protection/isolation between software etc etc.
Intel was not a good option — because why? SCO (unix) minix (same) ran on an intel. A motorla chip is not a holy grail or something. It’s just different.
Yes I did a few shortcuts to keep it understandable. It’s like a real time OS. The definition tells you about guaranteed “delivery” of something. In that sense is a clock also RT. And the monthy payout too if you have a good employer. It’s just the timing that surprisingly makes the difference. So does f/g bbg switching and you name it. The appearance is multitasking.
am I the only one that ran and still runs DR-DOS???
it definitely multitasks
on my DX4-100, I was showing a mate the multi tasking, forgot I had fractint running
while we were looking at a text file at the same time Duke Nukem was running, we heard the fractint completion noise come up
at the same time as the Duke Nukem “attract” screen was running
DR-DOS was way cool, smaller memory footprint, fast load times
just better all round
you were not alone. I tried DR-DOS, DesQview, OS/2, PC-MOS/386 5.01. It ended when I started playing with minix, sco unix, and finally slackware.
Slachware drove me short to Redhat’s stuff that time but swiftly went to SUSE in “all” it’s forms.
And that is precisely the reason (MS-DOS being mono-tasking) I got to know and got involved with Unix and UNIX-like Operating Systems. Mostly back then I ended working with Xenix as I was looking for something that could attend several serial ports at once, to hook models to built a multiuser system, pretty much similar to what was later known as BBS (Bulletin Board Systems)… oh those days… glorious days…
Back in the ’90s it was Task switching using TSRs in single tasking Dos(ie not multi user versions). Co-operative-Multitasking Win/386-3.x and Classic MacOS. Preemptive in OS/2 v2 up, NT Based Windows and all the *nix based stuff.
My first Dos was DR-DOS 6 matched with the GeoWorks Ensemble Pro 1.2 GUI on a 286/16 and the Task Switching worked well between these.