I read that DOS is a single-tasking OS.

But if old versions of Windows (also including Windows 95?) were just wrappers of DOS, how could Windows run as a multitasking OS?

  • 8
    It's called preemptive multitasking - support.microsoft.com/kb/117567
    – joeqwerty
    Mar 8, 2014 at 14:46
  • 20
    You're going to have to define "old" a lot better than that. DOS+Windows 9x and DOS+Windows 3.x in "386 Enhanced Mode" were quite different in this regard to DOS+Windows 3.x/2.x in "Standard Mode" and "Real Mode". And as joeqwerty alludes, there was coöperative multi-tasking as well as preëmptive. Whole books have been written on this, so a specific question is better.
    – JdeBP
    Mar 8, 2014 at 16:15
  • 7
    @joeqwerty The most awesome IMO is that Microsoft keeps documentation online about so antique software. There are even articles about advanced topics on older versions of MS-DOS... Really nice of them to keep that alive. Mar 8, 2014 at 17:38
  • 6
    DOS doesn't give you multitasking. You can still write fully multitasking programs on top of it without DOS's help, which is what early Windows does. Windows 95 is certainly not just a "wrapper" for DOS.
    – Boann
    Mar 9, 2014 at 14:21
  • 3
    @NigelNquande I've actually found MS to be fairly good about maintaining old documentation. Most of their retired KB articles are online (for example; a random Windows 3.1 KB, or docs on the print utility for Windows 2.1-3.0, or ansi.sys from MS-DOS 5.0), even after their stated 12-month end-of-life grace period. It's just not as easily browsable as active product documentation, you sort of have to be specific in your searches.
    – Jason C
    Mar 9, 2014 at 21:18

7 Answers 7


Windows 95

Windows 95 was far more than "just a wrapper" for MS-DOS. Quoting Raymond Chen:

MS-DOS served two purposes in Windows 95.

  • It served as the boot loader.
  • It acted as the 16-bit legacy device driver layer.

Windows 95 actually hooked/overrode just about all of MS-DOS, keeping it as a compatibility layer while doing all the heavy lifting itself. It also implemented preemptive multitasking for 32-bit programs.

Pre-Windows 95

