JPH10507853A

JPH10507853A - ウィンドウをサービスするためのオブジェクト指向システム

Info

Publication number: JPH10507853A
Application number: JP8513878A
Authority: JP
Inventors: リンチ−フレッシュナー，ローレンス，エイ．; マーシュ，ドナルド，エム．; ミルン，スティーヴ，エイチ．; ジアス，ジェフ，エイ．
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1994-10-25
Filing date: 1995-08-17
Publication date: 1998-07-28
Also published as: EP0788646B1; US5668997A; CA2202614A1; WO1996013026A1; EP0788646A1; DE69509406D1

Abstract

(57)【要約】ウィンドウ・サーバはクライアントと通信してウィンドウ・オブジェクトを生成し、破棄し、および変更する。オブジェクトは、クライアントによって与えられたパラメータに応答して生成される。クライアントは、ウィンドウ・サーバによって管理されるウィンドウに関する様々な情報を得ることができる。ハードウェア・ウィンドウはポリモーフィック・スクリーン・オブジェクトを提供するオブジェクトをサブクラス化することによりサポートされる。したがって、ウィンドウがハードウェアもしくはソフトウェア・エンティティのいずれによって生成されたかは問題とならない。クライアントは、特定のウィンドウに関して発生したあるイベント、たとえば構成の変更などに対する応答において、ウィンドウ・サーバにより通知されることがある。ウィンドウ・サーバはまた、クライアントによって指定された、若しくは指定されていないパラメータのほか、ウィンドウ・サーバによって現在管理されているウィンドウの特徴を考慮するデフォルトのウィンドウのレイヤリング方法を動的に管理することもできる。ウィンドウ・サーバはまた、ウィンドウのクラスタリングもサポートするが、これによって１つのウィンドウがモニタをスパンできるようにする。ウィンドウ・サーバはまた、構成プログラムに対する応答において、デスクトップの特徴に対する広汎な変更ができるようにする。

Description

