php舊版本windows_Windows的舊版本中如何進行多任務處理？

php舊版本windows

how-was-multi-tasking-possible-in-older-versions-of-windows-00

Considering that DOS was a single-tasking OS and the ties it had with early versions of Windows, just how did earlier versions of Windows manage to accomplish multi-tasking? Today’s SuperUser Q&A post looks at the answers to this question.

考慮到DOS是單任務操作系統，并且與早期Windows版本具有聯系，那么早期Windows版本如何完成多任務處理？今天的“超級用戶問答”帖子著眼于該問題的答案。

Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.

今天的“問答”環節由SuperUser提供，它是Stack Exchange的一個分支，該社區是由社區驅動的Q＆A網站分組。

Windows 95 screenshot courtesy of Wikipedia.

Windows 95屏幕截圖由Wikipedia提供。

問題 (The Question)

SuperUser reader LeNoob wants to know how older versions of Windows were able to run as multi-tasking systems?:

超級用戶讀者LeNoob想知道Windows的舊版本如何能夠作為多任務系統運行？

I read that DOS is a single-tasking OS. But if older versions of Windows (also including Windows 95?) were just wrappers for DOS, how could they run as a multi-tasking OS?
我讀到DOS是一個單任務操作系統。但是，如果舊版本的Windows(還包括Windows 95？)只是DOS的包裝，它們如何作為多任務OS運行？

Good question! How did older versions of Windows manage to run as multi-tasking systems?

好問題！ Windows的較早版本是如何設法作為多任務系統運行的？

答案 (The Answer)

SuperUser contributors Bob and Pete have the answer for us. First up, Bob:

超級用戶貢獻者Bob和Pete為我們找到了答案。首先，鮑勃：

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

Windows 95不僅僅是MS-DOS的“包裝” 。引用雷蒙·陳：

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.
MS-DOS在Windows 95中有兩個用途：1.)它用作引導加載程序。＆2.)充當16位舊式設備驅動程序層。
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.

Windows 95實際上幾乎鉤住/覆蓋了所有MS-DOS，在進行所有繁重的工作時將其保留為兼容層。它還為32位程序實現了搶先式多任務處理。

Pre-Windows 95

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

Windows 3.x和更早的版本大多是16位的(Win32s除外，后者是一種橋接16和32的兼容層，但是在這里我們將忽略它)，它們更多地依賴于DOS，并且僅使用協作式多任務處理–那就是他們不強迫正在運行的程序退出的程序；他們等待正在運行的程序產生控制權(基本上是通過告訴OS運行正在等待的下一個程序來說“我完成了”)。

Multi-tasking was cooperative, just like in old versions 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.
就像在舊版本的MacOS中一樣，多任務是協作的(盡管與多任務DOS 4.x不同，后者具有先發制人的多任務功能)。任務必須屈服于OS才能安排其他任務。收益內置于某些API調用中，尤其是消息處理。只要任務能夠及時處理消息，一切就很好。如果任務停止處理消息并忙于執行某些處理循環，則不再需要多任務處理。
Windows 3.x Architecture

Windows 3.x體系結構

As for how early Windows programs would yield control:

至于早期的Windows程序如何產生控制權：

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 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 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.
Windows 3.1使用協作式多任務處理-意味著正在運行的每個應用程序都被指示定期檢查消息隊列，以查找是否有其他任何應用程序正在請求使用CPU，如果有，則請求控制。該應用程序。但是，許多Windows 3.1應用程序只會很少或根本不檢查消息隊列，并在所需的時間內獨占CPU的控制權。像Windows 95這樣的搶占式多任務系統將使CPU失去對正在運行的應用程序的控制，并根據系統的需要將其分配給優先級更高的應用程序。
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.

DOS只會看到該單個應用程序(Windows或其他)正在運行，它將在不退出的情況下傳遞控制權。從理論上講，搶占式多任務可以通過使用實時時鐘和硬件中斷在DOS之上實現，以強制控制調度程序。正如Tonny所言，這實際上是由一些在DOS之上運行的操作系統完成的。

386 Enhanced Mode?

386增強模式？

Note: there have been some comments on 386 enhanced mode of Windows 3.x being 32-bit, and supporting pre-emptive multi-tasking.

注意：關于Windows 3.x的386增強模式(32位)并支持搶先式多任務處理，已有一些評論。

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.

這是一個有趣的案例。總結鏈接的博客文章，386增強模式基本上是運行虛擬機的32位管理程序。在其中一個虛擬機中運行Windows 3.x標準模式，該模式執行上述所有操作。

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也將在這些虛擬機中運行，并且顯然它們是搶先式的多任務處理-因此，似乎386增強模式虛擬機監控程序將在虛擬機之間共享CPU時間片(其中一個運行正常的3.x和其他運行MS-DOS的計算機)，則每個VM都會做自己的事– 3.x將協同執行多任務，而MS-DOS將是單任務。

MS-DOS

微軟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.

DOS本身只是單任務，但是它確實支持TSR程序，這些程序將一直在后臺運行，直到被硬件中斷觸發為止。遠非真正的多任務處理，但也不是完全單任務處理。

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.

好吧，嚴格來說，位和多任務并不相互依賴。應該可以以任何位方式實現任何多任務模式。但是，從16位處理器向32位處理器的遷移還引入了其他硬件功能，這些功能可以使搶先式多任務更易于實現。

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.

另外，由于32位程序是新的，因此在強制退出時更容易使它們工作-這可能會破壞某些舊的16位程序。

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.

當然，這全是猜測。如果您真的想知道為什么MS在Windows 3.x中沒有實施搶先式多任務處理(盡管有386增強模式)，則必須問在那里工作的人。

Also, I wanted to correct your assumption that Windows 95 was just a wrapper for DOS.
另外，我想糾正您的假設，即Windows 95只是DOS的包裝。

Followed by the answer from Pete:

隨后是Pete的回答：

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.

操作系統可以強制執行此控制，因為它可以強制CPU進入保護模式。

DOS, on the other hand, never enters protected mode, but stays in real mode (*see below). In real mode, the running applications 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.

另一方面，DOS永遠不會進入保護模式，而是停留在實模式( *見下文)。在實模式下，正在運行的應用程序可以執行其想要執行的任何操作，即直接訪問硬件。但是，以實模式運行的應用程序也可以告訴CPU進入保護模式。

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

最后一部分允許Windows 95之類的應用程序啟動多線程環境，即使它們基本上是從DOS啟動的也是如此。

DOS (Disk Operating System) was, as far as I know, not much more than a 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, 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.

據我所知，DOS(磁盤操作系統)只不過是文件管理系統而已。它提供了文件系統，用于導航文件系統的機制，一些工具以及啟動應用程序的可能性。它還確實允許某些應用程序保持駐留，例如，鼠標驅動程序和EMM仿真器。但是，它沒有像現代OS那樣嘗試控制計算機中的硬件。

*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.
*在1970年代首次創建DOS時，CPU中不存在保護模式。直到1980年代中期8080處理器才成為保護模式的一部分。

Make sure to browse on over to the original thread and read through the lively discussion on this topic using the link below!

確保瀏覽下面的原始主題，并使用下面的鏈接閱讀有關該主題的生動討論！

Have something to add to the explanation? Sound off in the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.

有什么補充說明嗎？在評論中聽起來不錯。是否想從其他精通Stack Exchange的用戶那里獲得更多答案？在此處查看完整的討論線程。