Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
7  
It's called preemptive multitasking - support.microsoft.com/kb/117567 –  joeqwerty Mar 8 at 14:46
19  
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 at 16:15
5  
@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. –  NothingsImpossible Mar 8 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 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 at 21:18

8 Answers 8

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.

source

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.


MS-DOS

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 ;)

share|improve this answer
4  
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 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 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 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 at 2:45
2  
The PDP-8 supported pre-emptive multitasking, and that was only a 12 bit computer. –  david25272 Mar 10 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. :)

share|improve this answer
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 at 14:52
    
mister or misses, why not 'Dr.' DOS? –  gtrak Mar 10 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 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.

share|improve this answer
2  
Mind that at the time CPUs had no such things as protected mode. –  jwenting Mar 11 at 10:21
1  
@jwenting - good point, I added a note about it –  Pete Mar 11 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).

share|improve this answer
    
Thanks for reminding me about DesqView. I used to use it all the time, but had completely forgotten about it. –  Emmet Mar 11 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.

share|improve this answer
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 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 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? –  Michael Kjörling Mar 13 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 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.

share|improve this answer
    
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 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 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).

share|improve this answer
    
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 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 at 0:33

Good question. In MS-DOS, the kernel was monolithic, meaning it only handled one task at a time, versus the new, modern kernel that was implemented in Windows 9x and current version. You can check out more here.

share|improve this answer
11  
-1 you suggeset that a monothithic OS cannot multitask-that's dead wrong. linux is FAMOUSLY monothithic kernel(there was a famous debate between linus torvalds and andrew tanenbaum) but linux can obviously multi-task. here is a link to show you linux is monolithic stackoverflow.com/questions/1806585/… –  barlop Mar 8 at 18:18
3  
Monolithic does not mean what you think it does. –  Thorbjørn Ravn Andersen Mar 9 at 22:01

protected by Diogo Mar 12 at 14:34

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.