JPH09504884A

JPH09504884A - オブジェクト指向ディスプレイ・システム

Info

Publication number: JPH09504884A
Application number: JP7512578A
Authority: JP
Inventors: ローゼンシュタイン，ラリー，エス．
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1993-10-25
Filing date: 1994-01-06
Publication date: 1997-05-13
Anticipated expiration: 2019-07-21
Also published as: EP0710388B1; AU6020894A; US6750858B1; DE69409812D1; EP0710388A1; WO1995012194A1; JP3544666B2; US5522025A

Abstract

(57)【要約】オブジェクト指向ウィンドウ・マネージャは別々のアプリケーション・プログラムによって生成されたウィンドウ表示間を調整する機能を提供し、表示されたウィンドウが変更されるたびに各アプリケーション・ウィンドウの可視エリアを計算し、ストアすることによってこの調整を行っている。各アプリケーション・プログラムはスクリーン・バッファ・メモリと直接にやりとりすることにより、その表示エリアに対応するスクリーン部分を、ウィンドウ・マネージャによって計算された可視エリアを使用して再ドローイング（再描画）する。また、各アプリケーション・プログラムは、アプリケーション・プログラムからは見えない柔軟性のある表示機能を備えたウィンドウ・オブジェクトを作成することによってオブジェクト指向ウィンドウ・マネージャとやりとりする。可視エリアの計算時間を削減するためにいくつかの手法が用いられている。第一に、上述したように、可視エリアのコピーは各ウィンドウ・オブジェクトにストアまたは「キャッシュ」される。このコピーは、もしアプリケーション・プログラムがウィンドウ・エリアを再ドローイングする必要が起こった場合、およびその可視エリアが変更されていなかったときに使用することができる。さらに、ウィンドウ・マネージャは、単一のウィンドウだけが変更されたことを想定するルーチンを使用して各アプリケーション・ウィンドウの新しい可視エリアを計算し、ウィンドウの新可視エリアを旧可視エリアと比較して変更エリアを得ている。この変更エリアは、変更されたウィンドウの背後にあるすべてのウィンドウの可視エリアを再計算するときに使用される。

Description

