$FONT.SYSが使用するINT15メモリーとは？ [DOS/V]

$FONT.SYS（DOS J5.02/V以前）が使用しているという「INT 15H」がHIMEM.SYSとは異なるメモリ管理手法というのは分かるが、その中身までは今まで考えたことがなかった。最近、画面表示周りの動作を調べる機会があったので、そのついでに知ったことを書いておく。

以下、$FONT.SYS - DBCS(2バイト・コード)フォントの使用 [FPCU]DOS/V&Windowsコマンド・プロンプト・リファレンスより。

$FONT.SYSは、フォントのイメージの格納のために、IBM PC/AT以降のBIOSのINT 15Hインターフェースを用いて、拡張メモリを使用します。このため、他の手法(XMSなど)でメモリを管理するプログラムよりも前に導入しておく必要があります。すなわち、CONFIG.SYS中では通常、HIMEM.SYSよりも前の行で導入する必要があります。

何らかの理由でHIMEM.SYSを先に導入したい場合、$FONT.SYSがフォントの格納のために使用するメモリ容量を、INT 15Hインターフェースで確保できるように設定しておく必要があります。HIMEM.SYSには、このような用途に使えるスイッチ”/INT15”が用意されています

ここで利用している「INT 15H」とは、内部動作を調べたところIBM PC/AT(またはその互換機) BIOSにある以下のファンクションのことらしい。

• INT 15h, AH=87h Move block to/from extended memory (ブロック転送)
• INT 15h, AH=88h Extended memory size determination (拡張メモリー・サイズの判別)

私の脳内イメージではてっきりINT 15HというBIOSにメモリ管理機能が備わっているものと思っていたが、なんとこの2つだけでは到底「管理」できるようには思えない。しかし、$FONT.SYSの内部動作を知ってみるとこれでまかり通ることが理解できる。

まず、$FONT.SYSはINT 15h, AH=88hを使って現在のPCで使用可能な総メモリー容量を取得する。そしてディスクのフォントファイルからフォントイメージを読み込み、INT 15h, AH=87hを使ってメモリーのケツにフォントイメージを格納する。フォントの読み込みが終わったら、$FONT.SYSはINT 15hをフックするのかDOS内部データを書き換えるのか知らないけども、INT 15h, AH=88hで返す「使用可能な総メモリー容量」をフォントイメージの格納に使用中のメモリー分だけ減らしておく。すると、次に導入されるHIMEM.SYSがINT 15h, AH=88を呼び出した時にフォントイメージのサイズ分差し引かれた容量が返ってくるため、HIMEM.SYSが管理するメモリーは拡張メモリーのケツからフォントイメージの領域を差し引いた分となる。

DOS J5.0/Vのマニュアルには下のようなメモリーマップ図が載っているが、ここでINT15メモリーが拡張メモリーの後尾(XMSメモリーより後ろ)にあるのはそういうことだ。

(引用元：『IBM DOS バージョンJ5.0/V 入門書(カンタンDOS)』、日本アイ・ビー・エム株式会社、1991年)

DOS 3.3標準のRAMドライブ機能であるVDISK.SYSもこの方式を使っていた。

逆にHIMEM.SYSの/INT15スイッチは、「使用可能な総メモリー容量」は減らさずにこのINT15メモリーの領域を最初から使用済みとして空けておくことになる。この手順の場合、INT15メモリーの使用量がHIMEM.SYSの/INT15で確保した容量を上回るとXMSメモリーのデータと衝突・破損する恐れがあるので、事前にINT15メモリーの使用量を見積もって決めておく必要がある。

この手法は$FONT.SYSやVDISK.SYSがそれぞれ独自にメモリーを管理しているため、相性による衝突が起きる可能性がある。同じDOSのドライバーであれば動作検証の上で不都合があれば双方同時に修正すればよいから問題ないが、サードパーティのソフトはそういかない。

例えば、INT 15h, AH=88hが返す値はメモリーが連続で使えることが前提であるため、ISAバスのメモリーマップドI/Oによって生じる使用不能な領域の穴(いわゆる15MB-16MBの壁)は考慮されていない。そのため、このファンクションで保証される数字は約15MBまでであり、それ以上の大容量メモリーを認識するには別の新しいファンクションを使うことになる。すると、$FONT.SYSだけでなく同時に使用するVDISK.SYSなども同じ仕様変更に対応しなければ衝突が起きる可能性がある。

DOS J4.0/Vが開発されていた段階ではHIMEM.SYSがまだ標準でなく、拡張メモリーを使用するのは$FONT.SYSの他にVDISK.SYS位だったのでさほど問題にならなかった。しかし、HIMEM.SYSを使用するWindows 3.0が発売され、またターゲットのユーザー層も企業ユーザーだけでなく個人ユーザーが視野に入ってくると、これを考慮する必要性が増してきた。

DOS J6.1/Vでは$FONT.SYSがXMSインターフェイスに対応し、HIMEM.SYSやその他XMS対応メモリーマネージャー(QEMMなど)が使えるようになっているため、このような懸念は解消された。

近々、これまで他所で度々話題になっているDOS/Vのテキストスクロールの話にも触れてみたい。