DOSがシングルタスクの場合、Windowsの古いバージョンでマルチタスクはどのように可能だったのですか？

DOSはシングルタスクOSであると読みました。

しかし、Windowsの古いバージョン（Windows 95も含む）がDOSの単なるラッパーである場合、WindowsはマルチタスクOSとしてどのように実行できますか？

Windows 95

Windows 95 は、MS-DOSの「単なるラッパー」以上のものでした。レイモンド・チェンの引用：

MS-DOSは、Windows 95で2つの目的を果たしました。

• ブートローダーとして機能しました。
• 16ビットのレガシーデバイスドライバーレイヤーとして機能しました。

Windows 95は実際にはほとんどすべてのMS-DOSをフック/オーバーロードし、互換性レイヤーとして維持しながら、すべての重労働を行います。また、32ビットプログラムのプリエンプティブマルチタスクを実装しました。

Pre-Windows 95

Windows 3.x以前はほとんど16ビットでした（16と32をブリッジするちょっとした互換性レイヤーであるWin32を除きますが、ここではそれを無視します）。DOSに依存し、協調マルチタスクのみを使用しました。実行中のプログラムを強制的に切り替えないもの。実行中のプログラムが制御を得るまで待機します（基本的に、待機中の次のプログラムを実行するようにOSに伝えることで「完了」と言います）。

MacOSの古いバージョンと同様に、マルチタスクは協調的でした（ただし、マルチタスクDOS 4.xはプリエンプティブマルチタスクを実行していません）。別のタスクをスケジュールするには、タスクがOSに譲らなければなりませんでした。yieldは特定のAPI呼び出し、特にメッセージ処理に組み込まれました。タスクがタイムリーにメッセージを処理する限り、すべてが素晴らしかったです。タスクがメッセージの処理を停止し、処理ループの実行でビジーだった場合、マルチタスクはそれ以上でした。

Windows 3.xアーキテクチャ

初期のWindowsプログラムがどのように制御をもたらすかについて：

Windows 3.1は協調型マルチタスクを使用します。つまり、実行中の各アプリケーションは、メッセージキューを定期的にチェックして、他のアプリケーションがCPUの使用を要求しているかどうかを確認します。 。ただし、多くのWindows 3.1アプリケーションは、メッセージキューを頻繁にチェックしないか、まったくチェックせず、必要な時間だけCPUの制御を独占します。Windows 95のようなプリエンプティブマルチタスクシステムは、実行中のアプリケーションからCPU制御を奪い、システムのニーズに基づいてより高い優先度を持つアプリケーションに配布します。

ソース

DOSは、この単一のアプリケーション（Windowsまたはその他）が実行されていることを確認し、終了せずに制御を渡します。理論的には、リアルタイムクロックとハードウェア割り込みを使用してスケジューラに強制的に制御を与えることにより、DOS上でプリエンプティブマルチタスクを実装できます。以下のようTonnyのコメント、これは実際にはDOS上で動作するいくつかのOSによって行われました。

386拡張モード？

注：Windows 3.xの386拡張モードは32ビットであり、プリエンプティブマルチタスクをサポートしているというコメントがいくつかあります。

これは興味深いケースです。リンクされたブログ投稿を要約すると、386拡張モードは基本的に32ビットハイパーバイザーであり、仮想マシンを実行していました。これらの仮想マシンの1つでは、Windows 3.x標準モードを実行し、上記のすべてを実行します。

MS-DOSはそれらの仮想マシン内でも実行され、明らかに先制的にマルチタスク化されていたようです-したがって、386拡張モードハイパーバイザーは仮想マシン間でCPUタイムスライスを共有するようです（1つは通常の3.xを、もう1つはMSを実行しました） -DOS）、および各VMは独自の処理を行います。3.xは協調的にマルチタスクを実行し、MS-DOSはシングルタスクを実行します。

MS-DOS

DOS自体は紙上ではシングルタスクでしたが、ハードウェア割り込みによってトリガーされるまでバックグラウンドに留まるTSRプログラムをサポートしていました。真のマルチタスクとはほど遠いですが、完全にシングルタスクではありません。

ビットネスのこのすべての話？マルチタスクについて質問しました！

厳密に言えば、ビットネスとマルチタスキングは互いに依存していません。任意のマルチタスクモードを任意のビット数で実装できる可能性があります。ただし、16ビットプロセッサから32ビットプロセッサへの移行により、プリエンプティブマルチタスクの実装が容易になる可能性のある他のハードウェア機能も導入されました。

また、32ビットプログラムは新しいものであるため、強制的に切り替えたときに動作しやすくなりました。これにより、一部のレガシー16ビットプログラムが破損する可能性がありました。

もちろん、これはすべて推測です。MSがWindows 3.xでプリエンプティブマルチタスクを実装しなかった理由（386拡張モードにもかかわらず）を本当に知りたい場合は、そこで働いていた人に尋ねる必要があります。

また、Windows 95はDOSのラッパーであるという仮定を修正したかったのです;）

Windowsと呼ばれる1つのプログラムを継続的に実行しました。その1つは、異なるプログラム間でCPU時間（およびその他のリソース）を分散させます。

