JPS62298882A - マルチ・ウィンドウ表示システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ３、発明の詳細な説明 Ａ、産業上の利用分野 本発明は、一般に、コンピュータおよびデータ・プロセ
ッサ・システムで通常使用されている陰極線管（ＣＲＴ
）、ガス・パネル、液晶ディスプレイ（ＬＣＤ’）、お
よび他の同様なディスプレイ上に多数のデータ・ウィン
ドウを表示する、マルチ・ウィンドウ表示システムに関
するものである。本発明の主な応用例は、各ウィンドウ
が種々なタスクのうちのそれぞれ異なる１個のタスクか
ら得られるデータを表示する、マルチ・タスク・コンピ
ュータ環境である。

Ｂ、従来技術および問題点 ラスク走査型ＣＲＴ用のビデオ・データを発生させる方
法は良く知られている。ＣＲＴ制御装置を使って、表示
リフレッシュ・バッファ用の記憶アドレスを発生させる
。この制御装置とバッファとの闇に設けられたセレクタ
を用いて、アドレスを交互に発生させ、リフレッシュ・
バッファの内容を変更できるようにする。したがって、
このセレクタは、制御装置からのリフレッシュ・アドレ
ス、またはシステム・アドレス母線上のアドレスを表示
リフレッシュ・バッファへ送給することができる。リフ
レッシュ・バッファのバンド幅を時分割多重化（ＴＤＭ
）することによって、リフレッシュとシステム・アクセ
スの闇の干渉をなくすることができる。英数字用のディ
スプレイでは、表示リフレッシュ・バッファに通常、文
字コード・ポイントおよびそれと関連する属性用の記憶
装置が設けられている。文字コード・ポイントを利用し
て文字画素発生器にアドレスする。この文字発生器から
の出力は、ＣｒｔＴ制御装置からの走査ライン・カウン
ト出力と同期して発生される。反転ビデオ、ブリンク、
アンダースコア等の属性機能が属性ロジックから文字発
生器の出力に与えられ、その結果書られる画素が直列化
されてビデオ・モニタに供給される。

多数のオペレーティング・システム（Ｏ８）プログラム
および適用プログラムが、コンピュータに多数のタスク
を同時に実行させる。たとえば、背景データ処理タスク
を前景ワード処理タスクと一緒に実行することができる
。この背景データ処理タスクに関係するタスクは、デー
タ処理タスクで発生させたデータからパイまたはパーチ
ャートを発生させる、グラフィック生成タスクである。

これらすべてのタスク内のデータを組み合わせて、１つ
のドキュメントを作成できる。マルチ・タスク動作は、
現在市場に出廻っているポピユラーなマイクロコンピュ
ータなどの単一のコンピュータ、または、ホスト・コン
ピュータに接続されたマイクロコンピュータによって実
行できる。後者の場合、一般に、ホスト・コンピュータ
で背景データ処理機能を行ない、マイクロコンピュータ
で前景データ処理を行なう、複合表示リフレッシュ・バ
ッファを形成することにより、このシステムで、多数の
′タスクからウィンドウを表示することもできる。これ
らのタスクは、それぞれ他のタスクから独立し、システ
ム・メモリ中で重なり合わないスペースを占めている。

システム・メモリ中に存在するタスクに対してユーザが
定義できるウィンドウを構成して、処理中の各タスクの
データを、スクリーン・サイズによって課される限界内
で表示することができる。ユーザの見通しに基づいて、
これらのウィンドウは、重なり合わないように、または
層状に、または重なり合うように表示することができる
。重ね合せ表示によって、システム・メモリ内のデータ
が失われることはない。各タスクごとにデータを保存す
る必要があるので、隠れたウィンドウをディスプレイ・
スクリーン内で、またはこのディスプレイ・スクリーン
から移動させるとき、リフレッシュ・バッファを更新す
ることによって下側の表示データを見ることができる。

上述の基本的インプリメンテーションは、ある種の用途
には十分であるが、ディスプレイ・ウィンドウおよびタ
スクの数が増加したり、ディスプレイ・スクリーンのサ
イズが増大する場合、性能が制限されることがある。表
示リフレッシュ・バッファを更新するのに必要な時間が
かなり増加すると、システムの応答時間が増加し、この
結果、スループットが減少するようになる。以下に説明
する要因によって、システムの応答時間が遅くなる。