【発明の詳細な説明】オブジェクト指向ディスプレイ・システム著作権表記本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁に記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではない。発明の分野本発明はコンピュータ・システムにおける改良に関し、具体的には、グラフィック・ユーザ・インタフェースにおいてウィンドウ・ディスプレイ・エリアを管理するためのオペレーティング・システム・ソフトウェアに関する。発明の背景現代のコンピューティング・システムの最も重要な側面の１つは、人間のユーザとマシンとの間のインタフェースである。初期の最もポピュラーなタイプのインタフェースはテキストをベースとしていた。つまり、ユーザはテキスト文字をキーボードからタイプすることでマシンと通信し、マシンはテキスト文字をディスプレイ・スクリーン上に表示することでユーザと通信していた。最近では、グラフィック・ユーザ・インタフェース(graphic user interface)がポピュラーになっているが、そこではマシンはテキストとピクチャを含むグラフィックスをディスプレイ・スクリーン上に表示することによってユーザと通信し、ユーザはテキスト・コマンドをタイプするだけではなく、表示されたピクチャをマウスなどのポインティング・デバイスで操作することによってマシンと通信している。最新コンピュータ・システムの多くは、ウィンドウ環境と呼ばれるグラフィック・ユーザ・インタフェースを使用して動作している。代表的なウィンドウ環境では、ディスプレイ・スクリーン上で縦長に表示されるグラフィカル・ディスプレイが電子的「デスクトップ」の表面と同じように配置され、コンピュータ上で実行される各アプリケーション・プログラムは、１つ以上の電子的「ペーパ・シート」で表され、これらシートは「ウィンドウ」と呼ばれるスクリーンの長方形領域に表示される。各ウィンドウ領域には、関連のアプリケーション・プログラムによって生成された情報が表示されるのが一般的であり、複数のウィンドウ領域が同時にデスクトップ上に存在することもあり、その場合は、各ウィンドウ領域は異なるアプリケーション・プログラムによって生成された情報を表している。アプリケーション・プログラムは、イメージ、グラフィックスまたはテキストをウィンドウ領域内でドロー（描画）または「ペイント」することによって、情報を各ウィンドウを通してユーザに提示している。ユーザの方は、ウィンドウ領域内のオブジェクトを、ポインティング・デバイスで制御されるカーソルで「ポイント」（指すこと）して、オブジェクトを操作または移動することにより、さらに、情報をキーボードからタイプインすることによりアプリケーションと通信している。ウィンドウ領域はディスプレイ・スクリーン上で各所に動かしたり、サイズや外観を変更したできるので、ユーザはデスクトップを都合のよいように配置することが可能になっている。ウィンドウ領域の各々は、サイジング・ボックス(sizing box)、ボタン、スクロール・バーなどの、いくつかの標準グラフィカル・オブジェクトを含んでいるのが代表的である。これらは、ユーザがカーソルでポイントして選択し、操作できるというユーザ・インタフェース・デバイスの特徴を表している。これらのデバイスが選択され、操作されると、ウィンドウ・システムを通してその基となるアプリケーション・プログラムに対して、ユーザの操作による制御が行われたことが、通知される。一般的に、上述したウィンドウ環境はコンピュータのオペレーティング・システムの一部になっている。オペレーティング・システムはユーティリティ・プログラム群も含んでいるのが代表的である。ユーティリティ・プログラムは、コンピュータ・システムが基本的操作を実行することを可能にするものである。基本的操作としては、情報をディスク・メモリにストアし、そこから情報を取り出すこと、ファイルの作成、命名、改名といったファイル操作を実行すること、場合によっては、誤動作の検出や回復のための診断操作を実行すること、などの操作がある。コンピュータ・システムの最後の部分は「アプリケーション・プログラム」であり、これはオペレーティング・システムとやりとりすることによって、さらにハイレベルの機能を実現し、特定のタスクを実行し、ユーザとの直接的インタフェースを提供する。アプリケーション・プログラムは、一連のタスク・コマンドをオペレーティング・システムに渡し、これを受けてオペレーティング・システムが要求タスクを実行することにより、オペレーティング・システムの機能を利用するのが代表的である。例えば、オペレーティング・システムが特定の情報をコンピュータのディスク・メモリにストアすること、あるいはビデオ・ディスプレイから情報を表示することをアプリケーション・プログラムが要求することができる。図１は、アプリケーション・プログラムとオペレーティング・システムの双方を利用する、代表的な従来のコンピュータ・システムを示す概略図である。コンピュータ・システムは点線の枠１００で示され、アプリケーション・プログラムは枠１０２で示され、オペレーティング・システムは枠１０６で示されている。アプリケーション・プログラム１０２とオペレーティング・システムとの前述したやりとりは、矢印１０４で図示されている。このデュアル・プログラム・システムは、メインフレームからパーソナル・コンピュータに至るまでの、多種類のコンピュータ・システムで使用されている。スクリーン・ディスプレイの扱い方はコンピュータによって異なり、この点に関して、図１は従来のパーソナル・コンピュータ・システムを示している。スクリーン・ディスプレイを提供するためには、アプリケーション・プログラムは表示すべき情報をスクリーン・バッファ１１０にストアしておくのが一般的である（このストア操作は矢印１０８で図示されている）。システム内の種々のハードウェアとソフトウェアの制御の下で、スクリーン・バッファ１１０の内容はバッファから読み出され、矢印１１４で図示するように、ディスプレイ・アダプタ１１２に渡される。ディスプレイ・アダプタ１１２はハードウェアとソフトウェア（ファームウェアの形になっていることもある）を内蔵しており、スクリーン・バッファ１１０に入っている情報を、ケーブル１１６でディスプレイ・アダプタ１１２に接続されたディスプレイ・モニタ１１８をドライブするために使用できる形体に変換する。図１に示す従来の構成は、どの時点においても単一のアプリケーション・プログラム１０２を動かすシステムで好適に作動する。この単純なシステムが正しく作動するのは、上記単一のアプリケーション・プログラム１０２がスクリーン・バッファ領域１１０全体のいずれかの領域に情報を書き込んでも、表示の問題が起こらないためである。しかし、図１に示す構成を、２つ以上のアプリケーション・プログラム１０２を同時に動作状態にできるようなシステム（例えば、「マルチタスキング」コンピュータ・システム）で使用すると、表示の問題が発生するおそれがある。具体的には、各アプリケーション・プログラムがスクリーン・バッファ１１０全体に対してアクセスできるとき、アプリケーション同士がなんらかの方法で直接に連絡し合っていないと、あるアプリケーションは別のアプリケーションが使用しているスクリーン・バッファ部分をオーバライト（重書き）するおそれがあるので、一方のアプリケーションによって生成された表示が他方のアプリケーションによって生成された表示でオーバライトされることになる。そのために、複数のアプリケーション・プログラムのオペレーションを調整するためのメカニズムが開発され、各アプリケーション・プログラムをスクリーン・バッファの一部だけに限定し、それにより、他のディスプレイから切り離すようにしている。この調整は、複数のウィンドウがスクリーン・ディスプレイ上で「オーバラップ」することを許容しているシステムでは複雑化する。ウィンドウが「オーバラップ」して現れるようにスクリーン・ディスプレイが構成されているときは、スクリーン上で別のウィンドウの「手前」に現れるウィンドウはその下のウィンドウの一部に被さって隠すことになる。従って、最も手前のウィンドウを除き、その下のウィンドウは、一部だけがスクリーン上に描画されるので、どの時点でも「可視である」のはその部分だけになる。さらに、ウィンドウはユーザが動かしたり、サイズを変えたりできるので、各ウィンドウで可視な部分は、他のウィンドウを動かしたり、サイズを変えたりすると、変化することになる。そのために、各アプリケーション・プログラムに割り当てられたスクリーン・バッファ部分も、他のアプリケーションからのウィンドウを動かしたり、サイズを変えたりすると変化することになる。ウィンドウを動かしたり、サイズを変えたりすると起こる、迅速なスクリーン変化に対処するために必要なスクリーン・バッファの変更を効率的に管理するために、図１に示す従来のコンピュータ構成は図２に示すように改良されている。この新しい構成では、コンピュータ・システム２００はコンピュータ・システムで同時に実行されている、１つ以上のアプリケーション・プログラムによって制御されている。なお、図には、プログラム２０２と２１６が示されており、コンピュータシステムにおいて同時に移動する。プログラムの各々は、矢印２０６と２２０で図示するように、オペレーティング・システム２０４と接続されている。しかし、ディスプレイ・スクリーン上で情報を表示するために、アプリケーション・プログラム２０２と２１６は、オペレーティング・システム２０４内に置かれている中央ウィンドウ管理プログラム２１８に表示情報を送っている。ウィンドウ管理プログラム２１８の方は、矢印２０８で図示するようにスクリーン・バッファ２１０と直接的に接続されている。スクリーン・バッファ２１０の内容は、矢印２１２で示すように、ケーブル２２２でディスプレイ・モニタ２２４に接続されたディスプレイ・アダプタ２１４に渡される。このようなシステムでは、ウィンドウ・マネージャ２１８は、ウィンドウ表示の全てのメンテナンス、すなわち、アプリケーション・プログラムの動作時にユーザが見るウィンドウ表示についての全てをメンテナンス（管理）することを受け持つのが一般である。ウィンドウ・マネージャ２１８は、すべてのアプリケーション・プログラムと連絡をとっているので、ウィンドウ表示がオーバラップしないようにアプリケーション間の調整を行うことができる。従って、ウィンドウの位置とサイズを記録しておくと共に、ドロー（描画）し、ウィンドウの移動時に再ドローしなければならないウィンドウ・エリアを記録しておくのはウィンドウ・マネージャの仕事である。ウィンドウ・マネージャ２１８はアプリケーション２０２と２１６の各々から表示要求を受け取る。しかし、ウィンドウ・マネージャ２１８だけがスクリーン・バッファ２１０と接続するので、ウィンドウ・マネージャはスクリーン・バッファ２１０のそれぞれのエリアを各アプリケーション用に割り振ることができ、別のアプリケーションよって生成された表示を誤って各アプリケーションがオーバライトすることがないようにする。図２に示す構成を利用するウィンドウ環境は、数種類の異なるものが市販されている。そのようものとして、Ｘ／Ｗｉｎｄｏｗオペレーティング環境、マイクロソフト社によって開発されたＷＩＮＤＯＷＳグラフィカル・ユーザ・インタフェース、およびインターナショナル・ビジネス・マシンズ（ＩＢＭ）社によって開発されたＯＳ／２プレゼンテーション・マネージャがある。これらのウィンドウ環境の各々は独自の内部ソフトウェア・アーキテクチャをもっているが、これらのアークテクチャはいずれも、コンピュータ・ネットワーク・ソフトウェアを記述するために使用される多層（マルチレイヤ）モデルに類似した多層モデルを使用することにより分類することができる。代表的な多層モデルは次のような層（レイヤ）を含んでいる。ユーザ・インタフェースウィンドウ・マネージャ資源管理と通信コンポーネント・ドライバ・ソフトウェアコンピュータ・ハードウェアただし、「ウィンドウ環境」という用語は上記の層のすべてを一体化したものを指している。最下位の、つまり、コンピュータ・ハードウェア・レベルには、ディスプレイ・モニタ、キーボード、ポインティング・デバイス（マウスやトラックボールなど）を含む基本的コンピュータおよび関連入出力デバイス、ならびにその他の標準コンポーネント（プリンタやディスク・ドライブなど）が含まれている。次のレベルの「コンポーネント・ドライバ・ソフトウェア」は、デバイス依存ソフトウェアからなり、これは、種々のハードウェア・コンポーネントの動作に必要なコマンドおよび信号を生成する。資源管理と通信層はコンポーネント・ドライバと接続し、ソフトウェア・ルーチン、すなわち、資源を割り振り、アプリケーション相互間で通信し、上位層によって生成された通信内容を下位層に多重通信するソフトウェア・ルーチンを含んでいる。ウィンドウ・マネージャは基本的ウィンドウ操作に対するユーザ・インタフェースを取り扱う。このような基本的ウィンドウ操作としては、ウィンドウの移動およびサイズ変更、ウィンドウの起動と終了、ウィンドウの再ドローと再ペイントなどがある。最後のユーザ・インタフェース層は、ハイレベル機能、すなわち、アプリケーション・プログラムが完全なユーザ・インタフェースを開発するために使用する種々のコントロール（ボタン、スライダ、ボックス、その他のコントロール）を実現するハイレベル機能を提供する。図２に示す構成はディスプレイ・スクリーン干渉問題を解決しているが、この構成には、アプリケーション・プログラムの全てによって生成されたスクリーン・ディスプレイ要求をウィンドウ・マネージャ２１８に処理させなければならないという欠点がある。これらの要求は直列的にしか処理できないので、要求はウィンドウ・マネージャへ渡すための待ち行列(queu)に置かれてから、各要求は処理され、端末２２４上の表示を生成する。多数のウィンドウがスクリーン上に同時に存在するような表示では、ウィンドウ・マネージャ２１８は表示情報の「ボトルネック」になりやすいので、アプリケーション・プログラム２０２と２１６による迅速な表示の変更の妨げになる。ウィンドウがユーザによって移動または再位置付けされたときに起こる、スクリーン再ドローの遅延は、ウィンドウが外見上断片的に作られていると、煩わしくなり、システムのオペレーションからかけ離れることになるので、顕在化することがよくある。以上に鑑みて、本発明の目的は、アプリケーション・プログラムと接続し、各アプリケーション・プログラムによって生成されたスクリーン表示を高速にかつ効率的に再ドローできるようにするウィンドウ・マネージャを提供することにある。本発明の別の目的は、アプケーション・プログラムの全ての表示の生成を調整して、アプリケーション・プログラムが相互に干渉し合ったり、スクリーンの表示上で相互にオーバライトするのを防止するウィンドウ・マネージャを提供することにある。さらに、本発明の別の目的は、アプリケーション・プログラムが実際のインプリメンテーション詳細にとらわれることなく、単純なコマンド構造によってアプリケーション・プログラムとの対話することができるウィンドウ・マネージャを提供することである。さらに、本発明の別の目的は、スクリーン表示プロセスに対する詳細な制御を必要とするアプリケーション・プログラム開発者が、フルセットの表示制御コマンドであって、各アプリケーション・プログラムが使用しなくてもよい表示制御コマンドによって、上記制御を達成できるようにするウィンドウ・マネージャを提供することにある。発明の概要上述した問題を解消し、上述した目的を達成するために、本発明の図示の実施例によれば、オブジェクト指向のウィンドウ・マネージャは、表示されているウィンドウが変更されるたびに、各アプリケーション・ウィンドウの可視エリア(v isible area)を計算し、ストアすることにより、別々のアプリケーション・プログラム間の調整を行う機能を備えている。各アプリケーションはスクリーン・バッファ・メモリと直接にやりとりすることにより、ウィンドウ・マネージャによって計算された可視エリアを使用してそのディスプレイ・エリアに対応するスクリーン部分を再ドローする。各アプリケーション・プログラムは、柔軟性に富んだ表示機能を備えたウィンドウ・オブジェクトを作成することによりオブジェクト指向ウィンドウ・マネージャと通信するが、表示機能はアプリケーション・プログラムからは見えないようになっている。ウィンドウ・オブジェクトは、ウィンドウ・マネージャと直接的に接続するためのコマンドと、ウィンドウ・マネージャによって計算された関連の可視エリアを一時的にストアしておくデータ・エリアとを含んでいる。可視エリアの計算時間を削減する手法のいくつかが使用される。第一は、上述したように、可視エリアのコピーを各ウィンドウ・オブジェクトにストアまたは「キャッシュ」する方法である。このコピーは、アプリケーション・プログラムがウィンドウ・エリアを再ドローする必要があって、可視エリアが変更されていなかったとき使用することができる。さらに、ウィンドウ・マネージャは、可視エリアの計算を高速化する２つのルーチンのうちの一方を用いて、各アプリケーション・ウィンドウの可視エリアを計算する。そのルーチンの一方は単一のウィンドウだけが変更されたことを想定して、ウィンドウの新しい可視エリアを元の可視エリアと比較して変更エリアを求める。この変更エリアは変更ウィンドウの背後にあるすべてのウィンドウの可視エリアを再計算するために使用される。他方の再計算ルーチンは可視エリアのすべてを再計算するもので、ウィンドウが例えば除去されたとき使用できる。図面の簡単な説明本発明の上記およびその他の利点をよりよく理解するために、以下、添付図面を参照して説明する。添付図面において、図１は従来のコンピュータ・システムを示す概要ブロック図であり、アプリケーション・プログラム、オペレーティング・システム、スクリーン・バッファおよびディスプレイ・モニタ間の関係を示している。図２は図１に示す従来のシステムの改良型を示す概略ブロック図であり、同時に実行されている複数のアプリケーション・プログラムがスクリーン表示を生成することを可能にしている。図３はコンピュータ・システム、例えば、本発明によるオブジェクト指向ウィンドウ・マネージャが稼働しているパーソナル・コンピュータ・システムを示す概略ブロック図である。図４は改良型コンピュータ・システムを示す概略ブロック図であり、複数のアプリケーション・プログラムとウィンドウ・マネージャとがスクリーン・バッファでやりとりして、グラフィック情報をディスプレイ・モニタから表示することを示している。図５は情報経路を示す概略ブロック図であり、アプリケーション・プログラムが本発明によるオブジェクト指向ウィンドウ・マネージャとどのようにやりとりするかを示している。図６は、ウィンドウ指向のディスプレイをサポートするグラフィカル・ユーザ・インタフェースの代表的な外観を示す概略図であり、ウィンドウのコンポーネントと部分を示している。図７Ａおよび図７Ｂは、アプリケーション・ウィンドウのサイズが変更されたとき再ドローする必要のあるディスプレイ・スクリーン部分を示す図である。図８は、アプリケーション・プログラムがオブジェクト指向ウィンドウ・マネージャとやりとりして、情報をディスプレイ・スクリーン上で表示するときのメソッドのフローチャートを示す図である。図９は、新しいウィンドウを作成するときアプリケーション・プログラムによって使用されるメソッドのフローチャートを示す図である。図１０は、既存のウィンドウをディスプレイから削除するとき使用されるメソッドのフローチャートを示す図である。図１１は、アプリケーション・プログラムが可視エリア情報をオブジェクト指向ウィンドウ・マネージャに要求するときのメソッドのフローチャートを示す図である。図１２は、ウィンドウ・オブジェクトがウィンドウ・マネージャとやりとりすることにより新しいウィンドウを作成するときのメソッドのフローチャートを示す図である。図１３は、ウィンドウ・オブジェクトがウィンドウ・マネージャとやりとりすることによりウィンドウを削除するときのメソッドのフローチャートを示す図である。図１４は可視エリア・マネージャとウィンドウ・マネージャが、選択したウィンドウを他のウィンドウの手前に置くようにウィンドウ・ディスプレイを並べ換えるときのメソッドのフローチャートを示す図である。図１５は、新しいウィンドウがウィンドウ・マネージャに置かれた可視エリア・マネージャによってアクチベートされるときのメソッドのフローチャートを示す図である。図１６は、新しいウィンドウの配列またはサイズが変更されたとき可視エリア・マネージャが新しい可視エリアを計算するときのメソッドのフローチャートを示す図である。図１７は、１つのウィンドウだけが変更されている、ウィンドウの新しい可視エリアを計算するために可視エリア・マネージャによって使用されるメソッドのフローチャートを示す図である。発明の好適実施例の詳細な説明本発明は、好ましくは、ＩＢＭ社ＰＳ／２またはアップル社マッキントッシュ・コンピュータなどのパーソナル・コンピュータに内蔵されているオペレーティング・システムを背景に実施される。図３は代表的なハードウェア環境を示しもので、本発明によるコンピュータ３００の代表的なハードウェア構成を示していてる。このコンピュータ３００は中央処理ユニット３０２（これは従来のマイクロプロセッサにすることが可能である）によって制御され、すべてがシステム・バス３０８を介して相互接続されている複数の他のユニットは特定のタスクを遂行するためのものである。特定のコンピュータは図３に示すユニットの一部だけを装備している場合もあれば、図示していない別のコンポーネントを装備している場合もあるが、大部分のコンピュータは少なくとも図示のユニットを装備している。具体的には、図３に示すコンピュータ３００は、情報を一時的にストアしておくためのランダム・アクセス・メモリ（ＲＡＭ）３０６、コンピュータの構成と基本的操作コマンドを永続的にストアしておくためのリードオンリ・メモリ（ＲＯＭ）３０４、およびディスク・ユニット３１３やプリンタ３１４などの周辺デバイスをそれぞれケーブル３１５，３１２を介してバス３０８に接続するための入出力（Ｉ／Ｏ）アダプタ１１２を装備している。また、ユーザ・インタフェース・アダプタ３１６は、キーボード３２０などの入力デバイスおよびマウス、スピーカ、マイクロホンなどの他の公知インタフェース・デバイスをバス３０８に接続するためのものである。ビジュアル出力は、バス３０８をビデオ・モニタなどのディスプレイ・デバイス３２２に接続するディスプレイ・アダプタ３１８から得られる。ワークステーションは、そこに常駐しているアップル・ジステム／７オペレーティング・システムなどのオペレーティング・システム・ソフトウェアによって制御され、調整されている。好適実施例において、本発明はオブジェクト指向プログラミング技法を用いてＣ++プログラミング言語で実現されている。Ｃ++はコンパイラ型言語(compiled language)である。つまり、プログラムは人間が理解できるスクリプト(human-re adable script)で書かれ、このスクリプトはコンパイラと呼ばれる別のプログラムに渡される。これを受けて、コンパイラはマシン可読の数値コードを生成する。このコードはコンピュータにロードすることも、コンピュータに直接に実行させることも可能である。下述するように、Ｃ++言語はある種の特性をもっている。この特性によると、ソフトウェア開発者は他人が書いたプログラムを簡単に利用することができると同時に、プログラムの再利用の管理を強化することによりプログラムの破壊や正しくない使用を防止することができる。Ｃ++言語は周知であり、この言語を詳しく説明した論文や文献が多数発表されている。さらに、Ｃ ++コンパイラは、Borland International，Inc．やマイクロソフト社などの、数社のベンダから市販されている。従って、以下では、混乱を避けるために、Ｃ++ 言語の詳細とＣ++コンパイラの動作については、これ以上詳しく説明することは省略する。この分野の精通者ならば理解されるように、オブジェクト指向プログラミング (Object-Oriented Programming‐ OOP)技法では、「オブジェクト」を定義し、作成し、使用し、消去することからなっている。これらのオブジェクトは、データ・エレメントと、そのデータ・エレメントを操作するルーチン、つまり、関数とからなるソフトウェア・エンティティ(software entity)である。データおよび関連の関数は、ソフトウェアによってエンティティとして扱われ、あたかも１つのアイテム（項目）であるかのように、作成し、使用し、削除することができる。データと関数が一緒になって、オブジェクトは、その特性（これはデータ・エレメントで表すことができる）とその振舞い(behavior)（これはそのデータ操作関数で表すことができる）からとらえて、ほとんどどのような実世界のエンティティでもモデル化することができる。このようにすると、オブジェクトは人やコンピュータのような具体物をモデル化することも、数や幾何学的デザインのような抽象的概念をモデル化することもできる。オブジェクトは「クラス」を作成することにより定義される。クラスとは、それ自体はオブジェクトでないが、実際のオブジェクトをどのように構築するかをコンパイラに指示するテンプレートの働きをするものである。例えば、クラスはデータ変数の数とタイプ、およびデータを操作する関数を実行するのに必要なステップを指定することができる。オブジェクトは、実際には、コンストラクタ(c onstructor)と呼ばれる特殊な関数によってプログラムの中に作成される。つまり、コンストラクタは対応するクラス定義と、オブジェクト作成期間に渡される引数などの追加情報とを使用して、オブジェクトを構築する。同様に、オブジェクトは、デストラクタ(destructor)と呼ばれる特殊な関数によって破壊（消去）される。オブジェクトはそのデータを使用し、その関数を呼び出すことによって使用することができる。オブジェクト指向プログラミング技法の主な利点は、３つの基本原理、つまり、カプセル化(encapsulation)、多態(polymorphism)および継承(inheritance)に起因している。具体的に説明すると、オブジェクトは、内部データ構造と内部関数のすべてまたは一部を外部から見えないように、つまり、カプセル化するように設計することができる。これを具体的に説明すると、プログラム設計期間に、プログラム開発者は、データ変数のすべてまたは一部および関連関数のすべてまたは一部が「私有(private)」、つまり、そのオブジェクト自身だけが使用するものと扱われるようなオブジェクトを定義することが可能である。その他のデータまたは関数は「公開(public)」、つまり、他のプログラムが使用できるものと宣言することができる。他のプログラムによる私有変数へのアクセスは、そのオブジェクトの私有データをアクセスするオブジェクト用に公開関数を定義することによって制御することができる。公開関数は、私有データと「外部」世界とを結ぶ、制御された統一的インタフェースとなるものである。私有変数を直接にアクセスするプログラム・コードを書くようなことをすると、コンパイラはプログラムのコンパイル時にエラーを引き起こし、そのエラー個所でコンパイル・プロセスは中止されるので、プログラムは実行されないことになる。多態は、全体のフォーマットが同じであるが、異なるデータを取り扱うオブジェクトと関数が異なる働き方をして、統一的な結果を得られるようにする概念である。例えば、加算関数は、変数Ａプラス変数Ｂ（Ａ＋Ｂ）と定義することができ、ＡとＢが数であるか、文字であるか、またはドルとセントであるかに関係なく、この同じフォーマットを使用することができる。しかし、加算を実行する実際のプログラム・コードは、ＡおよびＢを構成する変数のタイプによって大幅に異なることがある。多態によると、変数の各タイプ（数、文字、およびドル）別に３種類の関数定義を書くことができる。関数が定義されたあと、プログラムはいつでも、その共通フォーマット（Ａ＋Ｂ）によってその加算関数を参照することができ、コンパイル時には、Ｃ++コンパイラは、３つの関数のどれが実際に使用されているかを、変数のタイプを調べることによって判断する。そのあと、コンパイラは正しい関数コードを代入する。多態によると、類似の結果を出力する類似の関数をプログラムのソース・コードの中で「グループ化」して、より論理的で明確化されたプログラムの流れを得ることができる。オブジェクト指向プログラミングの基礎となっている第３の原理である継承によると、プログラム開発者は既存のプログラムを容易に再利用できるので、ソフトウェアを初めから作る必要がなくなる。継承の原理によると、ソフトウェア開発者はクラス（およびそのクラスからあとで作成されるオブジェクト）を、関連するものとして宣言することができる。具体的には、クラスは他の基底クラス(b ase class)のサブクラスと指定することができる。サブクラスはその基底クラスの公開関数のすべてを「継承する」ので、その関数がサブクラスに置かれているのと同じように、その関数をアクセスすることができる。別の方法として、サブクラスは継承した関数の一部または全部をオーバライドすることも、同じフォーマットの新しい関数を定義するだけで、継承した関数の一部または全部を変更することもできる（オーバライドまたは変更を行っても、基底クラスの関数はめったに変更されず、サブクラスでの関数の使い方が変更されるだけである）。別のクラスの機能の一部を持つ（選択的変更による）新しいクラスを作成すると、ソフトウェア開発者は既存のコードを特定の要求に合わせて容易にカストマイズすることができる。オブジェクト指向プログラミングは他のプログラミング概念に比べて大幅に改善されているが、特に、変更の対象となる既存ソフトウェア・プログラムがない場合プログラム開発には相当の時間量と作業量が必要である。その結果、従来の手法では、オブジェクト群とその他の雑多なルーチンを作成するための、相互に接続された事前定義クラス群をプログラム開発者のために用意しておく必要があったが、これらのルーチンはいずれも、普通に見られるタスクを特定の環境で実行することを目的としていた。このような事前定義クラスとライブラリは普通「フレームワーク」と呼ばれており、稼働アプリケーション用の事前に作られた構造を提供している。例えば、ユーザ・インタフェース用のフレームワークは、ウィンドウ、スクロールバー、メニューなどを作成する、事前定義のグラフィック・インタフェース・オブジェクト群を提供すると共に、これらのグラフィック・インタフェース・オブジェクトをサポートする機能と「デフォルト」の行動を提供する。フレームワークはオブジェクト指向技法に基づいているので、事前定義クラスを基底クラスとして使用することができ、さらに、組込みのデフォルト行動を開発者が定義したサブクラスによって継承して、変更またはオーバライドすることにより開発者はフレームワークを拡張し、カストマイズした問題解決手法を特定の専門知識分野で作成することができる。このオブジェクト指向手法が従来のプログラミングに比べて大きな利点となっているのは、プログラマはオリジナル・プオグラムを変更するのではなく、むしろ、オリジナル・プログラムの機能を拡張しようとするからである。さらに、開発者がコード層を始めから最後まで盲目的に作業しないのは、フレームワークにアーキテクチャに関するガイダンスとモデリングが用意されており、それと同時に、開発者は問題分野に対する固有の特定アクションを行わなくてもよいからである。どのレベルのシステムに関心があるか、どのような問題を解決しようとしているかに応じて、フレームワークには多種類のものが用意されている。フレームワークの種類は、ユーザ・インタフェースの開発を支援するハイレベルのアプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポー・ト、グラフィックスなどの基本的システム・ソフトウェア・サービスを提供するローレベルのフレームワークまでの範囲にわたっている。市販されているアプリケーション・フレームワークの例を挙げると、MacApp（アップル社）、Bedrock(Sy smantec社)、OWL（Borland社）、NeXT Step App Kit（NeXT 社）、およびSmallt alk-80 MVC(ParcPlace社)がある。フレームワーク手法はカプセル化、多態および継承のすべての原理をオブジェクト層に採用しており、他のプログラミング技法を大幅に改善しているが、いくつかの困難な問題が発生している。アプリケーション・フレームワークはモノリシック・オペレーティング・システムに上乗せされた１つ以上のオブジェクト「層」（レイヤ）から構成されているのが一般であり、オブジェクト層に柔軟性があるとしても、もとの扱いずらい手続き型コールによるオペレーティング・システムと直接にやりとりする必要がよく起こっている。アプリケーション・フレームワークがアプリケーション・プログラム用のプレハブ機能を開発者に提供しているのと同じように、好適実施例に取り入れられているようなシステム・フレームワークも、システム・レベルのサービス用のプレハブ機能を提供することができる。開発者は、これらの機能を変更またはオーバライドすることにより、カストマイズされた問題解決手法を作成することができるので、従来のアプリケーション・フレームワーク・プログラムで必要であった扱いずらい手続き型コールの使用を避けることができる。以下では、アプリケーション・プログラムによって生成された情報を表示するウィンドウを作成、削除および操作するときの土台を提供することができるディスプレイ・フレームワークを例にして説明する。これらの機能を必要とするアプリケーション・ソフトウェア開発者は、通常は、これらの機能を得るために特定のルーチンを書く必要があった。フレームワークを使用してこれを行う場合は、開発者は完成したディスプレイの特性と動作を与えるだけでよく、これらのタスクを実行する実際のルーチンはフレームワークから提供される。好適実施例ではフレームワークの概念を採用し、アプリケーションとオペレーティング・システムを含むシステム全体にこの概念を適用している。商業的なまたは企業の開発者、システム・インテグレータ、またはＯＥＭにとっては、このことは、MacAppなどのフレームワークについて説明してきた利点のすべては、テキストやユーザ・インタフェースなどの事物についてはアプリケーション・レベルで、印刷、グラフィックス、マルチメディア、ファイル・システム、入出力、テストなどのサービスについてはシステム・レベルで生かすことができる。図４は、本発明のオブジェクト指向ウィンドウ・マネージャを利用するコンピュータ・システムを示す概要図である。コンピュータ・システムは全体が点線枠４００で示されており、複数のアプリケーション・プログラム（図にはアプリケーション・プログラム４０２と４１８が示されている）とオペレーティング・システム４０４は、コンピュータのオペレーションを制御し、調整するために用意されたものである。図４を簡略化するために、アプリケーション・プログラム４０２、４１８とオペレーティング・システム４０４とのやりとりは、スクリーン・ディスプレイを取り扱うやりとりに限定されている。図に示すように、アプリケーション・プログラム４０２と４１８は両方とも、オペレーティング・システム４０４のウィンドウ・マネージャ４２０と接続している。他方、ウィンドウ・マネージャ４２０は、矢印４０８で図示するように情報をスクリーン・バッファへ送っている。しかるに、本発明によれば、図４に示すように、アプリケーション・プログラム４０２、４１８も、矢印４１０と４２８で図示するように情報をスクリーン・バッファ４１２へ直接に送っている。以下で詳しく説明するように、アプリケーション・プログラム４０２、４１８は表示情報を直接にウィンドウ４２０へ渡し、ウィンドウ表示が変更されたときは、ストアされた情報をウィンドウ・マネージャ４２０から取り出している。具体的に説明すると、ウィンドウが変更されると、ウィンドウ・マネージャ４２０は各ウィンドウの可視エリアを再計算してストアしておく。このストアされた可視エリアはそれぞれのアプリケーション・プログラムによって取り出され、クリッピング領域として使用されて、アプリケーション・プログラムはその中に表示情報をドローイングする。ウィンドウの再ペイントまたはドローイングは、スクリーン・再ペイント速度を向上するためにアプリケーション・プログラムによって同時に実行される。アプリケーションの表示がディスプレイ・スクリーン上で分離されたままになっているのは、ウィンドウ・マネージャ４２０が、ウィンドウの可視エリアのいずれもがオーバラップしないようにこれらのエリアを再計算するからである。従って、アプリケーション・プログラム４０２やアプリケーション・プログラム４１８のように、各アプリケーション・プログラムがウィンドウ・マネージャ４２０から送られてきた可視エリアにだけドローイングすれば、スクリーン・バッファによって作られた表示内容がオーバラップしないことになる。表示情報がドローイングされて、スクリーン・バッファ４１２に入れられると、この情報は矢印４１４で示すように、ディスプレイ・アダプタ４１６に渡される。このディスプレイ・アダプタはケーブルまたはバス４２４を介してディスプレイ・モニタ４２６に接続されている。アプリケーション・プログラムとウィンドウ・マネージャとのやりとりは、図５の系統図で詳しく示されている。前述したように、ウィンドウ・マネージャ（図５にボックス５１０で示されている）は、オブジェクト指向のプログラムである。従って、アプリケーション・プログラム５０８は「オブジェクト」を作成し操作することによって、ウィンドウ・マネージャと接続する。具体的には、各アプリケーション・プログラムはウィンドウ・オブジェクト（例えば、ウィンドウ・オブジェクト５００）を作成して、ウィンドウ・マネージャ５１０と通信する。そのあと、アプリケーション・プログラム５０８は矢印５０２で図示するようにウィンドウ・オブジェクト５００と通信する。ウィンドウ・マネージャ自体は、オペレーティング・システムの始動時に作成されるオブジェクトであり、ウィンドウ・オブジェクトが作成されると、ウィンドウ・マネージャ５１０は関連のウィンドウをディスプレイ・スクリーン上に作成する。以下で詳しく説明するように、各ウィンドウ・オブジェクト５００は小型のデータ・ストアまたは「キャッシュ」エリア（図示せず）を含んでおり、これは関連ウィンドウの可視エリアをストアするために使用される。アプリケーション・プログラムがその関連ウィンドウの１つで情報を再ドローイングする必要が起こると、ウィンドウ・オブジェクトは、まずキャッシュのステータス（状況）をチェックする。キャッシュ・エリアにストアされた情報が変更されていなければ、この情報はウィンドウを再ドローイングするために使用される。キャッシュ・エリアを使用すると、可視エリアをウィンドウ・マネージャ５１０から取り出す必要がなくなるので、再ドローイング・オペレーションを完了するまでの時間が短縮化される。多数のウィンドウ・オブジェクトは、多数のウィンドウをディスプレイ・スクリーン上に同時に表示するように同時に作成することができるので、各ウィンドウ・オブジェクトはデータ・ストリーム５０４を通してウィンドウ・マネージャ５１０と通信する。データ・ストリーム５０４は、「ストリーム・オブジェクト」、すなわち、情報をあるオブジェクトから別のオブジェクトへ転送するために必要なソフトウェア・コマンドを収めている「ストリーム・オブジェクト」を作成することにより作られる。例えば、ウィンドウ・オブジェクト５００が情報をウィンドウ・マネージャ・オブジェクト５１０へ転送する必要が起こると、ウィンドウ・オブジェクト５００はデータを「ストリーム化」してウィンドウ・マネージャ・オブジェクト５１０に入れるストリーム・オブジェクトを作成する。同様に、ウィンドウ・マネージャ・オブジェクト５１０が情報をウィンドウ・オブジェクト５００へ送り返す必要が起こると、ウィンドウ・マネージャ・オブジェクト５１０は、データを「ストリーム化」してウィンドウ・オブジェクト５００に入れるストリーム・オブジェクトを作成する。このようなストリーム・オブジェクトはそれ自体周知であるので、詳しく説明することは省略する。データをウィンドウ・オブジェクト５００からウィンドウ・マネージャ・オブジェクト５１０へ伝達するストリーム・オブジェクトと、情報をウィンドウ・マネージャ・オブジェクト５１０からウィンドウ・オブジェクト５００へ伝達するストリーム・オブジェクトは矢印５０４で代表して示されている。図５に示すように、ウィンドウ・マネージャ５１０は３つの主要部分から構成されている。つまり、可視エリア・マネージャ５０６、共有データ・エリア５１２およびウィンドウ・リスト５１４である。可視エリア・マネージャ５０６は、ウィンドウ・マネージャ５１０が作成されたときウィンドウ・マネージャ５１０によって始動される独立タスクである。以下で詳しく説明するように、可視エリア・マネージャは、データ・ディスプレイ・スクリーン上で可視化できるウィンドウの部分の管理を担当する。この目的のために、このマネージャは、ウィンドウまたはそのウィンドウの「手前」に置かれている別のウィンドウが変更されると、ウィンドウの可視エリアを再計算する。また、ウィンドウの向きが変わったときやサイズが変更されて、「デスクトップ」にあり、予め隠れていたエリアが見えるようになったときに起こるデスクトップの損傷の修復といった、他のいくつかのハウスキーピング・タスクも実行する。共有データ・エリア５１２は共有メモリと関連ストレージ内のエリアと、取出しルーチンとからなり、これらは一緒になってウィンドウに関係する情報をストアする。共有データ・エリアはウィンドウ・マネージャによって共有メモリ内に作成され、共有データ・エリアの一部はウィンドウの各々に割り当てられ、可視エリアのバージョンを示す「タイムスタンプ」を含む、種々のウィンドウ・パラメータを収めている。前述したような、可視エリアへアクセスするためのメッセージ・ストリームを使用することを少なくするために、各ウィンドウ・オブジェクト５００はローカル「キャッシュ」メモリも持っており、ここには、関連ウィンドウの可視エリアのコピーがストアされている。タイムスタンプもローカル・キャッシュ・メモリにストアされ、このタイムスタンプは、可視エリア、すなわち、ウィンドウ・サーバから取り出された可視エリアの最後のバージョンを示している。アプリケーション・プログラムは再ドローイング・オペレーションを開始するとき、可視エリアをウィンドウ・オブジェクトから要求する。これを受けて、ウィンドウ・オブジェクトはタイムスタンプを共有メモリ・エリアから取り出し、取り出したタイムスタンプをローカル・キャッシュ・メモリにストアされたタイムスタンプと比較する。２つのタイムスタンプの比較の結果、可視エリアが変更されていないことが分かると、ローカル・キャッシュ・メモリにストアされた可視エリアのコピーが再ドローイング・オペレーションのために使用される。逆に、タイムスタンプの比較の結果、ウィンドウ・マネージャが可視エリアを更新していたことが分かったときは、新しい可視エリアを取り出して、ローカル・キャッシュ・エリアにストアしておく必要がある。タイムスタンプを単独で取り出すようにすると、可視エリア全体を取り出す場合よりも高速化するので、ローカル・キャッシュに置かれたコピーが使用できるときは、総再ドローイング時間が削減されることになる。ウィンドウ・マネージャ５１０はウィンドウ・リスト５１４も保全し、これは図示のようにリンク・リストとして実現され、システムに現在存在する各ウィンドウの識別番号を収めている。本発明の好適実施例によれば、各ウィンドウには、ウィンドウの「種類(kind)」が割り当てられている。ウィンドウの種類はその全体が、スクリーン上に置かれているウィンドウの相対的位置に従っている種類階層から選択される。図示している種類階層は次のようになっている（ウィンドウ種類は図示のように、通常最前面のウィンドウ位置に現れるウィンドウ種類から始まっている）。最前面位置スクリーン・セーバメニューバーメニューウィンドイド（フローティング・パレットおよび他の同種タイプのウィンドウ用）ドキュメント最後方位置デスクトップウィンドウ・マネージャはスクリーン上に表示されているウィンドウを自動的に保全して、同種類のウィンドウがすべて種類「層」に一緒に置かれるようにする。この配置は、種類層間の区画を示す「プレースホルダ」をウィンドウ・リスト内に挿入することにより行われる。ウィンドウ・マネージャは、これらのプレースホルダの１つに到達するまでウィンドウ・リスト全体にわたって繰り返し、特定の種類層の終わりにいつ到達したかを判断して、新しい種類層の先頭から始めることができる。前述したように、好適実施例によれば、オペレーティング・システムは複数のタスクを同時に実行させる機能を備えているので、２つ以上のタスクが同時に動作していると、相互にやりとりする可能性がある。この相互のやりとりは、２つ以上のタスクが、共有データ・エリアやウィンドウ・リストなどのような共有資源を同時にアクセスしようとすると起こることがある。従って、このようなやりとりを管理し、望ましくない干渉を防止するために並行性コントロール(concurr ency control)が必要になる。図示の並行性コントロール技法はセマフォ(semaph ore)と呼ばれるもので、一実施例で使用されている。セマフォとは、ある資源への並行アクセスの試みを「逐次化」する周知のデバイスである。具体的には、あるタスクがセマフォによって制御されている資源をアクセスするには、その前に、そのタスクはセマフォを「獲得」しなければならない。タスクが資源の使用を終えると、そのセマフォを解放して、他のタスクが獲得できるようにする。一般に、各セマフォは要求待ち行列（キュー）が関連づけられているので、受け付けられないセマフォを獲得しようとする要求は（セマフォが別のタスクによってすでに獲得されているので）待ち行列上で保留にされる。現存システムでは、セマフォは複数の異なる共有資源を保護するために使用されている。具体的には、グローバル・ドローイング・セマフォはアプリケーション・プログラムがウィンドウ・マネージャと相互に作用し合うのを防止するために使用されている。可視エリアをアクセスする前に、各アプリケーション・プログラムはドローイング・セマフォを獲得しなければならない。現存システムで使用されているドローイング・セマフォには、２つのモードがある。共有モードと排他モードである。本発明によれば、アプリケーション・プログラムは他のアプリケーション・プログラムと同時にスクリーン・バッファに書き込む場合があるので、ドローイング・セマフォを「共有」モードで獲得しなければならない。アプリケーション・プログラムはウィンドウ・マネージャによってスクリーン・バッファ内で別々に保たれているので、この同時アクセスは問題とならない。しかし、ウィンドウ・マネージャが新しいウィンドウの作成といったオペレーションを行うと、すべてのウィンドウが影響を受けるので、ウィンドウ・マネージャはドローイング・セマフォを「排他」モードで獲得しなければならない。ウィンドウ・マネージャがドローイング・セマフォを排他的に獲得したときは、アプリケーションはそのセマフォを獲得できないので、スクリーン・バッファに書く込むことができない。この排他的オペレーションは、変更の通知があるまでは、アプリケーションがスクリーン・バッファの変更部分にオーバライト（重書き）するのを禁止する。同じように、グローバル・セマフォはウィンドウ・マネージャ５１０で共有データ・エリア５１２を保護するために使用されるが、これは、この共有エリアも共有資源であるためである。異なるアプリケーション・プログラムがウィンドウ・サーバを使用して同時にアクセスすることからウィンドウ・リスト５１４を保護するために類似のローカル・セマフォが使用される。種々のセマフォの獲得と解放の具体的説明は、プログラムによって使用される実際のルーチンの説明個所で詳しく説明する予定である。図６は、代表的な「ウィンドウ環境」プログラムによって生成されるスクリーン・ディスプレイを示す図である。ウィンドウ６００はボーダ（境界）で囲まれた矩形エリアであり、これは従来と同じように動かし、サイズを変えることができる。ウィンドウ６００は、タイトル・バー６０６とメニューバー６０４を含んでいるのが普通で、その各々はそれ自体が別のウィンドウを有している場合がある。メニューバー６０４は周知の方法で操作される複数のプルダウン・メニュー（図示せず）へのアクセスを可能にし、ユーザが種々のファイル、編集および他のコマンドへアクセスすることを可能にする。タイトルバー６０６、メニューバー６０４およびボーダを除いたあとの、ウィンドウ内に残っているエリアは「クライアント」エリアと呼ばれ、ドローイング・プログラムなどのアプリケーション・プログラムがドローまたはペイントすることができるメイン・エリアを構成している。クライアント・エリアは「子」ウィンドウと呼ばれ、メイン・ウィンドウと関連づけられている別のウィンドウを取り囲んでいる場合がある。この場合、メイン・ウィンドウは子ウィンドウとの関係で「親」ウィンドウと呼ばれている。各子ウィンドウには、それが親ウィンドウとなっている１つまたは複数のウィンドウを関連づけることも可能である（以下同様）。多くのアプリケーション・プログラムはクライアント・エリアを、それぞれが独立に制御される複数の子ウィンドウに細分割する。これらはドキュメント・ウィンドウ６２２、「ツールバー」または「パレット」ウィンドウ６１６、場合によっては、ステータス・ライン・ウィンドウ（図示せず）を含んでいるのが代表例である。ドキュメント・ウィンドウ６２２は水平および垂直スクロールバー６１８，６１４を備えることが可能であり、これらのバーを使用すると、ドキュメント・ウィンドウ内のオブジェクトをスクリーン上で動かすことができる。ドキュメント・ウィンドウ６２２は子ウィンドウ６０２，６１０，６２０に細分割することが可能であり、これらは相互にオーバラップすることもできる。どの時点でも、通常は、子ウィンドウ６０２，６１０，６２０の１つだけがアクティブ状態にあり、１つのウィンドウだけが入力「フォーカス」（input focus）をもっている。入力フォーカスを持つウィンドウだけが、マウスやキーボードなどの入力デバイスからの入力アクションやコマンドに応答する。キーボード入力に応答するウィンドウは、再位置付けやサイズ変更コマンド以外の入力に応答するので非位置付けウィンドウ(non-positional window)とも呼ばれている。ツールバー／パレット・ウィンドウ６１６は、アイコン６０８，６０２のように、使用頻度の高い、ある種のプログラムやサブルーチンを開始するときに使用すると便利な複数のアイコン・イメージを含んでいるのが普通である。例えば、アイコン６０８を選択すると、ボックスをスクリーン上にドローするドローイング・ルーチンを開始することができ、アイコン６１２を選択すると、スペリング・チェック・ルーチンを開始することができる。この種のツールバーとパレットの操作は一般に周知であるので、詳細説明は省略する。表示の制御はマウスや他の入力デバイスによって選択されるのが一般的である。マウスは、ウィンドウ・プログラムによってスクリーン上にドローされるカーソルを制御する。カーソルが選択すべきグラフィック・イメージ上に置かれているとき、マウスでボタンをアクチベートすると、アプリケーション・プログラムがこれに応答する。上述した制御は、一般的には、アプリケーション・プログラムにより移動したり、サイズ変更したりできないけれども、親ウィンドウと子ウィンドウは全体がアプリケーション・プログラムの制御下に置かれているのが普通である。アプリケーション・プログラムが複数のウィンドウを持っているとき、あるいは同時に実行される複数のアプリケーション・プログラムがウィンドウを表示しているときは、あるウィンドウのサイズまたは位置が変更されると、変更されたウィンドウの「下」にあるウィンドウの表示されているまたは可視エリアが変更されることになる。図７Ａと図７Ｂは、あるアプリケーションに関連するあるウィンドウを操作すると、同じアプリケーションおよび他の独立アプリケーションに関連する他のウィンドウの可視エリアがどのように変更されるかを示している。具体的には、図７Ａは、バックグラウンドまたはデスクトップに置かれた３つのウィンドウを示している。これらのウィンドウはオーバラップしている。つまり、ウィンドウ７００はバックグラウンドにあり、ウィンドウ７０２はウィンドウ７００の手前にあり、ウィンドウ７０４はウィンドウ７０２の手前にある。図７Ａに示すように、ウィンドウ７０４はウィンドウ７０２，７００の一部を隠している。ウィンドウ７００，７０２，７０４の各々は独立に移動し、サイズ変更できるので、オーバラップしたウィンドウ内のエリアを見えるようにしたり、隠したりできるので、これらのウィンドウの外観を変更することができる。しかし、ウィンドウの外観はオーバラップしているので、選択したウィンドウを変更しても、その影響を受けるのは選択したウィンドウの背後にあるウィンドウだけである。例えば、ウィンドウ７０４を変更すると、ウィンドウ７０２と７００が影響を受けるが、ウィンドウ７００を変更したときは、ウィンドウ７０２または７０４はオーバラップしてウィンドウ７００の一部を隠しているので、これらのウィンドウはその影響を受けることがない。図７Ｂは、図７Ａにおいて前面ウィンドウ７０４のサイズを変更したときの結果を示している。具体的には、図７Ｂは３つのウィンドウ７１２，７１４，７０６を示しており、これらはそれぞれ図７Ａのウィンドウ７０４，７０２，７００に対応している。しかし、図７Ｂでは、ウィンドウ７１２はサイズが変更されており、具体的には、サイズがオリジナル・サイズのウィンドウ７０４から縮小されている。ウィンドウ７１２のサイズが縮小されると、以前は全体がウィンドウ７１２によって隠されていたウィンドウ７１０のエリア（図には陰影エリアで示されている）が見えるようになる。同様に、ウィンドウ７０６の陰影部分７０８も見えるようになる。通常のウィンドウ環境オペレーションによれば、ウィンドウの可視部分だけがペイントされる。従って、エリア７０８と７０６はそれらが可視エリアとなったとき再ドローまたは再ペイントしなければならない。この再ドローイングは、前述したようにウィンドウ・マネージャとアプリケーション・プログラムとの間の調整により行われる。具体的に説明すると、ウィンドウ・マネージャは変更された各ウィンドウと、変更されたウィンドウの背景にあるすべてのウィンドウの新しい可視エリアを計算する。そのあと、ウィンドウ・マネージャは変更されたウィンドウに関連する各アプリケーションに「更新チックル(update tickle)」を送って、その可視エリアの一部を再ドローする必要があることをアプリケーションに通知する。これを受けて、各アプリケーションは、変更された可視エリアに関連するタイムスタップをウィンドウ・マネージャ内のウィンドウ・サーバから取り出すように、変更されたウィンドウに関連するウィンドウ・オブジェクトに働きかけることになる。ウィンドウ・オブジェクトは取り出したタイムスタンプを、そのローカル・キャッシュ・メモリにストアされたタイムスタンプと比較する。関連のウィンドウ可視エリアはウィンドウ・マネージャによって更新されているので、タイムスタンプの比較は、ウィンドウ・オブジェクトにキャッシュされている可視エリアが有効でなくなったことを示している。従って、ウィンドウ・オブジェクトは新しい可視エリアを共有データ・メモリから取り出したあと、上述したセマフォ・メカニズムを用いてスクリーン・バッファに直接に書き込むことにより可視エリアを更新する。新しい可視エリアを再ペイントするプロセスは、図８に示すフローチャートに詳しく示されている。具体的には、再ペイント・ルーチンはステップ８００から開始して、ステップ８０２へ進み、そこで再ペイントすべきウィンドウに関連するウィンドウ・オブジェクトはウィンドウ・マネージャから更新チックルを受け取る。更新チックルは、ウィンドウ・マネージャが図７Ａと図７Ｂに示すようにウィンドウのサイズを変更すると生成される。これを受けて、ウィンドウ・オブジェクトは機能ブロック８０４でドローイング・セマフォを獲得し、ステップ８０４に示すように、新しい可視領域に関連するタイプスタンプを共有データ・エリアから取り出す。ステップ８０６で、取り出されたタイムスタンプはウィンドウ・オブジェクトに既にキャッシュされているタイムスタンプと比較され、キャッシュ内の可視エリアが有効かどうかが判断される。キャッシュ内の可視エリアが有効であるとステップ８０８で判断されたときは、ルーチンはステップ８１２へ進む。逆に、キャッシュ内の可視エリアが有効でなければ、ルーチンはステップ８１０へ進み、そこでウィンドウ・サーバからの新しい可視エリアがウィンドウ・オブジェクトのキャッシュにロードされる。前述したように、スクリーン・バッファにドローイングする前に、各アプリケーション・プログラムは、ステップ８０４で示すようにグローバル・ドローイング・セマフォを共有モードで獲得しなければならない。更新領域は、機能ブロック８１２でスクリーン・メモリに直接に書き込むことによりアプリケーションによって再ペイントされる。再ペイントが終了すると、ルーチンはステップ８１６へ進み、そこでドローイング・セマフォは解放され、ルーチンはステップ８１８で終了する。また、前述したように、ウィンドウ・オブジェクトはウィンドウ・マネージャとやりとりすることにより、新しいウィンドウの作成といった、種々のウィンドウ管理関数を得ることができる。新しいウィンドウを作成するためにウィンドウ・オブジェクトによって使用されるルーチン例は、図９のフローチャートに詳しく示されている。ルーチンはステップ９００から開始し、ステップ９０２へ進み、そこでローカル・セマフォがウィンドウ・オブジェクトによって獲得される。ローカル・セマフォが必要であるのは、ウィンドウ・オブジェクトが複数のアプリケーションによってアクセスされる可能性があるからであり、従って、このセマフォは、ウィンドウ・オブジェクトと種々のアプリケーションとの間の望ましくないやりとりを防止するために使用される。ローカル・セマフォがステップ９０２で獲得されると、ルーチンはステップ９０４へ進み、そこで望ましいウィンドウを定義しているパラメータがウィンドウ・マネージャへ渡されるデータ・ストリーム（図５に矢印５０４で示されている）上でストリーム化される。さらに、新しいウィンドウを「登録」する要求がウィンドウ・マネージャ内の可視エリア・マネージャに対して行われる。この要求を受けると、可視エリア・マネージャは新しいウィンドウを作成する。新しいウィンドウを作成するときのウィンドウ・マネージャのオペレーションは以下で詳しく説明するが、簡単に説明すると、ウィンドウ・マネージャは新しいウィンドウをウィンドウ・リストに追加し、新しいウィンドウを作成するが、その過程で新ウィンドウの識別番号（ＩＤ）を生成する。ウィンドウ・マネージャによって生成されたＩＤは、ステップ９０８に示すように、戻りデータ・ストリーム上でストリーム化されてウィンドウ・オブジェクトに返却され、ステップ９１０で、ウィンドウ・オブジェクトはそのキャッシュ・データ内のウィンドウＩＤを、データ・ストリームから読み取ったＩＤにセットする。次に、ルーチンはステップ９１２へ進み、そこでローカル・セマフォが解放される。ルーチンはステップ９１４で終了する。ウィンドウ・オブジェクトは、選択したウィンドウを削除するようにウィンドウ・マネージャに要求することも可能である。このオペレーションにおけるステップは図１０に詳しく示されている。図示のフローチャートに示すように、ウィンドウ削除ルーチンはステップ１０００から開始し、ステップ１００２へ進み、そこでローカル・セマフォが獲得される。次に、ルーチンはステップ１００４へ進み、そこで削除しようとするウィンドウのウィンドウＩＤがローカル・メモリから取り出され、ウィンドウ・マネージャへ渡されるデータ・ストリーム上にストリーム化される。次に、ウィンドウを削除する要求が可視エリア・マネージャに対して行われる（ステップ１００６）。そのあと、ローカル・セマフォはステップ１００８で解放され、ルーチンはステップ１０１０で終了する。前述したように、スクリーン・バッファでドローイングする前に、各ウィンドウ・オブジェクトはそのキャッシュ内の可視エリアが有効であるかどうかをチェックして確かめるが、これは、ウィンドウ・オブジェクト・キャッシュ・メモリにストアされたタイムスタンプとウィンドウ・マネージャが管理する共有データから取り出されたタイムスタンプを調べ、比較することにより行われる。キャッシュ内の可視エリアが有効でなければ、新しい可視エリアがウィンドウ・マネージャ共有データ・エリアから要求される。新しい可視エリアを要求するとき行われるステップは図１１に詳しく示されている。具体的には、可視エリア要求ルーチンはステップ１１００から開始し、ステップ１１０２へ進み、そこでローカル・セマフォが獲得される。そのあと、ウィンドウ・オブジェクトは、ステップ１１０４に示すように、キャッシュ内の可視エリアに関連するタイムスタンプが有効かどうかをチェックする。タイムスタンプに関する判定はステップ１１０６で行われ、タイムスタンプが最新であり、キャッシュ可視エリアが有効であることを示していれば、ルーチンはステップ１１０６へ進み、そこでキャッシュされた可視エリアが使用される。次に、ルーチンはステップ１１２２へ進み、そこでローカル・セマフォは解放され、ルーチンはステップ１１２４で終了する。逆に、比較ステップ１１０６がキャッシュ内のタイムスタンプが最新でないことを示しているときは、新しい可視エリアを取得する要求を可視エリア・マネージャに対して行わなければならない。要求ルーチンはステップ１１００から開始し、そこで新しい可視エリアを収容するウィンドウのウィンドウＩＤがウィンドウ・マネージャへ渡されるデータ・ストリーム上にストリーム化される。そのあと、ルーチンはステップ１１１２へ進み、そこで新しい可視エリアを取り出す要求が可視エリア・マネージャに対して行われる。ステップ１１１４で、ウィンドウ・オブジェクトは戻りデータ・ストリームをチェックして、新しい可視エリアが用意されているかどうか確かめる（これは前に置かれたフラグで示される）。新しい可視エリアが用意されていなければ、ウィンドウ・オブジェクトにストアされたキャッシュ内の可視エリアはステップ１１２０で空にされるか、あるいはクリアされる。そのあと、ルーチンはステップ１１２２でローカル・セマフォを解放し、ステップ１１２４で終了する。逆に、ステップ１１１６に示すように新しい可視エリアが用意されていれば、ルーチンはステップ１１１８へ進み、そこで新しい可視エリアが戻りストリームから読み取られ、ウィンドウ・オブジェクトのローカル・キャッシュにストアされる。次に、ルーチンはステップ１１２２へ進み、そこでローカル・セマフォは解放され、ルーチンはステップ１１２４で終了する。図１２は、ウィンドウ・オブジェクトから要求があったとき新しいウィンドウを作成するためにウィンドウ・マネージャによって使用されるルーチン例のフローチャートである。ルーチンはステップ１２００から開始し、ステップ１２０２へ進み、そこでウィンドウ・オブジェクトによって生成され、ウィンドウ・マネージャへ渡すようにストリーム化されたウィンドウ・パラメータが到来データ・ストリームから読み取られる。次に、ステップ１２０４で、ウィンドウ・マネージャはグローバル・ドローイング・セマフォを排他モードで獲得する。前述したように、ドローイング・セマフォを排他モードで獲得すると、すべてのアプリケーションは、ウィンドウ・マネージャが終了するまでドローすることが禁止される。この並行性制御は、新しいウィンドウが作成中のときアプリケーションがスクリーン・バッファを変更することを防止するものである。このインタロックが必要であるのは、新しいウィンドウが残りのウィンドウの可視エリアを変更するおそれがあり、変更すると、可視エリアの再計算がトリガされることになるからである。ドローイング・セマフォが獲得されると、ルーチンはステップ１２０６へ進み、そこで新しいウィンドウが作成されるので、新しいウィンドウＩＤが生成される。このウィンドウＩＤは、ステップ１２０８でウィンドウ・リストに追加される。また、このＩＤはステップ１２１０でストリーム化されてウィンドウ・オブジェクトに戻される。新しいウィンドウの作成は、まず表示不能ウィンドウを作成し、次にウィンドウを表示可能にすることにより行われる。ウィンドウの可視性を表示不能から表示可能に変更するステップは、以下で詳しく説明するようにウィンドウ可視エリアの再計算をトリガする。最後に、ステップ１２１２で、ドローイング・セマフォは解放され、ルーチンはステップ１２１４で終了する。図１３のフローチャートは、ウィンドウ・オブジェクトからの要求に応答してウィンドウを削除するときウインドウ・マネージャによって使用されるルーチン例を示している。ルーチンはステップ１３００から開始し、ステップ１３０２へ進み、そこでグローバル・ドローイング・セマフォが排他モードで獲得される。次に、ルーチンはステップ１３０４へ進み、そこでウィンドウ・リスト・セマフォが獲得される。次に、ステップ１３０６で、ウィンドウは表示不能にされ、そのあとルーチンはステップ１３０８へ進み、そこでウィンドウは、そのウィンドウに関連するウィンドウＩＤを削除することによりウィンドウ・リストから取り除かれる。そのあと、ウィンドウ・リスト・セマフォはステップ１３１０で解放され、ドローイング・セマフォはステップ１３１２で解放され、ルーチンはステップ１３１４へ進んで終了する。図１４は、特定のウィンドウをウィンドウ種類層の先頭に置くためにウィンドウ・マネージャによって使用されるルーチンのフローチャートを示している。ルーチンはステップ１４００から開始し、ステップ１４０２へ進み、そこでウィンドウ・リストが調べられ、先頭に移動しようとするウィンドウと同じ種類の最初のウィンドウが得られる。次に、ステップ１４０４で、選択されたウィンドウはウィンドウ・リスト内の種類層の先頭に移される。この変更はウィンドウ・リストを調べ、種類プレースホルダ(kind place holder)に到達するまでウィンドウを先頭に向かって移動することにより行われる。ウィンドウを先頭に移動すると、移動したウィンドウの背後にあるウィンドウの可視エリアが影響されることがあるので、ルーチンはステップ１４０６へ進み、そこで選択したウィンドウの背後にあるウィンドウの可視エリアが再計算される（その方法は下述する）。次に、ステップ１４０８で、ウィンドウに関連する更新エリアがウィンドウ・オブジェクトから得られる。この更新エリアはデスクトップ・エリアと比較されデスクトップが「壊されて」いたかどうか、つまり、デスクトップのエリアが隠れていないので、選択したデスクトップ・カラーに再ペイントする必要があるかどうかが判断される。ルーチンはステップ１４１０では、デスクトップが壊れていたかどうかを、選択したウィンドウの更新エリアをデスクトップ・エリアと数学的に比較することによって判断する。壊されていれば、ルーチンはステップ１４１２へ進み、そこで損傷が修復される（これは、一般に、デスクトップ損傷エリアをあらかじめ決めたカラーを使用して再ペイントすることにより行われる）。どちらの場合も、ルーチンはステップ１４１４へ進み、そこで新しく移動したウィンドウが新しいアプリケーションに関連するものであるか、あるいは最前面のウィンドウになったかどうかの判断が行われる。そうであれば、「フォーカス」スイッチがステップ１４１６で生成される。このフォーカス・スイッチはメッセージをオペレーティング・システムに送ることにより開始されるのが一般であり、フォーカス・スイッチは選択されたウィンドウのビジュアル変更と関連づけられていることがよくある（例えば、ウィンドウのキャプションやメニューバーは異なるカラーになることがある）。そのあと、ルーチンはステップ１４１８へ進んで終了する。図１５は、ウィンドウの可視性を変更するために可視エリア・マネージャによって使用されるルーチン例のフローチャートである。このルーチンはステップ１５００から開始し、ステップ１５０２へ進み、そこで可視性を変更するためにウィンドウ・オブジェクトから受け取った要求が実際に可視性を変更するものかどうかの判断が行われる。例えば、すでに表示不能になっているウィンドウを表示不能にする要求があったときは、変更を行う必要はない。同様に、ウィンドウがすでに表示可能であって、それを表示可能にする要求を受けたときも、変更を行う必要がない。変更の必要がなければ、ルーチンは直接にステップ１５１６へ移って終了する。ステップ１５０２で、可視性の変更が実際に要求されていると判断されると、ルーチンはステップ１５０４へ進み、そこで「損傷」エリア変数がウィンドウの可視エリアにセットされる。この損傷エリア変数は、以下で説明するようにデスクトップの損傷を修復するときに使用される。次に、ルーチンはステップ１５０６へ進み、そこでウィンドウ・リストにストアされた可視性変数が新しい可視性を示すように変更される。次に、ステップ１５０８で、変更されたウィンドウの背後にあるウィンドウの可視エリアは以下で説明するように増分的に再計算される。次に、ウィンドウ可視ルーチンはステップ１５１０へ進み、そこでウィンドウが可視にされるものであるかどうかを判断するチェックが行われる。そうでなければ、ステップ１５０４でセットされた損傷変数は、ウィンドウが表示不能にされるものであり、可視エリア全体が見えなくなるので、正しい「損傷」を表している。従って、ルーチンは１５１６へ進み、そこで損傷エリアを消去するための要求がウィンドウ・マネージャに対して行われる。逆に、ステップ１５１０で、ウィンドウが可視にされるものであると判断されたときは、損傷エリア変数は、損傷エリアの一部が新しく可視になったウィンドウで隠されることを表すように調整する必要がある。この場合には、ルーチンはステップ１５１２へ進み、そこで新しい可視エリアはそれを再計算することにより得られる。次に、ルーチンはステップ１５１４へ進み、そこで「損傷」エリアは新しい可視エリアに基づいてリセットされる。具体的には、新しく可視になったウィンドウがデスクトップに損傷を引き起こしていれば、損傷エリア変数は可視エリアと排他的ＯＲ（ＸＯＲ）がとられる。そうでなければ、損傷エリア変数は減算によって新可視エリアだけ減少される。次に、ルーチンはステップ１５１６へ移り、そこでウィンドウ・マネージャにデスクトップ損傷を消去するように要求する。そのあと、ルーチンはステップ１５１８へ進んで終了する。図１６と図１７は、ウィンドウが変更されたときウィンドウ可視エリアを再計算するために可視エリア・マネージャによって使用される２つのルーチンを示している。図１６に示すルーチンを使用すると、変更されたウィンドウの背後にあるすべてのウィンドウの可視エリアを、どのような条件でも再計算することができるが、このルーチンは図１７に示すルーチンよりも低速である。図１７に示すルーチンは、１つのウィンドウだけがサイズ変更または移動されたとき可視エリアを再計算するために使用される。図１７に示すルーチンは高速であるため、計算回数が少なくて済む。図１６に示すルーチンは２つの変数AreaAbove とCurren tWindow を使用している。CurrentWindow 変数は、可視エリア・マネージャがそこで稼働している「現在のウィンドウ」を表し、AreaAbove 変数は、現在のウィンドウよりも「上」かあるいは「前面」近くにあるウィンドウのトータルのエリアを表している。可視エリア・マネージャは可視エリアが実際に変更されたかどうかに関係なく、図１６に示すルーチンを使用して、変更されたウィンドウの背後にあるすべてのウィンドウの可視エリアを再計算するが、これは、あるウィンドウの変更が別のウィンドウの可視エリアに影響にしなかったときそれを検出するメカニズムが図１６に示すルーチンでは使用されないためである。具体的には、ルーチンはステップ１６００から開始し、ステップ１６０２へ進み、そこでAreaAbove 変数がクリアされる。次に、ステップ１６０４で、Curren tWindow 変数はディスプレイ・スクリーン上に現れる最初のウィンドウまたは前面ウィンドウにセットされる。次に、ルーチンはステップ１６０６へ進み、そこで新しい CurrentWindow（これは現在最前面ウィンドウになっている）が変更されたウィンドウであるかどうかを判断するためのチェックが行われる。CurrentW indow が変更されたウィンドウであれば、ルーチンはステップ１６０８へ進み、そこでAreaAbove 変数を現ウィンドウ・エクステント（ウィンドウのフル・エリア）から減算することによりCurrentWindow の可視エリアが計算される。現ウィンドウが最前面ウィンドウである場合には、AreaAbove 変数はクリアされているので（ステップ１６０２で）、ステップ１６０８で計算された可視エリアは最前面ウィンドウ・エクステント・エリアであるにすぎない。次に、ルーチンはステップ１６１０へ進み、そこでAreaAbove 変数は、変更された現ウィンドウの影響を反映するように補正される。この補正は、AreaAbove 変数および現ウィンドウのエクステントを合体（ユニオン）にAreaAbove 変数をセットすることにより行われる。次に、ルーチンはステップ１６１４へ進み、そこでウィンドウ・リストがチェックされ、現ウィンドウの背後に別のウィンドウがあるかどうかが判断される。もしあれば、CurrentWindow 変数はステップ１６１２で次のウィンドウにセットされ、ルーチンはステップ１６０６へ戻り新しい現ウィンドウの可視エリアを再計算する。逆に、ステップ１６１４で残っているウィンドウがなければ、ルーチンはステップ１６１６で終了する。図１７に示す増分ルーチンは、ある種の場合においてパフォーマンスを向上するようにウィンドウの可視エリアを増分的に計算する方法を示している。この増分方法は、図１６に示すようなルーチンを使用して、変更されたウィンドウの可視エリアを最初に計算することから開始される。次に、増分ルーチンは変更ウィンドウの旧可視エリアと新可視エリアの排他的ＯＲを計算する。この「変更エリア」はウィンドウの変更によって影響を受けたエリアを表している。最後に、図１７に示す増分ルーチンは影響を受けたまたは変更されたエリアを変更ウィンドウの背後にあるウィンドウの各々に適用する。影響を受けたエリアだけが後続のウィンドウに適用されるので、パフォーマンス向上は２通りの方法で達成することができる。第一に、ウィンドウ・エクステント・エリアが影響を受けたまたは変更されたエリアと交差していなければ、そのウィンドウ可視エリアについてなにも行う必要がない。このことを判断するチェックを行うと、影響を受けなかったウィンドウに関係する計算を行わないで済むことになる。第二に、影響を受けたまたは変更されたエリアが空になっているかどうかを判断するチェックを行うことができる。空になっていれば、ルーチンがリスト上の最後のウィンドウまで到達していなくても、ルーチンを途中で終了させることができる。このルーチンは図１７に詳しく示されているが、ステップ１７００から開始する。次に、ルーチンはステップ１７０２へ進み、そこで変更されたウィンドウの旧またはオリジナル可視エリアがセーブされる。次に、ステップ１７０４で、変更ウィンドウについて新しい可視エリアが計算される。新しい可視エリアの計算は、図１６に示すようなルーチンを使用して行うことができる。具体的には、図１６に示すルーチンは、現ウィンドウが変更ウィンドウであることをステップ１６０６が示すまで、ステップ１６０６−１６１４からなるループを繰り返すことにより使用できる。この時点で、ステップ１６０８で計算された可視エリアがステップ１７０４で使用される。次に、ステップ１７０６で、”ChangedArea”と名づけた変数は、ステップ１７０２でストアされた旧可視エリアとステップ１７０４で計算された新可視エリアとの排他的ＯＲに等しくなるように計算される。このChangedAre a 変数は、変更ウィンドウの下にあるウィンドウのすべてを変更するときに使用される。この目的のために、ルーチンはステップ１７０８へ進み、そこでChange dArea 変数が空であるかどうかを判断するためのチェックが行われる。空であれば、ルーチンはステップ１７１６で終了する。ステップ１７０８で、ChangedArea 変数が空でないと判断されたときは、ルーチンはステップ１７１０へ進み、そこでウィンドウ・リストがチェックされ、別のウィンドウがリストに残っているかどうかが判断される。別のウィンドウがあれば、次のウィンドウの可視エリアが、ステップ１７１２に示すように、Chan gedArea 変数と次のウィンドウのエクステントとの排他的ＯＲをとることにより計算される。次に、ChangedArea 変数は、ステップ１７１４に示すように、次のウィンドウのエクステントをChangedArea 変数から減算することにより更新される。そのあと、ルーチンはリスト内の次のウィンドウを処理するために、まず新しいChangedArea 変数が空であるかどうかをステップ１７０８で判断する。空であれば、ルーチンはステップ１７１６で終了する。空でなければ、次のウィンドウが処理される。このオペレーションは、ChangedArea 変数が空になるか、あるいはウィンドウ・リストに残っているウィンドウがなくなるまで上記のように続けられる。以上、特定のシステム環境における好適実施例を参照して本発明を説明してきたが、この分野に精通した当業者が理解されるように、本発明は、変更を加えることにより、他の異なるハードウェアおよびソフトウェア環境で実施することが可能であり、このことは請求の範囲に明確化されている本発明の精神と範囲に属することはもちろんである。