Windows 3.x and older were mostly 16-bit (with the exception of Win32s, a kinda compatibility layer that bridges 16 and 32, but we'll ignore that here), were more dependent on DOS, and used only cooperative multitasking - that's the one where they don't force a running program to switch out; they wait for the running program to yield control (basically, say "I'm done" by telling the OS to run the next program that's waiting).

Multitasking was cooperative, just like in old versions of MacOS (though unlike Multitasking DOS 4.x, which sported preemptive multitasking). A task had to yield to the OS in order to schedule a different task. The yields were built into certain API calls, notably message processing. As long as a task processed messages in a timely manner, everything was great. If a task stopped processing messages and was busy executing some processing loop, multitasking was no more.

Windows 3.x architecture

As for how early Windows programs would yield control:

Windows 3.1 uses cooperative multitasking - meaning that each application that is in the process of running is instructed to periodically check a message queue to find out if any other application is asking for use of the CPU and, if so, to yield control to that application. However, many Windows 3.1 applications would check the message queue only infrequently, or not at all, and monopolize control of the CPU for as much time as they required. A preemptive multitasking system like Windows 95 will take CPU control away from a running application and distribute it to those that have a higher priority based on the system's needs.


All DOS would see is this single application (Windows or other) running, which would pass control around without exiting. In theory, preemptive multitasking can possibly be implemented on top of DOS anyway with the use of a real-time clock and hardware interrupts to forcibly give control to the scheduler. As Tonny comments, this was actually done by some OSes running on top of DOS.

386 enhanced mode?

Note: there have been some comments on 386 enhanced mode of Windows 3.x being 32-bit, and supporting preemptive multitasking.

This is an interesting case. To summarise the linked blog post, 386 enhanced mode was basically a 32-bit hypervisor, which ran virtual machines. Inside one of those virtual machines ran Windows 3.x standard mode, which does all the stuff listed above.

MS-DOS would also run inside those virtual machines, and apparently they were preemptively multitasked - so it seems that the 386 enhanced mode hypervisor will share CPU time slices between the virtual machines (one of which ran normal 3.x and others which ran MS-DOS), and each VM will do its own thing - 3.x would cooperatively multitask, while MS-DOS would be single-tasked.


DOS itself was single-tasking on paper, but it did have support for TSR programs, that would stay in the background until triggered by a hardware interrupt. Far from true multitasking, but not fully single-tasked either.

All this talk of bit-ness? I asked about multitasking!

Well, strictly speaking the bit-ness and multitasking are not dependent on each other. It should be possible top implement any multitasking mode in any bit-ness. However, the move from 16-bit processors to 32-bit processors also introduced other hardware functionality that could have made preemptive multitasking easier to implement.

Also, since 32-bit programs were new, it was easier to get them to work when they're forcibly switched out - which might have broken some legacy 16-bit programs.

Of course, this is all speculation. If you really want to know why MS didn't implement preemptive multitasking in Windows 3.x (386 enhanced mode notwithstanding), you'll have to ask someone who worked there.

Also, I wanted to correct your assumption that Windows 95 was jsut a wrapper for DOS ;)

  • 5
    Very nice write-up. If I remember correctly (OS design class was many years ago for me) Windows 9x hooked the timer-interrupts to enforce it's own scheduler, just like you suggested in your 2nd to last paragraph. There were other OS'es on top of DOS that did the same. I clearly remember this from AMX (real-time OS for industrial applications) and XINU (educational purpose small Unix/Posix like OS) that both ran on top of DOS. (AMX could run bare-metal straight from EPROM too. It was much easier to test/debug when run on DOS. Saved you from re-burning EPROMS for each test.)
    – Tonny
    Mar 8, 2014 at 15:51
  • @Tonny Thanks for confirming that that scheme is possible (and used in practice). At a guess, the reason Windows 1-3 didn't use preemptive multitasking isn't so much that they were unable to do so (MS-DOS 4 had it, though unreleased), but rather it would have broken backwards compatibility with DOS programs.
    – Bob
    Mar 8, 2014 at 15:58
  • 3
    Mmmmhhh Considering Windows 1-3: The fact that is was common code-base for 8086 CPU's and higher might have had more to do with it. Proper ring0-3 handling was only possible with 80286 and up and that was what Win9x used to implement multi-tasking. 4DOS and others already provided a limited multi-tasking on DOS (80286 was needed if I recall correctly). You could even run Win3 itself as a separate process in 4DOS.
    – Tonny
    Mar 8, 2014 at 21:41
  • 1
    Xinu really did not run on top of DOS. It started out as a LSI-11 operating system, after all. The statement that there was no preëmptive multitasking in DOS+Windows 3.x is false. In 386 Enhanced Mode there was, courtesy of the VMM. And the nonsense about 4DOS gets you a Frequently Given Answer: 4DOS is not an operating system. Statements that it provided multitasking are entirely wrong.
    – JdeBP
    Mar 9, 2014 at 2:45
  • 2
    The PDP-8 supported pre-emptive multitasking, and that was only a 12 bit computer.
    – david25272
    Mar 10, 2014 at 0:47

It continuously ran a single program, the one called windows. That one spread the CPU time (and other resources) between different programs.

Consider this analogy:

You have an office which can only have one person at the time (That person is called mister or missus DOS). That person works on one thing at the time. E.g. it phones a single person and starts to chat 24/7 with him/her.

Now you replace that person with Mr. secretary. (windows). It will phone someone and talk all the time with it (still a single task). Then after some time the other person will say "I have talked enough for now. Go talk to someone else and call me back in a bit".

Mr. secretary will call the other person. Chat with that one until that person says the same thing. Then it will call the next person until it is at the end of the list of people to speak with. At that time it will begin again at the top.

  • In technical terms this is called cooperative multitasking. It requires the other person to say that he/she had enough CPU time. If one does not do that then all falls apart.
  • Modern systems are much smarter. Including pre-emptive multitasking. Think of the secretary setting an alarm clock and cutting the other person off after 5 minutes. "That is nice Jane. But I have to talk to Joe now. I'll call you back in a bit. - Click."