（１）ディスプレイ・スクリーンに対してウィンドウ処
理されるシステム・メモリ内の位置をタスクが更新する
ごとに、表示リフレッシュ・バッファを更新する必要が
ある。制御ソフトウェア、通常はＯ８（オペレーティン
グ・システム）でこの状態の発生を監視し検出する必要
がある。

（２）１つまたは複数のディスプレイ・ウィンドウ内で
データをスクロールするためには、更新すべき表示リフ
レッシュ・バッファ内に対応する位置が必要である。こ
のことは第３図を参照することによって容易に理解でき
る。この図には、重なり合わないウィンドウの場合が示
されている。このスクロール動作は、システム・メモリ
内で可視ウィンドウを移動させることにより実行される
。重なり合ったウィンドウ内のデータをスクロールする
場合、対応する技術が使用される。

（３）ウィンドウのサイズまたは位置が変更されるとき
、表示リフレッシュ・バッファをシステム・メモリに対
して適当な位置で更新する必要がある。

このような問題点を解決する一方法として、ＥＰＣ（欧
州）公開特許公報第１４７５４２号には、以下の方法が
提案されている。すなわち、繰返し走査型の表示装置と
、この表示装置の表示域に直接マツピンクされた表示デ
ータ・エレメント位置を有するスクリーン・バッファと
、表示装置の表水域を走査する動作に同期して表示デー
タ・エレメント位置を走査するアクセス手段と、個々の
ユーザが独立して発生させた複数個のつオンドウから表
示すべきデータ・エレメントの集合をコンパイルするた
めの機能を備えた、マルチ・ウィンドウ表示システムを
設ける。このマルチ・ウィンドウ・ディスプレイ・シス
テムは、表示装置の表示域に直接マツピンクされたコン
パイル制御位置を有するピクチュア・マトリックスによ
って、このコンパイル機能が制御され、さらに、このコ
ンパイル機能が、制御位置の内容に直接応答し、種々の
ウィンドウから利用できるデータ・エレメントを表示域
ごとに自動的にフィルタ処理することを特徴とする。

ここで、′ユーザの語は、タスク、プロセッサ、または
オペレータまで含むものと拡大解釈するものとする。そ
の理由は、ディスプレイに対して、これらの間には、明
確な差異が存在しないからである。

そのハードウェアおよびソフトウェアの構成について説
明する。ハードウェア・インプリメンテーションについ
ては、複数のスクリーン・バッファを循環的に同時に読
み出し、タスク選択手段によってこれらバッファの１つ
の出力を任意の時間にビデオ出力と結合する。スクリー
ン上の任意のポイントについて、表示されるデータは選
択されたバッファから生じるものであり、このバッファ
は、複数のスクリーン・バッファからコンパイルさせた
スクリーン・ピクチュアを発生する全体構成に適してい
る。このタスク選択手段を、別々のタスク選択バッファ
とデコーダとすることもでき、この場合、タスク選択バ
ッファはスクリーン・バッファと同期してアドレスされ
、デコーダは、ディスプレイ・スクリーンの任意のポイ
ントについしてスクリーン・バッファの１つを読み出す
ことができる。別法として、これらスクリーン・バッフ
ァの１つを指定して、タスク選択バッファの動作を実行
させることもできる。指定されたスクリーン・バッファ
内の表示データは、所定のスクリーン位置に対応する位
置で、このスクリーン位置用の表示データのために使用
という意味で、弊透過データである。その理由は、この
バッファ位置に、この位置用のデータを取り出すべき他
のバッファの１つを示すために使用される一義的選択コ
ードがロードされるからである。アクセスされた非透過
バッファ位置にこれら選択コードの１つが存在しないと
、この位置にあるデータが、対応するスクリーン位置に
省略待状態として表示されるようになる。このようにし
て、表示が、一部はデータから、一部は非透過バッファ
から、さらに一部は他のスクリーン・バッファからどの
ようにしテ編集されるかが明らかになる。

ソフトウェア・インプリメンテーションは、システム・
メモリを広く利用したものである。システム・メモリは
、表示可能域の複数のウィンドウ用の適用データを受は
取るためのプレゼンテーション・スペースをもたらす。

各ウィンドウが対応するプレゼンテーション・スペース
の全体またはサブセットを定義する。ディスプレイ・ス
クリーンに対してマツピンクされたウィンドウ優先順位
マトリックスが、プレゼンテーション・スペースのウィ
ンドウからスクリーン・バッファにデータをフィルタ処
理して、どのデータをディスプレイ・スクリーンの対応
する位置に表示するかを指定する。ハイブリッド・バー
ジョンでは、ディスプレイ・データのフィルタ処理は、
スクリーン・バッファにロードする際にも、このような
データが複数設けられているスクリーン・バッファから
選択的に読み出す際にも実行できる。