この類推を考慮してください：

一度に1人しか持てないオフィスがあります（その人はミスターまたはミサスDOSと呼ばれます）。その人は一度に一つのことをします。たとえば、1人のユーザーに電話をかけ、24時間年中無休でチャットを開始します。

今、あなたはその人を秘書さんに置き換えます。（ウィンドウ）。誰かに電話をかけ、いつも話しかけます（1つのタスクのみ）。それからしばらくすると、相手は「今のところ十分話しました。他の人と話して、少し電話をかけ直してください」と言うでしょう。

秘書さんが相手に電話します。その人が同じことを言うまで、その人とチャットします。次に、会話する人のリストの最後になるまで次の人を呼び出します。その時点で、再び上部から開始されます。

• 技術的には、これは協調マルチタスクと呼ばれます。他の人には十分なCPU時間があると言う必要があります。そうしないと、すべてが崩壊します。
• 最新のシステムははるかにスマートです。プリエンプティブマルチタスクを含む。秘書が目覚まし時計を設定し、5分後に相手を切断することを考えてください。「それはいいジェーンです。しかし、私は今ジョーと話をしなければなりません。少し後で電話します。-クリック。」

複数のプロセッサを追加すると、さらに複雑になります。:)

最新のオペレーティングシステムでは、オペレーティングシステムがすべてのハードウェアリソースを制御し、実行中のアプリケーションはサンドボックスに保持されます。アプリケーションは、OSがそのアプリケーションに割り当てていないメモリへのアクセスを許可されず、コンピューター内のハードウェアデバイスに直接アクセスできません。ハードウェアアクセスが必要な場合、アプリケーションはデバイスドライバーを介して通信する必要があります。

OSは、CPUを強制的に保護モードにするため、この制御を強制できます。

一方、DOSは保護モードに入ることはありませんが、リアルモードのままです *。リアルモードでは、実行中のアプリケーションは、ハードウェアに直接アクセスするなど、必要な処理を実行できます。ただし、リアルモードで実行されているアプリケーションは、CPUに保護モードに入るように指示することもできます。

そして、この最後の部分により、Windows 95のようなアプリケーションは、基本的にDOSから起動されていても、マルチスレッド環境を開始できます。

DOS（ディスクオペレーティングシステム）は、ファイル管理システム以上のものではありませんでした。ファイルシステム、ファイルシステムをナビゲートするメカニズム、いくつかのツール、およびアプリケーションを起動する可能性を提供しました。また、マウスドライバーやEMMエミュレーターなど、一部のアプリケーションを常駐させることもできました。しかし、最新のOSのようにコンピューターのハードウェアを制御しようとしませんでした。

* 70年代にDOSが最初に作成されたとき、保護モードはCPUに存在しませんでした。80年代半ばの80286プロセッサがCPUの一部になったのは初めてでした。

マルチタスクDOSアプリケーションの最初のバージョンであるWindows 3.xの前には、DesqViewのようなプログラムもありました。たとえば、3つのDOSセッションを一度に実行している場合、DesqViewは4つの仮想マシンを作成します。3つのDOSセッションはそれぞれ、マシン全体を「所有」していると考えますが、実際にはファイルI / Oを実行するものはありません。代わりに、各セッションで実行されているDOSのバージョンにパッチを適用し、ファイルI / Oの要求をその目的専用の特別なセッションに転送します。PCのテキストモードハードウェアは、メモリ領域の内容を文字として継続的に表示するため、DesqViewは、各セッションの0xB8000-0xB9FFF範囲を独自のRAM領域にマッピングすることにより、各セッションに独自の仮想スクリーンを持たせることができます。定期的に現在のアプリケーションの領域を物理的な画面バッファーにコピーします。ディスプレイボード上の256KのRAMは、64Kのアドレス空間、一部のI / Oレジスタ、および特定の特定のシーケンスでの読み取りと書き込みを必要とする「興味深い」ハードウェアを使用して制御されたため、グラフィカルサポートははるかに困難でした。テキストモードでは、アプリケーションがテキストバッファーに何かを書き込むと、DesqViewは次のタイマーティックでディスプレイにコピーする必要があることを示すフラグを設定できます。DesqViewの介入が必要なのは、指定されたタイムティックのテキストバッファへの最初の書き込みのみです。他のすべては、次のタイマーティックに統合されます。ディスプレイボード上の256KのRAMは、64Kのアドレス空間、一部のI / Oレジスタ、および特定のシーケンスで読み取りと書き込みを必要とする「興味深い」ハードウェアを使用して制御されたためです。テキストモードでは、アプリケーションがテキストバッファーに何かを書き込むと、DesqViewは次のタイマーティックでディスプレイにコピーする必要があることを示すフラグを設定できます。DesqViewの介入が必要なのは、指定されたタイムティックのテキストバッファへの最初の書き込みのみです。他のすべては、次のタイマーティックに統合されます。ディスプレイボード上の256KのRAMは、64Kのアドレス空間、一部のI / Oレジスタ、および特定のシーケンスで読み取りと書き込みを必要とする「興味深い」ハードウェアを使用して制御されたためです。テキストモードでは、アプリケーションがテキストバッファーに何かを書き込むと、DesqViewは次のタイマーティックでディスプレイにコピーする必要があることを示すフラグを設定できます。DesqViewの介入が必要なのは、指定されたタイムティックのテキストバッファへの最初の書き込みのみです。他のすべては、次のタイマーティックに統合されます。DesqViewは、次のタイマーティックでディスプレイにコピーする必要があることを示すフラグを設定できます。DesqViewの介入が必要になるのは、指定されたタイムティック内のテキストバッファへの最初の書き込みのみです。他のすべては、次のタイマーティックに統合されます。DesqViewは、次のタイマーティックでディスプレイにコピーする必要があることを示すフラグを設定できます。DesqViewの介入が必要になるのは、指定されたタイムティック内のテキストバッファへの最初の書き込みのみです。他のすべては、次のタイマーティックに統合されます。