【発明の詳細な説明】ウィンドウをサービスするためのオブジェクト指向システム著作権の告示本特許出願の一部には、著作権保護のもとにある資料を含む。著作権者は、特許商標庁において現れるような特許文献または特許開示内容を何人もが原文通りに複製することを妨げるものではない。発明の分野本発明は、一般的にはコンピュータ・システムにおける改良に関し、特に、グラフィック・ユーザ・インタフェースにおけるウィンドウ・ディスプレイ領域を管理するためのオペレーティング・システム・ソフトウェアに関する。発明の背景現代のコンピュータ・システムの最も重要な面の一つは、人間のユーザと機械の間のインタフェースである。初期の最も一般的なインタフェースの型は、テキスト・ベースのものであった。ユーザは、キーボード上でテキスト文字をタイプして機械と通信し、機械はディスプレイ・スクリーン上にテキスト文字をディスプレイしてユーザと通信していた。最近は、グラフィック・ユーザ・インタフェースがより一般的になってきており、グラフィック・ユーザ・インタフェースでは、機械は、テキストや絵を含むグラフィックをディスプレイ・スクリーン上にディスプレイすることによりユーザと通信し、ユーザは、テキストからなるコマンドをタイプすること、及び、ディスプレイされている絵をマウスなどのポインティング・デバイスによって操作することの両方によって、機械と通信する。現代のコンピュータ・システムには、ウィンドウ環境と呼ばれるグラフィック・ユーザ・インタフェースを処理するものが多い。典型的なウィンドウ環境においては、ディスプレイ・スクリーン上に描かれたグラフィカル・ディスプレイは、電子的な「デスクトップ(desktop)」の表面に似せるように配置され、コンピュータ上で動作している各アプリケーション・プログラムは、「ウィンドウ(win dow)」と呼ばれるスクリーンの長方形の領域内にディスプレイされた１つまたは２つ以上の電子的な「用紙(paper sheet)」として表現される。各ウィンドウ領域は、一般的には関連するアプリケーション・プログラムによって生成される情報をディスプレイし、デスクトップ上に同時に複数のウィンドウ領域が存在して、それぞれの領域が異なるアプリケーション・プログラムによって生成された情報を表すことができる。アプリケーション・プログラムは、ユーザに対する情報を各ウィンドウを通じて提供するが、これは、イメージ、グラフィック、もしくはテキストをウィンドウ領域の中に描画もしくは「ペイント(p ainting)」することによって行う。一方、ユーザはアプリケーションと通信するが、これは、ウィンドウ領域内のオブジェクトをポインティング・デバイスによって制御されるカーソルで「指し示す」ことによって、及びそのオブジェクトを操作したり移動させたりすることによって、さらにまた、キーボード上に情報をタイプすることによって行う。ウィンドウ領域は、ディスプレイ・スクリーン上のいたるところに移動させたりサイズや姿を変更させることができるので、ユーザは便利なようにデスクトップを配置することができる。ウィンドウ領域のそれぞれは、典型的には標準的なグラフィカル・オブジェクト、たとえば大きさ変更のボックス(sizing box)、ボタン、及びスクロール・バーなどを含む。これらの機能は、ユーザがカーソルで指し示して選択したり処理したりできるようなユーザ・インタフェース・デバイスを表現している。これらのデバイスが選択され、もしくは操作されるときは、その下にあるアプリケーション・プログラムにウィンドウ・システム経由で、そのコントロールがユーザによって操作された旨の情報が伝えられる。一般的には、以上に説明したウィンドウ環境はコンピュータ・オペレーティング・システムの一部である。オペレーティング・システムはまた、典型的にはコンピュータ・システムが基本的な操作を実行できるようにするためのユーティリティ・プログラムの集合も含む。基本的な操作には、情報をディスク・メモリに格納したりこれから取り出したりすることや、ファイルの新規作成、名前付け、名前の変更を含むファイル操作を実行することや、場合によっては、機能不調(m alfunctions)を発見してこれから回復するための診断操作を実行することなどがある。コンピューティング・システムの最後の部分は、オペレーティング・システムと相互作用してより高いレベルの機能を提供し、特定のタスクを実行し、及びユーザとの直接インタフェースを提供する「アプリケーション・プログラム」である。アプリケーション・プログラムは、典型的にはオペレーティング・システムの機能を利用するが、これには、一連のタスク・コマンドをオペレーティング・システムに送り出し、その後でオペレーティング・システムは要求されたタスクを実行することがある。例えば、アプリケーション・プログラムは、オペレーティング・システムに特定の情報をコンピュータ・ディスク・メモリ上に格納するよう要求したり、ビデオ・ディスプレイ上に情報をディスプレイするよう要求したりできる。図１は、典型的な従来技術のコンピュータ・システムであってアプリケーション・プログラムとオペレーティング・システムの両方を利用するものの概略図である。コンピュータ・システムは、点線で描かれた箱１００によって概略的に表現され、アプリケーションは箱１０２によって表現され、オペレーティング・システムは箱１０６によって表現される。アプリケーション・プログラム１０２とオペレーティング・システム１０６との間の上述したような相互作用は図では矢印１０４で図示されている。このデュアル・プログラム・システム(dual progra m system)は、メイン・フレームからパーソナル・コンピュータまでの範囲の多くの種類のコンピュータ上で使用されている。スクリーン・ディスプレイの操作の方法はコンピュータごとに異なるが、この点について、図１は、従来技術のパーソナル・コンピュータ・システムを表現している。スクリーン・ディスプレイを提供するために、アプリケーション・プログラム１０２はディスプレイされる情報をスクリーン・バッファ１１０内に一般的には格納する（格納操作は矢印１０８によって概略的に示される）。システム内のさまざまなハードウェア及びソフトウェアの制御の下で、スクリーン・バッファ１１０の内容はバッファから読み出されて、矢印１１４によって概略的に示されるように、ディスプレイ・アダプタ１１２へ提供される。ディスプレイ・アダプタ１１２はハードウェアとソフトウェア（ファームウェアの形式によることもある）を含むが、これはスクリーン・バッファ１１０内の情報をディスプレイ・モニタ１１８を駆動するために使用できる形式に変換する。ここで、ディスプレイ・モニタ１１８は、ディスプレイ・アダプタ１１２とケーブル１１６によって接続されている。図１に示されている従来技術の構成(configuration)は、一般的には一つのアプリケーション・プログラム１０２だけがいかなる時も動作しているシステムではうまく働く。この単純なシステムは正しく動作するが、これはディスプレイ上の問題を起こすことなしに、単一のアプリケーション・プログラム１０２が全スクリーン・バッファ領域１１０のいかなる領域の中にも情報を書くことができるからである。しかし、図１に示されている構成が、１つより多いアプリケーション・プログラム１０２が同時に稼働するようなコンピュータ・システム内で使用される場合（例えば、「マルチタスキング(multi-tasking)」コンピュータ・システム）は、ディスプレイ上の問題が発生しうる。特に、各アプリケーション・プログラムが全スクリーン・バッファ１１０にアクセスする場合であって、アプリケーションの間のある種の直接通信がない場合には、あるアプリケーションが、別のアプリケーションによって使用されているスクリーン・バッファの一部を上書きしてしまい、そのために、あるアプリケーションによって生成されたディスプレイが他のアプリケーションによって生成されたディスプレイによって上書きされる結果となる。それ故に、アプリケーション・プログラムの操作を調節するための機構が開発されたが、これは、各アプリケーション・プログラムがスクリーン・バッファの一部のみに制限されるために他のディスプレイと分離されていることを保証するためである。この調節(coordination)は、ウィンドウがスクリーン・ディスプレイ上で「オーバラップ(overlap)」してもよいシステムでは、複雑になってしまっていた。スクリーン・ディスプレイが配置されてウィンドウが「オーバラップ」してディスプレイされるようになっている場合は、別のウィンドウの「前」にディスプレイされるウィンドウは、下にあるウィンドウの一部を覆って見えなくする。このように、一番前にあるウィンドウ以外は、下にあるウィンドウの一部だけがスクリーンにディスプレイされ、いかなるときも「見える」のはその一部だけとなることがある。さらに、ウィンドウはユーザによって移動されたり大きさを変更されたりするため、各ウィンドウの見える部分が、他のウィンドウが移動されたり大きさを変更されたりしたときに、変わることがある。したがって、各アプリケーション・ウィンドウに割り当てられたスクリーン・バッファの部分はまた、他のアプリケーションのウィンドウが移動し大きさが変更するとき変化する。ウィンドウの移動や大きさ変更によって発生する急速なスクリーンの変更に対応するのに必要なスクリーン・バッファに対する変更を効率よく管理するために、図１に示されている従来技術のコンピュータ配置は、図２に示されているように変更された。この新しい配置のコンピュータ・システム２００は、１つ又は複数のアプリケーション・プログラムによって制御され、そのプログラムとして２０２と２１６が図に示されているが、これらのプログラムはコンピュータ・システム内で同時に動作することができる。プログラムはそれぞれオペレーティング・システム２０４とインタフェースをとるが、この様子は図中の矢印２０６と２２０によって図示されている。しかし、ディスプレイ・スクリーン上に情報をディスプレイするために、アプリケーション・プログラム２０２と２１６はディスプレイ情報を、オペレーティング・システム２０４の中にある中央ウィンドウ・マネージャ・プログラム２１８に送る。次に、ウィンドウ・マネージャ・プログラム２１８は、直接スクリーン・バッファ２１０とインタフェースをとるが、この様子は図中では矢印２０８によって図示されている。スクリーン・バッファ２１０の内容が、矢印２１２に示されるように、ケーブル２２２によってディスプレイ・モニタ２２４に接続されているディスプレイ・アダプタ２１４に提供される。このようなシステムでは、ウィンドウ・マネージャ２１８は一般に、ユーザがアプリケーション・プログラムの処理中に見る全ウィンドウ・ディスプレイの管理の責任を負うことになる。ウィンドウ・マネージャ２１８は全アプリケーション・プログラムと通信状態にあるので、アプリケーション間の調節をしてウィンドウ・ディスプレイが重ならないようにすることができる。その結果、一般に、ウィンドウ・マネージャがする作業は、ウィンドウ及び、ウィンドウが移動したときに描画あるいは再描画しなければならないウィンドウ領域の、位置と大きさを追跡し続けることである。ウィンドウ・マネージャ２１８はディスプレイ要求をアプリケーション２０２と２１６のそれぞれから受信する。しかし、ウィンドウ・マネージャ２１８だけがスクリーン・バッファ２１０とインタフェースをとっているので、各アプリケーションに対してスクリーン・バッファ２１０の各々の領域を割り当てることができ、アプリケーションが間違って別のアプリケーションによって生成されたディスプレイを上書きすることがないことが保証できる。市販されている異なるウィンドウ環境には、図２に図示した配置を利用しているものがいくつかある。これには、Ｘ／ＷｉｎｄｏｗＯｐｅｒａｔｉｎｇ環境、ＷＩＮＤＯＷＳ、Micros oft 社によって開発されたグラフィカル・ユーザ・インタフェース(graphical u ser interface)、及びInternational Business Machines 社によって開発されたＯＳ／２プレゼンテーション・マネージャ(Presentation Manager)が含まれる。これらのウィンドウ環境のそれぞれは、自分用の内部ソフトウェア・アーキテクチャを持っているが、これらアーキテクチャは、コンピュータ・ネットワーク・ソフトウェアを記述するために使用される多層(multi-layer)モデルに類似した多層モデルを使用することによって、すべて分類することができる。典型的な多層モデルには、以下の層が含まれる。ユーザ・インタフェースウィンドウ・マネージャリソース制御及び通信コンポーネント・ドライバ・ソフトウェアコンピュータ・ハードウェアただし、用語「ウィンドウ環境(window environment)」は、上記のすべての層をまとめたものを意味する。最下層のコンピュータ・ハードウェア・レベルは、基本コンピュータ及びディスプレイ・モニタ、キーボード、マウスやトラック・ボールなどのポインティング・デバイスなどを含むこれに関連する入出力デバイス、及びプリンタやディスク・ドライブなどを含むその他の標準コンポーネントを含む。次の層の「コンポーネント・ドライバ・ソフトウェア」レベルは、さまざまなハードウェア・コンポーネントを操作するために必要なコマンドや信号を生成するデバイス依存ソフトウェアからなる。リソース制御及び通信層は、コンポーネント・ドライバとインタフェースをとり、ソフトウェア・ルーチンであってリソースを割り当て、アプリケーション間の通信を行い、高い層によって生成された通信を下にある層へ多重(multiplex)するソフトウェア・ルーチンを含む。ウィンドウ・マネージャは、ウィンドウの移動や大きさ変更、ウィンドウのアクチベート(activate)やインアクチベート(inactivate)、ウィンドウの再描画や再ペイントなどの基本ウィンドウ操作に対するユーザ・インタフェースを処理する。最後のユーザ・インタフェース層は、完全なユーザ・インタフェースを開発するためにアプリケーション・プログラムが使用するさまざまな制御（ボタン、スライダ、ボックスおよび他の制御）を実装する高レベルの機能を提供する。図２に示した配置によってディスプレイ・スクリーンの干渉問題は解決されるが、全アプリケーション・プログラムによって生成されるスクリーン・ディスプレイ要求をウィンドウ・マネージャ２１８が処理しなければならないという欠点がある。これらの要求は順を追って処理することができるだけなので、要求はウィンドウ・マネージャに対して提示するためのキューに入れられ、その後で、各要求が処理されて端末２２４上にディスプレイが生成される。スクリーン上に同時にたくさんのウィンドウが存在するようなディスプレイにおいては、ウィンドウ・マネージャ２１８は容易にディスプレイ情報に対する「ボトルネック」となりうるので、アプリケーション・プログラム２０２及び２１６によるディスプレイの高速な変更ができなくなる。ユーザによってウィンドウが移動されたときや再配置されたときにスクリーンの再描画に時間がかかるため、ウィンドウが少しずつ構築されていく様子が見えるので時間がかかっていることがわかってしまい、これはいらいらさせることになり、システムの操作を損なうことになる。したがって、本発明の目的は、各アプリケーション・プログラムによって生成されたスクリーン・ディスプレイをすばやく効率よく再描画できるような方法でアプリケーション・プログラムとのインタフェースをとることができるウィンドウ・マネージャを提供することである。本発明の別の目的は、全アプリケーション・プログラム若しくはクライアントのディスプレイ生成を調節して、アプリケーションやクライアントが互いに干渉したりスクリーン・ディスプレイ上で互いに上書きしたりするのを防ぐことである。本発明のさらに別の目的は、アプリケーション・プログラムやクライアントと単純なコマンド構造によって相互作用でき、その際にアプリケーション・プログラムは実際の実装の詳細について知る必要がないようなウィンドウ・マネージャを提供することである。さらに、本発明の別の目的は、スクリーン・ディスプレイプロセスを通じて詳細な制御を必要とするアプリケーション・プログラムの開発者が、利用できるが各アプリケーション・プログラムによって使用される必要はないディスプレイコントロール・コマンドのフル・セットによってこのコントロールを完成できるように処理するようなウィンドウ・マネージャを提供することである。発明の概要オブジェクト指向ウィンドウ・サーバ(object-oriented window server)がクライアントとディスプレイ・システムとの間の調整をおこなう本発明の例示的実施の形態においては、上述の問題は克服され、上述の目的は達成される。各クライアントは、パラメータをウィンドウ・サーバに送ることによってウィンドウを作成できる。ウィンドウ・サーバは、そのパラメータにしたがってウィンドウ・オブジェクト(window objects)を作成する。オブジェクト指向の設計、特にウィンドウ・サーバによって作成されたオブジェクトのユニークな特性が、デスクトップやその要素などのディスプレイ空間(display space)のさまざまな面(aspect )の作成、変更、消滅を望むクライアントに対する一貫したインタフェースを提供する。パラメータを受信すると、ウィンドウ・サーバは特定のパラメータが存在するか調べる。特定のパラメータが存在する場合は、そのパラメータにしたがって、ウィンドウはディスプレイ空間や他のウィンドウに相対的な位置にディスプレイされる。特定のパラメータが存在しない場合は、そのウィンドウはデフォルトの階層スキーム(default layerlng scheme)を使用してディスプレイされ、そのウィンドウはすでにディスプレイされているウィンドウに関連するパラメータを引き受ける。ウィンドウ・サーバはまた、サブクラス化(subclass)によって作成されることがあるハードウェア・ウィンドウも提供するが、これは、多相的(polymorphic) なスクリーン・デバイス・オブジェクトを作成するためである。したがって、クライアントがハードウェア・エンティティ(entity)とソフトウェア・エンティティのいずれであっても、ウィンドウ・サーバにとっては無関係である。さらにウィンドウ・サーバは、複数のモニタのスパン(span)をサポートするが、これは、モニタのスパンに必要な内部ウィンドウを含むクラスタ・オブジェクト(cluster object)を作成することによっておこなう。図面の簡単な説明前述及び後述する本発明の利点は、添付した図面と組み合せて以下の説明を参照することによって、よりよく理解されると思われる。図１は、アプリケーション・プログラム、オペレーティング・システム、スクリーン・バッファ、及びディスプレイ・モニタの関係を示す従来技術のコンピュータ・システムの概略ブロック図である。図２は、図１に示された従来技術のシステムを変更した概略ブロック図であり、これによって複数の同時に動作しているアプリケーション・プログラムがスクリーン・ディスプレイを生成できるようになる。図３は、コンピュータ・システム、例えば、本発明のオブジェクト指向ウィンドウ・マネージャが処理を行うパーソナル・コンピュータ・システムの概略ブロック図である。図４は、変更したコンピュータ・システムの概略ブロック図であり、ディスプレイ・モニタ上にグラフィック情報をディスプレイするために多数のアプリケーション・プログラムとウィンドウ・マネージャとの間のスクリーン・バッファにおける相互作用をしている。図５は、情報経路の概略ブロック図であり、アプリケーション・プログラムが本発明のオブジェクト指向マネージャと通信する方法を示している。図６は、システム・レベルのウィンドウ・サーバ(Window Server)、及びウィンドウ・サーバとクライアント(Clients)の間の関係を示すブロック図である。図７は、ウィンドウを作成するためにクライアントからウィンドウ・サーバに送られるパラメータを含む要素及び操作を明らかにするブロック図である。図８は、クライアントによって指定されたウィンドウの種類と位置に応じて、ウィンドウ・サーバによってウィンドウの位置が決められる方法を説明するフローチャートを示す図である。図９は、ノーティフィケーション・インスタンス(notification instances)を作成するためにクライアントがウィンドウ・オブジェクトと相互作用する方法を明らかにするブロック図である。図１０は、本発明の好適実施の形態におけるウィンドウ、ウィンドウ・サーバ、およびイベント・サーバの間の相互作用を示すブロック図である。図１１は、デスクトップを形成する各ディスプレイ・デバイスに対して入出力アクセス・マネージャ(ＩＯ access manager)が存在することを明らかにするブロック図である。図１２は、構成チーム(configuration team)、すなわち、ディスプレイ・デバイス・フレームワーク、ウィンドウ・サーバ、ディスプレイ・デバイス・アクセス・マネージャの間の操作の要素及び流れを示す図である。図１３は、デスクトップ・ジオメトリ(geometry)に対するアクセスのために使用されるクラスを示す図である。図１４は、各コンポーネント・グラフ(graf)・デバイスがTGrafDevice及びMSc reenDeviceによって表現される方法を説明するブーチ図(Booch diagram)を示す図である。図１５は、クライアント・チームのウィンドウ、及びウィンドウ・サーバのウィンドウを示すブロック図である。図１６は、ハードウェア・ウィンドウを実装するためにサブクラス化されたTI nternalWindowを明らかにするブーチ図である。図１７は、TSystemWindow及びTInternalWindowのサブクラス化を示すブーチ図である。図１８は、デスクトップを形成する各ディスプレイ・デバイスを示すブロック図であり、ウィンドウの中で生きて(live)いるTDisplayDeviceがある。図１９は、内部ウィンドウが作成される方法を示すブロック図である。図２０は、ブロック・ダイアグラムによって、異なる３つのモニタにスパンするウィンドウを示す図である。図２１は、ウィンドウが３つのモニタにスパンできるようにするために使用されるシステムを示す図である。図２２は、モニタのスパンをサポートするのに必要なオブジェクトを図示するブーチ図である。発明の好適実施の形態の詳細な説明本発明は、好ましくは、ＩＢＭ、ＰＳ／２、Apple、Macintoshコンピュータなどのパーソナル・コンピュータの上に常駐するオペレーティング・システムの枠内において実施される。代表的なハードウェア環境は図３に描かれており、これは、本発明にしたがったコンピュータ３００の典型的なコンピュータ構成を図示する。コンピュータ３００は、中央処理ユニット３０２（これは、従来のマイクロプロセッサでもよい）によって制御されており、他の何個かのユニットは、すべてシステム・バス３０８によって内部的に接続されているが、特定の処理を達成するために提供されている。特定のコンピュータでは、図３に図示したユニットのうちのいくつかしかないかもしれないし、図示されていないものがあるかもしれないが、多くのコンピュータでは少なくとも図示したユニットがある。特に、図３に示されたコンピュータ３００は、情報の一時的な格納のためにランダム・アクセス・メモリ(random access memory：ＲＡＭ)３０６と、コンピュータの構成及び基本操作コマンドの永久的な格納のために読み出し専用メモリ(r ead only memory：ＲＯＭ)３０４と、及びディスク・ユニット３１３及びプリンタ３１４などの周辺デバイスをバス３０８に、それぞれケーブル３１５及び３１２経由で接続するための入力／出力（Ｉ／Ｏ）アダプタ３１０とを含む。また、ユーザ・インタフェース・アダプタ３１６は、キーボード３２０などの入力デバイス及びマウス、スピーカ、マイクロフォンを含む既知のインタフェース・デバイスをバス３０８に接続するために提供されている。視覚的な出力はディスプレイ・アダプタ３１８により提供されて、バス３０８をディスプレイ・デバイス３２２、例えばビデオ・モニタに接続する。ワークステーションは、その上に常駐するものを有し、Apple System／７、オペレーティング・システムなどのオペレーティング・システム・ソフトウェアによって制御され調整されている。好適実施の形態においては、本発明はＣ＋＋プログラミング言語によって、オブジェクト指向プログラミング技法を用いて実装される。Ｃ＋＋は、コンパイル型言語(compiled language)である、すなわち、プログラムが人間が読みやすいスクリプト(human-readable script)として書かれ、次にこのスクリプトがコンパイラと呼ばれる他のプログラムに提供され、コンパイラは、コンピュータ内にロードできてコンピュータによって直接実行できる機械可読(machine-readable) な数値コードを生成する。以下で説明する通り、Ｃ＋＋言語には、他人が書いたプログラムをソフトウェア開発者が簡単に使用できるという特徴がある一方で、それでもプログラムの再利用を広範囲に渡って制御してその破棄や不適切な使用が防止できるようになっている。Ｃ＋＋言語は、周知であって、この言語の詳細を説明する多くの記事や文書が入手できる。さらに、Ｃ＋＋コンパイラは、Borl and International社、Microsoft社を含む複数のベンダから市販されている。それゆえ、明快にするために、Ｃ＋＋言語及びＣ＋＋コンパイラの処理の詳細については、ここでは論じない。本分野における当業者によって理解されている通り、オブジェクト指向プログラミング(Object-Oriented Programming：ＯＯＰ)技法は、「オブジェクト（obj ects)」の定義(definition)、生成(creation)、使用(use)、消滅(destruction) を含む。これらのオブジェクトはデータ要素及びそのデータ要素を操作するルーチン、いいかえれば関数を備えたソフトウェア・エンティティである。データ及び関連する関数は、ソフトウェアによってエンティティとして扱われ、あたかも単一のアイテム(item)であるかのように、生成され、使用され、削除されることができる。ともに、データ及び関数は、オブジェクトがデータ要素によって表現されうる、実世界のエンティティをその特徴の観点から仮想的(virtually)にモデル化することができるようになり、そのデータの操作関数によって表現されうる、その振舞い(behavior)を仮想的にモデル化することができるようになる。この方法では、オブジェクトは、人間やコンピュータのように具体的なものをモデル化することができ、数や幾何学的なデザインのように抽象的な概念もモデル化することができる。オブジェクトは、「クラス(classes)」を生成することによって定義される。「クラス」はオブジェクト自体ではないが、実際のオブジェクトを構築する方法をコンパイラに指示するテンプレート(templates)として働く。たとえば、クラスは、データ変数の数と型、及びそのデータを操作する関数に含まれるステップを指定する。オブジェクトは実際には、コンストラクタ(constructor)と呼ばれる特殊な関数という手段によって、プログラム内で生成される。コンストラクタは対応するクラス定義やその他の情報、例えばオブジェクト生成の際に提供された引数などを使用してオブジェクトを構築する。同様に、オブジェクトはデストラクタ(destructor)と呼ばれる特殊な関数によって破棄される。オブジェクトは、そのデータを使用しその関数を起動することによって、使用することができる。オブジェクト指向プログラミング技法の利点は、３つの基本的な原理から生ずる。その３つの原理とは、カプセル化(encapsulation)、ポリモーフィズム(poly morphism)、及び継承(inheritance)である。特に、オブジェクトは、内部データ構造や内部関数の全部もしくは一部を隠す、つまり、カプセル化するように設計することができる。特に、プログラムの設計の間、プログラム開発者は、データ変数の全部または一部及び関連する関数の全部または一部が「非公開(private) 」、つまり、そのオブジェクト自身のみによる使用のためであるようなオブジェクトを定義することができる。他のデータや関数は、「公開(public)」、つまり、他のプログラムによる使用のために利用できるように宣言することができる。他のプログラムによる非公開変数に対するアクセスは、オブジェクトの非公開データにアクセスする公開関数をそのオブジェクトに対して定義することによって制御することができる。公開関数は、非公開データと「外側」の世界との間の制御された矛盾のないインタフェースを形成する。直接非公開データにアクセスするプログラム・コードを書こうとしても、コンパイラはプログラムのコンパイルの間にエラーを生成し、そのエラーはコンパイル過程を停止させることになるので、プログラムの実行は防止される。ポリモーフィズムは、同じ全体的なフォーマットを持つが、異なるデータを扱うオブジェクトや関数が、矛盾のない結果を作成するために異なる機能を果たすことができるようにさせる概念である。たとえば、加算関数は、変数Ａプラス変数Ｂ（Ａ＋Ｂ）として定義できるが、ＡやＢが数、文字、ドル、セントのいずれの場合であってもこれと同じフォーマットが使用できる。しかし、加算を実行する実際のプログラム・コードは、Ａ及びＢを備える変数の型に依存して大きく異なる。ポリモーフィズムは、３つの独立した関数定義を、変数のそれぞれの型（数、文字およびドル）に対して１つずつ書くことができるようにする。関数を定義した後は、それ以降は、プログラムは、共通のフォーマット（Ａ＋Ｂ）によって加算関数を参照することができ、コンパイルの際に、Ｃ＋＋コンパイラが、変数の型を調べることによって実際に使用されるのは３つの関数のいずれかを決定する。次に、コンパイラは適切な関数コードを置換する。ポリモーフィズムは、類似した結果を作成する類似した関数がプログラム・ソース・コード内で「グループ化」してより論理的で明快なプログラム・フローを生成することができるようにする。オブジェクト指向プログラミングの基礎をなす３番目の原理は継承である。継承によって、プログラム開発者は簡単に既存のプログラムを再利用することができるようになり、ソフトウェアの生成を単なる寄せ集め(scratch)でないようにすることができるようになる。継承の原理は、ソフトウェア開発者が複数のクラス（及びそれらから後に生成されるオブジェクト）を関連あるものとして宣言することができるようにする。特に、クラスは他の基本クラス(base class)のサブクラスとして指定することができる。サブクラスは、その基本クラスの公開関数のすべてを「継承」し、アクセスできるが、これはあたかもそれらの関数がそのサブクラスの中に存在するかのようである。そのかわり、サブクラスは継承した関数の一部若しくは全部をオーバーライド(override)することができ、あるいは、同じ形式の新しい関数を単に定義することによって、継承した関数の一部若しくは全部を変更することができる（オーバーライドや変更は、基本クラスの関数を変更するわけではなく、サブクラスにおけるその関数の使用を変更するだけである）。他のクラスの機能を（選択的に変更して）いくつか持つ新しいサブクラスの生成は、ソフトウェア開発者が容易に既存のコードをカスタマイズ(custmize) して特定の必要を満たすことができるようにする。オブジェクト指向プログラミングは他のプログラミング概念を超える大きな改善をもたらすが、プログラムの開発には、まだ時間と労力の大きな出費が必要とされ、変更して利用できる既存のソフトウェア・プログラムがない場合は特にそうである。その結果、従来技術のアプローチは、プログラム開発者にあらかじめ定義された相互に結びつけられたクラスであって、特定の環境において一般的に見られる処理を実行することをすべて指示されるオブジェクト及び追加の雑多なルーチンを生成するクラスのセットを提供することであった。このようなあらかじめ定義されたクラス及びライブラリは典型的には「フレームワーク(framework )」と呼ばれるものであり、アプリケーションを動作させるためには、あらかじめ作りあげられた構造を提供することが不可欠であった。たとえば、ユーザ・インタフェースに対するフレームワーク(framework)は、ウィンドウ、スクロール・バー、メニューなどを生成するあらかじめ定められたグラフィック・インタフェース・オブジェクトのセットを提供し、これらのグラフィック・インタフェース・オブジェクトに対するサポート及び「デフォルト」の振舞いを提供する。フレームワークはオブジェクト指向技法に基くので、あらかじめ定めたクラスは基本クラスとして使用することができ、組込のデフォルトの振舞いは開発者が定義したサブクラスにより継承したり、変更もしくはオーバーライドのいずれかをしたりすることができ、これによって開発者はフレームワークを拡張して専門的知識(expertise)の特定の領域においてカスタマイズされた解決方法を生成することができるようになる。このオブジェクト指向アプローチには、伝統的なプログラミングに対する大きな利点がある。プログラマは、元のプログラムを変更せずに、元のプログラムの機能を拡張するからである。さらに、フレームワークが階層的構造のガイダンス及びモデル化を提供するので、開発者はコードの層を通して無闇に働くことはなく、同時に、開発者はその問題の領域に特有のアクションを提供することから解放される。含まれるシステムのレベル及び解決すべき問題の種類によって、利用できるさまざまな種類のフレームワークがある。フレームワークの種類は、ユーザ・インタフェースを開発する際に役立つ高レベルのアプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポート、グラフィックなどの基本システム・ソフトウェア・サービスを提供する最低レベルのフレームワークにまで及ぶ。アプリケーション・フレームワークの商業的な例には、ＭａｃＡｐｐ（Ap ple社）、ＢｅｄＲｏｃｋ(Symantec社)、ＯＷＬ(Borland社)、ＮｅＸＴＳｔｅｐＡｐｐＫｉｔ（NeXT社）Ｓｍａｌｌｔａｌｋ−８０ＭＶＣ（ParPlace社）などがある。フレームワーク・アプローチは、オブジェクト層においてカプセル化、ポリモーフィズム、継承の原理をすべて利用しており、他のプログラミング技法に対して重要な改善がされているが、その一方で発生した問題がある。アプリケーション・フレームワークは一般的に、モノリシック(monolithic)なオペレーティング・システムの頂上にある１つ若しくは複数のオブジェクト「層」からなり、オブジェクト層の柔軟さをもってしても、厄介な手続き呼び出しによって基礎となるオペレーティング・システムと直接相互作用をする必要があることがしばしばある。アプリケーション・フレームワークが開発者にアプリケーション・プログラムに対するプレハブ(prefab)の機能を提供する方法と同様の方法で、システム・フレームワーク、たとえば好適実施の形態に含まれるものなどは、システム・レベル・サービスに対するプレハブの機能を提供でき、このサービスを開発者は変更したりオーバーライドしたりしてカスタマイズされた解決方法を生成することができ、それによって従来技術のアプリケーション・フレームワーク・プログラムで必要だった厄介な手続き呼び出しを避けることができる。たとえば、アプリケーション・プログラムによって発生された情報をディスプレイするウィンドウの生成、削除及び操作に対する基礎を提供できるディスプレイフレームワークを考えよう。これらの機能を必要とするアプリケーション・ソフトウェア開発者は、通常これらを提供するための特定のルーチンを書かなければならなかった。フレームワークを使ってこれを行うには、開発者は完成されたディスプレイ(finishe d display)の特徴と振舞いを提供する必要があるだけであり、その一方でフレームワークがこの処理を実行する実際のルーチンを提供するのである。好適実施の形態では、フレームワークの概念を採用しこれを、アプリケーション及びオペレーティング・システムを含む全システムに適用する。商業的もしくは会社の開発者、システム・インテグレータ、もしくはＯＥＭにとっては、これはＭａｃＡｐｐなどのフレームワークに対して説明されてきた利点の全てが、アプリケーション・レベルにおいてテキストやユーザ・インタフェースなどのようなものに対してのみならず、システム・レベルにおいて、印刷、グラフィック、マルチメディア、ファイル・システム、入出力、テストなどのようなサービスに対しても利用(leverage)できることを意味する。図４は、本発明のオブジェクト指向ウィンドウ・マネージャを利用するコンピュータ・システムの概要を示す。コンピュータ・システムは一般的に、点線で囲まれた箱４００で示され、複数のアプリケーション・プログラム（そのうちのアプリケーション・プログラム４０２と４１８が示されている）及びオペレーティング・システム４０４は、コンピュータの操作を制御し調整するために提供されている。図４を簡単にするために、アプリケーション・プログラム４０２及び４１８とオペレーティング・システム４０４との相互作用は、スクリーン・ディスプレイを扱う相互作用に限定されている。図に示す通り、アプリケーション・プログラム４０２と４１８の両方は、オペレーティング・システム４０４のウィンドウ・マネージャ部４２０とインタフェースをとる。次に、ウィンドウ・マネージャ４２０は、情報をスクリーン・バッファ４１２に送るが、これは矢印４０８で概略的に図示されている。しかし、本発明にしたがい及び図４に示すように、アプリケーション・プログラム４０２及び４１８はスクリーン・バッファ４１２に直接情報を送る。この様子は矢印４１０と４２８で図示されている。以下に詳細に説明する通り、アプリケーション・プログラム４０２及び４１８はディスプレイ情報を直接ウィンドウ４２０に提供し、ウィンドウ・ディスプレイが変更されたときにウィンドウ・マネージャ４２０から格納された情報を取り出す。特に、ウィンドウが変更されるとき、ウィンドウ・マネージャ４２０は各ウィンドウの可視領域を再計算して格納する。この格納された可視領域はそれぞれのアプリケーション・プログラムによって取り出され、アプリケーションがディスプレイ情報を描画するクリッピング領域(clipping region)として使用される。ウィンドウの再ペイントや描画はアプリケーション・プログラムによって同時に実行されるが、これはスクリーンの再ペイントの速度をあげるためである。アプリケーション・ディスプレイはディスプレイ・スクリーン上で分割されたままであるが、これはウィンドウ・マネージャ４２０がウィンドウの可視領域(v isible area)を再計算するため、どの領域も重ならないからである。このようにして、各アプリケーション・プログラム、たとえばアプリケーション・プログラム４０２やアプリケーション・プログラム４１８が、ウィンドウ・マネージャ４２０によって自分に提供された可視領域の中だけを描画する場合は、スクリーン・バッファによって生成されるディスプレイの中に重なる部分はない。ディスプレイ情報がスクリーン・バッファ４１２の中にいったん描画されると、今度は、矢印４１４で示されるようにディスプレイ・アダプタ４１６に提供されるが、ディスプレイ・アダプタはケーブル若しくはバス４２４によってディスプレイ・モニタ４２６に接続されている。アプリケーション・プログラムとウィンドウ・マネージャの相互作用は概略図の図５においてより詳細に図示されている。前述した通り、ウィンドウ・マネージャ（図５では箱５１０として図示されている）は、オブジェクト指向プログラムである。したがって、アプリケーション・プログラム５０８は、「オブジェクト」を生成して操作することによってウィンドウ・マネージャとインタフェースをとる。特に、各アプリケーション・プログラムは、ウィンドウ・マネージャ５１０と通信するためにウィンドウ・オブジェクト、例えばウィンドウ・オブジェクト５００を生成する。次にアプリケーション・プログラム５０８はウィンドウ・オブジェクト５００と通信するが、図では矢印５０２で示されている。ウィンドウ・マネージャ自身は、オペレーティング・システムが開始されるときに生成されるオブジェクトであり、ウィンドウ・オブジェクトの生成によってウィンドウ・マネージャ５１０がディスプレイ・スクリーン上の対応するウィンドウを生成することとなる。ディスプレイ・スクリーン上に多くのウィンドウを同時にディスプレイするために、多くのウィンドウ・オブジェクトを同時に生成できるため、各ウィンドウ・オブジェクト５００はウィンドウ・マネージャ５１０とデータ・ストリーム５０４によって通信する。データ・ストリーム５０４は「ストリーム」オブジェクトを生成することによって生成されるが、これにはあるオブジェクトから別のオブジェクトへ情報を転送するために必要なソフトウェア・コマンドが含まれている。たとえば、ウィンドウ・オブジェクト５００がウィンドウ・マネージャ・オブジェクト５１０に情報を転送したいとき、ウィンドウ・オブジェクト５００は、データをウィンドウ・マネージャ・オブジェクト５１０に「流し込む(stream) 」ストリーム・オブジェクト(stream object)を生成する。同様に、ウィンドウ・マネージャ・オブジェクト５１０がウィンドウ・オブジェクト５００に情報を戻して転送したいときは、ウィンドウ・マネージャ・オブジェクト５１０がデータをウィンドウ・オブジェクト５１０に「流し込む」ストリーム・オブジェクトを生成する。このようなストリーム・オブジェクトは本質的に慣習的なものであり、ここでは詳細は説明しない。ウィンドウ・オブジェクト５００からウィンドウ・マネージャ・オブジェクト５１０へデータを運ぶストリーム・オブジェクト及びウィンドウ・マネージャ・オブジェクト５１０からウィンドウ・オブジェクト５００へデータを運ぶストリーム・オブジェクトは、まとめて矢印５０４として図示されている。図５に示すように、ウィンドウ・マネージャ・オブジェクト５１０は３つの主要な部分からなる。可視領域マネージャ５０６、共用データ領域５１２、及びウィンドウ・リスト５１４である。可視領域マネージャ５０６は、ウィンドウ・マネージャ５１０が生成されるときにウィンドウ・マネージャ５１０によって開始される独立したタスクである。以下で詳細に説明する通り、可視領域マネージャは、データ・ディスプレイ・スクリーン上で見えるウィンドウの部分を管理することについて責任がある。この目的のため、可視領域マネージャは、あるウィンドウ、若しくはそのウィンドウの前にある別のウィンドウが変更されたときにウィンドウの可視領域を再計算する。また、可視領域マネージャは、たとえばウィンドウが再オリエント(reorient)されたり大きさを変更されたりして下にある「デスクトップ」の以前は覆われていた領域がさらされるときに発生するデスクトップの「損傷」を直すことなどの、多くの他の管理タスク(housekeeping tasks) も実行する。共用データ領域５１２は、共用メモリ内の領域と関連する格納及び取り出しルーチンを含むが、これらはともにウィンドウに関連する情報を格納する。共用データ領域は、ウィンドウ・マネージャによって共用メモリ内に生成され、共用データ領域の一部はウィンドウのそれぞれに割り当てられ、可視領域のバージョンを意味する「タイム・スタンプ(time stamp)」などのさまざまなウィンドウ・パラメータを含むこととなる。可視領域にアクセスするためのメッセージ・ストリームの使用を減らすため、各ウィンドウ・オブジェクト５００は、ローカルな「キャッシュ」メモリも管理している。このメモリは関連するウィンドウの可視領域のコピーを格納する。タイム・スタンプもまたローカル・キャッシュ・メモリに格納されるが、このタイム・スタンプはウィンドウ・サーバから取り出された可視領域の最新のバージョン(last version)を示す。アプリケーション・プログラムが再描画操作を開始するときは、アプリケーション・プログラムはウィンドウ・オブジェクトからの可視領域を要求する。次に、ウィンドウ・オブジェクトは、共用メモリ領域からタイム・スタンプを取り出されたタイム・スタンプとローカル・キャッシュ・メモリに格納されているタイム・スタンプと比較する。この２つのタイム・スタンプの比較により可視領域が変更されていないことが示された場合には、ローカル・キャッシュ・メモリに格納されている可視領域のコピーが再描画処理に使用される。そうではなく、タイム・スタンプの比較によりウィンドウ・マネージャが可視領域を更新したことが示された場合には、新しい可視領域が取り出され、ローカル・キャッシュ・エリアに格納される。タイム・スタンプだけを取り出すことは、可視領域全体を取り出すことに比べてずっと高速なので、再描画全体にかかる時間は、ローカル・キャッシュ・コピーが使用できる場合には短くなる。ウィンドウ・マネージャ５１０は、ウィンドウ・リスト５１４も管理する。これは、図示したようにリンクド・リスト(lined list)として実装され、システム内の現在の各ウィンドウの識別番号を含む。本発明の好適実施の形態によれば、各ウィンドウはウィンドウの「種類(kind)」を割り当てられている。ウィンドウの種類は、一般的にはスクリーン上のウィンドウの相対的な位置に従った種類の階層から選択される。実例となる種類の階層は以下の通りである（ウィンドウの種類は、通常ウィンドウの一番前の位置にあるウィンドウの種類から始めるように説明する）：一番前の位置：スクリーン・セーバ、メニュー・バー、メニュー、ウィンドイド（フローティング・パレットや他の類似する型のウィンドウを意図したもの）、及び文書。一番後の位置：デスクトップ。ウィンドウ・マネージャは自動的にスクリーン上のディスプレイされているウィンドウを管理するが、それは、同じ種類のウィンドウはすべてある種類の「層」にいっしよに位置するようにおこなわれる。この位置付けは、種類の層の間の分割を示すウィンドウ・リスト内に「プレース・ホルダー(place holder)」を挿入することにより達成される。これによってウィンドウ・マネージャは、これらのプレース・ホルダーの１つに到達するまでウィンドウ・リスト中を通して繰返し、特定の種類の層の終りが新しい種類の層が始まる開始に到達したときを決定できる。前述した通り、好適実施の形態においては、オペレーティング・システムは複数のタスクを同時に動作させることができ、２つ以上のタスクが同時に処理をしているときはいつでも、互いの相互作用(mutual interaction)の潜在的可能性がある。このような互いの相互作用は、２つ以上のタスクが同時に共用リソース、たとえば、共用データ領域やウィンドウ・リストなどにアクセスしようとしたときに発生し得る。したがって、このような相互作用を管理するため及び望ましくない干渉を防止するために、並列制御(concurrency control)が必要である。セマフォ(semaphore)として知られている実例となる並列制御技法が、実施の形態において使用されている。セマフォは周知のデバイスであって、これはリソースに対する並列アクセスの試みに「順序を付ける(serialize)」ために使用される。特に、タスクがセマフォによって制御されているリソースにアクセスできるようになる前に、タスクはそのセマフォを「取得する(acquire)」ことが必要である。そのリソースを使うタスクが終了するときは、そのタスクは、他のタスクによる取得(acquisition)のためにセマフォを解放(release)する。各セマフォは、一般的にはそれに対応する要求キュー(request queue)を持っているので、セマフォを取得するための要求であって、（そのセマフォが他のタスクによって取得されているために）その権利を得ることができなかったものがキューの中に保持されている。現在のシステムでは、セマフォはさまざまな異なる共用リソースを保護するために使用されている。特に、グローバルな描画セマフォ(drawing semaphore)は、アプリケーション・プログラムがウィンドウ・マネージャと相互作用を起こさないようにするために使用されている。可視領域にアクセスする前に、各アプリケーション・プログラムは描画セマフォを取得しなければならない。現在のシステムで使用されている描画セマフォには２つのモードがある。共用モードと排他モードである。本発明によれば、アプリケーション・プログラムは他のアプリケーション・プログラムと同時にスクリーン・バッファ内に書き込みをしてもよいので、「共用」モードで描画セマフォを取得しなければならない。アプリケーション・プログラムはウィンドウ・マネージャによってスクリーン・バッファから切り離されているので、この同時アクセスは問題を起こさない。しかし、ウィンドウ・マネージャは全ウィンドウに影響を与える操作、たとえば新しいウィンドウの生成などを実行するが、したがって、ウィンドウ・マネージャは「排他」モードで描画セマフォを取得しなければならない。ウィンドウ・マネージャが描画セマフォを排他的に取得しているときは、アプリケーションはセマフォを取得することができないので、スクリーン・バッファ内に書き込むこともできない。この排他処理によって、アプリケーションは、変更を知らされる前にスクリーン・バッファの変更された部分を上書きしてしまうことがなくなる。同様に、グローバル・セマフォは、ウィンドウ・マネージャ５１０内の共用データ領域５１２を保護するために使用されるが、この共用領域もまた共用リソースである。同様のローカル・セマフォは、ウィンドウ・リスト５１４をウィンドウ・サーバ(Window Server)を使用する異なるアプリケーション・プログラムによる同時アクセスから保護するために使用される。さまざまなセマフォの特定の取得と解放の詳細については、プログラムによって使用される実際のルーチンの詳細を説明するときに述べる。ウィンドウ・サーバは、層サーバ(layer server)として参照することができるが、動作している全プログラムに対するスクリーンの不動産(real-estate)を割り当てて管理するために使用される。ウィンドウ・サーバは、本発明によれば、伝統的なウィンドウ・サーバ機能のほかに数々の機能を実行する。これらの機能には、以下のものが含まれる。描画セマフォを保持したまま死んだタスクからの回復。オペレーティング・システムが動作中のときのディスプレイのユーザ再構成（ビット深さやモニタ位置の変更）。デスクトップ・ジオメトリ(desktop geo metry)に対するプログラマ・アクセス。ハードウェア・ウィンドウ、つまり、ウィンドウをハードウェアによって高速化できるようにすること。更新とアクティブ化／非アクティブ化(activate/deactivate)に対するイベントのかわりの使用通知(use notification)。ディスプレイ・デバイスの結合した管理。図６は、システム・レベル６０８におけるウィンドウ・サーバ６０６を示す。ウィンドウ・サーバ６０６は、コンピュータ・システム内のクライアント６００及び６１０などによって非公開で使用される。プログラマがウィンドウ・サーバ６０６を扱う必要はほとんどない。たとえば、ウィンドウを生成し操作するオブジェクト及びシステムの一部は、ウィンドウ・サーバ６０６のクライアントと考えられる。別の例は、文書レベルのウィンドウ・マネージャ、ＭａｃやＯＳ／２アダプタなどのパーソナリティ（ウィンドウを生成して操作するため）、構成モデル（ディスプレイを再構成するため）、グラフィックス・システム（ディスプレイ・デバイスに対する問合せと操作をするため）などのエンティティである。さらに、ウィンドウ・サーバ６０６は、ディスプレイ・デバイス・ドライバ生成者によって拡張されることができる。たとえば、ウィンドウ・サーバ６０６は、ハードウェアがこれをサポートする場合には、ハードウェア・ウィンドウ６１６を実装するように拡張することができ、また、グラフィックス機能６１８を追加するように拡張することができる。拡張は図６の破線で示されており、これはウィンドウ・サーバ６０６の拡張であることを意味している。ウィンドウ・サーバ６０６は、動作している全プログラムの間で、利用できるスクリーン領域を分割するオブジェクト指向システムである。システム・レベル・ウィンドウ・マネージャを使用する他のレベルには、ウィンドウ・マネージャがあることもある。たとえば、システムに文書レベルのウィンドウ・マネージャがあることもあり、これは文書のウィンドウ内のスクリーン空間を管理する。ウィンドウ・サーバのクライアント６００と６１０は、ある境界（任意の領域）を持つウィンドウを生成する。クライアントはシステム・レベル６１０でも非システム・レベル６００でもよい。ウィンドウの順序付け及びその重なり方に基いて、ウィンドウ・サーバ６０６は各ウィンドウの可視部分を決定することができる。クライアントはこの領域に描画を制限することを期待されている。特別なユーザ・インタフェース機能（たとえば、フローティング・ウィンドウ (floating windows)）をサポートするために、ウィンドウ・サーバ６０６は、ウィンドウの種類の数を、６２０で示されているように定義する。これらの種類は、順番がつけられ、ウィンドウ・サーバ６０６は、ある種類に属する全ウィンドウが、それに続く種類に属する全ウィンドウの前にあることを保証する。種類のフル・セットは、以下で説明するが、これには、メニュー・バー、ウィンドイド (windoid)、文書、デスクトップのようなものが含まれる。ウィンドウ・サーバ６０６は、また、各ウィンドウの更新領域６０４を管理するが、これは、ウィンドウ操作のために「損傷」してしまったウィンドウの部分を記述するものである。（文書自身内で発生する損傷は、文書ウィンドウ・マネージャによって管理される。たとえば、文書ウィンドウ・マネージャは、閲覧操作(view manipulation)、非有効化(invalidation)などによって生ずる損傷を管理する。）ウィンドウ・サーバ６０６は、クライアント６００（例えば文書ウィンドウ・マネージャ）に、６０２で示す通り、そのウィンドウの更新領域が空でなくなったとき通知する。また、これは、ウィンドウの損傷した部分の消去もするが、これは部分的にはクライアント（例えば文書ウィンドウ・マネージャ）によって、ウィンドウ毎に(window-by-window)の原則によって制御されている。ウィンドウ・サーバ６０６は、６０２で示す通り、（文書ウィンドウ・マネージャなどの）クライアントに、ウィンドウがアクティブ化／非アクティブ化されたとき通知する。一番前のウィンドウはアクティブなウィンドウであり、他のウィンドウは非アクティブである。ウィンドウ・サーバ６０６は、デスクトップを形成し、デスクトップディスプレイ・デバイス情報(Desktop Display Device Info)６１４の中にあるディスプレイ・デバイスの情報も管理する。構成プログラム６１２は、ビット深さ、モニタ位置及びディスプレーの他のハードウェア固有の属性を変更するために、この情報を問い合わせて変更することができる。以下の説明では、オブジェクトを、大文字の「Ｔ」が前にあるオブジェクト名で参照する。たとえば、システム・ウィンドウ・オブジェクトは、TSystemWindo wとして参照される。クライアント・クラスあるクラスによって、クライアントはウィンドウの生成、破棄、及び操作ができるようになる。たとえば、１． TSystemWindowは新しいウィンドウを生成する。オブジェクトのインスタンシエート(instantiate)はウィンドウを生成する。オブジェクトの削除はウィンドウを破棄する。２． TSystemWindowSurrogateは、TSystemWindowとまったく同じに働くが、代理(surrogate)を破棄しても実際のウィンドウには影響がない点が異なる。図７は、ウィンドウ生成を示す。ウィンドウを生成するには、クライアント７００（文書ウィンドウ・マネージャ若しくはパーソナリティ）が、システム・レベル７０８にあるウィンドウ・サーバ７０６に以下のパラメータを渡して、TSys temWindowを生成する。このパラメータは、（世界座標における領域オブジェクトとして表現される）ウィンドウのエクステント(extent)（位置と形状）、ウィンドウに対するイベント及び通知を受信するタスクを識別するイベント・レシーバ (event receiver)ＩＤ、ウィンドウの前から後への順序付け(front-to-back ord ering)、ウィンドウは最初から見えるようにしておくべきかどうか、ウィンドウ・サーバは自動的にウィンドウの損傷した部分を消去すべきかどうか、及び、ウィンドウの種類などである。ウィンドウ・サーバはウィンドウ上の操作の基本セットをサポートする。クライアントは、ウィンドウの情報を得ることができる。これには、そのイベント・レシーバＩＤ、現在の更新領域、及び現在の可視領域が含まれ、図７ではウィンドウ・サーバ７０６からクライアント７００への矢印として示されている。さらに、クライアントはウィンドウの属性を変更できる。クライアントは、ウィンドウのエクステントを変更したり、ウィンドウを隠したり示したり、ウィンドウを同じ種類の他のウィンドウの前に持ってくることができるが、これはクライアント７００からウィンドウ・サーバ７０６への矢印で示されている。図８は、ウィンドウ・マネージャによってクライアントからの情報に応答してウィンドウの位置が決められる方法を示すフローチャートである。ウィンドウ位置を指定する方法は２つあり、それぞれ専用のコンストラクタがある。第１に、クライアントはウィンドウの種類、及び、それがその種類のウィンドウの一番前か一番後かのいずれにすべきかを指定することができる。この情報が与えられているか否かの決定は、８００における決定によって示されている。種類と位置が指定されている場合は、ウィンドウは位置付けされる（８０２）。第２に、種類が指定されていない場合は、新しいウィンドウはただちに既存のウィンドウの前もしくは後に位置付けできる（８０４）（したがってその種類を用いる(adopt) ことになる）。 TSystemWindowのサブクラスはハードウェア固有のウィンドウを生成するために使用することができる。これは、以降の節「ハードウェア・ウィンドウ」において詳しく説明する。ウィンドウが変更されたとき、ウィンドウ・サーバは、その可視領域を再計算して、（できるかぎり）ウィンドウの更新領域に追加する。ウィンドウ・サーバは、また、クライアントに、ウィンドウが更新を必要とするときや、ウィンドウのアクティブな状態が変化したときの通知もする。各ウィンドウは、その可視領域の現在の「バージョン」を示すタイム・スタンプを管理している。クライアントはこれを使用してウィンドウの可視領域が変換したときを検出することができ、現在の可視領域と古い領域に基いてインクリメンタル更新(incremental updat es)を実行することができる。ウィンドウ上の全操作は、TSystemWindowクラス及びこれとほとんど同じTSyst emWindowSurrogateクラス内で利用できる。この２つのクラスの違いは、「物理的」ウィンドウとTSystemWindowのインスタンスとの間には１対１の対応があることである。オブジェクトを生成するとウィンドウが生成される。オブジェクトが削除されるとウィンドウが破棄される。これは、TSystemWindowのインスタンスは、他のタスクにコピーしたり渡したりできないことを意味する。TSystemWin dowSurrogateのインスタンスは、コピーしたり渡したりができ、他のウィンドウを参照するように変更することができる。TSystemWindowSurrogateのオブジェクトを削除しても、スクリーン上のウィンドウの存在には影響しない。 TSystemWindowクラスは、多数の静的メンバ関数を通して、グローバルなウィンドウ機能を実装できる。たとえば、特定のスクリーンの点を含むウィンドウを取ってマウスのクリックを処理したり、システム描画を停止したり開始したりすることができる。ウィンドウは、ウィンドウがアクティブや非アクティブになったとき、及び、ウィンドウが損傷を受けて更新が必要になったときに、イベントをアプリケーションに送る。このサービスに対する主なクライアントは、文書ウィンドウ・マネージャである。イベントをポスト(post)するかわりに、ウィンドウは通知(notification)を使用する。TSystemWindow及びTSystemWindowSurrogateは、通知者(notifiers)になることができる。図９に示すように、クライアント９００は、９０６で示すように、これらのクラス９０２のどれかに、以下に対するインテレスト(interest)を生成するように、インスタンス生成(Instance Creation)９０４経由で、依頼する。 ActivateWindow このウィンドウがアクティブになっている。 DeactivateWindow 別のウィンドウがアクティブになっている。 WindowUpdate このウィンドウは損傷を受けており再描画しなければならない。ウィンドウがアクティブである旨の通知は、文書によって受信されるイベントと必ずしも同期していない。たとえば、ユーザが非アクティブなウィンドウ上でクリックして、その後でタイプを始めた場合、マウスとキーのイベントが、アクティブになった旨の通知の前に、文書に配送されることがある。アクティブ化についての、イベントに対する通知の使用の利点は、（１）パフォーマンスが良く、（２）プログラミング・モデルが簡単であることであるが、これによってより管理しやすいコードが結果として得られる。図１０は、本願発明の好適実施の形態におけるウィンドウ、ウィンドウ・サーバ１００４、及びイベント・サーバ１００２の間の相互作用を示すブロック図である。ウィンドウ・サーバ１００４は、デフォルトのディレクタ(director)１００６を使用して、デフォルトのイベント（たとえばキーストローク）をどのウィンドウが受信するかを管理する。デフォルト・イベントを受信するウィンドウは、常に一番前にある（ただし、そのウィンドウがデフォルト・イベントを受信できないことを文書ウィンドウ・マネージャが指定した場合を除く）。デフォルト・イベントを誰が受信するかの決定は、イベント・サーバ１００２によって実行される。ウィンドウの１つ１０００は、イベント・サーバ１００２に、（クライアント・クラスを使用して）新しいウィンドウが一番前になるたびに通知を送る。ウィンドウ・サーバはそのウィンドウのイベント・レシーバＩＤをイベント・サーバに渡す。イベント・サーバはこの情報を使用して誰がデフォルト・イベントを得るべきかを決定する。ウィンドウは、ウィンドウ可視領域のセットに対するアクセスを保護する描画セマフォを提供する。可視領域を変更する前に、ウィンドウはこのセマフォを取得する。可視領域に描画する前に、クライアントはこのセマフォを共用モードで取得しなければならない。この慣習による結果は、ウィンドウが可視領域を変更する必要があるときは、現在の描画操作が完了するまでブロックすることである。新しい描画操作は、ウィンドウが完成するまで開始することができない。これは、クライアントが描画するときに、可視領域が本当に正しいとを保証する。クライアントの描画は、文書ウィンドウ・マネージャによって可視領域にクリップされるので、これは、クライアントに割り当てられていないスクリーンの部分にそのクライアントが描画することはないことを保証する。発生する一つの問題は、描画セマフォを保持したままクライアントのタスクが死ぬかもしれないことである。システム・カーネル(kernel)は死んだタスクによって保持されているセマフォを解放しない。その結果は、すべての描画がデッドロック(deadlocks)し、エンド・ユーザにはシステムが完全にハングした(hung) ように見えるので、破滅的である。好適実施の形態では、回復セマフォ(TRecove rableSemaphore)をシステム・カーネルに追加することによってこの状況は改善されている。このセマフォを保持したタスクが死ぬときに、カーネルは自動的にこれを解放する。 TSystemWindow及びTSystemWindowSurrogateには、このセマフォに対するクライアントのアクセスを許可するメンバ関数がある。これらのメンバ関数は、セマフォに対する取得、解放(release)、待ち(wait)の機能が含まれる。図１１は、デスクトップを形成する各ディスプレイ・デバイス用に入出力マネージャ１１０４が１つあることを明らかにするブロック図である。入出力アクセス・マネージャを持つ１つ又は複数のクライアント・チーム１１００がある。TD isplayDeviceHandles１１０２は、ディスプレイ・デバイスと通信するために使用されるクライアント・オブジェクトである。ディスプレイ・デバイス入出力アクセス・マネージャ１１０４は、ハードウェアディスプレイ・デバイスの状態、たとえばモニタ・ビット深さ(monitorbit de pth)や位置などの管理と操作に対する責任がある。ディスプレイ・デバイス・ハンドル(display device handles)は、これらの属性を変更する構成プログラムによって使用される。ディスプレイ・デバイス・ドライバの生成者は、TDisplayDeviceHandleをサブクラス化して自分のハードウェアによって提供されている機能をサポートしなければならない。カードが特有の機能、たとえばクロマキー(chroma keying)によるビデオ・オーバレイなどを実行する場合は、サブクラス側ではTDisplayDevice Ha ndleにメンバ関数を追加して、クライアントがこの機能にアクセスできるようにするとよい。構成プログラムは、スクリーンの再構成の前に、全描画を停止する必要がある。ビット深さ及びモニタ位置は、ユーザが再構成できる事項の例である。図１２は、構成チーム(Configuration Teams)１２００、ディスプレイ・デバイス・フレームワーク(Display Device Framework)１２０６、ウィンドウ・サーバ(Window Server)１２０４、及び、ディスプレイ・デバイス・アクセス・マネージャ(Display Device Access Manager)１２１２の間の操作の要素と流れを示す。以下で概説するステップは、図１２の丸で囲まれた番号に対応する。１）構成チーム１２００は、TDisplayDeviceHandle１２０２のメンバ関数を呼び出して、再構成の要求を出す。２）この要求はディスプレイ・デバイス入出力アクセス・マネージャ１２１２に送られる。３）ディスプレイ・デバイス・フレームワーク１２０６は、要求を中断(inter cept)する。これが構成の更新要求であることがわかったときは、フレームワークは要求をウィンドウ・サーバ１２０４によって処理されているウィンドウに（非公開ウィンドウ・クライアント１２０８経由で）送り、全描画を停止させる。４）全描画が停止したときに、ディスプレイ・デバイス・フレームワーク１２０６は要求をディスパッチ(dispatch)するので、サブクラス１２１０が再構成を実行する結果となる。５）サブクラスが再構成を完了したときに、ディスプレイ・デバイス・フレームワーク１２０６は、ウィンドウに描画を再開するよう指示する。ウィンドウは、ディスプレー上のウィンドウに更新通知を送ることにより、影響を受けたスクリーン領域に再描画をさせる。ウィンドウはまた、グラフ・デバイス・シード(g raf device seed)も変更するが、これは文書ウィンドウ・マネージャによって新しいグラフ・デバイスを得なければならないことを通知するために使用される。 TDesktopDisplayは、次の節で説明するが、モニタ構成がどのように変更されたかを正確に知ることにアプリケーションが興味がある場合に使用することができる。デスクトップ・ジオメトリへのアクセス多くのアプリケーションでは、デスクトップのジオメトリ(geometry)、すなわち、デスクトップ全体用のTGArea及びデスクトップを形成する各スクリーン用の TGAreaにアクセスする必要がある。このような機能を利用することができ数少ないクライアントの例は以下の通りである。文書フレームワークは、ズームされたウィンドウがスクリーン全体に広がることができるようにする必要がある。これをするためには、スクリーンの大きさを知る必要がある。文書は、以前はより大きなデスクトップ（たとえば２１インチのモニタ）にディスプレイされていたウィンドウをもっと小さいスクリーン（たとえば９インチのモニタ）上で見えるようにする必要があることがある。カーソル・コードは、デスクトップ・ジオメトリを知ってカーソルをスクリーン上にピン止め(pin)できるようにする必要がある。図１３は、デスクトップ・ジオメトリにアクセスするために使用されるクラスを示すブーチ図(Booch diagram)である。TDesktopDisplay１３００は、全デスクトップを表現するオブジェクトであり、ビット深さの変更及びモニタ位置の変更の通知をする。TDesktopDisplay１３００は、デスクトップを形成するディスプレイのすべてを表現する。これは、TGrafCluster１３０２を有するが、これな全ディスプレイに対するレンダリング・オブジェクト(renderingo bject)である。 TGrafCluster１３０２は、デスクトップを形成するレンダリング・オブジェクトのすべての集合である。TGrafClusterは、全コンポーネント・グラフ(graf)・デバイスを通じて繰り返しを行うメンバ関数のほか、デスクトップ・ジオメトリを領域として取るメンバ関数が含まれる。TGrafDevice１３０４は、レンダリング・オブジェクトである。TGrafDevice１３０６は、各々それぞれのディスプレイに対するサブクラスを表現する。これらのサブクラスは、また、MScreenDevice 内でミックスされるが、これについては後述する。図１４は、各コンポーネント・グラフ・デバイスがTGrafDevice及びMScreenDe viceのサブクラスによってどのように表現されるかを説明するブーチ図である。 MScreenDevice１４０４は、TGrafDeviceにコンポジット(composit)、スプライト (sprite)、及びマルチタスクの同期機能を追加する。TDisplayDeviceHandle１４０６は、実際のディスプレイ・デバイスについて問い合わせを行う。ディスプレイサブクラス・オブジェクト１４０２は、ディスプレイを表現するサブクラスを含む。TGrafDevice１４００については前述した。ディスプレイのジオメトリは、まずMScreenDevice１４０４にそのディスプレイ・デバイス・ハンドルを尋ねることによって得ることができる。TDesktopDisplayは、また、ある条件が発生したときに通知を送ることができる。たとえば、ジオメトリが変化したときに、若しくは、ユーザがモニタの位置を再度決めたりしたときに、TDesktopDisplay は、通知を送ることができる。ハードウェア・ウィンドウ好適実施の形態は、ハードウェア・ウィンドウをサポートするが、これは、ポリモーフィック(polymorphic)なスクリーン・デバイス・オブジェクトを使用することにより、ウィンドウの割り当て、移動、大きさの変更をする。ウィンドウが、ソフトウェアあるいは、ハードウェアのいずれによって描画されても、ウィンドウ・サーバに対する問題はおきない。ウィンドウは、ハードウェア内にウィンドウ機能を実装するディスプレイ・デバイスを用意することもできる。ハードウェアは、ウィンドウの移動、ウィンドウに対する可視領域の計算、ウィンドウに対する更新領域の計算のときに、ウィンドウの再ペイントを高速化するためにしばしば使用される。内部ウィンドウ図１５は、クライアント・チーム１５００のウィンドウ、及び、ウィンドウ・サーバ１５０２のウィンドウを示すブロック図である。ウィンドウ・サーバは、内部的にウィンドウ・サーバ１５０２内のスクリーンの不動産(real-estate)の一片を表現するために、クラスＴInternalWindow１５０６を使用する。クライアント・チーム１５００、たとえば文書ウィンドウ・マネージャなどがTSystemWin do w１５０４を生成するときはいつでも、TInternalWindow１５０６がウィンドウの内部に生成される。図１６は、ハードウェア・ウィンドウを実装するためにサブクラス化されたTI nternalWindowを説明するブーチ図である。TInternalWindow１６００は、内部ウィンドウの抽象基本クラス(abstract base class)である。TXYZInternalWindow １６０２は、ハードウェア・ウィンドウ・サブクラスを表現する。図１６では、１６０２は、ＸＹＺ社があると仮定した場合のＸＹＺ社からの、ハードウェア・ウィンドウ・サブクラスを表現する。TFlatFrameBufferInternalWindow１６０４は、フラットなフレームバッファ(framebuffers)に適したウィンドウを表現する。 TInternalWindow１６０２は、以下の責任を有する。１）ウィンドウの、TGAreaとして表現された、エクステント（位置と大きさ）の管理。２）位置が変わったときのウィンドウの移動。ソフトウェア・ウィンドウに対しては、これは、可視ウィンドウの内容をコピービット(copybit)することを意味する。ハードウェア・スクロールを使用するハードウェア・ウィンドウに対しては、これはあるレジスタにウィンドウを移動すべき旨を書込むことを意味する。３）ウィンドウについて以下の情報を返すこと。 − 自分自身の可視領域が計算できるか？ソフトウェア・ウィンドウは通常はしないが、そのウィンドウはソフトウェア・ウィンドウのためにこれを行う。ハードウェア・ウィンドウによっては、できるものがある（これができるのは、ハードウェア・ウィンドウは全ソフトウェア・ウィンドウの頂上に制約されるからである）。もしそのウィンドウが自分の可視領域を計算できる場合は、そのウィンドウは計算する必要はない。 − 自分自身の損傷を受けた領域を計算できるか？ふたたび、そのウィンドウが自分自身でこれができない場合は、ウィンドウ・サーバが通常これを行う。４）可視領域と更新領域のセッタ(setter)とゲッタ(getter)を持つこと。ハードウェア・ウィンドウは、ハードウェアでこれらを計算している場合は、これらの領域を最新の状態に保つ必要がある。５）ウィンドウが位置を変えたときはいつでも、ウィンドウ・サーバがウィンドウにその内部ウィンドウのリストを前から後(front-to-back)の順に手渡す。ハードウェア・ウィンドウは、可視領域と更新領域を決定するためにこの情報を使用することができる。６）ウィンドウの非公開管理。これは、サブクラス部は詳細について心配する必要がないことを意味する。ハードウェア・ウィンドウ・デバイス・ドライバを書くときは、以上の責任を果たすため、TInternalWindowがサブクラス化されなければならない。デバイスがハードウェア・ウィンドウをサポートしておらず、フラットなフレーム・バッファのように見える場合は、TInternalWindow及びTSystemWindowはサブクラス化される必要はない。ストック(stock)されたクラスでうまく動作するだろう。図１７は、TSystemWindow１７００及びTInternalWindow１７０４をサブクラス化することによって、新しいメンバ関数をシステム・ウィンドウ・サブクラスに追加する様子を示すブーチ図である。図示したように、TSystemWindow１７００もまた、特別のメンバ関数を追加する必要がある場合には、TXYZSystemWindow１７０６によって示すように、サブクラス化することができる。一般的に、TSyste mWindow１７００がサブクラス化された場合は、次にTInternalWindow１７０４もまたサブクラス化されなければならないが、これは、実際に作業を行う非公開ハンドラ・メンバ関数(private handler member function)を追加するためである。TInternalWindowのサブクラス化は、TXYZInternalWindow１７０８によって示されている。ディスプレイ・デバイス図１８は、デスクトップを形成する各ディスプレイ・デバイスに対するものを示すブロック図であり、ウィンドウ・サーバ１８００の中で生きているTDisplay Device１８０２がある。ディスプレイ・デバイスはディスプレーの入出力アクセス・マネージャ１８０４と必要があるときに通信する。TDisplayDevice１８０３は、ウィンドウ・サーバ１８００の中に常駐している。ディスプレイ・デバイスは、内部ウィンドウの生成のほか、内部ウィンドウによって参照されるのに必要となり得るデバイス固有の情報の管理について責任がある。内部ウィンドウの生成図１９は、内部ウィンドウが生成される方法を図示するブロック図である。１）クライアント・チーム１９００がTSystemWindow１９０２をインスタンシエート(instantiate)する。２）TSystemWindow１９０２がウィンドウ・パラメータをTInternalWindowDesc ription１９０４内にパッケージ化して、これをウィンドウ・サーバ１９０６のディスパッチャ(dispatcher)１９０８に送る。TInternalWindowDescription１９０４はウィンドウの生成に必要な全パラメータ（前述の「システム・ウィンドウの生成と削除」において説明したパラメータ）を有し、ウィンドウの大きさと位置（TGAreaとして記述される）が含まれる。TSystemWindow１９０２及びTIntern alWindow１９１２がサブクラス化されて追加の構築(construction)パラメータを必要とする場合は、これをサブクラス化して新しいパラメータを追加することができる。３）ウィンドウは、どのディスプレイ・デバイスの上にウィンドウがあるかを計算(figure out)する。ウィンドウは、ディスプレイ・デバイスに、TInternalW indow１９１２を生成するようにTDisplayDevice１９１０経由で頼む。（ウィンドウが複数のモニタにスパンしている場合は、次節「モニタのスパン」で説明する）。４）ディスプレイ・デバイスは、TInternalWindow１９１２（フラットなフレームバッファである場合）又はサブクラス（ハードウェア・ウィンドウ若しくは他の追加機能をサポートする場合）のいずれかを生成する。モニタのスパン図２０は、ブロック・ダイアグラムによって、３つの異なるモニタにスパンするウィンドウを図示する。この例では、モニタＡ２０００は、単純なフレーム・バッファである。モニタＢ２００４は、ハードウェア・ウィンドウをサポートする。モニタＣ２００６は、モニタＢ２００４とは異なる種類のハードウェア・ウィンドウをサポートする。ウィンドウ２００２は、これらの３つのモニタをスパンしている。図２１は、ウィンドウが３つのモニタにスパンできるようにするために使用されるシステムを図示する。図２２は、モニタのスパンをサポートするのに必要なオブジェクトを図示するブーチ図である。ウィンドウは、TInternalWindowのサブクラス、TInternalWindowCluster（２２０２）を生成することによって、これを処理する。TInternalWindowCluster２２０２は、３つの他の内部ウィンドウ（２１０２、２１０４、２１０６）を「持つ」内部ウィンドウである。３つのコンポーネント内部ウィンドウは、ディスプレイ・デバイスによって生成されるが、これは前節で説明した通りである。ウィンドウ・クラスタ２１００が移動するよう指示を受けたとき、向きを変えて、そのコンポーネント内部ウィンドウに適切に移動してその大きさを変更するよう指示を出す。クラスタに対する他のウィンドウ要求のすべてについても同じことがいえる。クラスタはある種の解釈を行って要求をそのコンポーネントに引き渡す。インプリメンタ(implementor)は、内部ウィンドウ・クラスタを生成するときの選択をすることができる。必要なとき（たとえば、ウィンドウが異なる種類のモニタにスパンするとき）だけクラスタを生成することによって最適化を図ることもできるし、あるいは、一つのモニタのみにウィンドウが入っている場合であっても各ウィンドウに対してクラスタが生成されるという単純な解決方法を選択することもできる。上記の解決方法に対する単純な他の方法を考えることもできる。たとえば、ウィンドウが複数のモニタをスパンするときはいつでも、ストックされたソフトウェア・ウィンドウに戻るものなどである。これは、TInternalWindowの継承されたメンバ関数を呼び出すことによって可能となる。この解決方法は単純だが、ディスプレイ・デバイスが、そのスクリーン上にあるウィンドウのすべてを知ることができないという欠点がある。この情報は、可視範囲及び更新範囲の計算を高速化する際に役立てることができる。 TXYZInternalWindowをストックされたTFlatFrameBufferWindowに戻らせる簡単な方法は、TFlatFrameBufferWindowから継承して、戻らせることが必要なときはいつでも、継承されたメンバ関数を呼び出すことである。ハードウェア・デバイスは、固定数のハードウェア・ウィンドウだけしかサポートできないことがある。この場合、ハードウェア・ウィンドウの数が超過したときにストックされたソフトウェア・ウィンドウへ戻ることは、TInternalWindo wサブクラスの責任である。ハードウェア・ウィンドウの最大数が超過したとき計算するために、あるTInt ernalWindowサブクラスがそれに対応するTDisplayDeviceと通信する必要があるということを考える。TDisplayDeviceサブクラスは存在するハードウェア・ウィンドウの数を管理する。TInternalWindowは、この情報を得るためにディスプレイ・デバイスに問い合わせる。クライアントが、システム・ウィンドウを生成するときに、ハードウェア・ウィンドウを要求することができる。これをするには、TSystemWindowではなく直接TSystemWindowサブクラスをインスタンシエートすることによる。これは、特定のハードウェア・デバイス上でのみ動作することがわかっているアプリケーション、たとえば、ＩＢＭＡｃｔｉｏｎＭｅｄｉａＩＩＰｌａｙｂａｃｋカードを使用するアプリケーションなどに対しては、便利である。このカードは、ディジタル・ビデオを伸張(decompress)してオンボードのフレーム・バッファにディスプレイし、それ以外の場所にはディスプレイしない機能を持つ。ビュー(view)がディスプレイされているディスプレイ・デバイスの種類が何かを、ビューが知りたいときが何度かある。これによって、TViewサブクラスはハードウェアによって提供されるあるかわった(fancy)機能を利用できるようになる。TSystemWindowは、そのウィンドウが位置しているTDisplayDeviceHandleのすべてについてクライアントが繰り返しできるようにするためのイテレータ(ite rator)を返すメンバ関数がある。ビューのサブクラスは、この情報を使用してどのデバイスにそのビューがあり、それに従って動作しているか調べることができる。本発明は特定のシステム環境における好適実施の形態の観点から説明したが、以降の請求の範囲の精神と範囲内で、本発明を、変更して、他の異なるハードウェアやソフトウェア環境において実行することができることは、本技術分野の当業者であれば認識できるだろう。