現在、あるタスクがその従属タスクを発生させ、それら
の従属タスクがそれ自体の従属タスクを発生させるタス
ク構造が可能であり、がっ、ウィンドウ・フレームおよ
びウィンドウ・パックグラウンドを形成する機能を、表
示すべき実際のデータを供給する機能、およびウィンド
ウ内の種々のデータが未知のデータがあたかも異なるウ
ィンドウ内に存在しているかのようにこれらデータを処
理する機能から分離することが可能であるが、十分な量
のハードウェア・スクリーン・バッファを設けることは
実際上問題あり、またウィンドウ優先順位マトリックス
を使用したり維持することは、前述の手順に従う場合、
極めて大きな処理上の負担となってしまう。

Ｃ９問題点を解決するための手段 本発明の目的は、ウィンドウの優先順位定義を極めて簡
単に使用したり維持できるように構成された、マルチ・
ウィンドウ・ディスプレイ・システムを提供することで
ある。

したがって、本発明は、表示装置と、表示装置の各表示
域に対するデータに寄与するウィンドウの識別子を指示
する画面所有権域即ち割り当て領域とを有するマルチ・
ウィンドウ・ディスプレイ・システムを提供する。この
マルチ・ウィンドウ・ディスプレイ・システムは、その
優先順位の順に配列された、アクティブ・ウィンドウの
リストが維持され、装置の表示域当りのリスト位置に関
してこのリストに変更が加えられると、このリストを優
先順位の低いものから重ね書きして進めて行くことによ
って、このリストから画面所有権域即ち割り当て領域を
再形成する手段が設けられ、このリストは、その各位置
で、当該の優先順位を有するウィンドウの識別子を示す
ことを特徴とするものである。

したがって、このウィンドウの優先順位の定義は、リス
トの更新とこのリストからの画面所有権域の再生の組合
せによって維持される。

後述するように、ウィンドウの優先順位は、どの位最近
に使われたか、および既存タスクの階層内でのこのウィ
ンドウの位置に応じて決まる。特定のタスク・ウィンド
ウ内に変化が生じたり、このウィンドウと通信が行なわ
れたり、あるいは単にこのウィンドウを見る必要があっ
たために、この特定のウィンドウがアクティブになると
、このウィンドウは最も高い優先順位を持つようになり
、したがってリストの先頭に来ると言うことができる。

このウィンドウに関連するタスクが従属タスクであり、
したがって、タスクの階層のあるブランチのメンバーで
ある場合、このブランチに関連するすべてのタスクは、
優先順位が上がり、特定のタスクが、シフトされたタス
ク・グループの先頭に行く点を除けば相対的に同じ優先
順位を保持しながら、リストの先頭へ移動するようにな
る。

アクティブでないウィンドウは、このリストには現われ
ない。

このリストは、ウィンドウの記憶されたデータ形式の制
御ブロックの記憶装置中でのアドレスを含み、さらに、
このデータの特性、すなわち、ウィンドウ・フレーム、
ウィンドウ・パックグラウンドまたはデータ・タイプ（
グラフィック、テキスト等）の指示を含んでいる。また
、画面所有権域には、表示データ域当り１つの記憶バイ
トが含まれているので、８ビツトのバイトであれば、こ
の画面所有権域中に記憶すべきものは、すべて対応する
リスト位置の指示なので、最大限２５５個までのアクテ
ィブなウィンドウが存在できる。また、このリスト位置
は記憶装置内のウィンドウのデータ形式の制御ブロック
中にも記憶される。

画面所有権域の更新は、必要な情報が与えられるので比
較的直接的である。たとえば、処理すべきリストの最新
レベルに、ウィンドウの寸法を得るために向かうべきア
ドレスがあり、このウィンドウの性質が、明らかにリス
ト中に含まれており、リストで定義されるウィンドウが
、対応する画面所有権域に含まれるすべてのウィンドウ
に置き換わる。スクリーンの幅全体が間係するが、通常
の状況の下ではその一部分が行であると予想される場合
には、画面所有権域即ち割り当て領域の更新を１回の操
作で行なうことができる。

