- 彼女はブートローダーを務めました。
- 16ビットドライバーとの互換性レイヤーとして機能しました。
CONFIG.SYS
ファイルを処理し、
COMMAND.COM
起動して
AUTOEXEC.BAT
を実行し、最終的に
WIN.COM
実行して、32ブートプロセスを開始しました。ビット仮想マシンマネージャーVMM
この特別なバージョンのMS-DOSは、「完全に機能する」という言葉が一般にMS-DOSに当てはまる程度まで完全に機能していました。 他の方法はありえませんでした。MS-DOSエミュレーションモードに入ると、このバージョンのみが機能し続けました。
WIN.COM
プログラムは、ほとんどの人がWindows自体と呼ぶもののダウンロードを開始しました。 MS-DOSのコピーを使用して、仮想マシンマネージャーをダウンロードし、
SYSTEM.INI
ファイルを読み取り、仮想デバイスドライバーをロードし、EMM386（存在する場合）をオフにして、保護モードに切り替えました。 ほとんどの人の観点から見た「リアルウィンドウ」-保護モードです。
保護モードでは、仮想デバイスドライバーが魔法をかけました。 それらのアクションの中には、MS-DOSの状態全体を引き出し 、32ビットファイルサブシステムの状態に転送し、MS-DOSを無効にすることがありました。 それ以降のすべてのファイル操作は、32ビットファイルサブシステムに送信されました。 プログラムが
int 21h
にアクセスすると、32ビットファイルサブシステムが処理を担当することが判明しました。
これは、2番目のMS-DOSの役割が作用する場所です。 おわかりのように、MS-DOSプログラムとドライバーは、オペレーティングシステムの深部に埋め込むのが大好きでした。
21h
割り込みハンドラーを置き換え、システムコードにパッチを適用し、低レベルのディスクハンドラー
int 25h
および
int 26h
置き換えることができます。 また、ディスクの操作を担当する
int 13h
などのBIOS割り込みを使用して、
int 13h
べきことを行うこともできます。
プログラムが
int 21h
にアクセスしたとき、要求は最初に32ビットファイルサブシステムに送信され、そこでいくつかの前処理が行われました。 次に、誰かが
int 21h
ベクトルをインターセプトしたことをファイルサブシステムが検出すると、インターセプターの実行を許可するために16ビットコードに戻ります。 ベクトル
int 21h
置き換えは、ウィンドウのサブクラス化
int 21h
イデオロギー的に似ています。 古いベクトルを取得し、新しいベクトルを設定します。 設定したハンドラーが呼び出されたら、何かをしてから古いハンドラーを呼び出します。 古いハンドラーから戻った後、コントロールを返す前に何か他のことができます。
CONFIG.SYS
からロードされた16ビットドライバの1つは
IFSMGR.SYS
。 彼の仕事は、他のすべてのドライバーとプログラムがチャンスを得る前に、 まずMS-DOSをインターセプトすることでした！ このドライバーは32ビットファイルサブシステムと共謀して、16ビットコードから32ビットに戻り 、ファイルサブシステムが作業を続行できるようにしました。
言い換えれば、MS-DOSは非常に巧みなおとりでした。 16ビットのドライバーとプログラムは、実際のMS-DOSのように見えたハンドラーにパッチを当て、インターセプトしましたが、実際には餌でした。 32ビットファイルサブシステムが誰かが餌を購入したことを確認した場合、おとりのアヒルを偽造しました。
MS-DOSに導入された「悪意のある」ドライバーやプログラムのないシステムから始めましょう。
それは楽園です。 32ビットファイルサブシステムは、派手なことをする迷惑なドライバーと対話することなく、すべての作業を行うことができました。 MS-DOS状態変数を更新する追加のステップに注意してください。 ダウンロード中にそれらを抽出しましたが、ドライバーとプログラムはしばしばそれらを「知って」おり、オペレーティングシステムをバイパスして状態変数を直接操作したため、それらを最新の状態に保ちます。 その結果、ファイルサブシステムはMS-DOSの責任の幻想をサポートすることになっており（MS-DOSは実際には動作していませんでしたが）、そのようなドライバーとプログラムは期待どおりに見えました。
また、状態変数は仮想マシンごとに異なることに注意してください。 （つまり、開いている各MS-DOSセッションは、状態変数の独自のコピーを受け取りました。）最後に、 各MS-DOSセッションには、個別の現在のフォルダー 、個別のファイルテーブルなどがありました。 ただし、開いているファイルの実際のリストは32ビットファイルサブシステムに格納されていたため、これはすべてパフォーマンスでした。 ディスクキャッシュは一貫している必要があり、ファイル共有の制限はグローバルにチェックする必要があったため、そうでなければできませんでした。 1つのMS-DOSセッションが排他的アクセスのためにファイルを開いた場合、別のMS-DOSセッションで実行されているプログラムによる同じファイルを開く試みは失敗するはずです。
まあ、それは単純なケースでした。 ハードケース：
int 21h
をインターセプトしたドライバーがありました。 このドライバーが何をするのかわかりません。たとえば、これはネットワークドライブのI / Oをインターセプトし、特に何らかの方法で処理するネットワークドライバーです。 また、MS-DOSセッションで実行されているTSRプログラムが
int 21h
をインターセプトして、
int 21h
が呼び出されたときに画面1に印刷され、
int 21h
終了したときに2に印刷されるとします 。 ローカルドライブ（ネットワークドライバーではないため、ネットワークドライバーは何もしない）へのアピールをトレースしてみましょう。
32ビットファイルサブシステムがすべての作業を引き続き行うことに注意してください。 呼び出しは、16ビットMS-DOSの責任の幻想を維持するためにのみ、16ビットチェーン全体を通過します。 16ビットの世界では、TSRとドライバーによってインストールされたコードのみが
IFSMGR
、さらにコンポーネントをリンクする
IFSMGR
小さな断片が
IFSMGR
されました。 16ビットMS-DOSコードは実行されませんでした。 32ビットファイルシステムは、MS-DOSからのすべての作業を傍受しました。
I / Oサブシステムが16ビットデバイスドライバーからハードドライブを制御したときに、「通常の操作を傍受するが、誰かが異常なアクションを要求した場合に異常なアクションを許可する」という同様のダンスが発生しました。 サブシステムがドライバーを認識した場合、32ビットファイルサブシステムが16ビットMS-DOSの代わりに操作を処理したのと同じ方法で、ドライバーのステータスを収集し、すべての操作を処理しました。 一方、サブシステムがドライバーを認識しなかった場合、サブシステムはディスクの責任を負います。 コマンドを32ビット環境から16ビットドライバーに送信するコンポーネントはRMMと呼ばれていました 。
何らかの種類のディスクにRMMを使用することが不運な場合、おそらくこのディスクでの操作のパフォーマンスがひどいことに気づいたでしょう。 この理由は、高速のマルチスレッド32ビットドライバーではなく、古い厄介な16ビットドライバーを使用しているためです。 （16ビットドライバーは1つのI / O操作を処理していましたが、16ビットドライバーはマルチスレッド用に設計されていないため、別のI / Oを処理することはできませんでした。）
奇妙に思えるかもしれませんが、RMMを使用することはMS-DOSウイルスがコンピュータに感染する初期の兆候だったため、RMMは恐ろしいため有用であることが判明しました。 最終的に、MS-DOSウイルスはTSRおよびドライバーと同じことを行いました。それらは割り込みベクトルをインターセプトし、ハードドライブの制御を獲得しました。 I / Oサブシステムの観点から見ると、16ビットのハードディスクドライバーのように見えました。 「Windowsが突然ひどくスローダウンし始めた」と人々が不平を言ったとき、コントロールパネルのシステムパフォーマンスページに誘導し、「一部のディスクはMS-DOSモードで動作します」または「すべてのディスクはMS-DOS互換モードを使用します」という行があるかどうかを尋ねました。 その場合、RMMがディスクを担当し、ハードウェアを変更しなかった場合、おそらくウイルスを意味していました。
最後に、MS-DOSの一部はI / Oに関連していませんでした。 たとえば、メモリの割り当て、 FCB形式のワイルドカードを使用した文字列の解析などの関数がありました。 これらの関数はMS-DOSで処理されました。これらは「補助ライブラリ」の関数であり、「はい、やった」と言う可能性を除いて、32ビットコードでの書き換えの恩恵を受けませんでした。 古い16ビットコードは正常に機能し、既製のコードを使用することにより、MS-DOSにパッチを適用したプログラムとの互換性を維持して、そのような関数の動作を変更できました。
元の記事に対する最初のコメント：「最も印象的なのは、ほとんどの場合、ほとんどの時間は本当に（ほとんど）働いていたことです。」