各章の題名をクリックすると、この目次に戻ります。
BIOSの元々の狙いは、I/Oデバイスに対する、標準かつある程度デバイスに 依存しないインタフェースを提供することであった。そうすれば、OSは様々 なメーカが出すI/Oデバイス個々の癖に一々係わらないで済む。概念的には BIOSはその機械で動作させるいかなるOSからも利用することができるはずの ものである。
ところが実際には、BIOSの機能はどんなOSにも役立つようにはならなかっ た。OSとはDOSかその類似の物に限られた。BIOSの最初のデザイナーがマル チタスクのことを十分考えに入れていなかったのだ。OS/2を初めとする先 進的なOSはほとんどのBIOSの機能をバイパスしなければならない。OS/2だ けを使っている限り、BIOSは結構なROM空間を潰しているだけのようなもの である。
それでもなお、OS/2がBIOSを無視できない場面がある:
忘れられがちな点がある。もし2台の物理的なディスクを持っているな ら、それらの(完全にではないが)ほとんど互いに独立な装置の間で、 ある程度の並列動作が可能である。つまり、例えば片方のディスクで読 み書きを行っている間、もう一方のディスクのヘッドを次に読み書きす る位置に移動することができるわけだ。このオーバーラップによって、 速度が向上することになる。
一方、一台のディスクに2つの区画の場合は、このような速度の上の 利点はない。実際、一台のディスクのある区画から別の区画へ大きな ファイルを複写するなどという操作は非常に遅くなることがある。そ れはある区画から別の区画へヘッドが行ったり来たりしなければなら ないからだ。
区画分けには他にも不利な点がある。ディスク空間の利用が多少窮屈 になる点だ。ディスク容量が足りなくなって来た時、ディスクの総空 き容量が十分なのに、区画に分けたせいでそれぞれの区画での空きが 減り、必要な操作が出来なくなる場合がある。
上に見たように、区画に分けるのは良くないアイディアである。そう は言うものの、区画に分けたくなる理由は幾つかある。
名前なし ブートマネジャ C: FAT DOS/Windows D: FAT 共用のデータ、プログラム E: HPFS OS/2幾つかの理由で、一つの区画に複数のOSを入れるよりも、この 方法が優れている。
他のOSにも、例えばDOSがそうだが、FDISKがある。異なった版は完全 に同じとは言えないが、大体は同じなので、注意して使えばいかなる OS用の区画も用意することができる。
規則によると、一台のディスクに作ることのできる区画の数は4以下 である。随分きつい制限に見えるが、抜け道がある:区画は「基本区 画」と「拡張区画」に分けられ、一つの拡張区画にはさらに複数の論 理区画を作ることができる。拡張区画は一台のディスクに一つしか作 れないが、それで十分である。実際には次のような区画を作ることが できる:
OS/2やLinuxのような進んだOSは基本区画にも論理区画にも導入できる。 一方ある種のシステム、例えばWindowsNT、DOS、Windows95などのDOS シェル(訳注:Window95はWindows3.1と同様DOS+DOS Extenderだと言っ ている)は基本区画からブートしないといけない。複数のOSを走らせた いなら、区画の設定にあたって十分考えるべきである。
ここで、致命的な問題が出る:複数の基本区画を作成しても、それらは 互いに他が「見え」ない。全ての基本区画は同じドライブ文字が割りふ られる。何が起きるか、例を見よう。
C: 基本 FAT DOS C: 基本 FAT Windows NT D: 論理拡張 FAT 共用のデータ、プログラム E: 論理拡張 HPFS OS/2 名なし ブートマネジャこの例ではDOSとWindowsNTの両方を基本区画に導入しないといけない。 そこでドライブC:の区画が二つ出来る。この2つの区画は互いに相手が 見えない。D:は3つのOS全てから見える。E:はDOSからは見えない。DOS はHPFSの見方を知らないからである;WindowsNTからは見えるかもしれ ないし見えないかもしれない。PINBALL.SYSが導入されているかどうか に依存する。OS/2からは3つの区画が見える。しかしどちらのC:が見え るかは、OS/2がブートする前にどちらが「アクティブ」だったかに依存 する。
お楽しみは最後にとってある。2台目のドライブを上の構成に追加しよう。 ドライブ文字は気も狂わんばかりになる。こんな風に。
Disk 1: C: 基本 FAT DOS C: 基本 FAT Windows NT E: 論理拡張 FAT 共用データ、プログラム F: 論理拡張 HPFS OS/2 名前なし ブートマネジャ Disk 2: D: 基本 HPFS データ区画 G: 論理拡張 FAT なんでも何が起きたかというと、全ての基本区画は論理区画の前にドライブ文字 を割りふられるのである。その結果として最初のディスクのドライブ文 字が変わる。最初のディスクには全然タッチしなくても、である。これ が混乱をもたらすのは明らかだろう。おまけにDOSから見たドライブ文字 とOS/2から見たドライブ文字とが異なる。DOSからはFAT区画の前に来た HPFS区画が見えないからである。
教訓は単純だ: 追加のディスクには基本区画をおかないこと。
さて、きょう日こんなに小さなディスクなんて誰も作っていない。じゃあど うすればいい? 512バイトのブロックサイズを大きくすればいいのである。 物理的なブロック(訳注:「セクタ」)の大きさは変えずに、ディレクトリ 操作に当たっては、隣接したいくつかのブロックを一つの「クラスタ」(訳 注:「塊」)にまとめて扱う。例えば8 KB(16物理ブロック)のクラスタを 作れば、512MBのディスクまで扱うことができる。
ファイルサイズはクラスタの整数倍に切り上げられなければならないことに なったわけだ。8 KBといえばなかなか大きなクラスタである。どうなるかと いうと、例えば数十文字程度の長さのバッチファイルも8 KBに切り上げられ てディスクを消費する。そのクラスタの大部分は無駄になるわけだ。
実際、FATをまともに使うにはディスクを小さな区画に分けてやらなければ ならない。そうすればそれぞれの区画のクラスタサイズは小さくなる。
もっとまともな方法は、FATシステムなんてやめちゃうことである。FATは ディスケット用に考えられたもので、本来大きなディスクには向いていな い。残念ながらDOSとの互換性のために一つはFAT区画を残す必要がある人 がほとんどだろう。
FATでディレクトリがどう働くかを説明するのはやめておこう。多くの人 にはつまらないだけだから。
最初の重要な事実は、HPFSにはクラスタサイズによる制限がないことである。 HPFSではクラスタサイズは物理的なディスクのブロックの大きさに等しい。 どんなにディスクが大容量でも変わりがない。(限界はあるのだが、それに 到達するのはまだまだ先である)。これは、無駄になる容量が少ないことを 意味する。区画を大きくしても平気である。望みとあらば、ディスク丸ごと 1区画で設定してもよい。(訳注:これはHPFSがセクタを32bit数で管理し ているため4G個までのセクタを扱えるからである。512バイトセクタだった ら2TBの大容量ディスクをまるまる1区画で扱える)
第2に、HPFSはディレクトリを木構造で持っている。FATでは、ディレクト リは線形リストであり、ディレクトリが大きくなると検索に時間がかかる ようになる。このようにHPFSのディレクトリは高速検索に向いている(訳 注:HPFSのディレクトリはB Treeと呼ばれる構造である。このB Treeは、 アルファベット順に順序付けられている。線形リストを検索するには最初 からリストを逐一舐める必要があるが、HPFSの方法だと遥かに高速な算法 を使うことができる。また、ファイル自体もB+ Treeで管理されているので、 ますます高速である)
第3に、HPFSがファイルにディスクを割り当てる方法は、FATより若干高級 である。FATは単に「最初の空ブロックをみつける」だけである。どのよう な算法を使っているか良く知らないが、それがなんであれディスクの分断化 をFATに比べ遥かに起こしづらいと言われている。(分断化「フラグメン テーション」はディスクの空部分がまとまって存在せず、小さな空部分がた くさん散在する形になることである)。分断化を避けることは重要だ。なぜ ならば分断化すると、ディスク操作が実に遅くなるからだ(訳注:ヘッドの 移動が増えるため。また、最近のディスクは複数の連続セクタを一気読みす る機能があるが、この機能も死んでしまう。)(訳注:HPFSでは、ディスク は単なるセクタの列ではなく、「連続セクタのブロック」として管理されて いる)
ではHPFSの欠点は? HPFSはFATより複雑なので、ディスク容量と処理時間 を余計に必要とする。しかし、利点が遥かに大きく、欠点を埋め合わせて おつりがくる。極めて小さいディスクやわずかなファイルしか存在しない ディスクには向いていないであろう。HPFSをディスケットに適用するのは 良くないだろう(訳注:できない(^_^))
FATのような雑なファイルシステムはディレクトリエントリに最低限の容量 しか割り当てていない。HPFSはそれぞれのファイルにずっと多くの情報を 持っている。特に、HPFSには有名なファイル名の"8.3"制限がない。
ファイルをHPFS区画からFAT区画に複写すると、FATのディレクトリに入りき らない情報がでてくる。そのような情報を拡張属性(Extended Attributes、 EA)と一括して呼ぶ。この情報は捨てられてしまう訳ではなく、隠しファイ ル("EA DATA. SF"という名前)にしまわれる。ファイル名に空白が入って いるのは間違えて消されないようにである(訳注:2重ブートでMS-DOSから 消されるのが恐いのだが、空白を含むファイル名はMS-DOSのコマンドではそ れなりのテクがないと扱えない)。このファイルはFATの補助と考えればよい。
("WP ROOT. SF"という隠しファイルにも気づくかもしれない。これはHPFSを 含む全ての区画にある。このファイルはディレクトリツリーのルートノード を保存している。
HPFS区画からディスケットにファイルを複写して、それを他の機械に持って 行き、そこのHPFS区画に複写すると、"EA DATA. SF"の情報を使ってディレ クトリエントリが再現される。その結果長いファイル名やアイコンが失われ ない。
(注意:これをWindows95で試さないこと。似た名前の他のファイルを上書 きすることがある。長いファイル名をちゃんと実装しないで模倣すると、こ ういうことが起こる)。
拡張属性を必要としないファイルはたくさんあり、拡張属性は必要がなけれ ば保存されない。そうでなければ拡張属性は相当大きくなる可能性があり、 検索上問題になる。
この図式の小さな問題として、全てのファイルが2つの名前を持つことがあ げられる。これらはフォルダの詳細表示で「題名」「実名」として表示され る。2つの名前はHPFS区画では同じである。FAT区画では屡々異なる。題名- 即ち長い名前 - はデスクトップの操作で用いられる。例えばマウスでの複 写である。実名はコマンドラインでの操作で用いられる。テクがあれば、 題名と実名とを全く別にもできるが‥まあ混乱するだけだからやめておいた 方が良いであろう。
コンピュータの電源をいれるか、リセットボタンを押して再起動をかけるか すると、BIOSに制御が渡される。BIOSは初期化の過程で、活性化された(アク ティブな)基本区画から「ブートブロック」を読み込む。ブートブロックには 通常小さなローダが含まれる。ローダの役割は、OSの残りの部分を読み込むこ とである。
アクティブな基本区画とは何だろう。既に見たようにディスクには複数のC: ドライブが存在しうる(訳注:基本区画を複数作った場合)。BIOSはこの内 どれに制御を渡すか決めなければならない。そのため、ディスクの主ブート レコード(Master Boot Record, MBR)にフラグ(訳注:真/偽どちらかの 値を - 値のみをとる変数。一種の論理的なスイッチと思えばよい)を用意し て、競合する区画のどれを「ブート可能」にするか決めている。
ブートマネジャは小さな基本区画を一つ占有し(ドライブ文字は与えられ ない)、それをブート可能にする。つまりBIOSが起動する「OS」はブート マネジャ自体である。ブートマネジャのプログラムが行うことは単純だ: OSをロードする区画をユーザに問い合わせ、その区画からOSをロードする。 複数の区画に、それぞれのOSを導入してあれば、ユーザはそれをブートマ ネジャのメニューに加えるだけでよい。それにはFDISKを使う。
BIOSは基本区画からしかシステムを起動することができないが、ブートマ ネジャはいかなるディスクのいかなる区画からもシステムを起動すること ができる。基本区画からしか起動できないOSを論理区画において、ブート マネジャ経由で起動することもできるが、現実にはその手の原始的なOSは 基本区画にしか導入することもできないので、こういうことに意味はない。
そういわれても‥そんなことはしないに尽きる。これが最良のアドバイスだ。 頭を冷やして、ちょいと考えて、ブートマネジャを導入しよう。いろんな点 でうまくないアイデアである。
とはいうものの、OS/2はこの機能をもっているし、既にDOSを導入していて 「拡張導入」を選ぶだけの勇気がない人にとっては、実の所、導入時のデ フォルトは二重ブートになっている。というわけで、二重ブートが選ばれ がちであることも無視できない。
二重ブートがどう実現されているかというと、ブートドライブの幾つかの 非常に重要な部分の書替えによる。現在OS/2を使っているとして、「DOSへ 切り換える」(訳注:訳者は二重ブートを使わなくなって久しいので、正 確な表現を覚えていない)を実行すると、ディスクの最初に近い、小さな 部分を適当な所にバックアップする。次いでDOSが必要とする内容に書替え る。機械を遮断し再起動すると、BIOSがロードするのはその書替えられた 部分になり、BIOSから制御を移されるのもその書替えられた部分になる。 その部分はDOSを起動するのに適当なコードになっている。DOSからOS/2に 切り換える時も同様なことが行われる。
上記の操作に加え、AUTOEXEC.BATとCONFIG.SYSの複写または改名が必要で ある。DOSもOS/2も同じ名前を使っているが、中身は同じではない。これ らのファイルのすり替えも二重ブートの必要な機能の一つである。
このようなディスク内容のすり替えを必要とすることが、二重ブートを 勧められない最大の理由である。悪いタイミングで停電したり、誰かが電 源スイッチやリセットスイッチを押したりしたら - 気が散っている時は ついやってしまうものだ - すり替えが途中で終わってしまうことになる。 こうなると、OS/2もDOSも起動しない。
AUTOEXEC.BATにはDOSコマンドの列が書かれ、DOSプログラムやDOSのコマン ドシェルを起動する度に実行される。(思い出してほしいのだが、WinOS2 セッションもDOSのコマンドシェルから実行される) 一般的には、環境 変数の設定が行われる。殊にPATHの設定である。
OS/2とDOS両方を導入しているなら、AUTOEXEC.BATというファイルが2つ 存在する。この2つを混同しないこと。例えばC:にDOSを、E:にOS/2を導 入している場合、DOSを起動するとC:¥AUTOEXEC.BATが、OS/2利用中には E:¥AUTOEXEC.BATがDOSプログラムを走らす毎に実行される。
(二重ブートを使っているならOS/2とDOSの両方のAUTOEXEC.BATが同じドラ イブにある。二重ブートのプログラムがシステムを切り換える毎にAUTOEXEC.BAT を改名する。)
DOS、殊にWindowsプログラムを導入する時に良く知られた問題はPATHが やたらと長くなる事である。典型的なPATHを良くみると、そのエントリ のほとんどはまれにしか使われないことに気づくであろう。でも一つか 二つのプログラムのために、それを削ることができないのだ。OS/2での DOSエミュレーションでは、異なった複数の"AUTOEXEC"ファイルを - も ちろん名前は変えなければならないが - 持つことができる。DOSプログ ラムに特別のAUTOEXECファイルを指定するには、「プロパティ」ノート ブックを開いて「DOS設定」に行き、DOS_AUTOEXECエントリを選ぶ。
各種デバイスドライバの機能を見るには、「HELP BASEDEV」というコマン ドを実行する。全てのドライバについて説明があるわけではないが、主た るものについてはある。さて、「V」ではじまるドライバはDOSセッション 用と思ってもまず大丈夫である。
CONFIG.SYSにはPATH, DPATH, LIBPATH, HELPの定義が含まれる。DOSと同じ くPATH環境変数には、実行ファイルを検索すべきディレクトリが記述され ている。DPATHにはデータファイルを検索すべきディレクトリが記述されて いる。(しかし、どのプログラムがこのDPATHを使うのかはっきりしない) LIBPATHはDLL(動的リンクライブラリ)の検索に、HELPはヘルプファイル の検索に用いられる。
CONFIG.SYSの残りの部分はいわゆる「環境変数」を定義している。環境変 数はシステム全体で有効な定数である(なんでこれが変数と呼ばれるか、 私には判らない)。その値は、たくさんのプログラムから利用される。例 えばTZという定数がCONFIG.SYSで定義されているが、これは一般的な通則 としてユーザのいる時間帯(Time Zone、訳注:日本時、グリニッチ標準 時など)を示すものとして、多くのプログラムが利用している。
CONFIG.SYSはシステム全体のための資源であって、一つや二つのプログラ ムから参照するためだけに環境変数を定義するなど愚の骨頂である。とこ ろが、愚劣な開発者は極めて多い。あるプログラム(さあ、それは何だろ う)に至っては、「システムマネジャ」のパスワードを何と暗号化もせず にCONFIG.SYSに書き込んでくれる。時が経つにつれ、またいかれたプログ ラムを導入するにつれ、どこにもドキュメントされていない暗号もどきで CONFIG.SYSは一杯になっていく。遠い昔に削除したプログラムの環境変数 が含まれているかも知れない。
CONFIG.SYSで重要なのは、起動時に一度読み込まれるだけであることであ る。CONFIG.SYSに行った変更は、次の起動時に初めて有効になる。これが アプリケーションによっては導入時に再起動を必要とする理由である。逆 に再起動を要求する導入プログラムは、CONFIG.SYSを変更しているはずで る。その手のプログラムには気を付けよう、多くの場合捨てた後にもゴミ をまき散らしたままにする手合いである。
通常のシステムの利用で変化するパラメタを記録する必要もある:フォルダ の位置やアプリケーション毎に設定するパラメタなどである。OS/2では、 この目的のためにINIファイルを利用している。INIファイルは効率を上 げるためバイナリファイルになっており、テクストエディタで読むことは できない。しかし、フリーウェアやシェアウェアのINIファイルエディタが 存在し、それらを使うとINIファイルの中身を見る事ができる。
INIファイルの各エントリは、実効的に、(アプリケーション、鍵、値) の3ツ組である。アプリケーションと鍵は通常、人間にも読める形で書か れている。値の部分に関しては、サイズ、形式、意味共アプリケーション に依存している。数、文字列、あるいはもっと複雑なデータ構造でもあり うる。普通はその意味はどこにも書かれていない。プログラマから見ると、 INIファイルのデータなぞ、原作者だけが知っていればいい内部情報だか らである。(その結果INIファイルの編集にはリスクが伴う。)
INIファイルを使うことの大きな強みの一つは、アプリケーション毎に自 前のINIファイルを持てる事である。別の方法は一つの巨大な中央登録簿 を用意して、システム内の設定を全て押し込むことである。しかしこれは 大変まずい設計である:アプリケーションがシステムに触るのを許すこと になりかねないし、アプリケーション相互の影響も起こりうるし、登録簿 のサイズが大きいので効率も悪くなろう。アプリケーションが自分のディ レクトリに自分でデータをとっておく方がずっといい。
システムINIファイル(OS2SYS.INI)とユーザINIファイル(OS2.INI)と 呼ばれる2つの「大域」INIファイルがある。システムINIファイルはOSと 「中心的な」アプリケーションが必要とするデータをしまっている。プロ グラマがみんな期待するほど優秀というわけではないので、大域INIファ イルには本来はアプリケーション自前のINIファイルにあるべきエントリ が入っている。
システムは常にいらなくなったINIファイルのエントリを消すわけではな いので、INIファイルは時とともに大きくなる。この現象はOS/2 2.0では 特に顕著だった。以降の版では改善されているが、それでも時々INIファ イルチェッカを走らせ、不正または不要なエントリを消すのが望ましい。
OSによっては、「フォルダ」と「ディレクトリ」は全く異なった概念であ る。OS/2では実効的には同じものだ。「デスクトップ」(典型例)という ディレクトリが起動ディスクにある。ファイル管理ソフトを使ってその中 身を見ると、デスクトップフォルダの各サブフォルダに対応したサブディ レクトリがあるのに気づくだろう。デスクトップ上ないしデスクトップフォ ルダの中のファイルは全て対応したディレクトリのファイルとして表示さ れるであろう。
逆にドライブオブジェクトでディスクのディレクトリを見ると、全てのファ イルをデスクトップのオブジェクトとして見る事になり、サブディレクト リはフォルダとして表現される事になる。
若干複雑で混乱の元になりそうなことがある。ドライブオブジェクトを使 いデスクトップの「詳細表示」を開くと(またはもっと簡単にデスクトッ プを右クリックして Open as details view と喋る(訳注:Warp4は本来 VoiceType標準装備である(;_;))と)、タイトルだけあって実名がないオ ブジェクトがあるだろう。多くのファイル管理ソフトでは、これらは表示 されない。
なんでこうなるかというと、多くのデスクトップオブジェクトはINIファイル の中だけで定義されており、ディスク空間を消費しないからである。というわ けで、ディレクトリエントリにはファイル名が登録されない。これらを、大き さ0のファイルとして表示するファイル管理ソフトもあるが、ほとんどの場合 単純に無視するだけである。
(逆に、シャドウを削除しても元のファイルはそのままである)
プログラムオブジェクトは結局の所、実際の実行ファイルを参照しているのだ が、シャドウと異なり、一人前の独立したオブジェクトである。シャドウより 柔軟なポインタの一種と思っていい。プログラムオブジェクトのプロパティノー トブックは実行ファイルのとは別物である。簡単な例を挙げると、アイコンを 異なるものにすることができる。もっと重要なのは、パラメタ欄に異なった内 容を入れられる事である。後でその利点を説明しよう。
シャドウは、削除しても簡単に作り直せる。うっかりプログラムオブジェクト を削除してしまうと、作り直すのは若干面倒である。一方、実際のファイルを 削除してしまうと、それは消え去ってしまう。いま扱っているのがどのような オブジェクトなのかを知る事は大切である。
多くの人はデスクトップのカラースキームを調整して、シャドウの題名の色を 他のものと変えている(訳注:デフォルトでそうなっているはず)。それでも 不十分なら、オブジェクトを右クリックするといい。シャドウなら「オリジナ ル」というサブメニューがメニューにあるはずである。
他の2つを区別にはプロパティノートブックを開く。実際のファイルなら、 「ファイル」ページがある。それがなければ、オブジェクトは抽象オブジェク トである。(デスクトップフォルダはこの分類では「実際のファイ ル」である)
現実のオフィスでは、ほとんどのファイルはキャビネットに収まっているべき ものである。デスクトップは空いていなければならない。良く使う道具と、現 在進行中の仕事だけがあるべきである。よろしい、あなたの机はそうなってい ないかも知れない。私の机だってそうだ。しかしきっちりやれば、こうなるは ずなのである。
同様に、OS/2のデスクトップにも(フォルダは別にして)生のファイルそのも のをおくべきではない。デスクトップ上のフォルダの中でもそうだ。デスクトッ プに置いていいもの、デスクトップ上のフォルダに入れていいものは、フォル ダ、抽象オブジェクト、シャドウだけである。
シャドウの主な役目はファイリングシステム中の、良く使われるオブジェクト への近道としてである。私のデスクトップには「シャドウ」というフォルダが あり、良く開くディレクトリのシャドウが入れてある。
プログラムをデスクトップに置く場合、シャドウは一つの方法である。しかし プログラムオブジェクトを使うのが普通はもっといい。その理由は、
ほとんどの人がOOP入門をC++でやっているのは、なんとも哀れを誘う(訳注: 著者はModula-2プログラマである)。ある世代のプログラマ全体が、OOPとは何 かやたらと複雑怪奇なもので、法律家以外誰も見向きもしないような隠微な規 則と特例だらけの迷路だ、と信じ込みながら育っているのだ。
この印象は見当外れである。単にC++のデザイナが太古のCの流儀に従ったから こんなになっただけである:どんなあいまいなでくのぼうであろうと、それを 合法化する方法はあるものだ。もっと「純粋」な形でOOPをサポートするプロ グラミング言語を一つでも知っているなら、OOPの哲学が「概念の節約」を旨 としていることに気づくであろう。
基本的な出発点はオブジェクトクラス object class と呼ばれる何かである。 クラス class とは、データ型であって、多くの言語で「レコード record 」 型と呼ばれるもの、Cでいう「struct」型に似ている。違いはここだ:クラス の定義では、データ要素だけでなく、そのクラスのオブジェクトに作用する 手続きや関数も含まれる。(OOPの用語法では通常「メソッド method」と呼 ばれる。) データ保護の観点、また「きれいな」プログラミングの為に、 オブジェクトのデータには一緒に定義されたメソッドと通してだけ触れるよ うにするのが有意義である。
強調するために、もう一度書こう。伝統的なレコード型は、オブジェクトの データ要素を定義する。クラスはこれを超えるものだ:オブジェクトの構造 を定義することは、同時にオブジェクトを操作する方法の一覧を用意するこ とになる。
これだけではOOPにならない。「情報隠蔽」の原則をサポートしたプログラミ ング言語なら - 名前は変わっても - 同じことができる。これをOOPにするに は、継承 inheritanceが必要である。
さてここで、C1というクラスが既に定義してあるとしよう。次いで新しいクラ スC2を定義しようとしているとする。C2がC1を継承すると指定すれ ば、C2にはC1で定義した全てのデータ要素とメソッドとが含まれるようになる。 加えてC2はC1に存在しない新しい要素やメソッドを持つことができる。つまり、 C2型のオブジェクトはC1型のオブジェクトに他ならず、しかしC1にはない特性 も持っているということである。
この関係を呼ぶ方法の一つが、「C2はC1のサブクラス subclass である」とい うことである。私自身はこの呼び方は混乱を生むと思う;むしろ「C2はC1の詳 細化 refinement である」と呼びたい。どちらの呼び方も一般的である。
ほとんどのOOPの実装では、多態性 polymorphismと呼ばれる特徴を サポートしている。それはこんな風に働く。C1にFというメソッドがあるとしよ う。C2にも同じ名前のFというメソッドがあって、実装(訳注:ここでは処理内 容くらいの意味)が異なっているとする。これが可能 - ほとんどのOOPでは可 能 - なら、Fという名前は潜在的な曖昧さを持つ事になる。なぜならば同じ名 前で2つの機能があるからだ。この曖昧さを解決する明らかな方法がある:F がC2クラスのオブジェクトに適用されたら、C2のメソッドが使われる。C1(で かつC2でない(訳注:C2クラスはC1を*含む*のでこういう表現をしている)) クラスのオブジェクトに適用されたらC1のメソッドが使われる。
その結果、いろいろな版の関数が出る事になる。関数がオブジェクトを操作す る時にクラスがどの版を使うか決める。
実際には、もっといろいろなことがあるのだが、そういった極度に細かいこと は、プログラマが興味を持てばいい。ここではOSにとってのオブジェクト指向 が何なのか見るのが狙いである。
ある意味で、「オブジェクト指向プログラミング」と「オブジェクト指向OS」 とは全く異なっている。オブジェクト指向OSを非オブジェクト指向のプログラ ミング言語で書く事もできるし、逆もまた真である。しかし、同じ継承の考え がどちらにも利用されている。クラスの継承をサポートしていれば、オブジェ クト指向のOSである。ユーザに継承の結果が見えれば、オブジェクト指向のユー ザインタフェースである。
具体的な例をとってみよう。「ファイル」というクラスから始める。このクラ スのメソッドは標準的なファイル操作を含んでいるはずだ:オープン、クロー ズ、読み込み、書き込み。
次に、サブクラスを定義してクラスを詳細化できる。いくつかの異なったやり かたで。例えば、「ディレクトリ」というサブクラスを定義しよう;このクラ スのオブジェクトは特殊なファイルである。「ファイル」に行える全ての操作 は「ディレクトリ」にも行えるが、「ディレクトリ」に行える操作には、どん なファイルにも使えないものがある。
別の例を挙げる。いろいろな種類のスクリーンオブジェクトがクラスを次々 に詳細化して構成されるのは、直ぐにわかるだろう。例えば「スクリーン矩 形」というクラスを定義して長方形を描くための基本的 primitive な操作を 組み込むことができる。こうするとそれをさらに特殊化してタイトルバーな どを含んだ「スクリーン窓」クラスを定義することができる。もうちょっと やれば「編集可能なテクスト窓」クラスを定義することもできる。このクラ スには先祖の全ての性質 properties が含まれ、編集にだけ必要な、いくた リかの特別な操作(挿入、削除など)をそれらに加えてもっている。実際、 OS/2システムエディタはこういった種類の詳細化から組み上げられた具体的 な現実例(訳注:instance、インスタンス)の一つである。
プログラマにとっては、オブジェクト指向のやり方の主なポイントは、それ が手許に存在するソフトウェアを再利用するための仕掛けを提供することで ある。新しいオブジェクトクラスを定義する際、狙いに一番近い、現存のク ラスをとってきて、少量の新しい特徴を加えてサブクラスを作る。もし十分 近いクラスが存在しなければ、詳細化の更に過程を何段階か必要とする。仕 事は増えるだろうが、無から始めるよりはましだ。
こういったことが、OS内部の何か秘密めいた作業であると思わないことが大 切である。例えば有名な「Zip」「Unzip」ユーティリティのドラッグ&ドロッ プ版を作ろうとしているとする。OS/2には既に「フォルダ」クラスがあって ユーザが何かをドラッグで入れたり出したりすることができる。このフォル ダクラスのサブクラスを作って、何かがドラッグで入れられたら自動的に圧 縮し、取り出されたら自動的に展開するようにすればよい。このためには、 何もOS/2開発部隊の一員である必要も、OS/2のソースを閲覧する必要も ない。アプリケーション開発者にもできる事だ。オブジェクト指 向のOSでは、ユーザインタフェースに独自の拡張を加えることは容易である。
ユーザの視点から見ると、オブジェクト指向の大きな功徳というのは、イン タフェースが一貫していることである。デスクトップオブジェクトは各種あ るが、基本的なマウス操作(ドラッグ、オープンメニュー、など)をサポー トするあるクラスを共通の先祖に持っている。一度あるオブジェクトでドラッ グ操作を学べば、共通のクラスをベースにしているので、他のオブジェクト のドラッグも全く同じように行える。
最も明白で伝統的なライブラリの使い方は、プログラマが手続きや関数を呼ん だ所で、呼ばれた部分のコードがプログラマ自身のコードにリンクされ、最終 的な実行プログラムの一部になる(訳注:静的リンク)というのである。
しかし、もし2つのプログラムがライブラリの同じ関数を呼ぶとし、更に、 両者が同時に実行されるとしよう。どうなる? ライブラリの関数のコピー が2つ同時に主記憶に存在する事になる。これではメモリがもったいない。 一つのコードだけをロードして、それを分け合うことができれば、このよう な無駄はなくなる。
これを実現する一つの方法は、全てのライブラリを最初にロードしてしまう ことである。プログラマはライブラリを実行ファイルの一部にリンクしない で、代りに最初にロードされたライブラリの機能を呼べばいい。これは可能 であるし、実際昔は行われた。現在ではライブラリが巨大になっているので それらをロードするだけで膨大なメモリを必要とする。それらの大部分は、 使われないで終わるかもしれない。となると、これはメモリの有効利用とは いい難い。
動的リンクライブラリ dynamic linked library (DLL) は、この両極端の中 間を行くものである。プログラマが何かをDLLから呼んでも、その時点では コードはリンクされず、実行時に初めてリンクされる。(だから「動的」な のである。) システムは、何かがDLLを要求していると通知されると、それ を主記憶にロードできるようにする。もし2つの異なるプログラムが同じDLL を使っても、ロードされるのは1つのみである。DLLを利用するプログラムが 全て終了すれば、DLLは主記憶から削除できるようになり、他のアプリケーショ ンがそのメモリを使えるようになる。
動的リンクは若干の実行時オーヴァヘッドを伴う。静的リンクされたプログラ ムほど高速にはロードできないからである。しかし主記憶利用の改善に比べ ると、ほとんどの人がこのオーヴァヘッドを容認するだろう。
後で見るように、OS/2はいくたりかのDLLを起動時にロードしてしまう。これ はDLLの哲学に反するように見えるかもしれない(し、起動時間が長くなる)。 こういうことを行う主な理由は、いくつかのDLLは極めて頻繁に呼ばれるので、 ロードしたりアンロードしたり繰り返すのが無駄だからである;常に利用でき るようにしておく方がいい。
(一方、起動時にロードされるDLLが全て「極めて頻繁に呼ばれる」かは明ら かでない。エキスパートの間でもプリロードの是非に関しては論議が続いて いる)
VIO(仮想I/O)はOS/2の一部で、テクストモードの画面出力に与かる。プログ ラマは「OS/2窓」「OS/2全画面」セッションでプログラムを実行したいとき、 VIOを呼び出す。つまり、テクストモードのOS/2アプリケーションは通常VIO アプリケーションである。
(全画面セッションでは、VIOをバイパスして画面をもっと直接制御しグラフィ クスを描画することもできる(訳注:例えばVitrual Pascal/2では、これを行 うためのライブラリが公開されている)。しかしこれは全画面に限られる。 窓では実行できない。)
プレゼンテーションマネジャ Presentatiion Manager (PM)は更に上のレベ ルのソフトウェア層であり、もっと複雑な特徴をもっている:グラフィック窓、 窓の中の窓、メニュー、押しボタン、複数の文字フォント、などなど。OS/2の グラフィックモードアプリケーションはほぼ全てPMアプリケーションである。
OSのコマンドシェルはユーザの入力をうけ、それに何かの作用をす る部分である。コマンドシェルには、テクストモードでタイプされたコマンド を受付けるものもあるし、グラフィカルユーザインタフェース(GUI)でマウ ス(や他のポインティングデバイス)を主たるコマンドの入力源とするのもあ る。OS/2には標準でテクストモードシェルとGUIシェルがそれぞれ1つづつ付い てくる。オプションでサードパーティのシェルに替えることもできる。
テクストモードのシェルはCMD.EXEである。OS/2窓や全画面のセッションを開 くと実行される。
標準のGUIシェルはPMSHELL.EXEである。これがワークプレースシェル Workplace Shell (WPS)として知られるものである。CONFIG.SYSには通常 PROTSHELL行があり、システムが起動する時WPSを開始する。望みとあらば、 WPSなしでOS/2を始動することができる。単にPROTSHELL行のPMSHELLをCMDに 変えればよい。
OS/2全画面セッションを使っている間、一時的にWPSは停止され、コントロー ルがテクストモードシェルに移る。OS/2窓ではそうでない:テクストモード シェルをPMアプリケーションとしてWPSの制御下で走らせているのである。
コマンドプロセッサが「シェル」と呼ばれるのは、それが厳密にはOSの一部 ではないからだ;OSの直ぐ上に乗る層を形作る。OSに関する限り、コマンド シェルは単に一つのアプリケーションに過ぎない。
プログラマが新しいオブジェクトクラスを作った場合、その定義は潜在的なユー ザからアクセスできないといけない。同じプログラムの中だけで使うなら、そ れは使っているプログラミング言語のスコープ則に依存しており、OSは関知し ない。しかしクラスを他のプログラムからも使えるようにする場合、 OSはそれを通知されなければいけない。その時クラスは登録済みクラスになる。
[註: 短くするためにここでは無理に単純化している。登録済みクラスに関す る完全な話はかなり複雑であり、私もちゃんと理解しているか不安である。 この項目の記述は、あくまでもラフスケッチとして受け取って欲しい。]
クラスはデータ構造とクラスを制御するための一そろいのメソッド - 即ち実行 コード - からなることを思い出して欲しい。実行コードをどこにおけばいい? OS/2ではそれらをDLLに入れる。クラスを他のプログラムから使えるように登録 する際、プログラマはクラス名とDLLの名前を提供する。その結果、クラスを利 用すると、当該DLLのコードが実行される。
OS/2の最近の版では、クラスのDLLの内いくつかは起動時にメモリにロードされ る。(この機能がいつ現れたか覚えていないが、少なくともWarp4ではそうなっ ている。) これで起動は遅くなるが、頻繁に使われるDLLへのアクセスは速く なる。もし起動時にロードされたDLLが実際には使われなければ、直ぐに主記憶 からディスクにスワップされる。
プリロードされたクラスはOS2.INIのPM_Workplace:IplLoadにリストされている。 加えて、厳密にはプリロードされているわけではないが、システム起動時から ほとんど常に存在するクラスもある。これらはWPSのように(ほとんどのOS/2 ユーザにとって)常に動作しているソフトウェアの部品の場合である。
これらのDLLは多くの(恐らくはほとんどの)場合複数のクラスを実装してい ることに注意されたい。たった一つのクラスを利用するためにも、DLL全部を ロードする必要があり、そのDLLがサポートする他のクラスもロードされるこ とになる。これが、例えば、有害極まるイメージビューアを取り除くのに、 マルチメディアサポート全体を捨てなければならない理由である。
ソフトウェアにそれ程詳しくないユーザは全く異なった観点を持っている。彼 らにとっては、重要なファイルというのはワードプロセッサの文書、表計算の シート、データベースなどである。プログラムは単に計算機の「からくり」の 一部で、ないと動かないが理解しなくてもいい何かである。
オブジェクト指向のアプローチは、この2番目のグループに特に適している。 何かのオブジェクトで仕事を始める時は、基本操作は「このオブジェクトを開 け」である。そのオブジェクトをワードプロセッサの文書として開くか、WWW のリファレンスとして開くか、または他の何か適当な動作をするかは、計算機 が決めればいいことである。
これはデータオブジェクトとプログラムとを関連付けることで可能である。一 度これをやってしまうと、オブジェクトを「開け」ば自動的に関連付けられた プログラムが起動する。OS/2では2種類の関連付けができる:
[特例:Warp4のイメージビューアは各種グラフィックファイルのデフォルト に収まってしまい、どうやっても変更できない。ファイル一つづつ操作する しかない。これはWarp4の新しいバグ^H^H仕様である]
いろいろなファイルのプロパティノートブックを見ると、実行ファイルは通 常関連付けの頁を持っているのに、データにはないことに気づくであろう。 これはWarp4の新しい仕様である。以前のOS/2では、多くのユーザがデータオ ブジェクトの関連付けを変更しようとして、望んだ結果にならないことに驚 いたものである。(何が起きたかというと、特定のオブジェクトの関連付け だけが変わって、その型全般には変わらなかったのである。) 新しいシス テムでは、関連付けをプログラム側からだけ変更できるので、このような誤 りは少なくなった。
データオブジェクトのプロパティノートブックには「タイプ」頁があるが、 時に「変更」頁もあることがある。OS/2はオブジェクトクラスと関連型を 「合理的な」デフォルトの仮定に基づき設定するが、ユーザが結果を好まな ければ、変更することができる。