Ｅ、実施例 前述の構成は、従来技術によるものであれ、あるいは本
発明によるものであれ、ＣＲＴディスプレイで使用する
ためのものである。ただし、ＣＲＴディスプレイは、ガ
ス・パネルや液晶ディスプレイなど、本発明が適用でき
る種々のタイプのディスプレイのうちの一種にすぎない
。したがって、当業者にとって容′易に理解できるよう
に、本例で説明するＣＲＴディスプレイは、単に一例に
すぎない。したがって、′リフレッシュ・バッファ″の
語は、ＣＲＴディスプレイに適用するときは特定の意味
をもつものの、表示すべきデータを記憶するハードウェ
アまたはソフトウェアのスクリーン・バッファと完全に
等価なことになる。　本発明は、最新のスクリーン保管
域を維持するためのもので、この保管域は本明細書で引
用し、その第１図および第２図に図示した従来技術のス
クリーン・マトリックスと１ａ接に等価である。この従
来技術に関する詳細な説明は、前述のＲＰＣ公開特許広
報に出ている。また、本発明は、組み込まれたスクリー
ン・バッファの数には無関係である。

また、参照した従来技術が、本願の第２図に関係してい
るので（従来例の第７図）、便宜上その抜粋を再掲する
。

本願の第２図に示した従来技術では、２個の独立したハ
ードウェア・バッファ１２１および１２２のみが用いら
れている。ただし、均質なシステムメモリの定義済み区
域が広く使用され、また、やはりスクリーン・マトリッ
クス（４０、メモリ中に保持されている）によって決定
されるフィルタ処理機能は、従来の実施例（ＲＰＣ公開
特許広報１４７５４２号）と同様に、これらバッファの
１つに何をロー°ドさせるか（相対的に言うと、「ワン
タイム機能」）および、２つのバッファのどちらがスク
リーンに現在の出力を供給させるかの選択に分割される
。その効果は同じである。操作用メモリ中では、もっと
多くの作業が行なわれるが、それは実行の頻度が低下す
るために相殺される。

図に示した特定の場合には、ホスト・コンピュータに接
続されたマイクロコンピュータは、バッファ１２２がマ
イクロコンピュータ・バッファであるものと仮定される
。しかし、当業者なら容易に理解できるように、システ
ム・メモリに十分に余裕がある場合には、スクリーン・
マトリックスの制御下でのプリバッファ・フィルタ処理
を、単一バッファを有する単一コンピュータにも適用で
きる。

図に示すように、このインプリメンテーションでは、ス
クリーン制御ブロック３２、ウィンドウ制御ブロック３
４、プレゼンテーション・スペース制御ブロック３６、
プレゼンテーション・スペース３８およびスクリーン・
マトリックス４０が用いられる。たとえば、１０個のス
クリーン制御ブロックと１０組のウィンドウ制御ブロッ
クが、各スクリーン・レイアウトごとにそれぞれ１つず
つある。どのスクリーン制御ブロック３２も、対応する
１組のウィンドウ制御ブロック３４を指示する。各プレ
ゼンテーション・スペース３８は、スクリーン・レイア
ウト１つ当り少なくとも１個のウィンドウを備えている
。プレゼンテーション・スペースは、すべてのスクリー
ンに対して共通であるが、ウィンドウはそうではない。

スクリーン・レイアウト内のどのプレゼンテーション・
スペース３８に対応するウィンドウ制御ブロック３４も
、プレゼンテーション・スペース内のウィンドウの原点
（左上隅）を定義すると共に、プレゼンテーション・ス
ペース内のそのウィンドウの幅と高さ、さらに、ディス
プレイ・スクリーン上のウィンドウの原点を定義する。

スクリーン・マトリックス４０は表示すべきデータのマ
ツプであり、一実施例によれば、このマトリックス４０
は、文字ごとに１対１で、どれをＣＩｔＴスクリーン上
に表示すべきかをマツプするが、このようなマツピンク
は、画素ごとにまたは他の基準で行なうこともできる。