対照的に、グラフィックモードを仮想化するには、DeskViewが個々の書き込みをすべてトラップして、メモリまたはI / Oレジスタを表示する必要があります。これにより、メモリ書き込みが約100倍遅くなり、グラフィックプログラムはテキストプログラムよりも多くのデータを書き込む必要があるため、ほとんどのグラフィックソフトウェアのリアルタイム仮想化は実用的ではありませんでした。代わりに、グラフィックスは、フォアグラウンドアプリケーションになるまでグラフィックスを一時停止しようとする非フォアグラウンドアプリケーションを持ち、画面全体を完全に制御することで処理されました。制御が別のアプリケーションに切り替えられると、DesqViewはすべてのグラフィックレジスタの状態のコピーを作成してから切り替えようとします。グラフィカルアプリケーションに切り替えると、DesqViewは保存された状態を復元します。

ある意味では、マルチタスクの非グラフィカルDOSアプリケーションは、共有リソースが非常に少なく、アプリケーションが相互にやり取りする必要がないため、マルチタスクのWindowsアプリケーションよりも簡単でした。対照的に、Windowsでは、クリップボードや、あるプログラムのウィンドウが他のウィンドウを覆い隠すような動きをする可能性などに対処する必要があります。Windows 95はWindowsの最初のバージョンであり、コードが描画を試みている間に画面の領域が使用できなくなることに対応できるウィンドウシステムのようなものを含めることにより、このような制限を克服できました（描画がマスクされる効果があります） ）。

マルチタスクは、アプリケーションを同時に実行しているように見えるだけです。あなたの側では同時実行として認識されますが、実際にはプロセスA、B、Cはこの順序でCPU時間を共有しています：A、B、C、A、B、C、A、B ...すぐにオフになります。2つのプロセスが実際に同時に実行されることはありません。

したがって、1つのプロセスを一時停止し、次のプロセスを短時間実行し、そのプロセスを一時停止し、最初のプロセスにジャンプするなどして、MS-DOSをマルチタスクにすることは完全に可能です。

マルチタスクは、CPUがこれらのプロセスを回転し続け、エンドユーザーに同時に見えるようにするのに十分なほど高速になり始めたときに開発された単なる巧妙な機能です。

覚えている人にとっては、Windowsが遅すぎたため、ゲームはDOS4GWでまだ実行されていました。

1つのタスクのみに焦点を当てることができますが、それが行うことは、あるタスクから別のタスクにすばやく移動する単純なステップです。このように、それはマルチタスキングであるように見えましたが、実際には1に焦点を当ててから、別のものに、次に別のものに、などなど。

私がここで言及していなかった1つのことは、ちょっと面白いです：

Windows 3.0はプリエンプティブマルチタスクシステムではなく、OS X--Oneアプリが他のアプリがアクションを実行する前に呼び出しから復帰するまで、MacOSのすべてのバージョンのように協調的でした。

しかし、コメンターが私に思い出させたように、DOSアプリはマルチタスクでした。これは、それらが「協調的に」マルチタスクに書き込まれていないためです（これを使用するシステムに常に組み込む必要があります）。

当時、今日のデバイスドライバーに取って代わるTSR（Terminate-Stay Resident）と呼ばれるプログラムがありました。これらのドライバーは独立して実行されます。一般的には、OSのイベントハンドラーのいずれかに自分自身を挿入することにより、独自のスレッドで実行されます。Windowsは一般にそれらについては知りませんでした。それらは低いレベルで実行されました。

これらは実際にはWindowsアプリではありませんでしたが、プリンタードライバー、COMドライバーなど、Windows 3.1より前のすべてのスレッド処理が行われた方法でした。

Windows 3.1はマルチタスクでしたが、DOSはそうではありませんでしたが、Windows 3.1はdosを邪魔にならないようにプッシュし、起動時に引き継ぎました（その後、しばしばDOSプロンプトからwindowsを起動しました）。

良い質問。MS-DOSでは、カーネルはモノリシックでした。つまり、Windows 9xおよび現在のバージョンで実装された新しい最新のカーネルに対して、一度に1つのタスクしか処理しませんでした。詳細はこちらをご覧ください。