【手続補正書】特許法第１８４条の８第１項【提出日】１９９６年９月３０日【補正内容】請求の範囲１．コンピュータ・システム上で使用する複数のウィンドウ・ディスプレイを割り当てかつ管理する装置であって、複数のアプリケーション・プログラム（６１０）が動作するシステム・アドレス空間（６０８）およびプログラム・アドレス空間（６００）を含むメモリと、ディスプレイ・デバイス（３２２）と、複数のクライアント・アプリケーション・プログラム（６１０）であって、そのそれぞれが親ウィンドウ・ディスプレイ内のディスプレイのためにグラフィック情報を作成するものと、ユーザ・ウィンドウ操作要求（３２０）を受信するデバイスと、システム・アドレス空間（６０８）内のシステム・ウィンドウ・サーバ（６０６、１５０２）であって、複数の親ウィンドウ・ディスプレイのそれぞれに対する可視領域の位置と大きさを定義する格納されたデータ（６０４）を維持し、かつ複数の親ウィンドウ・ディスプレイの該位置と大きさに基いて該格納されたデータを決定するものとを有する装置において、プログラム・アドレス空間内の文書ウィンドウ・マネージャ（１５００）は、可視領域データを得るためにシステム・ウィンドウ・サーバ（５１０、６０６、１５０２）と通信し、アプリケーション・プログラム（６１０）により作成されたグラフィック情報を受信し、該グラフィック情報を該可視領域にディスプレイするディスプレイ・デバイス（３２２）を直接制御することを特徴とする装置。２．請求項１に記載の装置において、前記文書ウィンドウ・マネージャ（１５００）は、更新マネージャ（１５０４）において、親ウィンドウ・ディスプレイの位置と大きさを変更するユーザ・ウィンドウ操作要求に、該親ウィンドウ・ディスプレイの新しい位置と大きさを決定することにより、かつ該新しい位置と大きさをシステム・ウィンドウ・サーバに通知することにより応答する更新マネージャ（１５０４）を備えたことを特徴とする装置。３．請求項２に記載の装置において、前記システム・ウィンドウ・サーバ（５１０）は、前記更新マネージャ（１５０４）からの通知（５０４）に、新しい位置と大きさに基づく前記可視領域のデータを再計算することにより応答する可視領域マネージャ（５０６）を備えたことを特徴とする装置。４．請求項１に記載の装置において、複数のアプリケーション・プログラム（６１０）のそれぞれは、対応するプログラム・アドレス空間内で動作し、メイン親ウィンドウ・ディスプレイを有し、文書ウィンドウ・マネージャ（１５００）を対応するプログラム・アドレス空間内に有し、文書ウィンドウ・マネージャ（１５００）が、該メイン親ウィンドウの前記可視領域内のグラフィック情報のディスプレイを直接制御することを特徴とする装置。５．請求項４に記載の装置において、複数の子ウィンドウ・ディスプレイを前記メイン親ウィンドウ・ディスプレイ内にさらに備え、対応するアドレス空間内の文書ウィンドウ・マネージャ（１５００）は、複数の子ウィンドウ・ディスプレイのそれぞれに対する可視領域の位置と大きさとを定義する格納された子ウィンドウ・データを管理し、該可視領域の位置と大きさを変更するユーザ・ウィンドウ操作要求に、該格納された子ウィンドウ・データを変更することにより応答することを特徴とする装置。６．請求項５に記載の装置において、コンピュータ・システムは、スクリーン・バッファ（４１２）及びディスプレイ・デバイス上のスクリーン・バッファの内容をレンダリングする機構（４１６）を含み、文書ウィンドウ・マネージャ（１５００）はグラフィック情報を該スクリーン・バッファ（４１２）の中に子ウィンドウ可視領域のそれぞれの中に書き込むための描画機構を対応するプログラム・アドレス空間内にさらに備えたことを特徴とする装置。７．請求項１に記載の装置において、可視領域内のグラフィック情報のディスプレイを制御するために文書ウィンドウ・マネージャ（１５０２）により使用される描画セマフォをさらに備えたことを特徴とする装置。８．請求項７に記載の装置において、前記システム・ウィンドウ・サーバ（５１０、６０６、１５０２）は、グラフィック情報が複数の親ウィンドウ・ディスプレイのいずれかの中にディスプレイされているか否かを決めるために前記描画セマフォを検査し、グラフィック情報がディスプレイされているときに格納されたメイン・ウィンドウ可視領域データに対するいかなる変更をも防止する機構を備えたことを特徴とする装置。９．請求項１に記載の装置において、前記文書ウィンドウ・マネージャ（５００）は、関連するウィンドウ・ディスプレイ用の可視領域の位置及び大きさを定義するデータのコピーを格納するキャッシュ・メモリをプログラム・アドレス空間内に含むことを特徴とする装置。１０．請求項９に記載の装置において、前記キャッシュ・メモリは、前記可視領域データの前記コピーが前記キャッシュ・メモリに格納された時を示すローカル・タイム・スタンプを含むことを特徴とする装置。１１．請求項１０に記載の装置において、前記システム・ウィンドウ・サーバ（５１０、６０６、１５０２）は、前記可視領域データがシステム・アドレス空間内に格納された時を示すシステム・タイム・スタンプを該システム・アドレス空間内に格納する機構を含むことを特徴とする装置。１２．請求項１１に記載の装置において、前記文書ウィンドウ・マネージャ（１５００）は、前記キャッシュ・メモリ内に格納された前記可視領域データがシステム・アドレス空間内に格納された可視領域データのコピーであるか否かを決定するために、ローカル・タイム・スタンプと前記システム・タイム・スタンプとを比較する機構を含むことを特徴とする装置。１３．コンピュータ・システム上で使用する複数のウィンドウ・ディスプレイを割り当てかつ管理する方法であって、複数のアプリケーション・プログラム（６１０）が動作するシステム・アドレス空間（６０８）およびプログラム・アドレス空間（６００）を含むメモリと、ディスプレイ・デバイス（３２２）と、複数のクライアント・アプリケーション・プログラム（６１０）であって、そのそれぞれが親ウィンドウ・ディスプレイ内のディスプレイのためにグラフィック情報を作成するものと、ユーザ・ウィンドウ操作要求（３２０）を受信するデバイスと、システム・アドレス空間（６０８）内のシステム・ウィンドウ・サーバ（６０６、１５０２）であって、複数の親ウィンドウ・ディスプレイのそれぞれに対する可視領域の位置と大きさを定義する格納されたデータ（６０４）を維持し、かつ複数の親ウィンドウ・ディスプレイの該位置と大きさに基いて該格納されたデータを決定するものとを有する方法において、（ａ）該可視領域データを得るためにシステム・ウィンドウ・サーバ（５１０、６０６、１５０２）と通信し、アプリケーション・プログラム（６１０）により作成された前記グラフィック情報を受信し、前記可視領域内の前記グラフィック情報をディスプレイするためにディスプレイ・デバイス（３２２）を直接制御する文書ウィンドウ・マネージャ（１５００）をプログラム・アドレス空間内に構築するステップを備えたことを特徴とする方法。１４．請求項１３に記載の方法において、ステップ（ａ）は、（ａ１）親ウィンドウ・ディスプレイの位置と大きさを変更するユーザ・ウィンドウ操作要求に、親ウィンドウ・ディスプレイの新しい位置と大きさを決定することにより、かつ該新しい位置と大きさをシステム・ウィンドウ・サーバに通知することにより応答する更新マネージャ（１５０４）を構築するステップを備えたことを特徴とする方法。１５．請求項１３に記載の方法において、複数のアプリケーション・プログラムのそれぞれは、対応するプログラム・アドレス空間内で動作し、メイン親ウィンドウ・ディスプレイを有し、かつステップ（ａ）は、（ａ２）文書ウィンドウ・マネージャ（１５００）を対応するプログラム・アドレス空間に構築するステップであって、ドキュメント・ウィンドウ・マネージャはメイン（１５００）親ウィンドウの可視領域内のグラフィック情報の前記作成を管理するステップを備えたことを特徴とする方法。１６．請求項１５に記載の方法において、複数の子ウィンドウ・ディスプレイをメイン親ウィンドウ・ディスプレイ内にさらに備え、かつステップ（ａ）は、（ａ３）該複数の子ウィンドウ・ディスプレイのそれぞれに対する可視領域の位置と大きさを定義する格納された子ウィンドウ・データを管理するステップと、（ａ４）前記可視領域の前記位置と大きさを変更するユーザ・ウィンドウ操作要求に、前記格納された子ウィンドウ・データを変更することにより応答するステップとを備えたことを特徴とする方法。１７．請求項１６に記載の方法において、コンピュータ・システムは、スクリーン・バッファ（４１２）及びディスプレイ・デバイス上のスクリーン・バッファの内容をレンダリングするための機構（４１６）とを含み、該方法は、（ｂ）該スクリーン・バッファ（４１２）の中に子ウィンドウ可視領域のそれぞれの中にグラフィック情報を書き込むために、描画機構を対応するプログラム・アドレス空間内に生成するステップをさらに備えたことを特徴とする方法。１８．請求項１３に記載の方法において、（ｃ）前記可視領域内のグラフィック情報の作成を制御するために前記文書ウィンドウ・マネージャ（１５００）内に描画セマフォを使用するステップをさらに備えたことを特徴とする方法。１９．請求項１８に記載の方法において、（ｄ）システム・ウィンドウ・サーバ（５１０、６０６、１５０２）に、複数の親ウィンドウ・ディスプレイのいずれかの中にグラフィック情報を生成しているか否かを決定するために前記描画セマフォを検査させ、グラフィック情報が作成されているときに前記格納されたメイン・ウィンドウ可視領域データに対するいかなる変更をも防止させるステップをさらに備えたことを特徴とする方法。２０．請求項１３に記載の方法において、（ｅ）関連するウィンドウ・ディスプレイに対する可視領域の位置と場所を定義するデータのコピーを前記プログラム・アドレス空間内のキャッシュ・メモリ内に格納するステップをさらに備えたことを特徴とする方法。２１．請求項２０に記載の方法において、ステップ（ｅ）は、（ｅ１）前記可視領域データの前記コピーが前記キャッシュ・メモリ内に格納された時を示すローカル・タイム・スタンプを使用するステップを備えたことを特徴とする方法。２２．請求項２１に記載の方法において、（ｆ）前記可視領域データが前記システム・アドレス空間内に格納された時を示すシステム・タイム・スタンプを前記システム・アドレス空間に格納するステップをさらに備えたことを特徴とする方法。２３．請求項２２に記載の方法において、（ｇ）前記キャッシュ・メモリ内に格納された前記可視領域データが前記システム・アドレス空間内に格納された前記可視領域データのコピーであるか否かを決定するために、前記ローカル・タイム・スタンプと前記システム・タイム・スタンプとを比較するステップをさらに備えたことを特徴とする方法。