複数タスクからのディスプレイ出力のすべてがメモリに
送給される。具体的に言うと、ハードウェア・リフレッ
シュ・バッファではなくてプレゼンテーション・スペー
ス３８に送給される。第２図の構成では、たとえば、Ｉ
ＢＭ（登録商標）パーソナル・コンピュータ（ＰＣ）を
、１８Ｍ３２７４制御装置などの制御装置を介して、１
８Ｍ３２７０コンピユータなどのホスト・コンピュータ
に取り付けるものとする。この場合、ＰＣハードウェア
・バッファ１２゜は、ＰＣプレゼンテーション・スペー
スとして機能する。各プレゼンテーション・スペースは
、識別タグを割り当てられ、また、サイズやスクリーン
内での位置に関してオペレータや適用プログラムが定義
する、関連するウィンドウを備えている。オペレータや
適用プログラムがこれらつ、イントウを互いに調整する
と、このシステムは、適当な位置に整列された識別タグ
から構成されるスクリーン・マトリックス４０内に、イ
メージを形成する。また、このマトリックス４０を、Ｃ
ＲＴスクリーン上で表示される順序とは逆の順序で形成
することもできる。こうすると、オーバーラツプするウ
ィンドウが重ね書きによって形成できるようになる。別
法として、比較機能を使って、−容土のウィンドウから
始めてオーバーレイまで次々に下ることによって、この
マトリックス４０を形成することもできる。マトリック
ス４０を形成する方法は、所望のシステムの性能に応じ
て選択できる。このシステムは、すべてのスクリーン更
新をスクリーン・マトリックス４０を介してフィルタ処
理することにより、ディスプレイ出力をリフレッシュ・
バッファに送給する。こうすると、スクリーン上で実際
に変更または表示すべき文字のみを、リフレッシュ・バ
ッファに到達させることにより、オーバーラツプしたウ
ィンドウ・システム内で性能を向上させることができる
。現在必要でない文字は、このリフレッシュ・バッファ
に到達せず、不必要な再作図を生じさせない。このよう
な不必要な再作図が起こらないため、１つのウィンドウ
の内容が変更されたとき、すべてのウィンドウを絶えず
更新する必要がなくなる。

文字を書くには、１８Ｍ３２７４制御装置、監視適用プ
ログラムまたはＰＣが、文字コードをプレゼンテーショ
ン・スペース３８に書き込む。その書込み位置は、この
プレゼンテーション・スペース３８のカーソル値制御ブ
ロックによって指定される。他の更新は不要である。す
なわち、この文字が、対応するウィンドウ制御ブロック
３４によって指定されたウィンドウおよび、そのウィン
ドウのスクリーン・マトリックス４０によって表示のた
めに指定された部分内に含まれるか否かに応じて、新し
い文字が表示されたり表示されなかったりする。ＰＣバ
ッファ１２２を使用するには、他のウィンドウ・ブロッ
ク３４と同様にＰＣ用のウィンドウ制御ブロックを確立
する。この制御ブロック３４は、幅、高さ、プレゼンテ
ーション・スペース原点およびスクリーン原点を含んで
いる。スクリーン・マトリックス４０が更新され、ウィ
ンドウ制御ブロック３４によって定義されるＰＣバッフ
ァ中のウィンドウからのデータが、スクリーン・マトリ
ックス４０の許容する範囲内で、ＣＲＴスクリーン」二
に表示される。ウィンドウ内のデータは、ウィンドウ原
点のＹ値またはＹ値を減分または増分させることによっ
てスクロールできる。他の制御更新は不要である。スク
リーン・バッファ中の対応するウィンドウのみを書き替
えるか、または、ＰＣウィンドウの場合、オフセット・
レジスタを変更するだけでよい。ウィンドウ用のウィン
ドウ制御ブロック３４中の原点の座標を変更することに
より、ウィンドウをスクリーン上で再配置することがで
きる。スクリーン・マトリックス４０を更新して、非Ｐ
Ｃスクリーン・バッファ全体を、非ＰＣタスク用データ
およびＰＣ用コード（１６進数ＦＦ）で再書き込みする
。スクロールを行なわずにプレゼンテーション・スペー
スの可視部分を拡大するには、まずこのプレゼンテーシ
ョン・スペース３８用のウィンドウ制御ブロック３４を
、その輻または高さあるいはその両方を変更することに
よって更新する。ウィンドウの原点が変化しない場合、
これはウィンドウの右または下２１一 端のみに追加される。通常、プレゼンテーション・スペ
ースまたはスクリーンからのあぶれが存在しない限り、
原点は変化しない。あぶれがある場合は、対応する原点
が変更される。次に、優先順位が最も低いウィンドウ制
御ブロックから順にマトリックスのウィンドウ指定コー
ドを重ね書きすることによって、スクリーン・マトリッ
クス４０を更新する。次に、非ＰＣリフレッシュ・バッ
ファ１２１に対するすべてのウィンドウを、非ＰＣウィ
ンドウ用のプレゼンテーション・スペースからのデータ
、およびＰＣウィンドウ用の１６進コードＦＦで再書き
込みする。