【手続補正書】特許法第１８４条の８【提出日】１９９５年１１月２９日【補正内容】請求の範囲１．ウィンドウ・マネージャ（４２０）を包含するオペレーティング・システム（４０４）を有するコンピュータであって、デスクトップ・バックグラウンド（６２２）上に表示される複数のウィンドウ・エリア（７００，７０２，７０４）を有する表示を生成するためにディスプレイ・デバイス（４２６）を制御するコンピュータを持ち、前記複数のウィンドウ・エリア（７００，７０２，７０４）の各々は、複数のアプリケーション・プログラム（４０２，４０８，５０８）の１つによって生成されたスクリーン情報を表示するコンピュータ・システムにおいて、変更可能なサイズを持つ複数のストレージ・エリアを持ち、複数のウィンドウ・エリアの１つについてのスクリーン情報をストアする手段を含んでいるスクリーン・バッファ・ストレージ装置（４１２）であって、該スクリーン情報が表示を生成するためにディスプレイ・デバイスによって使用されるスクリーン・バッファ・ストレージ装置と、前記複数のアプリケーション・プログラム（４０２，４１８，５０８）によって制御されるプロセッサとを有し、前記複数のアプリケーション・プログラムの各々は、前記スクリーン・バッファ・ストレージ装置と直接に通信して、該スクリーン・バッファ・ストレージ装置のストレージ・エリア内でストアされたスクリーン情報を直接に変更するための手段を有しており、前記ウィンドウ・エリアが変更に応じて、前記複数のアプリケーション・プログラムが該ウィンドウ・エリアの変更に応答できるように該ウィンドウ・エリアの変更を複数のアプリケーション・プログラムに伝達するためのオブジェクト手段とを具えたことを特徴とするコンピュータ・システム。２．前記ウィンドウ・エリアの変更を伝達するオブジェクト手段はオペレーティ・ング・システムによって作成されることを特徴とする請求項１に記載のコンピュータ・システム。３．前記ウィンドウ・エリアの各々は、対応するストレージ・エリアの位置とサイズを変更することにより移動し、サイズ変更することが可能であり、前記伝達するオブジェクト手段は前記複数のストレージ・エリアの１つの位置とサイズの変更に応じて前記複数のストレージ・エリアのいくつかのストレージ・エリア・サイズを再計算することを特徴とする請求項１に記載のコンピュータ・システム。４．前記再計算は、前記複数のストレージ・エリアの１つについての位置とサイズの変更に応じてトリガされ、当該複数のストレージ・エリアの１つの一部であって位置とサイズの変更によって修正する変更エリアを計算し、該変更エリアに応じて、該変更エリアと、前記複数のストレージ・エリアのいくつかに対応するストアされたエリアとを結合することにより該複数のストレージ・エリアのいくつかのストレージ・エリア・サイズを再計算することを特徴とする請求項３に記載のコンピュータ・システム。５．前記ウィンドウ・エリアはオーバラップしていて、前面から後面への配列を持つように視覚的に表示され、前記オブジェクト手段は前記複数のウィンドウの各々を、複数のリスト位置を持つ配列リストで管理し、当該各リスト位置は前面から後面への配列内の位置に対応していることを特徴とする請求項１に記載のコンピュータ・システム。６．前記複数のウィンドウの各々に関連づけられたウィンドウ・オブジェクトをさらに含み、当該各ウィンドウ・オブジェクトはウィンドウ・データとウィンドウ関数を含み、前記アプリケーション・プログラムによって作成されることを特徴とする請求項１に記載のコンピュータ・システム。７．前記各ウィンドウ・オブジェクトと前記伝達するオブジェクト手段との間でデータ・ストリーム・オブジェクトによって情報が転送されることを特徴とする請求項６に記載のコンピュータ・システム。８．前記ウィンドウ・オブジェクトは前記複数のアプリケーションの１つからの要求に応答して、当該要求を行った複数のアプリケーション・プログラムの１つへストレージ・エリア・ロケーションおよびサイズを引渡すことを特徴とする請求項６に記載のコンピュータ・システム。９．前記ウィンドウ・オブジェクトのウィンドウ・データは、関連ウィンドウのストレージ・エリア・サイズのコピーを含み、該ウィンドウ・オブジェクトは前記複数のアプリケーションの１つからの要求に応答して前記ストレージ・エリア・サイズ・コピーの有効性を判断することを特徴とする請求項８に記載のコンピュータ・システム。１０．前記伝達するオブジェクト手段は、各ストレージ・エリア・サイズに対応していて、該ストレージ・エリア・サイズが再計算されたときの時刻を示す第１スタンプをストアする装置を含み、前記ウィンドウ・オブジェクトは前記ストレージ・エリア・サイズ・コピーが前記ウィンドウ・オブジェクトにストアされたときの時刻を示す第２タイムスタンプを前記ストレージ・エリア・サイズ・コピーと一緒にストアする装置を含むことを特徴とする請求項９に記載のコンピュータ・システム。１１．前記有効性判断装置は、前記ウィンドウに対応する選択したストレージ・エリア・サイズについて前記アプリケーション・プログラムからの要求に応じて、当該選択したストレージ・エリア・サイズと一緒にストアされた第１タイムスタンプを前記伝達するオブジェクト手段から取り出す装置と、当該取り出した第１タイムスタンプに応じて、該取り出した第１タイムスタンプを前記ウィンドウ・オブジェクトにストアされた第２タイムスタンプと比較する装置とを含むことを特徴とする請求項１０に記載のコンピュータ・システム。１２．ウィンドウ・マネージャ（４２０）を包含するオペレーティング・システム（４０４）を有するコンピュータであって、デスクトツプ・バックグラウンド上に表示される複数のオーバーラップのウィンドウを有する表示を生成するためにディスプレイ・デバイスを制御するコンピュータを含み、前記複数のウィンドウの各々は、複数のアプリケーション・プログラムの１つによって生成されたスクリーン情報を表示する可視エリアを有するコンピュータ・システムにおいて、前記複数のアプリケーション・プログラムによって制御されて、前記コンピュータ・システムのオペレーションを制御し調整するプロセッサと、共有データ・エリアを持ち、ウィンドウ可視エリアをストアし、前記複数のウィンドウの１つの可視エリアの変更に応じて前記複数のウィンドウの他のウィンドウの可視エリアを変更するオブジェクト手段と、前記複数のアプリケーション・プログラムの１つによって作成されるウィンドウ・オブジェクトであって、当該各ウィンドウ・オブジェクトは前記複数のウィンドウの各々に関連づけられており、当該各ウィンドウ・オブジェクトは関連ウィンドウの可視エリアのコピーをストアするキャッシュ・メモリを含むことを特徴とするコンピュータ・システム。１３．前記ウィンドウ・オブジェクトと前記オブジェクト手段との間でデータ・ストリーム・オブジェクトを介して情報がストリーム化されることを特徴とする請求項１２に記載のコンピュータ・システム。１４．前記ウィンドウ・オブジェクトは前記複数のアプリケーション・プログラムの１つからの要求に応じて、当該要求した複数のアプリケーション・プログラムの１つへ前記複数のウィンドウの１つの可視エリアを引渡すことを特徴とする請求項１２に記載のコンピュータ・システム。１５．各ウィンドウ・オブジェクトは複数のアプリケーション・プログラムの１つからの要求に応答して、ウィンドウ可視エリア・コピーの有効性を判断することを特徴とする請求項１２に記載のコンピュータ・システム。１６．前記オブジェクト手段は、前記ウィンドウ可視エリアが最後に再計算されたときの時刻を示す第１タイムスタンプを前記各ウィンドウ可視エリアと一緒にストアする手段を含み、前記ウィンドウ・オブジェクトは前記ウィンドウ可視エリア・コピーがキャッシュ・メモリにストアされたときの時刻を示す第２タイムスタンプをキャッシュ・メモリにストアすることを特徴とする請求項１５に記載のコンピュータ・システム。１７．各ウィンドウ・オブジェクトは、選択したウィンドウ可視エリアを求めるアプリケーション・プログラムからの要求に応答して、第１タイムスタンプをオブジェクト手段から取り出す手段と、取り出した第１タイムスタンプに応答して、該取り出した第１タイムスタンプを前記キャッシュ・メモリにストアされた第２タイムスタンプと比較する装置とを含むことを特徴とする請求項１６に記載のコンピュータ・システム。１８．前記キャッシュ・メモリにストアされた可視エリアが、前記オブジェクト手段による最後の再計算の前にストアされたことを前記タイムスタンプ比較装置が示しているとき、前記各ウィンドウ・オブジェクトは前記ウィンドウ可視エリアを前記オブジェクト手段から取り出す手段をさらに含んでいることを特徴とする請求項１７に記載のコンピュータ・システム。１９．オペレーティング・システムおよびアプリケーション・プログラムによって制御されるプロセッサを持つコンピュータを操作してデスクトップ・バックグラウンドに表示される複数のウィンドウ・エリアの１つにスクリーン情報をディスプレイ・デバイス上で表示するように操作する方法であって、前記複数のウィンドウ・エリアの各々は変更可能な可視エリアを持つ方法において、（Ａ）共有データ・エリアを持ち、１つのウィンドウの可視エリアの変更に応じて、少なくとも１つの他のウィンドウの可視エリアを変更するウィンドウ・マネージャを作成するステップと、（Ｂ）前記アプリケーション・プログラムに前記ウィンドウ・マネージャからの、複数のウィンドウ・エリアの１つの可視エリアを要求させるステップと、（Ｃ）前記アプリケーション・プログラムに前記ウィンドウ・マネージャから取得した可視エリアにだけスクリーン情報を表示させるステップとを含むことを特徴とする方法。２０．前記ウィンドウ・エリアはオーバラップしていて、前面から後面への配列を持つように視覚的に表示され、前記ステップ（ａ）は、（Ａ１）前記複数のウィンドウの各々を複数のリスト位置を持つ配列リスト内で管理するウィンドウ・リスト・オブジェクトを作成するステップを含み、当該各リスト位置は前面から後面への配列内の位置に対応していることを特徴とする請求項１９に記載の方法。２１．前記ステップ（ｂ）は、（Ｂ１）前記複数のウィンドウの各々に関連づけられたウィンドウ・オブジェクトを作成するステップであって、当該各ウィンドウ・オブジェクトはウィンドウ・データとウィンドウ関数を含んでいて、アプリケーション・プログラムによって作成されるステップと、（Ｂ２）前記ウィンドウ・オブジェクトに前記可視エリアを要求させるステップとを含むことを特徴とする請求項１９に記載の方法。２２．前記ステップＢ２は、（Ｂ２Ａ）要求情報を前記各ウィンドウ・オブジェクトと前記ウィンドウ・マネージャとの間でデータ・ストリーム・オブジェクトを介して転送するステップを含むことを特徴とする請求項２１に記載の方法。２３．前記ステップＢ２は、（Ｂ２Ｂ）可視エリアのキャッシュ・コピーをウィンドウ・オブジェクト内で管理するステップと、（Ｂ２Ｃ）前記ウィンドウ・オブジェクト内のキャッシュ・コピーをチェックしてからストアされた前記可視エリアのコピーを前記ウィンドウ・マネージャに要求するステップとを含むことを特徴とする請求項２１に記載の方法。２４．前記ステップＢ２は、（Ｂ２Ｄ）前記可視エリアが再計算されたときの時刻を示す第１タイムスタンプを前記各ウィンドウ可視エリアと一緒に前記共有データ・エリアにストアするステップと、（Ｂ２Ｅ）前記キャッシュ・コピーが前記ウィンドウ・オブジェクトにストアされた時刻を示す第２タイムスタンプをウィンドウ・オブジェクトにストアするステップとを含むことを特徴とする請求項２３に記載の方法。２５．前記ステップＢ２は、（Ｂ２Ｆ）前記ウィンドウ可視エリアについての要求を前記アプリケーション・プログラムから受け取ったとき、選択した前記ウィンドウ可視エリアと一緒にストアされた前記第１タイムスタンプを前記ウィンドウ・マネージャから取り出すステップと、（Ｂ２Ｇ）前記取り出した第１タイムスタンプを前記ウィンドウ・オブジェクトにストアされた第２タイムスタンプと比較するステップとを含むことを特徴とする請求項２４に記載の方法。２６．前記ステップＢ２は、（Ｂ２Ｈ）前記ステップＢ２Ｇのタイムスタンプ比較がウィンドウ・オブジェクトにストアされたキャッシュ・コピーが有効でないことを示しているとき、前記ウィンドウ・マネージャにストアされたウィンドウ可視エリアを取り出すステップを含むことを特徴とする請求項２５に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ【要約の続き】イングする必要が起こった場合、およびその可視エリアが変更されていなかったときに使用することができる。さらに、ウィンドウ・マネージャは、単一のウィンドウだけが変更されたことを想定するルーチンを使用して各アプリケーション・ウィンドウの新しい可視エリアを計算し、ウィンドウの新可視エリアを旧可視エリアと比較して変更エリアを得ている。この変更エリアは、変更されたウィンドウの背後にあるすべてのウィンドウの可視エリアを再計算するときに使用される。