───────────────────────────────────────────────────── フロントページの続き (72)発明者マーシュ，ドナルド，エム. アメリカ合衆国 94043 カリフォルニア州マウンテンビューデルアヴェニュ 476 (72)発明者ミルン，スティーヴ，エイチ. アメリカ合衆国 94301 カリフォルニア州パロアルトウェブスターストリート 137 (72)発明者ジアス，ジェフ，エイ. アメリカ合衆国 95070 カリフォルニア州サラトガビューリッジドライブ 19823

Claims

【特許請求の範囲】１．デスクトップ・バックグランド上にディスプレイされた複数のウィンドウ領域を有するディスプレイを作成するディスプレイ・デバイスを制御するためのコンピュータ・システムであって、該複数のウィンドウ領域のそれぞれは複数のクライアントの１つにより作成されたスクリーン情報をディスプレイするコンピュータ・システムにおいて、該コンピュータ・システムは、ウィンドウ・オブジェクトの生成を要求する１つ以上のクライアントと、１つ以上の領域内のディスプレイ上に前記クライアントに関連した情報をディスプレイするディスプレイ・デバイスと、少なくとも１つのパラメータを前記１つ以上のクライアントから受信したことに応答してウィンドウ・オブジェクトを生成し、前記少なくとも１つのパラメータによって指定されている場合、種類にしたがってウィンドウ領域を順序づけるウィンドウ・サーバとを備えたことを特徴とするコンピュータ・システム。２．請求項１に記載のコンピュータ・システムにおいて、前記少なくとも１つのパラメータはウィンドウ・パラメータのエクステントを備えたことを特徴とするコンピュータ・システム。３．請求項１に記載のコンピュータ・システムにおいて、前記少なくとも１つのパラメータはイベント・レシーバＩＤを備えたことを特徴とするコンピュータ・システム。４．請求項１に記載のコンピュータ・システムにおいて、前記少なくとも１つのパラメータは前から後への順序指示部を備えたことを特徴とするコンピュータ・システム。５．請求項１に記載のコンピュータ・システムにおいて、前記少なくとも１つのパラメータは初期可視性指示部を備えたことを特徴とするコンピュータ・システム。６．請求項１に記載のコンピュータ・システムにおいて、前記少なくとも１つのパラメータは自動消去指示部を備えたことを特徴とするコンピュータ・システム。７．請求項１に記載のコンピュータ・システムにおいて、前記少なくとも１つのパラメータはウィンドウ層のインデックスを備えたことを特徴とするコンピュータ・システム。８．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは、１つ以上のクライアントにクライアントのウィンドウ・オブジェクトに関するイベントを通知する手段を備えたことを特徴とするコンピュータ・システム。９．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは、各ウィンドウの更新領域を維持する手段と、前記クライアントの更新ウィンドウが空でなくなったときにクライアントに通知する手段とを備えたことを特徴とするコンピュータ・システム。１０．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバはハードウェア・ウィンドウ・サポートを前記ウィンドウ・サーバの拡張として含むことを特徴とするコンピュータ・システム。１１．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバはグラフィックス機能を前記ウィンドウ・サーバの拡張として含むことを特徴とするコンピュータ・システム。１２．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは構成プログラムにより変更可能なデスクトップ・ディスプレイ情報を備えたことを特徴とするコンピュータ・システム。１３．請求項１２に記載のコンピュータ・システムにおいて、前記デスクトップ・ディスプレイ情報はビット深さ情報を含むことを特徴とするコンピュータ・システム。１４．請求項１２に記載のコンピュータ・システムにおいて、前記デスクトップ・ディスプレイ情報はモニタ情報を含むことを特徴とするコンピュータ・システム。１５．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは、構成プログラムにより問い合わせに応答して得られたデスクトップ・ディスプレイ情報を備えたことを特徴とするコンピュータ・システム。１６．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは代理ウィンドウ・オブジェクトを生成する手段を備えたことを特徴とするコンピュータ・システム。１７．請求項１に記載のコンピュータ・システムにおいて、再構成のための要求を作成する構成プログラムと、再構成のための前記要求を管理するために前記要求を中断するディスプレイ・デバイス・フレームワークとを備えたことを特徴とするコンピュータ・システム。１８．請求項１に記載のコンピュータ・システムにおいて、デスクトップを形成する全ディスプレイを表現するデスクトップ・ディスプレイ・オブジェクトを備えたことを特徴とするコンピュータ・システム。１９．請求項１８に記載のコンピュータ・システムにおいて、前記デスクトップ・ディスプレイ・オブジェクトは全ディスプレイのためのレンダリング・オブジェクトを有することを特徴とするコンピュータ・システム。２０．請求項１に記載のコンピュータ・システムにおいて、ハードウェア・ウィンドウを実装するためのオブジェクトを備えたことを特徴とするコンピュータ・システム。２１．請求項２０に記載のコンピュータ・システムにおいて、ハードウェア・ウィンドウを実装するための前記オブジェクトはポリモーフィック・スクリーン・デバイス・オブジェクトであることを特徴とするコンピュータ・システム。２２．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは、どのディスプレイ・デバイス上にウィンドウが生成されるかを調べる手段を備えたことを特徴とするコンピュータ・システム。２３．請求項１に記載のコンピュータ・システムにおいて、前記ウィンドウ・サーバは、モニタをスパンするウィンドウ・クラスタ・オブジェクトを実装する手段を備えたことを特徴とするコンピュータ・システム。２４．デスクトップ・バックグランド上にディスプレイされた複数のウィンドウ領域を有するディスプレイを作成するためにディスプレイ・デバイスを制御するコンピュータ・システムにおけるコンピュータによる実装方法であって、該複数のウィンドウ領域のそれぞれは複数のクライアントの１つにより作成されたスクリーン情報をディスプレイするコンピュータによる実装方法において、該コンピュータによる実装方法は、システム・レベル・ウィンドウ・サーバにより、少なくとも１つのパラメータをクライアントから受信するステップと、前記クライアントからの前記少なくとも１つのパラメータを受信することに応答してウィンドウ・オブジェクトを生成するステップと、前記少なくとも１つのパラメータにより指定されたウィンドウ層にしたがって前記ウィンドウ領域を順序づけるステップとを備えたことを特徴とするコンピュータによる実装方法。２５．請求項２４に記載のコンピュータによる実装方法において、ウィンドウの１つ又は複数の特定のパラメータは前記少なくとも１つのパラメータにより指定されているか否かを決定するステップと、１つ又は複数の特定のパラメータが指定されていないと決定された場合はデフォルトにしたがってウィンドウの位置を決めるステップと、１つ又は複数の特定のパラメータが指定されている決定された場合は指定された位置にしたがってウィンドウの位置を決めるステップとを含むことを特徴とするコンピュータによる実装方法。２６．請求項２４に記載のコンピュータによる実装方法において、ウィンドウの１つ又は複数の特定のパラメータが前記少なくとも１つのパラメータにより指定されているか否かを決定するステップと、１つ又は複数の特定のパラメータが指定されていないと決定された場合はすでに存在するウィンドウの層を用いるステップとを含むことを特徴とするコンピュータによる実装方法。２７．請求項２４に記載のコンピュータによる実装方法において、前記ウィンドウ・サーバにより管理されているウィンドウの特徴に関する情報をクライアントにおいて受信するステップを含むことを特徴とするコンピュータによる実装方法。２８．請求項２４に記載のコンピュータによる実装方法において、ウィンドウ属性の変更を要求するクライアントに応答してウィンドウ属性を変更するステップを含むことを特徴とするコンピュータによる実装方法。２９．請求項２４に記載のコンピュータによる実装方法において、代理ウィンドウ・オブジェクトを生成するステップを含むことを特徴とするコンピュータによる実装方法。３０．請求項２４に記載のコンピュータによる実装方法において、デバイス・マネージャに対する再構成の要求作成するステップと、前記要求された再構成を管理するために前記要求を中断するステップとを含むことを特徴とするコンピュータによる実装方法。３１．請求項２４に記載のコンピュータによる実装方法において、ハードウェア・ウィンドウをサポートするオブジェクトを生成するステップを含むことを特徴とするコンピュータによる実装方法。３２．請求項３１に記載のコンピュータによる実装方法において、ハードウェア・ウィンドウをサポートするオブジェクトを生成する前記ステップは該オブジェクトに対するポリモーフィックな特徴を提供するステップを含むことを特徴とするコンピュータによる実装方法。３３．請求項２４に記載のコンピュータによる実装方法において、どのディスプレイ・デバイス上にウィンドウが生成されているのかを決定するステップを含むことを特徴とするコンピュータによる実装方法。３４．請求項２４に記載のコンピュータによる実装方法において、モニタをスパンするクラスタ・オブジェクトを生成するステップを含むことを特徴とするコンピュータによる実装方法。