このような状況において、スクリーン・マトリックスを
維持するために必要な努力は、タスク構造の複軸さに正
比例する。このような努力は、汎用記憶装置に配置でき
るので、以下ではスクリーン所有権域即ち割り当て領域
と呼ぶことにする。次に、本願の第１図に示したシステ
ム構造について考察する。論理的に考えると、このシス
テムは、１個の実装置、すなわちスクリーン自体を備え
ている。スクリーン操作に関する限り、実タスクが１つ
存在し、それはスクリーン上で必要な内容を表示するタ
スクである。この目的のためにメイン・タスク・マネー
ジャが存在し、これは、第２図の環境では、スクリーン
制御ブロック３２を取り扱う。潜在的に多数の従属タス
クが、それぞれそれ自体のタスク・マネージャを有し、
それ自体の個々のウィンドウ制御ブロックおよびプレゼ
ンテーション・スペース制御ブロックを維持している。

それらのタスク・マネージャは、あたかもスクリーン全
体を所有しているかのように動作する。実際、それらの
従属タスクは、それぞれ仮想装置を操作する。あるいは
、従属タスクがそれ自体に従属する別のタスクを生成す
ることが可能でない場合ならば、そうなるはずである。

こうして、第３図を見るとわかるように、タスクの階層
が形成される。

実装置およびそのタスク・マネージャが、この階層の頂
点にあり、ウィンドウ１、ウィンドウ２およびウィンド
ウ３によって示される第１段のブランチは、実装置、す
なわち、スクリーン上に表示される内容を供給する。同
様に、ウィンドウ２は、ウィンドウ２．１．２．２およ
び２．３で表示されるそれ自体の従属タスクをサポート
するように分割される。このウィンドウ２は、ウィンド
ウ２゜１．２．２．２．３によって供給される内容を示
−すだけである。あるいは、ウィンドウ２だけが実タス
ク・マネージャにアクセスできる場合なら、そうなるは
ずである。しかしながら、ウィンドウ２は、ウィンドウ
１および３と争奪しなければならない。従属タスクでは
なく、ターミナル仮想装置のみが、実装置の所有権を争
奪するのであり、したがって図のように、ウィンドウ２
自体は、ディスプレイ用の候補でなく、ウィンドウ１．
２．１．２．２．２．３および３だけが候補となること
に注意すべきである。

ウィンドウは、ウィンドウが存在するためではなく、シ
ステム外部のユーザまたは処理によってウィンドウが呼
び出されるためにウィンドウがここで使用されるという
意味で、アクティブになる。

最も最近に呼び出されたウィンドウが、現在量も優先順
位の高いウィンドウであり、スクリーンの所有権に関す
る限り、一番の優先順位を有する。

すなわち、ウィンドウ２．３が呼び出されてアクティブ
になると、ウィンドウ２はそれ自体は表示されないが、
ウィンドウ１や３よりも優先順位が上になる。しかし、
ウィンドウ２はウィンドウ２゜１．２．２ならびにウィ
ンドウ２．３から構成されているので、これら２つの兄
弟ウィンドウもウィンドウ２．３はどではないが優先順
位が上がる。

ウィンドウは、一度呼び出されると、特に廃棄されるま
で、アクティブのままとなる。すなわち、上記の試況で
は、ウィンドウ２．３が廃棄されても、ウィンドウ２．
１および２．２は優先順位が高いままである。このこと
から明らかなように、ウィンドウが呼び出されるごとに
、スクリーン所有権域を再構成し、ウィンドウ階層を処
理するのは、特に、多数のターミナル仮想装置を収容で
きることが狙いであるため、たちまち非現実的となるこ
とがありうる。

本発明によれば、このような問題点を克服するため、第
４図ないし第６図に示すようなシステムによって、所有
権優先順位リストが維持される。

このリストは、ブツシュダウン・スタックであり、これ
から中間項目を除去したり、差し替えることができる。

リストＰＭ（ただしＭは１．２．３・・・）中の項目の
位置は、このスクリーン所有権域で操作を行なう際の１
つの制御因子である。リスト位置の個々の内容が、第２
の制御因子である。各リスト位置は、その優先順位を有
するタスクＮによって定義されるウィンドウＮに対応す
るウィンドウ制御ブロックＷＣＢＮのアドレスＣＢＮを
含んでいる。ウィンドウのタイプＫＮ、すなわちパック
グラウンド、フレームその他の標識もアドレスＣＢＮと
一緒に含まれる。ウィンドウ制御ブロックによって、こ
のウィンドウのサイズと原点が定義されているので、こ
のウィンドウが要求する実際のスクリーン域が、さらに
調査することなく得られるようになる。このリスト位置
ＰＭがウィンドウ制御ブロックＷＣＢＮ中に書き込まれ
る。

