デバイスドライバ

はじめに
デバイスドライバヘッダ
リクエストパケット
BPB（BIOS パラメータブロック）
デバイスドライバファンクション

6.1 はじめに

ロード可能なデバイスドライバは、付加的なハードウェアデバイスをサポートする能力を提供します。 いったんロードされたデバイスドライバは、IBMBIO.COM ファイルに結合された常駐デバイスドライバと、構造上なんら差異はありません。 ふつう、デバイスドライバは 8080 形式のメモリモデルをしており、コードセグメントとデータセグメントは同じです。 （野暮な訳注 : 8080 形式というのはつまり、インテルの 8 ビット CPU である i8080 のような、という意味なんだと思いますけど…） デバイスドライバは一般的に、.SYS 拡張子をつけています。 デバイスドライバは .COM 形式でも .EXE 形式でもかまいません。 メモリイメージは、デバイスヘッダを先頭にしなければならず、デバイスヘッダは以下のセクションで記述されるフォーマットのデータ構造です。

デバイスドライバには２つのタイプがあります。 ブロックデバイスとキャラクタデバイスです。

キャラクタデバイスはシーケンシャル入出力を扱います。 入出力を行うために、アプリケーションはキャラクタデバイスへの回線を開くことができます。 キャラクタデバイスは、たとえば MODEM といった、それぞれ個別の名前を持っています。

ブロックデバイスは、システムのディスクドライブへのランダム入出力を扱います。 ブロックデバイスは名前づけされていませんが、A:、B:、以下同様のドライブレターを割り付けられています。 単一の物理ディスクが複数の割り付けユニットに区画分けされていることもあります。 最小のブロックサイズは、デバイスの物理セクタサイズです。 たとえば、往々にしてディスケットドライブはユニット A:、B: であり、最初のハードディスクは C: と D: のふたつの区画に分かれています。 ブロックデバイスドライバは、複数の物理ユニットそれぞれを、ユニット個別の割り付けを行うことで管理します。 それぞれが多数のユニットを管理する、多数のデバイスドライバがあることになります。

6.2 デバイスドライバヘッダ

Figure 6-1
デバイスドライバヘッダの構造

オフセット	型	値	説明
00h	dword	NEXTDH	次のデバイスドライバへのポインタ
04h	word	ATTRIBUTE	デバイスドライバの属性
06h	word	STRATEGY	ストラテジコードのエントリポイント （オフセットのみ）
08h	word	INTERRUPT	インタラプトコードのエントリポイント （オフセットのみ）
0Ah	8 bytes	UNIT	デバイス名（キャラクタデバイス）、 サポートするユニット数（ブロックデバイス）

6.2.1 NEXTDH

次のデバイスドライバへのダブルワードポインタです。 デバイスドライバチェーンの最後のドライバでは、NEXTDH は特別な値 FFFF:FFFFh です。

6.2.2 ATTRIBUTE

このフィールドは、デバイスドライバの特徴を記述します。 Figure 6-2 は ATTRIBUTE フィールドのビットを定義しています。

Figure 6-2
キャラクタデバイスの属性ビット

ビット	説明
15	1 -- キャラクタデバイス
14	1 -- IOCTL ファンクションサポート
13	1 -- OUTPUT UNTIL BUSY サポート
12	予約 (0)
11	1 -- OPEN/CLOSE/RM ファンクションサポート
10〜7	予約 (0)
6	1 -- GENERIC IOCTL サポート
5	予約 (0)
4	Special bit 1 -- INT 29h での高速文字表示サポート （訳注 : この項追加）
3	1 -- カレント CLOCK デバイス
2	1 -- カレント NUL デバイス
1	1 -- カレント標準出力デバイス
0	1 -- カレント標準入力デバイス

Figure 6-3
ブロックデバイスの属性ビット

ビット	説明
15	0 -- ブロックデバイス
14	1 -- IOCTL ファンクションサポート
13	1 -- NON FAT ID （BUILD BPB ファンクション参照）
12	予約 (0)
11	1 -- OPEN/CLOSE/RM ファンクションサポート
10〜7	予約 (0)
6	1 -- GENERIC IOCTL、GET/SET logical device サポート
5〜2	予約 (0)
1	1 -- 32 ビットセクタ番号サポート
0	予約 (0)

