考慮到DOS是一個單任務作業系統，以及它與早期版本Windows的聯絡，那麼早期版本Windows是如何實現多工的呢？今天的超級使用者問答帖子將探討這個問題的答案。

今天的問答環節是由SuperUser提供的，SuperUser是Stack Exchange的一個分支，是一個由社群驅動的問答網站分組。

維基百科提供的Windows95螢幕截圖。

問題

超級使用者讀者LeNoob想知道舊版本的Windows是如何作為多工系統執行的？:

I read that DOS is a single-tasking OS. But if older versi*** of Windows (also including Windows 95?) were just wrappers for DOS, how could they run as a multi-tasking OS?

好問題！舊版本的Windows是如何作為多工系統執行的？

答案

超級使用者貢獻者Bob和Pete為我們提供了答案。首先，鮑勃：

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

• MS-DOS served two purposes in Windows 95: 1.) It served as the boot loader. & 2.) 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 pre-emptive multi-tasking for 32-bit programs.

Pre-Windows 95

Windows 3.x and older were mostly 16-bit (with the exception of Win32s, a kind of compatibility layer that bridges 16 and 32, but we will ignore that here), were more dependent on DOS, and used only cooperative multi-tasking – that is the one where they do not force a running program to switch out; they wait for the running program to yield control (basically, say “I am done” by telling the OS to run the next program that is waiting).

• Multi-tasking was cooperative, just like in old versi*** of MacOS (though unlike Multi-tasking DOS 4.x, which sported pre-emptive multi-tasking). 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, multi-tasking was no more.

Windows 3.x Architecture

As for how early Windows programs would yield control:

• Windows 3.1 uses cooperative multi-tasking – 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 applicati*** 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 pre-emptive multi-tasking 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, pre-emptive multi-tasking 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 pre-emptive multi-tasking.

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 pre-emptively multi-tasked – 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 multi-task, 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 multi-tasking, but not fully single-tasked either.

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

Well, strictly speaking, the bit-ness and multi-tasking are not dependent on each other. It should be possible to implement any multi-tasking 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 pre-emptive multi-tasking easier to implement.

Also, since 32-bit programs were new, it was easier to get them to work when they were 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 did not implement pre-emptive multi-tasking in Windows 3.x (386 enhanced mode notwithstanding), you will have to ask someone who worked there.

Also, I wanted to correct your assumption that Windows 95 was just a wrapper for DOS.

接著是皮特的回答：

In a modern operating system, the operating system controls all hardware resources, and running applicati*** 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 (*see below). In real mode, the running applicati*** can perform anything that it wants to, i.e. access hardware directly. But an application running in real mode can also tell the CPU to enter protected mode.

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

DOS (Disk Operating System) was, as far as I know, not much more than a file management system. It provided a file system, mechani**s for navigating the file system, a few tools, and the possibility to launch applicati***. It did also allow for some applicati*** to stay resident, i.e. 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 1970s, protected mode did not exist in the CPU. It was not until the 80286 processor in the mid 1980s that protected mode became part of the CPU.

一定要瀏覽到原來的執行緒和閱讀透過這個主題的生動討論使用下面的連結！

有什麼要補充的解釋嗎？在評論中發出聲音。想從其他精通技術的Stack Exchange使用者那裡瞭解更多答案嗎？在這裡檢視完整的討論主題。