リスト位置ＰＭは、そのＰＭが利用できる最も重要なリ
スト位置となっているスクリーン制御域の各表示データ
域中に書き込まれる。

第４図の矢印は、関係を示すものである。ウィンドウＮ
が唯一のアクティブ・ウィンドウである場合、Ｍは１に
等しく、ウィンドウＮがスクリーン上で表示される唯一
のウィンドウとなり、スクリーン所有権域の対応するデ
ータ域がそれぞれＰｌを含むことになる。

残りの図は、略図のような形で示されている。

これらの図は、互いに極めて類似しているので、第５Ａ
図のみを詳細に取り扱うことにする。

第５Ａ図は、タスクＴ１、Ｔ２．１、Ｔ２．２、Ｔ２．
３およびＴ３用のプレゼンテーション・スペースを示す
。便宜上、これらのスペースはそれぞれ、スクリーンの
サイズで示してあり、その当該の位置に、対応するウィ
ンドウｗ１、ｗ２．１、Ｗ２．３およびＷ３が示されて
いる。また、優先位置Ｐ１のみを有するリストと、生デ
ータ域内のリスト位置に記号で表わしたスクリーン所有
権域と、このスクリーン所有権域と図のウィンドウ構成
とに対応するスクリーン・ディスプレイも示されている
。図の種々の部分間の接続は、すべて論理的なものであ
る。このリスト位置は、ＷＣＢアドレスおよびそのリス
ト位置が関係するウィンドウのタイプ標識Ｋを含むのに
十分な大きさである。

スクリーン所有権データ域セルは、実際には、スクリー
ン・データ域当り１つであり、十分には表示されていな
いが、それぞれバイト・サイズであり、Ｍが１６進数’
ＦＦ’　　（“Ｆ″と略記）に対応する最大（優先順位
が最も低い）値をとることができる。

この第５Ａ図では、Ｔ３のみがアクティブであると仮定
されている。したがって、このリストは、Ｃ８４および
、対応するその位置Ｐ１のＫを含んでいる。スクリーン
所有権域のセルは、すべて可能な最高（優先順位が最低
）の値であるＦにセットされる。その後、制御ブロック
ＣＢ３にアクセスして、ウィンドウＷ３のサイズと位置
が決定され、このサイズとウィンドウ位置に対応するス
クリーン所有権域のセルがそれぞれ１″にセットされる
。他のウィンドウがアクティブではないので、他の処置
は不要であり、ディスプレイを生成するための通常の機
構が働いて、図には示されていないＴ３によって記憶装
置中で定義され、スクリーン・バッファへ転送された、
ウィンドウＷ２３のみを表示するスクリーンを生成する
。

次に、第５Ｂ図に移るが、ここでは、Ｔ２．３がすでに
アクティブになっているものと仮定する。

Ｐｌの内容がこの目的のために生成されたＰ２にブツシ
ュダウンされており、Ｔ２．３に該当する項目がＰｌ中
に入力されていることが図かられかるはずである。スク
リーン所有権域のセルは、この場合もすべて′Ｆ″にセ
ットされる。リストの最高（優先順位が最低）の占有さ
れた位置Ｐ２に該当するセルが１“２”にセットされ、
その後、次に低い（優先順位が高い）値のリスト位置に
相当するスクリーン所有権域のセルが“１”にセットさ
れ、そこにあった内容が何であれそれを重ね書きする。

セルの内容の性質およびそれから生成されたスクリーン
・ディスプレイが示される。

次に、第５Ｃ図、第５Ｄ図および第５Ｅ図では、Ｔ２．
２、Ｔ２．１およびＴ１が順次アクティブになるのを表
示するために必要なものが追加されている。各繰返しの
際に、スクリーン所有権域の“セルがまず゛Ｆ”にセッ
トされ、リストが、優先順位の大きさが低い順に最後ま
で走査される。

次に、第６図では、とのＴも削除されていない状態で、
Ｔ２．３を再び呼び出すものと仮定する。