6.2.3 STRATEGY

ドライバ中の本オフセットは、ストラテジコードのエントリーポイントです。 ストラテジコードは、ファンクションが実行されるとき、DR-DOS によって呼び出されます。 DR-DOS はリクエストパケットのポインタを（訳注 : ES:BX に）渡します。 デバイスドライバはパケットポインタをキューに格納します。 このコールの実行中、レジスタの内容は保存されていなければなりません。

（重要な訳注 : ドライバヘッダ中の STRATEGY と INTERRUPT はそれぞれワード値であり、エントリーポイントへのオフセット値のみを格納していますが、DOS はこれらのコードを FAR CALL で呼び出します。 したがって、これらのルーチンは RETF 命令で終了させなければなりません。 たとえば ArrowASM でデバイスドライバを書く場合、ArrowASM は RETF と RETN を明示的に書き分けられないので、ストラテジコードとインタラプトコードを PROC FAR 〜 ENDP の中に入れるか、RETF 命令に相当するバイナリコード (CBh) をなんらかの方法で埋め込む必要があるでしょう。 ）

6.2.4 INTERRUPT

ドライバ中の本オフセットは、インタラプトコードのエントリーポイントです。 インタラプトコードは、その前のストラテジエントリの呼び出しでセットされたリクエストパケットを処理するため、DR-DOS によって呼び出されます。 ドライバはリクエストパケットを解釈し、ファンクションを実行して DR-DOS に戻ります。 レジスタは、ファンクションが値を返すために使うことはなく、その内容は保存されていなければなりません。

（訳注 : STRATEGY の「重要な訳注」を参照のこと）

6.2.5 UNIT

キャラクタデバイスでは、このフィールドには、8 バイトの ASCII デバイス名を格納します。 デバイス名は 8 バイトで、8 バイト未満の場合は空白文字で残りを埋めます。 ファイル名として有効な文字のみが使えます。 ブロックデバイスでは、このフィールドの先頭バイトには、ドライバがサポートするユニット数を格納します。 ドライバが初期化（訳注 : INIT ファンクション）を行ったのち、DR-DOS はこのフィールドを埋めます。

6.3 リクエストパケット

リクエストパケットの構造体は、ファンクションに依存した可変長になっています。 最小のサイズは、以下に定義する 13 バイトです。 パケットのアドレスは、ドライバへのストラテジ呼び出しの際、ES:BX のレジスタペアに渡されます。

Figure 6-4
リクエストパケット固定部分の構造

（Table 6-1 参照）

Table 6-1
リクエストパケット固定部分の内容

オフセット	型	名前	説明
00h	byte	RPLENGTH	バイト単位でのパケット長
01h	byte	UNIT	ユニット番号 （ブロックデバイスのみ）
02h	byte	FUNCTION	ファンクション番号。 定義は以下の通り。 0 = Init 1= Media check 2 = Build BPB 3 = IOCTL input 4 = Input 5 = Non destructive input no wait 6 = Input status 7 = Input Flush 8 = Output 9 = Output with verify 10 = Output status 11 = Output flush 12 = IOCTL output 13 = Device open 14 = Device close 15 = Removable media 19 = Generic IOCTL request 23 = Get logical device 24 = Set logical device
03h	word	STATUS	ステータス
05h	8 bytes		予約

Figure 6-5
リクエストパケットの STATUS

ビット	内容
15	1 -- エラー 0 -- 正常
14〜10	予約 (0)
9	1 -- BUSY
8	1 -- DONE （エラーで終了、もしくは正常に終了した）
7〜0	エラーコード （bit15 = 1 の場合） 00h -- ライトプロテクト違反 Write protect violation 01h -- 不明なユニット Unknown unit 02h -- デバイスの準備ができていない Device not ready 03h -- 不明なファンクション Unknown command 04h -- CRC エラー CRC failure 05h -- リクエストパケットの長さが不正 Bad request structure length 06h -- シークエラー Seek faiure 07h -- 不明なメディア Unknown media 08h -- セクタが見つからない Sector not found 09h -- プリンタ用紙切れ Printer out of paper 0Ah -- 書き込み失敗 Write failure 0Bh -- 読み込み失敗 Read failure 0Ch -- その他全般の失敗 General failure 0Dh -- （予約） 0Eh -- （予約） 0Fh -- 不正なディスク交換 Invalid disk change （訳注 : Table 3-3 の 00h〜0Ch のあたり、Table 5-1 のエラーコード 19〜31 のあたりも見てみるといいかもしれません）

