
DOS のメモリ管理では、上位メモリ領域( UMA ) はIBM PCまたは互換機の640 KBから 1024 KB ( 0x A0000–0xFFFFF)のアドレス間のメモリです。IBM は、 8088 CPUの 1024 KB アドレス空間の最上位 384 KBをBIOS ROM、ビデオ BIOS、オプション ROM、ビデオ RAM、周辺機器のRAM、メモリ マップド I/O、および廃止されたROM BASIC用に予約しました。[ 1 ]
しかし、ビデオRAM、ROM BIOS、ビデオBIOS、オプションROM、周辺機器用のI/Oポートがあっても、この384KB のアドレス空間の大部分は未使用でした。640KBのメモリ制限がますます大きな障害となるにつれて、空き領域をRAMで埋める技術が発見されました。これらの領域は上位メモリブロック(UMB )と呼ばれていました。
DOSの進化の次の段階は、オペレーティングシステムが上位メモリブロック(UMB)と高メモリ領域(HMA)を使用することでした。これは1990年にDR DOS 5.0がリリースされたときに実現しました。[ 2 ] DR DOSの組み込みメモリマネージャであるEMM386.EXEは、 QEMMや同等のプログラムの基本的な機能のほとんどを実行できました。
DR DOS 5.0が、旧バージョンのDOSとQEMMを組み合わせたものよりも優れていた点は、DR DOSカーネル自体とそのデータ構造のほぼすべてをハイメモリにロードできたことである。これにより、ベースメモリのほぼすべてが 空き領域となり、 640KBのうち最大620KBを 空き領域として利用できる構成が可能になった。
設定は自動化されておらず、空きUMBを手動で識別し、 CONFIG.SYSからEMM386をロードする行に手動で含める必要がありました。その後、ドライバなどをCONFIG.SYSとAUTOEXEC.BATからUMBに手動でロードする必要がありました。この設定は簡単なプロセスではありませんでした。QEMMのインストールプログラムによって大部分が自動化されていたため、このプログラムは市場で生き残りました。実際、DR DOS独自のHMAおよびUMBサポートとうまく連携し、PC向けユーティリティのベストセラーの1つとなりました。
この機能は、1991 年 6 月にMicrosoftがMS-DOS 5.0をリリースした際にコピーされました。 [ 2 ]最終的には、さらに多くの DOS データ構造が従来のメモリから移動され、 640 KB のうち最大 631 KB が空き領域として残されました。MS-DOS バージョン 6.0 以降、Microsoft はMEMMAKER と呼ばれるプログラムも組み込み、これは終了して常駐する(TSR) プログラムを上位メモリに移動することで、従来のメモリを自動的に最適化するために使用されました。
1990年代初頭のある時期、DOSのメモリマップを手動で最適化する技術は非常に高く評価され、最も複雑なPC構成でも大規模なアプリケーションを実行できるようになりました。この技術は、まず可能な限り多くのUMB(Uniformed Memory Map)を作成し、カラーマシンにおけるモノクロ表示領域など、割り当て済みだが未使用のメモリブロックを再マッピングすることから始まりました。次に、DOSの多数のサブコンポーネントをこれらのUMBに正しい順序でロードし、メモリブロックを可能な限り効率的に使用する必要がありました。一部のTSRプログラムはロード中に追加のメモリを必要とし、ロードが完了すると再び解放されました。幸いなことに、これらのモジュール間の依存関係は少なかったため、ほぼ任意の順序でロードすることが可能でした。例外として、CD-ROMを正常にキャッシュするには、ほとんどのディスクキャッシュをCD-ROMドライバの後にロードする必要があり、ほとんどのネットワークスタックのモジュールは、基本的にOSIモデルのレイヤーを段階的に上っていく特定の順序でロードする必要がありました。
従来型メモリを最適化するために用いられた基本的かつ効果的な方法は、HIMEM.SYSをデバイスとしてロードし、その後EMM386.EXEを「RAM AUTO」オプション付きでデバイスとしてロードすることでした。このオプションにより、デバイスドライバをdevicehighとしてロードすることでUMAへのアクセスが可能になります。この方法により、基本的なメモリマネージャが従来型メモリに効率的にロードされ、その後、他のすべてのメモリがUMAにロードされます。MSCDEXなどの従来型メモリを大量に消費するプログラムも同様の方法でUMAにロードできるため、従来型メモリを大幅に解放できます。
Windows 3.0の人気が高まるにつれ、上位メモリ領域の必要性は薄れていった。Windows アプリケーションは DOS の基本メモリ制限に直接影響されないが、Windows 上で動作する DOS プログラム (Windows 自体がマルチタスクマネージャとして機能する) は依然として制約を受けていたからである。Windows 95のリリースにより、その重要性はさらに低下した。このバージョンの Windows は、CD、ネットワーク、サウンドのサポートなど、DOS デバイス ドライバの多くの機能を Windows 上で動作する DOS アプリケーションに提供するようになったためである。Windows 95 の DOS ボックスのメモリ マップは自動的に最適化された。しかし、すべての DOS プログラムがこの環境で実行できたわけではなかった。具体的には、リアルモードからプロテクトモードに直接切り替えようとするプログラムは、実行中の仮想8086モードではそれが許可されていなかったため、動作しませんでした。また、仮想制御プログラムインターフェイス(VCPI)API(前述のように、メモリマネージャによって設定された仮想8086モードからプロテクトモードが必要なDOSプログラムがプロテクトモードに移行できるようにするために導入されたもの)を使用して切り替えを試みるプログラムも、Windows 95では動作しませんでした。プロテクトモードへの切り替えには、 DOSプロテクトモードインターフェイス(DPMI)APIのみがサポートされていました。
仮想8086モードで実行中に拡張メモリを上位メモリ領域にマッピングすることで、上位メモリブロックを作成できます。これは、拡張メモリを使用して拡張メモリをエミュレートする方法と同様であるため、この上位メモリブロックの提供方法は通常、拡張メモリマネージャ(例えばEMM386)によって提供されます。上位メモリブロックを管理するためのアプリケーションプログラミングインターフェイスは、拡張メモリ仕様で規定されています。
最新のシステムを含む多くのシステムでは、拡張カードROMのシャドウイング用に予約されているメモリを上位メモリとして使用することが可能です。多くのチップセットはこの目的のために最大384KBのRAMを予約しており、このRAMは通常使用されていないため、UMBPCIなどのカスタムデバイスドライバを使用してリアルモード の上位メモリとして使用できます。[ 3 ]
IBM XTコンピュータでは、マザーボードにメモリを追加し、カスタムアドレス デコーダPROMを使用して、それを上位メモリ領域に表示させることが可能でした。[ 4 ]上記の 386 ベースの上位メモリと同様に、追加の RAM は TSR ファイルのロードやRAM ディスクとして使用できました。
XT クラスのコンピュータ用のアドオンメモリ管理ユニットであるAllCardは、通常のメモリを 0xA0000-EFFFF アドレス範囲にマッピングできるようにし、DOS プログラムに最大 952 KB のメモリを提供しました。ビデオ メモリに直接アクセスするLotus 1-2-3などのプログラムは、このメモリ レイアウトを処理するためにパッチを適用する必要がありました。そのため、ソフトウェアの互換性を犠牲にして640 KB の制限が取り除かれました。この上位メモリ領域の使用方法は、デバイス ドライバと TSR を1 MBアドレス空間の上位 384 KB に移動して従来のメモリを解放するために使用された上位メモリ ブロックの使用とは異なりますが、アドレス指定可能なメモリ量 (640 KB) はそのまま残されます。
[…] 機能追加における最も重要な刺激の一つは
、1990年の春に初めて知った
DRDOS 5.0からの競争圧力でした。DRDOSの機能セットによって、
UMB
サポート、タスクスワッピング、およびUndelete機能を追加することになりました。 […] チームの管理部門の相当な注意が、ファイル転送ソフトウェア、Undelete、ネットワークインストールなどの新機能に向けられました。 […] 最終的に、この状況は1990年7月末に危機的状況に達し、
BradS
の主導の下、チームの管理部門は、プロジェクトを終了するためのスケジュールとプロセスを確定するために、骨の折れる一連の会議を行いました。 […]
(1+32ページ)