このＴ２．３をリストの最上部に移さなければならない
。ただし、Ｔ２自体はその子孫Ｔ２．１、Ｔ２．２およ
びＴ２．３の形でしか表示されないものの、Ｔ２．３が
存在するのはＴ２のおかげである。したがって、Ｔ２．
３がリストの最上部に移るだけではなく、Ｔ２が表示で
きるように、Ｔ２．１およびＴ２．２もＴ２．３と一緒
にリストの最上部に移動する。Ｔ２．１およびＴ２．２
は、それらの相対的優先順位を維持し、Ｔ２．３が占め
る優先順位位置のすぐ下の２つの優先順位位置を占める
。Ｔ１およびＴ３はそれ自体の相対的優先順位位置を保
持するが、リストの一番下にある。

現在の優先順位リストは、以下のように表示される。す
なわち、ＰｌをＣＢ２．３が占め、Ｂ２をＣＢ２．１が
占め、Ｂ３をＣＢ２．２が占め、Ｂ４をＣＢ１が占め、
Ｂ５をＣＢ３が占める。それぞれ対応するタイプ標１１
ｉＫを伴っている。スクリーン所有権域は、以前と同様
に、各セルをＦにセットし、続いて当該の各セルをリス
ト位置が低い順に順次重ね書きすることにより、再構成
される。

図のようなスクリーン・ディスプレイが生成される。

リスト位置にタイプ標識Ｋが含まれているため、単−Ｗ
ＣＢのアドレスを使ってそれに関連するプレゼンテーシ
ョン・スペースの個々の特徴が表現できる。

各リスト位置にＷＣＢアドレスが含まれるため、表示域
の占有者を決定するために階層を処理する必要がない。

前述したバイト・サイズのセルおよび位置リストの長さ
２２５に対する制限は決して限定的なものではない。た
とえば、そのようなセルを、各表示域ごとに２個設けて
、並列にアクセスすることもできる。

このような構成は、タスク階層の複雑さが自動的に考慮
されており、さらに、追加の機能を提供する。たとえば
、ユーザーが自分のウィンドウが他のウィンドウに衝突
したり、他のウィンドウから衝突されたりするかどうか
知る必要がある場合、自分のウィンドウに対応するセル
について優先順位リスト位置番号が自分のものより低い
かそれとも高いかをテストすれば、スクリーン所有権域
の内容からそのことを直接テストすることができる。

上下に重ね合わさった情報が必要でない場合、これらウ
ィンドウの相対的優先順位を、リスト位置の制御ブロッ
ク入力から直接決定することができる。

対応するウィンドウがスクリーンのサイズである場合は
、スクリーン所有権域全体を所定のリスト位置の値にリ
セットできるが、スクリーン所有権域の重ね書きは、主
として行による。

優先順位の大きさの相対的順序を逆にするとと、　　も
できることは明らかである。最も最近にアクティブにな
ったウィンドウをリストの必要度が最低の位置に移すこ
ともできる。その場合、スクリーン所有権域のセルは“
Ｆ”ではなく“０”にセットされる。

【図面の簡単な説明】

第１図は、本発明によるマルチ・ウィンドウ・ディスプ
レイ・システムの簡単なタスク構造化構成のブロック・
ダイヤグラムである。 第２図は、ＢＰ公開特許広報第１４７５４２号から引用
した従来技術のラスク走査型ＣＲＴディスプレイ・ジェ
ネレータの実施例のブロック・ダイヤグラムである。 第３図は、第１図のシステムで実現できる最小のウィン
ドウ階層のブロック・ダイヤグラムである。 第４図は、タスクＮと、その現在のリスト位置Ｍ５画面
所有権域ならびにスクリーン・ディスプレイとの関係を
、別々に示したブロック・ダイヤグラムである。 第５Ａ図、第５Ｂ図、第５Ｃ図、第５Ｄ図、および第５
Ｅ図は、連続した５つのタスクがアクティブになり、そ
の状態に留まっているときのリスト、画面所有権域およ
びディスプレイの形成過程を示す。 第６図は、第５Ｅ図で表わしたシステムの環境中で１つ
だけタスクが存在するとき、そのタスクを昇進させる効
果を示した同様の図である。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　岡　　１）　次　　生（外１名） Ｋ　に　密　Ｋｔ

Claims (1)

1. 【特許請求の範囲】 表示装置およびウィンドウの識別子を指すスクリーン割
   り当て領域とを有する多重ウィンドウ表示システムにお
   いて、 表示スクリーン上に割り当てられるウィンドウの情報を
   表示の優先順位の順番に複数位置のそれぞれに記憶する
   リストと、リストの内容の変更時に優先順位を高める順
   番で上記リストの上記位置のウィンドウ情報を読出し上
   記スクリーン割り当て領域を再形成することを特徴とす
   る上記多重ウィンドウ表示システム。