6.4 BPB（BIOS パラメータブロック）

（訳注 : 元の図 (fig6-6.gif) の判読が困難なので、これは参照にとどめ、訳者の一存で記述しました。 ）

6.5 デバイスドライバファンクション

DR-DOS は、デバイスドライバ構築のために、多数のファンクションを用意しています。 ファンクションは以下のサブセクション中で記述されています。

6.5.1 INIT ファンクション

ドライバのためにハードウェアとソフトウェアの初期化を行い、リクエストヘッダにドライバの終了アドレスとステータスワードをセットします。 ブロックデバイスでは、ユニット数と BPB 配列のポインタもセットします。 終了アドレスをセットすることにより、必要とされないメモリを開放、もしくは、データ構造体やバッファのためにより多くのメモリを確保することができます。

NBRUNITS

ドライバがサポートするユニット数をセットします（ブロックデバイスのみ）。

ENDADDR

ドライバに続く、利用可能なメモリの先頭ポインタをセットします。 このことによりシングルドライバのメモリ空間を増加、もしくは削減でき、ドライバに割り当てたメモリ空間の最大限の活用を可能にします。 複数のドライバが１グループに結合している場合、グループ内のそれぞれのドライバが、グループのメモリ終端を示す変数を変更し、その値を ENDADDR フィールドに返します。 このようにして各ドライバがデータ空間を確保できます。 この変数は、各ドライバが初期化されるごとに ENDADDR フィールドに値を返します。 INIT ファンクションはドライバインストール時に一度だけ呼び出されるので、INIT コードは ENDADDR の値で示されるドライバ終端よりも後方に置いてかまいません。 これにより INIT ファンクション用コードは破棄されます。

（ 訳注 : DEVICEHIGH でドライバを UMB に読み込んだ場合、ドライバの使用可能な最上位アドレスが ENDADDR に格納されています。 このアドレスを超えるメモリをドライバが使用したばあい、システム破壊の可能性が極めて濃厚ですので、ドライバの初期サイズよりも大容量のメモリを使用する場合はあらかじめ ENDADDR の値を確認しておいた方がよいでしょう。 しかし、DEVICEHIGH 以外の方法でドライバを読み込んだ場合の ENDADDR の初期値がどうなるのかよく知りません。 ひょっとすると不定なのかもしれません。 例えばコードセグメントの値を調べて、ドライバが UMB にロードされた時だけ ENDADDR の初期値を確認する、といった対策が必要なのかもしれません… ）

BPBPTR

ブロックデバイスで、BPB 構造体へのワードポインタ配列を指すためにセットします。 ドライバでサポートされる各ユニットにひとつづつ、ワードポインタ配列のエントリが存在します。 BPB は読み込まれるのみなので、ふたつ以上のユニットが同じ BPB を使用する場合、ワードポインタ配列の該当エントリは同じ BPB 構造体を指すことができます。

入力時、BPBPTR はオプションを格納した文字列を指しています。 この文字列は CONFIG.SYS ファイル中の "DEVICE=" 文でロードされたドライバのために使用されます。 この文字列は "DEVICE=" 以降にある、空白でない最初の文字の位置を指しています。

（訳注 : たとえば、CONFIG.SYS 中に

DEVICE=C:\myprog\hoge.sys param1 param2

BLKNBR

ドライバがサポートする先頭ユニットの論理ドライブ番号が、DR-DOS によってセットされています。 （訳注 : 0 = A:, 1 = B: ...）

6.5.2 MEDIA CHECK ファンクション