Claims

【特許請求の範囲】１．デスクトップ・バックグランド上に表示される複数のウィンドウ・エリアを持つ表示を生成するようにディスプレイ・デバイスを制御するコンピュータ・システムであって、該複数のウィンドウ・エリアの各々は、複数のアプリケーション・プログラムの１つによって生成されたスクリーン情報を表示するコンピュータ・システムにおいて、複数のストレージ・エリアを持つスクリーン・バッファ・ストレージ装置であって、該複数のストレージ・エリアの各々はサイズを持ち、前記複数のウィンドウ・エリアの１つのためのスクリーン情報をストアするスクリーン・バッファ・ストレージ装置と、前記スクリーン情報を前記スクリーン・バッファ・ストレージ装置にストアするように前記複数のアプリケーション・プログラムによって制御されるプロセッサと、該プロセッサと共同作用して前記ディスプレイ・デバイスを制御するオペレーティング・システムと、共有データ・エリアを持ち、あるストレージ・エリアのストレージ・エリア・サイズの変更に応じて少なくとも１つの他のストレージ・エリアのストレージ・エリア・サイズを変更するウィンドウ・マネージャ・オブジェクトとを具えていることを特徴とするコンピュータ・システム。２．前記ウィンドウ・マネージャ・オブジェクトは前記オペレーティング・システムによって作成されることを特徴とする請求項１に記載のコンピュータ・システム。３．前記ウィンドウ・エリアの各々は対応するストレージ・エリアの位置とサイズを変更することにより移動し、サイズ変更することが可能であり、前記ウィンドウ・マネージャ・オブジェクトは複数のストレージ・エリアの１つの位置とサイズの変更に応じて前記複数のストレージ・エリアのいくつかのストレージ・エリア・サイズを再計算する装置を含むことを特徴とする請求項１に記載のコンピュータ・システム。４．前記再計算装置は、前記複数のストレージ・エリアの１つの位置とサイズが変更されると、変更エリア、すなわち、前記複数のストレージ・エリアの中の位置とサイズの変更によって変更されたものの一部分である変更エリアを計算するメカニズムと、前記変更エリアを受けて、複数のストレージ・エリアのいくつかに対応のストアされたエリア・サイズと前記変更エリアとを結合することにより前記複数のストレージ・エリアのいくつかのストレージ・エリア・サイズを再計算する装置とを含むことを特徴とする請求項３に記載のコンピュータ・システム。５．前記ウィンドウ・エリアはオーバラップしていて、前面から後面への配列を持つように視覚的に表示され、前記ウィンドウ・マネージャ・オブジェクトは、前記複数のウィンドウの各々を複数のリスト位置を持つ配列リスト内で管理するメカニズムを含み、各リスト位置は前面から後面への配列の位置に対応していることを特徴とする請求項１に記載のコンピュータ・システム。６．前記複数のウィンドウの各々に関連づけられたウィンドウ・オブジェクトをさらに含み、前記各ウィンドウ・オブジェクトはウィンドウ・データとウィンドウ関数を含み、アプリケーション・プログラムによって作成されることを特徴とする請求項１に記載のコンピュータ・システム。７．前記各ウィンドウ・オブジェクトとウィンドウ・マネージャとの間でデータ・ストリーム・オブジェクトによって情報が転送されることを特徴とする請求項６に記載のコンピュータ・システム。８．前記ウィンドウ・オブジェクトは複数の前記アプリケーション・プログラムの１つから要求を受け取るメカニズムと、当該受け取った要求に応答して、ストレージ・エリア・ロケーションとサイズを、要求を行った前記複数のアプリケーション・プログラムの１つへ引渡す装置とを含むことを特徴とする請求項６に記載のコンピュータ・システム。９．前記ウィンドウ・データは関連ウィンドウのストレージ・エリア・サイズのコピーを含み、前記ウィンドウ・オブジェクトは前記複数のアプリケーションの１つからの要求に応答して、該ストレージ・エリア・サイズ・コピーの有効性を判断する装置を含むことを特徴とする請求項８に記載のコンピュータ・システム。１０．前記ウィンドウ・マネージャ・オブジェクトは、ストレージ・エリア・サイズが再計算されたときの時刻を示す第１タイムスタンプを各ストレージ・エリア・サイズと一緒にストアする装置を含み、前記ウィンドウ・オブジェクトは、前記ストレージ・エリア・コピーが前記ウィンドウ・オブジェクトにストアされたときの時刻を示す第２タイムスタンプを前記ストレージ・エリア・コピーと一緒にストアする装置を含むことを特徴とする請求項９に記載のコンピュータ・システム。１１．前記有効性判断装置は、１つのウィンドウに対応し、選択されたストレージ・エリア・サイズについてのアプリケーション・プログラムからの要求に応答して、当該選択されたストレージ・エリア・サイズと一緒にストアされた第１タイムスタンプを前記ウィンドウ・マネージャ・オブジェクトから取り出す装置と、該取り出した第１タイムスタンプを前記ウィンドウ・オブジェクトにストアされた第２タイムスタンプと比較する装置とを含むことを特徴とする請求項１０に記載のコンピュータ・システム。１２．前記有効性判断装置は、前記ウィンドウ・オブジェクトにストアされたストレージ・エリアが有効でないとタイムスタンプ比較装置が示しているとき、前記ウィンドウ・マネージャ・オブジェクト内にストアされたストレージ・エリア・サイズを取り出す手段をさらに含んでいることを特徴とする請求項１１に記載のコンピュータ・システム。１３．デスクトップ・バックグランド上に表示される複数のウィンドウ・エリアを持つ表示を生成するようにディスプレイ・デバイスを制御するコンピュータ・システムであって、該複数のウィンドウ・エリアには、複数のアプリケーション・プログラムの１つによって生成されたスクリーン情報が表示されるコンピュータ・システムにおいて、サイズ変更可能な複数のストレージ・エリアを持つスクリーン・バッファ・ストレージ装置であって、当該サイズ変更可能な複数のストレージ・エリアの各々はサイズを持ち、前記複数のウィンドウ・エリアの１つのスクリーン情報をストアするスクリーン・バッファ・ストレージ装置と、前記複数のアプリケーション・プログラムの中の選択された１つからスクリーン情報を受け取って、当該受け取ったスクリーン情報を前記選択された１つのアプリケーション・プログラムに対応するサイズ変更可能な複数のストレージ・エリアの中の１つにストアするように前記複数のアプリケーション・プログラムによって制御されるプロセッサと、プロセッサと共同作用して前記ディスプレイ・デバイスを制御するオペレーティング・システムと、共有データ・エリアを持ち、あるストレージ・エリアのストレージ・エリア・サイズの変更に応じて少なくとも１つの他のストレージ・エリアのストレージ・エリア・サイズを変更するウィンドウ・マネージャ・オブジェクトと前記複数のアプリケーション・プログラムの各々によって作成されるウィンドウ・オブジェクトであって、該ウィンドウ・オブジェクトは、作成されると、前記ウィンドウ・マネージャ・オブジェクトと共同作用して、前記複数のストレージ・エリアの１つを割り当てることによりウィンドウ・エリアを作成するウィンドウ・オブジェクトを具えたことを特徴とするコンピュータ・システム。１４．前記ウィンドウ・マネージャ・オブジェクトは前記オペレーティング・システムによって作成されることを特徴とする請求項１３に記載のコンピュータ・システム。１５．前記ウィンドウ・エリアはオーバラップしていて、前面から後面への配列を持つように視覚的に表示され、前記ウィンドウ・マネージャ・オブジェクトは、前記複数のウィンドウの各々を複数のリスト位置を持つ配列リスト内で管理するメカニズムを含み、前記各リストの位置は前面から後面への配列の位置に対応していることを特徴とする請求項１４に記載のコンピュータ・システム。１６．前記ウィンドウ・マネージャ・オブジェクトは、前記複数のウィンドウ・エリアの１つの位置とサイズが変更されると、変更ウィンドウ・エリア、すなわち、前記複数のウィンドウ・エリアの中の位置とサイズの変更されたものの一部である変更ウィンドウ・エリアを計算する装置と、該変更ウィンドウ・エリアを受けて、前記配列リストによって判断された１つのウィンドウ・エリアの背後に現れるウィンドウ・エリアに対応するストレージ・エリアのストレージ・エリア・サイズを再計算する装置とを含むことを特徴とする請求項１５に記載のコンピュータ・システム。１７．前記再計算装置は、ストアされたエリア・サイズを、前記配列リストによって判断された１つのウィンドウ・エリアの背後に現れるウィンドウ・エリアに対応するストアされたエリア・サイズと結合することによって前記ストレージ・エリア・サイズを再計算することを特徴とする請求項１６に記載のコンピュータ・システム。１８．前記複数のウィンドウ・オブジェクトの各々はキャッシュ・メモリと、前記ウィンドウ・エリアを操作するための複数のメソッドとを含むことを特徴とする請求項１７に記載のコンピュータ・システム。１９．前記各ウィンドウ・オブジェクトと前記ウィンドウ・マネージャ・オブジェクトとの間でデータ・ストリーム・オブジェクトによって情報が転送されることを特徴とする請求項１８に記載のコンピュータ・システム。２０．前記ウィンドウ・オブジェクトは前記複数のアプリケーション・プログラムの１つから要求を受け取るメカニズムと、当該受け取った要求に応答して、ストレージ・エリア・ロケーションとサイズを、当該要求を行った複数のアプリケーション・プログラムの１つへ引渡す装置とを含むことを特徴とする請求項１９に記載のコンピュータ・システム。２１．関連ウィンドウのストレージ・エリア・サイズのコピーが前記ウィンドウ・オブジェクト・キャッシュ・メモリにストアされ、ウィンドウ・オブジェクトは前記複数のアプリケーションの１つからの要求に応答して、前記ストレージ・エリア・サイズ・コピーの有効性を判断する装置を含むことを特徴とする請求項２０に記載のコンピュータ・システム。２２．前記ウィンドウ・マネージャ・オブジェクトは、前記ストレージ・エリア・サイズが最後に再計算されたときの時刻を示す第１タイムスタンプを各ストレージ・エリア・サイズと一緒にストアする装置を含み、前記ウィンドウ・オブジェクトは、前記ストレージ・エリア・コピーが前記キャッシュ・メモリにストアされたときの時刻を示す第２タイムスタンプを該キャッシュ・メモリにストアする装置を含むことを特徴とする請求項２１に記載のコンピュータ・システム。２３．前記有効性判断装置は、１つのウィンドウに対応し、選択されたストレージ・エリア・サイズについてのアプリケーション・プログラムからの要求に応答して、当該選択されたストレージ・エリア・サイズと一緒にストアされた第１タイムスタンプをウィンドウ・マネージャ・オブジェクトから取り出す装置と、当該取り出した第１タイムスタンプをキャッシュ・メモリにストアされた第２タイムスタンプと比較する装置とを含むことを特徴とする請求項２２に記載のコンピュータ・システム。２４．前記有効性判断装置は、前記キャッシュ・メモリにストアされたストレージ・エリアが前記ウィンドウ・マネージャ・オブジェクトによる最後の再計算の前にストアされたことを前記タイムスタンプ比較装置が示しているとき、該ウィンドウ・マネージャ・オブジェクトにストアされたストレージ・エリア・サイズを取り出す手段をさらに含むことを特徴とする請求項２３に記載のコンピュータ・システム。２５．デスクトップ・バックグランド上に表示される複数のオーバラップしたウィンドウ・エリアを持つ表示を生成するようにディスプレイ・デバイスを制御するコンピュータ・システムであって、該複数のウィンドウ・エリアの各々は複数のアプリケーション・プログラムの１つによって生成されたスクリーン情報を表示するための可視エリアを持つコンピュータ・システムにおいて、前記複数のアプリケーション・プログラムによって制御されて、前記コンピュータ・システムのオペレーションを制御し、調整するプロセッサと、該プロセッサと共同作用して前記ディスプレイ・デバイスを制御するオペレーティング・システムと、共有データ・エリアを持ち、前記複数のウィンドウの１つの可視エリアが変更されると、当該複数のウィンドウの他のウィンドウの可視エリアを変更するウィンドウ・マネージャ・オブジェクトと、前記複数のアプリケーション・プログラムの各々によって作成され、前記複数のウィンドウの１つと関連づけられているウィンドウ・オブジェクトであって、関連の１つのウィンドウの可視エリアのコピーをストアするキャッシュ・メモリを含むウィンドウ・オブジェクトとを具えたことを特徴とするコンピュータ・システム。２６．前記情報はウィンドウ・オブジェクトと前記ウィンドウ・マネージャ・オブジェクトとの間でデータ・ストリーム・オブジェクトによって情報がストリーム化されることを特徴とする請求項２５に記載のコンピュータ・システム。２７．前記ウィンドウ・オブジェクトは前記複数のアプリケーション・プログラムの１つから要求を受け取るメカニズムと、当該受け取った要求に応答して、前記複数のウィンドウの１つの可視エリアを、前記複数のアプリケーション・プログラムの要求を行なった１つへ引渡す装置とを含むことを特徴とする請求項２５に記載のコンピュータ・システム。２８．ウィンドウ・オブジェクトは前記複数のアプリケーションの１つからの要求に応答して、前記ウィンドウ可視エリアのコピーの有効性を判断する装置を含むことを特徴とする請求項２５に記載のコンピュータ・システム。２９．前記ウィンドウ・マネージャ・オブジェクトは、前記ウィンドウ可視エリアが最後に再計算されたときの時刻を示す第１タイムスタンプを前記各ウィンドウ可視エリアと一緒にストアする装置を含み、前記ウィンドウ・オブジェクトは、前記可視エリアのコピーが前記キャッシュ・メモリにストアされたときの時刻を示す第２タイムスタンプをキャッシュ・メモリにストアする装置を含むことを特徴とする請求項２８に記載のコンピュータ・システム。３０．前記有効性判断装置は、選択されたウィンドウ可視エリアについての前記アプリケーション・プログラムからの要求に応答して、前記第１タイムスタンプをウィンドウ・マネージャ・オブジェクトから取り出す装置と、当該取り出した第１タイムスタンプを前記キャッシュ・メモリにストアされた第２タイムスタンプと比較する装置とを含むことを特徴とする請求項２９に記載のコンピュータ・システム。３１．前記有効性判断装置は、前記キャッシュ・メモリにストアされた可視エリアが前記ウィンドウ・マネージャ・オブジェクトによる最後の再計算の前にストアされたことを前記タイムスタンプ比較装置が示しているとき、当該ウィンドウ可視エリアを前記ウィンドウ・マネージャ・オブジェクトから取り出す手段をさらに含んでいることを特徴とする請求項３２に記載のコンピュータ・システム。３２．その各々がエクステント・エリアを持ち、デスクトップ・バックグランド上に表示される複数のオーバラップしたウィンドウの可視エリアを計算するウィンドウ・マネージャ装置において、前記複数のウィンドウをあらかじめ決めた前面から後面までの順序で管理するための配列リストを含むウィンドウ・リスト・オブジェクトと、配列リスト情報を前記ウィンドウ・リスト・オブジェクトから得るためのリスト要求メカニズムと、前記配列リスト情報に応じて、前記複数のウィンドウの１つの可視エリアがオリジナル・エリアから新しいエリアに変更されると、前記１つのウィンドウの手前に配列されたすべてのウィンドウのエリアの合体(union)を計算する装置と、前記ウィンドウのオリジナル・エリアと該ウィンドウの新エリアに応じて、当該オリジナル・ウィンドウ・エリアと新ウィンドウ・エリアとの排他的ＯＲをとって変更エリアを計算する変更エリア装置と、前記ウィンドウの１つの背後に配列されたウィンドウの可視エリアを再計算する再計算装置とを具えたことを特徴とするウィンドウ・マネージャ装置。３３．前記再計算装置は変更エリアに応じて、変更エリアと、前記ウィンドウの１つの背後にある、配列リスト内の次のウィンドウのエクステント・エリアとの排他的ＯＲをとる可視エリア調整装置と、前記次のウィンドウのエクステント・エリアを該変更エリアから減算することにより該変更エリアを調整する変更エリア調整装置とを含むことを特徴とする請求項３２に記載のウィンドウ・マネージャ装置。３４．アプリケーション・プログラムがデスクトップ・バックグランド上に表示される複数のウィンドウ・エリアの内の１つにスクリーン情報を表示するための方法であって、該複数のウィンドウ・エリアの各々は変更可能な可視エリアを持つ方法において、Ａ．共有データ・エリアを持ち、１つのウィンドウの可視エリアが変更されると、少なくとも１つの他のウィンドウの可視エリアを変更するウィンドウ・マネージャ・オブジェクトを作成するステップと、Ｂ．前記アプリケーション・プログラムに前記複数のウィンドウ・エリアの内の１つのストアされた可視エリアを前記ウィンドウ・マネージャから要求させるステップと、Ｃ．前記アプリケーション・プログラムに前記スクリーン情報を、前記ウィンドウ・マネージャから得た可視エリアにだけ表示させるステップとを含むことを特徴とする方法。３５．前記ウィンドウ・エリアはオーバラップしていて、前面から後面への配列を持つように視覚的に表示され、前記ステップＡは、Ａ１．前記複数のウィンドウの各々を配列リスト内で管理するウィンドウ・リスト・オブジェクトを作成し、該配列リストは複数のリスト位置を持つステップであって、前記各リスト位置は前面から後面への配列内の位置に対応しているステップを含むことを特徴とする請求項３４に記載の方法。３６．前記ステップＢは、Ｂ１．前記複数のウィンドウの各々に関連づけられたウィンドウ・オブジェクトを作成するステップであって、前記各ウィンドウ・オブジェクトがウィンドウ・データおよびウィンドウ関数を含み、ならびに前記アプリケーション・プログラムによって作成されるステップと、Ｂ２．ストアされた可視エリアを前記ウィンドウ・オブジェクトに要求させるステップとを含むことを特徴とする請求項３４に記載の方法。３７．前記ステップＢ２は、Ｂ２Ａ．要求情報を前記各ウィンドウ・オブジェクトと前記ウィンドウ・マネージャ・オブジェクトとの間でデータ・ストリーム・オブジェクトによって転送するステップを含むことを特徴とする請求項３６に記載の方法。３８．前記ステップＢ２は、Ｂ２Ｂ．前記ウィンドウ・オブジェクト内にストアされた可視エリアのキャッシュ・コピーを管理するステップと、Ｂ２Ｃ．前記ウィンドウ・オブジェクト内のキャッシュ・コピーをチェックしてから前記ストアされた可視エリアのコピーを前記ウィンドウ・マネージャ・オブジェクトに要求するステップとを含むことを特徴とする請求項３６に記載の方法。３９．前記ステップＢ２は、Ｂ２Ｄ．前記可視エリアが再計算されたときの時刻を示す第１タイムスタンプを前記各ウィンドウ可視エリアと一緒に共有データ・エリアにストアするステップと、Ｂ２Ｅ．前記キャッシュ・コピーが前記ウィンドウ・オブジェクトにストアされたときの時刻を示す第２タイムスタンプを前記ウィンドウ・オブジェクトにストアするステップとを含むことを特徴とする請求項３８に記載の方法。４０．ステップＢ２は、Ｂ２Ｆ．前記ウィンドウ可視エリアについてアプリケーション・プログラムから要求を受け取ったとき、選択したウィンドウ可視エリアと一緒にストアされた前記第１タイムスタンプを前記ウィンドウ・マネージャ・オブジェクトから取り出すステップと、Ｂ２Ｇ．当該取り出した第１タイムスタンプを前記ウィンドウ・オブジェクトにストアされた第２タイムスタンプと比較するステップとを含むことを特徴とする請求項３９に記載の方法。４１．前記ステップＢ２はさらに、Ｂ２Ｈ．前記ステップＢ２Ｇのタイムスタンプ比較が前記ウィンドウ・オブジェクトにストアされたキャッシュ・コピーが有効でないことを示しているとき、前記ウィンドウ・マネージャ・オブジェクトにストアされたウィンドウ可視エリアを取り出すステップを含むことを特徴とする請求項４０に記載の方法。４２．その各々がエクステント・エリアを持ち、デスクトップ・バックグラウンド上に表示される複数のオーバラップしたウィンドウの可視エリアを計算する方法において、Ａ．前記複数のウィンドウを前面から後面へのあらかじめ決めた順序で管理するための配列リストを含むウィンドウ・リスト・オブジェクトを作成するステップと、Ｂ．配列リスト情報を前記ウィンドウ・リスト・オブジェクトから取得するステップと、Ｃ．前記複数のウィンドウの１つの可視エリアがオリジナル・エリアから新エリアに変更されると、当該１つのウィンドウの手前に配列されたすべてのウィンドウのエリアの合体を計算するステップと、Ｄ．前記オリジナル・ウィンドウ・エリアと前記新ウィンドウ・エリアとの排他的ＯＲをとって変更エリアを計算するステップと、Ｅ．前記１つのウィンドウの背後に配列されたウィンドウの可視エリアを再計算するステップとを含むことを特徴とする方法。４３．前記ステップＥは、Ｅ１．変更エリアと、前記配列リスト内で前記１つのウィンドウの背後にある次のウィンドウのエクステント・エリアとの排他的ＯＲをとるステップと、Ｅ２．前記次のウィンドウのエクステント・エリアを前記変更エリアから減算することによって当該変更エリアを調整するステップと、Ｅ３．該１つのウィンドウの背後にある各ウィンドウごとに前記ステップＥ１および前記Ｅ２を繰り返すステップとを含むことを特徴とする請求項４２に記載の方法。