If you add multiple processors it gets even more complicated. :)

  • 1
    Don't you mean cooperative/non-preemptive multitasking in your first point? Also, interestingly, Windows 95 introduced preemptive multitasking for 32-bit programs. It wasn't so much a wrapper for DOS, as it was an OS that used DOS as a bootloader but replaced major parts of it (keeping enough for 16-bit/DOS program support).
    – Bob
    Mar 8, 2014 at 14:52
  • mister or misses, why not 'Dr.' DOS?
    – gtrak
    Mar 10, 2014 at 20:25
  • 1
    "It continuously ran a single program... That one spread the CPU time (and other resources) between different programs." can't that be said about any operating system? Though the question implies that MS-DOS could not. I'm strongly opposed to analogies/metaphors when disusing technical details of technology. Ok, so now we know how some hypothetical office works? That doesn't really explain the answer to the question.
    – Celeritas
    Mar 12, 2014 at 8:32

In a modern operating system, the operating system controls all hardware resources, and running applications are kept in sandboxes. An application is not permitted to access memory that the OS has not allocated to that application, and it cannot directly access hardware devices in the computer. If hardware access is required, the application must communicate through device drivers.

The OS can enforce this control, because it forces the CPU to enter protected mode.

DOS, on the other hand, never enters protected mode, but stays in real mode *. In real mode, the running applications can perform anything that it wants to, e.g. access hardware directly. But an application running in real mode can also tell the CPU to enter protected mode.

And this last part allows applications like Windows 95 to start a multi threaded environment even though they were basically launched from DOS.

DOS (Disk Operating System) was, afaik, not much more than file management system. It provided a file system, mechanisms for navigating the file system, a few tools, and the possibility to launch applications. It did also allow for some applications to stay resident, e.g. mouse drivers and EMM emulators. But it did not attempt to control the hardware in the computer the way a modern OS does.

* When DOS was first created in the 70's, protected mode did not exist in the CPU. It wasn't until the 80286 processor in the mid 80's that protected mode became part of the CPU.

  • 2
    Mind that at the time CPUs had no such things as protected mode.
    – jwenting
    Mar 11, 2014 at 10:21
  • 1
    @jwenting - good point, I added a note about it
    – Pete
    Mar 11, 2014 at 10:54

Prior to Windows 3.x which was the first version to multitask DOS applications, there were programs such as DesqView which could do likewise. If one was e.g. running three DOS sessions at once, then DesqView would create four virtual machines. The three DOS sessions would each think that they "owned" the entire machine, except that none of them would actually perform file I/O. Instead, the version of DOS running in each session would be patched so that it would forward any requests for file I/O to a special session, which was dedicated to that purpose. Since the PC's text mode hardware would continuously display the contents of an area of memory as characters; DesqView could let each session have its own virtual screen by mapping each session's 0xB8000-0xB9FFF range to its own area of RAM, and periodically copying the current application's area to the physical screen buffer. Graphical support was much harder, because 256K of RAM on the display board was controlled using 64K of address space, some I/O registers, and some "interesting" hardware which required things to be read and written in certain specific sequences. In text mode, when an application wrote something to the text buffer was written, DesqView could set a flag indicating it should be copied to the display on the next timer tick; only the first write to the text buffer in a given time tick would require DesqView's intervention; all the others would be consolidated to the next timer tick.

By contrast, virtualizing graphics mode would require DeskView to trap every single individual write to display memory or I/O registers. Given that this would slow down memory writes by a factor of about 100, and graphics programs had to write a lot more data than text programs, real-time virtualization of most graphic software was not practical. Instead, graphics were handled by having any non-foreground application which tried to do graphics pause until it became the foreground application, and then giving it full control over the screen. When control switched to a different application, DesqView would try to make a copy of the state of all graphics registers and then switch. Upon switching back to the graphical application, DesqView would restore the saved state.

In a way, multi-tasking non-graphical DOS applications was easier than multi-tasking Windows applications because there were very few shared resources, and applications didn't have to interact with each other. In Windows, by contrast, it's necessary to deal with things like the clipboard, or the possibility that one program's windows might move in such a fashion as to obscure another's. Windows 95 was the first version of Windows which could overcome such limitations by including things like a windowing system which could accommodate having an area of the screen become unavailable while code was trying to draw to it (with the effect that the drawing would be masked off).

  • Thanks for reminding me about DesqView. I used to use it all the time, but had completely forgotten about it.
    – Emmet
    Mar 11, 2014 at 19:19