最後にあった入出力ファンクション以降にメディアが交換されたか判定するため、ユニットを調べます。 このファンクションはブロックデバイスでのみ使用され、その目的はパフォーマンスの向上です。 メディアが交換されていない場合、DR-DOS が再度ドライブにログする必要はありません。

MDB は、DR-DOS から渡される、現在のメディア ID です。 本ファンクションは、以下の３つのうちひとつの値を RETURN フィールドに返します。

-1 (FFh)	メディアは交換された
0	メディアは交換された、かもしれない （交換されたかどうかわからない）
1	メディアは交換されていない

ハードウェアのチェンジラインが利用できないドライブの場合、最後に成功したディスクアクセスの後の２秒間は「交換されていない」を返す、という簡単なタイマを使えます。 これにより、ディスクに規則的にくり返しアクセスのあるリムーバブルメディアで、パフォーマンスが向上します。

6.5.3 BUILD BPB ファンクション

ブロックデバイスのみで使用されます。 メディアの交換が検出され、DR-DOS がディスクに再度ログすることが必要なとき、呼び出されます。 デバイスドライバは、メディアタイプ判別のためにディスクを読み取り、選択もしくは作成した BPB へのポインタを返します。

デバイスドライバヘッダ中の、ATTRIBUTE フィールドの bit 13 が 0 の場合、DR-DOS は、FAT の先頭セクタを格納したセクタバッファへのポインタを TFRADDR に渡します。 （FAT の先頭セクタが、ドライバによってサポートされるすべてのディスクで、同じ位置になければならないことに注意してください） FAT ID バイトはこのバッファの先頭バイトであり、ドライバはこの値を読み込んで BPB にセットすることができます。 ATTRIBUTE フィールドの bit 13 が 1 の場合、TFRADDR はセクタバッファを指し、このセクタバッファは、ドライバがディスクを読み込んで BPB を判定するために使用できます。

BPB の構造は 6.4 BPB に記述されています。

6.5.4 INPUT, OUTPUT, OUTPUT with VERIFY ファンクション

INPUT ファンクションは、キャラクタデバイスからは指定された文字数を、ブロックデバイスからは指定されたセクタ数を読み取ります。 デバイスドライバは実際に転送したセクタ数、もしくはバイト数を COUNT フィールドに返し、STATUS ワードの戻り値をセットします。

OUTPUT ファンクションは、キャラクタデバイスへ指定された文字数を、ブロックデバイスへ指定されたセクタ数を書き込みます。 デバイスドライバは実際に転送したセクタ数、もしくはバイト数を COUNT フィールドに返し、STATUS ワードの戻り値をセットします。

OUTPUT with VERIFY ファンクションは OUTPUT とほぼ同じですが、データが正しく書き込まれたことを確認するために、書き込み後の読み出しチェックがブロックデバイス上で行われる点が違います。 IOCTL INPUT と IOCTL OUTPUT は INPUT、OUTPUT と同じやり方で処理を行いますが、エラーチェックは行いません。

NOTE : 小容量のブロックデバイスでは、最大セクタ番号の位置は 65536 未満で、RPLENGTH は 22 です。 大容量ブロックデバイスでは、セクタ番号は 32 ビット長で、RPLENGTH は 24 です。 この場合、STARTSEC の上位ワードも使用されます。

（訳注 : デバイスヘッダの ATTRIBUTE フィールド中、bit 1 がセットされている場合、つまり３２ビットセクタ番号がサポートされている場合、STARTSEC のかわりに STARTSEC32 フィールドが使用されます。
　このガイドの原文によると、オフセット 14h の STARTSEC は word/dword いずれかの型であり、どちらの型かを判別するには RPLENGTH の値を調べるのだそうです。 RPLENGTH が 22 の場合は STARTSEC は word であり、24 の場合は dword です。 ちなみに STARTSEC よりも後のフィールドは未定義です。 しかしこの記述を信ずるならば、DR-DOS と MS(PC)-DOS との間には、３２ビットセクタアクセスの方法に互換性がないことになります。 たとえばサードパーティ製の MO や PD のドライバを組み込むことを考えれば、これが非常にゆゆしき事態であることがおわかりいただけると思います。
　気になったので OpenDOS 7.01 のカーネルソースをすこし見てみたのですが、結局のところ、MS(PC)-DOS 4.0 以降と互換性のある方式をとっているようです。 おそらく原文の記述は、DR-DOS 6.0、でなければもっと以前の DR(EZ)-DOS のものであろうと思います。
　ということで、この部分のヘッダの説明は MS(PC)-DOS 方面の文献を元に作成しました。）

6.5.5 NONDESTRUCTIVE INPUT, NO WAT ファンクション

本ファンクションはキャラクタデバイスでのみ利用され、DR-DOS が入力バッファから除去せずに文字入力することを許します。 文字はリクエストヘッダに返され、STATUS の BUSY ビットが 0 にセットされます。 入力文字がない場合、BUSY ビットは 1 が返されます。

6.5.6 INPUT FLUSH, OUTPUT FLUSH ファンクション

キャラクタデバイスで使われる入力、出力バッファをフラッシュさせます。 STATUS ワードはエラーなし（0100h）をセットします。

6.5.7 OPEN, CLOSE ファンクション

ブロックデバイス上のファイルがオープン、クローズされるたびに、あるいはキャラクタデバイスがオープン、クローズされた時に BIOS に告知するため、DR-DOS はこれらのファンクションを使います。

これにより、デバイス上にオープンされているファイルがあるかどうかを BIOS が記録できるようになります。 BIOS が、リムーバブルメディアのデバイス上で、たとえばトラックバッファのようなローカルバッファを管理している場合、デバイス上の最後のファイルがクローズされた時に、BIOS はローカルバッファをフラッシュできます。 プリンタのようなキャラクタデバイスでは、デバイスがオープンされたとき、BIOS は文字フォントリセットのエスケープシーケンスを送り、紙送り（フォームフィード）することができます。

6.5.8 REMOVABLE MEDIA ファンクション

本ファンクションはブロックデバイス用で、ユニットがリムーバブル（交換可能）メディアを格納するかどうかを報告します。 メディアが固定されている場合、STATUS ワードの BUSY ビットは 1 がセットされ、リムーバブルの場合は 0 がセットされます。

6.5.9 STATUS ファンクション

STATUS ファンクションはキャラクタデバイス用で、出力デバイスが準備完了状態か、あるいは入力デバイスのバッファが文字を格納しているかを調べます。 本ファンクションは、これに続く INPUT もしくは OUTPUT ファンクションが、ドライバ内部でハードウェアの処理完了を待たなくてもよいことを保証するために使用されます。 デバイスが INPUT あるいは OUTPUT の準備ができている場合には STATUS ワードの BUSY ビットに 0 を返し、続く INPUT もしくは OUTPUT ファンクションがドライバ内部で処理を待たねばならない場合は 1 を返します。

6.5.10 GENERIC IOCTL request ファンクション

本ファンクションは、DR-DOS ファンクション 44h のための、対ドライバ用インターフェースです。 本ファンクションのための完全なインターフェースは Appendix Aに記述されています。 リクエストヘッダは、アプリケーションが渡すパラメータブロックを指す、ダブルワードポインタ GENPB を渡します。 CX レジスタは、アプリケーションが要求したメジャーファンクションコード、マイナーファンクションコードとして、リクエストヘッダ内に渡されます。

6.5.11 GET/SET LOGICAL DEVICE ファンクション

ふたつ以上のユニットを同一の物理デバイスに割り付けたブロックデバイスを、アプリケーションが使用できるようにします。 一例として、フロッピードライブがひとつのシステムでは、ディスクのデバイスドライバが先頭のフロッピーディスクドライブに A: と B: の両ドライブを割り付けています。 割り付けが行われていない場合、GET LOGICAL ファンクションは LOGICAL フィールドに 0 を返し、そうでない場合は 1、2、などなどの、その物理ドライブに現在割り付けられているユニット番号を返します。 SET LOGICAL ファンクションは、現行ユニットにしたい論理ユニットの番号をアプリケーションが渡せるようにします。 LOGICAL フィールドは GET LOGICAL ファンクションの場合と同様の値が返されます。