Multitasking is nothing more than an illusion of running applications simultaneously. It is perceived as simultaneous execution on your end, but in fact processes A, B and C are sharing CPU time in this order: A, B, C, A, B, C, A, B...they just switch on and off very quickly. No two processes are actually running at the same time.

So, it is perfectly possible to make MS-DOS multitask by making it pause one process, run the next for a short period of time, pause that one, jump back to the first one, and so on.

Multitasking is just a clever feature developed when CPUs started being fast enough to keep rotating through these processes and making it seem simultaneous to the end user.

For those who remember, games were still being ran on DOS4GW because Windows was just too slow.

  • 1
    and for the most part, that's still how things work in operating systems to this day. That's why you can run 10 things "at the same time" on a 4 core CPU for example.
    – jwenting
    Mar 11, 2014 at 10:22
  • 2
    It isn't really that “CPUs started being fast enough”. It was possible to run multi-user multi-tasking operating systems on a '286 (such as The Mark Williams Company's Coherent, a fine OS introduced to PC in 1983). MS-DOS and Windows (not NT) versions up to (and including) “Millenium” really were atrocious by any objective standard, even the technical standards of the time, but once MS-DOS was established as the standard for PCs by IBM, Microsoft marketing and momentum (not to mention criminal abuse of their monopoly power) effectively excluded the better competition for a very long time.
    – Emmet
    Mar 11, 2014 at 19:33
  • 2
    "Multitasking is just a clever feature developed when CPUs started being fast enough..." You mean like how the Apollo Guidance Computer was a multi-tasking design?
    – user
    Mar 13, 2014 at 10:50
  • 1
    When I said "CPUs" I meant the mass-produced ones, and when I said "multitasking" I meant the multitasking of PC applications. And, finally, by the "end user" I meant the kid behind the PC, not the astronaut. Still, kudos for the interesting comment.
    – Dan Horvat
    Mar 13, 2014 at 14:18

Even though it can only focus on one task, what it would do is a simple step of quickly going from one to the other. This way it appeared that it was multitasking, but in truth its just focusing on 1, then on another, then on another, etc.

  • You're conflating multitasking with multiprocessor computing there. Switching amongst multiple tasks very rapidly is multi-tasking, in the computer world. The usual definition does not demand parallel execution. Various "old versions of Windows" did multitasking differently, dependent from what version of Windows, what mode it ran in, and whether it was even DOS-based in the first place. (Windows NT 3.1 is older than DOS+Windows 95, and could do SMP.) As I pointed out in another comment, entire books have been written on this. That really isn't the best 2 sentence summary.
    – JdeBP
    Mar 9, 2014 at 3:12
  • @JdeBP ... I know the difference between multitasking and multiprocessor as I mainly still use single core processors! Computers work serially. True parallel will only be seen in quantum computing.
    – Thoth
    Mar 25, 2014 at 6:09

One thing I didn't see mentioned here that is kind of interesting:

Windows 3.0 was not a pre-emptive multitasking system it was cooperative like all the versions of MacOS up until OS X--One app had to return from a call before any other app could take any action.

As a commenter reminded me however, DOS apps were mult-tasked. This is because they weren't written to "Cooperatively" multi-task (This must always be built into systems that use it).

At the time there were programs called TSRs (Terminate-Stay Resident) that took the place of today's device drivers. These drivers would run independantly--generally on their own thread by inserting themselves in one of the OS's event handlers. Windows didn't generally know about them, they ran at a lower level.

These weren't really windows apps, but they were how all threading activity took place before windows 3.1 such as printer drivers, com drivers, etc.

Although windows 3.1 was multi-tasking, DOS wasn't, but Windows 3.1 just pushed dos out of the way and took over when it started (Back then you often started windows from a DOS prompt).

  • Windows 3.0 supported preemptive multitasking of DOS applications when run on a 386 or higher processor. Only Windows applications were multitasked cooperatively.
    – Jules
    Mar 11, 2014 at 17:33
  • Oh, that's correct--I was coding windows apps at the time and wasn't really thinking about DOS. It did treat DOS apps differently--thanks for pointing that out.
    – Bill K
    Mar 12, 2014 at 0:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .