JPH1069391A - マルチタスク環境において動作するアプリケーションのための汎用通信機構 - Google Patents
マルチタスク環境において動作するアプリケーションのための汎用通信機構Info
- Publication number
- JPH1069391A JPH1069391A JP9177409A JP17740997A JPH1069391A JP H1069391 A JPH1069391 A JP H1069391A JP 9177409 A JP9177409 A JP 9177409A JP 17740997 A JP17740997 A JP 17740997A JP H1069391 A JPH1069391 A JP H1069391A
- Authority
- JP
- Japan
- Prior art keywords
- application
- message
- device driver
- data store
- function call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Stored Programmes (AREA)
Abstract
(57)【要約】
【課題】 異なるメモリ・アドレッシング・モードの複
数のアプリケーション・プログラム間の通信をするため
の、簡便な方法および装置を提供する。 【解決手段】 アプリケーション・プログラム間の通信
を、仮想デバイス・ドライバに対して該アプリケーショ
ン・プログラムがファンクション・コールを実行するこ
とによって可能にする。該デバイス・ドライバは、各ア
プリケーションを、アプリケーション対アプリケーショ
ン通信のためのリクエストに対する応答としてレジスタ
する。レジスタ処理の間、デバイス・ドライバはレジス
タされているアプリケーションのアドレッシング・モー
ドを調べて決定する。アドレス・マッピング処理が実行
され、マッピング処理の結果は、アプリケーションに関
するほかの情報と合わせて、デバイス・ドライバのカー
ネルによって管理されるデータ・ストアにストアされ
る。
数のアプリケーション・プログラム間の通信をするため
の、簡便な方法および装置を提供する。 【解決手段】 アプリケーション・プログラム間の通信
を、仮想デバイス・ドライバに対して該アプリケーショ
ン・プログラムがファンクション・コールを実行するこ
とによって可能にする。該デバイス・ドライバは、各ア
プリケーションを、アプリケーション対アプリケーショ
ン通信のためのリクエストに対する応答としてレジスタ
する。レジスタ処理の間、デバイス・ドライバはレジス
タされているアプリケーションのアドレッシング・モー
ドを調べて決定する。アドレス・マッピング処理が実行
され、マッピング処理の結果は、アプリケーションに関
するほかの情報と合わせて、デバイス・ドライバのカー
ネルによって管理されるデータ・ストアにストアされ
る。
Description
【０００１】
【発明の属する技術分野】本発明は、一般的にはマイク
ロソフト・ウインドウズ・オペレーティング・システム
環境などのマルチタスク環境におけるアプリケーション
・プログラム間の通信に関する( 「マイクロソフト」お
よび「ウインドウズ」はマイクロソフト社の登録商標で
ある) 。特に、本発明は、コンピュータ実装された潜在
的に異なるメモリ・アドレッシング・モードのアプリケ
ーションが、情報を互いに従来の様式で共有し、その際
に、各アプリケーションがほかのアプリケーションのア
ドレッシング・モードを知らなくともメッセージやデー
タなどの情報を共有することができる、汎用的通信機構
に関する。
ロソフト・ウインドウズ・オペレーティング・システム
環境などのマルチタスク環境におけるアプリケーション
・プログラム間の通信に関する( 「マイクロソフト」お
よび「ウインドウズ」はマイクロソフト社の登録商標で
ある) 。特に、本発明は、コンピュータ実装された潜在
的に異なるメモリ・アドレッシング・モードのアプリケ
ーションが、情報を互いに従来の様式で共有し、その際
に、各アプリケーションがほかのアプリケーションのア
ドレッシング・モードを知らなくともメッセージやデー
タなどの情報を共有することができる、汎用的通信機構
に関する。
【０００２】現在の好適実施形態においては、本発明は
ウインドウズ仮想デバイス・ドライバ（ＶｘＤ）として
実装されており、これにアプリケーションは標準ＡＰＩ
ファンクション・コールを通じてアクセスして、所望の
アプリケーション間通信をトランスペアレントに（透過
的に）行うことができる。
ウインドウズ仮想デバイス・ドライバ（ＶｘＤ）として
実装されており、これにアプリケーションは標準ＡＰＩ
ファンクション・コールを通じてアクセスして、所望の
アプリケーション間通信をトランスペアレントに（透過
的に）行うことができる。
【０００３】
【発明の背景】主として歴史的な理由により、マイクロ
ソフト・ウインドウズ・オペレーティング・システムは
複数の異なるアドレッシング・モードをサポートしてい
る。少なくとも８メガバイトのメモリを備えたインテル
80386 プロセッサを基礎としたマシン上では、ウインド
ウズ3.x （ウインドウズ3.1 およびウインドウズ・フォ
ー・ワークグループス(WINDOWS For Workgroups)が３８
６エンハンスト・モードで動作する。エンハンスト・モ
ードにおいては、ウインドウズ・オペレーティング・シ
ステムは、１６ビットと３２ビットの両方のウインドウ
ズ・アプリケーションおよびＤＯＳアプリケーションを
サポートすることができる。ＤＯＳアプリケーション
は、マイクロプロセッサの「仮想８６」モードにおいて
動作する。ウインドウズ3.x オペレーティング・システ
ムが登場する以前は、ＩＢＭ−ＰＣおよびＰＣ互換機に
対するアプリケーション・プログラムの多くはＤＯＳロ
グラムであって、これは設計によって、６４０Ｋのメモ
リ空間内で動作するように制限されていた。３８６プロ
セッサの仮想８６モードは、同時に１つまたは複数の仮
想ＤＯＳマシンを模倣(mimic) することができ、１つま
たは複数のＤＯＳアプリケーションのロードが並行して
互いに独立に行うことができるようになる。仮想８６モ
ードによって、各ＤＯＳアプリケーションは自分自身の
メモリ空間を持つことができるようになり、これは、Ｄ
ＯＳアプリケーションにとっては、あたかも従来のＤＯ
Ｓマシンの使用環境全体を有しているかのように見え
る。ウインドウズ９５オペレーティング・システムの登
場に伴い、３２ビット・メモリ・モードが、プログラム
が有することのできるアドレッシング・モードの選択の
パレットに追加された。
ソフト・ウインドウズ・オペレーティング・システムは
複数の異なるアドレッシング・モードをサポートしてい
る。少なくとも８メガバイトのメモリを備えたインテル
80386 プロセッサを基礎としたマシン上では、ウインド
ウズ3.x （ウインドウズ3.1 およびウインドウズ・フォ
ー・ワークグループス(WINDOWS For Workgroups)が３８
６エンハンスト・モードで動作する。エンハンスト・モ
ードにおいては、ウインドウズ・オペレーティング・シ
ステムは、１６ビットと３２ビットの両方のウインドウ
ズ・アプリケーションおよびＤＯＳアプリケーションを
サポートすることができる。ＤＯＳアプリケーション
は、マイクロプロセッサの「仮想８６」モードにおいて
動作する。ウインドウズ3.x オペレーティング・システ
ムが登場する以前は、ＩＢＭ−ＰＣおよびＰＣ互換機に
対するアプリケーション・プログラムの多くはＤＯＳロ
グラムであって、これは設計によって、６４０Ｋのメモ
リ空間内で動作するように制限されていた。３８６プロ
セッサの仮想８６モードは、同時に１つまたは複数の仮
想ＤＯＳマシンを模倣(mimic) することができ、１つま
たは複数のＤＯＳアプリケーションのロードが並行して
互いに独立に行うことができるようになる。仮想８６モ
ードによって、各ＤＯＳアプリケーションは自分自身の
メモリ空間を持つことができるようになり、これは、Ｄ
ＯＳアプリケーションにとっては、あたかも従来のＤＯ
Ｓマシンの使用環境全体を有しているかのように見え
る。ウインドウズ９５オペレーティング・システムの登
場に伴い、３２ビット・メモリ・モードが、プログラム
が有することのできるアドレッシング・モードの選択の
パレットに追加された。
【０００４】利用できるアドレッシング・モード（仮想
８６モード、ウインドウズ１６ビット・モード、ウイン
ドウズ３２ビット・モード）は基本的には互いに互換性
がない。仮想８６モードは、インテル・マイクロプロセ
ッサ・ファミリーの標準セグメント・メモリ・アーキテ
クチャに基いている。２０ビット・アドレスが２つの１
６ビット値、つまりセグメント値とオフセット値の特別
なマージ処理によって計算される。このアドレッシング
・モードを通じて、アプリケーション・プログラムは１
メガバイト・メモリ空間にアクセスすることができる。
このオフセット値との組合せは、結局２０ビット・アド
レスとなる。
８６モード、ウインドウズ１６ビット・モード、ウイン
ドウズ３２ビット・モード）は基本的には互いに互換性
がない。仮想８６モードは、インテル・マイクロプロセ
ッサ・ファミリーの標準セグメント・メモリ・アーキテ
クチャに基いている。２０ビット・アドレスが２つの１
６ビット値、つまりセグメント値とオフセット値の特別
なマージ処理によって計算される。このアドレッシング
・モードを通じて、アプリケーション・プログラムは１
メガバイト・メモリ空間にアクセスすることができる。
このオフセット値との組合せは、結局２０ビット・アド
レスとなる。
【０００５】ウインドウズ１６ビット・アドレッシング
・モードは、仮想８６モードとはさまざまな点で異な
る。第１に、２つの分離した値がリニア・アドレスを生
成するために使用されるが、セグメント値（このモード
では「セレクタ」と呼ばれる)はリニア・メモリ・アド
レスを表現していない。そうではなく、これは、リニア
・メモリ内の３２ビット・ベース・アドレスを供給する
「デスクリプタ(descriptor)表」内へのオフセットを表
現している。オフセット・アドレスが、それから、ベー
ス・アドレスへ加算され、３２ビット・アドレスが生成
される。この方法において、ウインドウズ１６ビット・
アドレッシング・モードは、１６メガバイトまでのリニ
ア（仮想) メモリにアクセスすることができる。
・モードは、仮想８６モードとはさまざまな点で異な
る。第１に、２つの分離した値がリニア・アドレスを生
成するために使用されるが、セグメント値（このモード
では「セレクタ」と呼ばれる)はリニア・メモリ・アド
レスを表現していない。そうではなく、これは、リニア
・メモリ内の３２ビット・ベース・アドレスを供給する
「デスクリプタ(descriptor)表」内へのオフセットを表
現している。オフセット・アドレスが、それから、ベー
ス・アドレスへ加算され、３２ビット・アドレスが生成
される。この方法において、ウインドウズ１６ビット・
アドレッシング・モードは、１６メガバイトまでのリニ
ア（仮想) メモリにアクセスすることができる。
【０００６】ウインドウズ３２ビット・アドレッシング
・モードはなお異なる。３２ビット・アドレスは、単純
にフラットに２つの１６ビット・ワードを連結したもの
(concatenation) であり、３２ビット・リニア・アドレ
スを生成する。
・モードはなお異なる。３２ビット・アドレスは、単純
にフラットに２つの１６ビット・ワードを連結したもの
(concatenation) であり、３２ビット・リニア・アドレ
スを生成する。
【０００７】ソフトウェア・タスクがより複雑になって
いるので、マルチタスク・ソフトウェア・ソリューショ
ンがより一層魅力的になってきている。タスクの異なる
アスペクトを異なる並行実行アプリケーションであって
それぞれが固有に構成されてタスクの一部を処理するア
プリケーションへ割り当てることにより、有利に解決し
うる多くのソフトウェア・タスクがある。現在のマイク
ロソフト・ウインドウズ環境においては、このような作
業の分割を、同じアドレッシング・モードの複数のアプ
リケーションによって従来から達成しようとしていた。
同じアドレッシング・モードにすることにより、複数の
ウインドウズ・アプリケーションは、情報を互いに、直
接ほかのアプリケーションのメモリ空間にアクセスする
ことによって、共有することができるようになる。しか
し、ＤＯＳアプリケーション（仮想８６) は、それぞれ
が自分自身のアドレス空間を有するので、このように情
報を直接ほかのアプリケーションのメモリ空間にアクセ
スすることによって共有することはできない。
いるので、マルチタスク・ソフトウェア・ソリューショ
ンがより一層魅力的になってきている。タスクの異なる
アスペクトを異なる並行実行アプリケーションであって
それぞれが固有に構成されてタスクの一部を処理するア
プリケーションへ割り当てることにより、有利に解決し
うる多くのソフトウェア・タスクがある。現在のマイク
ロソフト・ウインドウズ環境においては、このような作
業の分割を、同じアドレッシング・モードの複数のアプ
リケーションによって従来から達成しようとしていた。
同じアドレッシング・モードにすることにより、複数の
ウインドウズ・アプリケーションは、情報を互いに、直
接ほかのアプリケーションのメモリ空間にアクセスする
ことによって、共有することができるようになる。しか
し、ＤＯＳアプリケーション（仮想８６) は、それぞれ
が自分自身のアドレス空間を有するので、このように情
報を直接ほかのアプリケーションのメモリ空間にアクセ
スすることによって共有することはできない。
【０００８】これまでは、異なるアドレッシング・モー
ドの複数のアプリケーションが、互いにこの形態で通信
することは便利ではなかった。異なるメモリ・アドレッ
シング・モードのアプリケーションが直接互いに通信す
るためには、これまでは、通信する相手先(communicati
ng partner) のアドレッシング・モードを決めることが
できるように、アプリケーションを特有の構成とする必
要があった。これは、その相手先のメモリに正しいアド
レッシング・モードを使用してアドレスするためであ
る。このため、たとえば、ほかのアプリケーション・プ
ログラムとの通信をサポートできるようにするには、ま
ず、既存のアプリケーション・プログラムを大幅に書き
換えるか修正する必要があった。
ドの複数のアプリケーションが、互いにこの形態で通信
することは便利ではなかった。異なるメモリ・アドレッ
シング・モードのアプリケーションが直接互いに通信す
るためには、これまでは、通信する相手先(communicati
ng partner) のアドレッシング・モードを決めることが
できるように、アプリケーションを特有の構成とする必
要があった。これは、その相手先のメモリに正しいアド
レッシング・モードを使用してアドレスするためであ
る。このため、たとえば、ほかのアプリケーション・プ
ログラムとの通信をサポートできるようにするには、ま
ず、既存のアプリケーション・プログラムを大幅に書き
換えるか修正する必要があった。
【０００９】
【発明の概要】本願発明は、異なるメモリ・アドレッシ
ング・モードのアプリケーション・プログラムが互いに
通信できるようにし、ほかのアプリケーションのアドレ
ッシング・モードがわからない場合でもこれができるよ
うにする汎用的な通信機構を提供する。特に、本発明
は、オペレーティング・システム環境内の情報を、異な
るメモリ・アドレスを利用する環境において動作するコ
ンピュータに実装されたアプリケーションの間で渡すた
めの通信機構を提供する。この通信機構は、オペレーテ
ィング・システム環境と連結され、アプリケーション・
プログラム・インタフェースを該アプリケーションにあ
らかじめ定めたファンクション・コールのセットを通じ
て提供するデバイス・ドライバを備える。このデバイス
・ドライバは、これらのファンクション・コールに対し
て応答するメッセージ・ハンドラを有する。このデバイ
ス・ドライバは、バッファリングされた通信を、送信側
アプリケーションと受信側アプリケーションの間で確立
するためのメッセージ・バッファを含む。マッピング機
構は、送信側アプリケーションのアドレッシング・モー
ドを調べて決定し、送信側アプリケーションのアドレッ
シング・モードをあらかじめ定めたアドレッシング・モ
ードに変換する。このマッピング機構は、メッセージを
送信側アプリケーションから受信側アプリケーション内
へコピーするメッセージ転送機構によって使用される。
このメッセージ転送機構は、その後、受信側アプリケー
ションにシグナルを送り、受信側アプリケーションのバ
ッファに通信されているメッセージをコピーするようド
ライバに頼む。この方法においては、通信されるメッセ
ージのコピーは、送信側アプリケーションから受信側ア
プリケーションへ渡されるが、その際に、受信側アプリ
ケーションが送信側アプリケーションのアドレッシング
・モードを知っている必要はない。
ング・モードのアプリケーション・プログラムが互いに
通信できるようにし、ほかのアプリケーションのアドレ
ッシング・モードがわからない場合でもこれができるよ
うにする汎用的な通信機構を提供する。特に、本発明
は、オペレーティング・システム環境内の情報を、異な
るメモリ・アドレスを利用する環境において動作するコ
ンピュータに実装されたアプリケーションの間で渡すた
めの通信機構を提供する。この通信機構は、オペレーテ
ィング・システム環境と連結され、アプリケーション・
プログラム・インタフェースを該アプリケーションにあ
らかじめ定めたファンクション・コールのセットを通じ
て提供するデバイス・ドライバを備える。このデバイス
・ドライバは、これらのファンクション・コールに対し
て応答するメッセージ・ハンドラを有する。このデバイ
ス・ドライバは、バッファリングされた通信を、送信側
アプリケーションと受信側アプリケーションの間で確立
するためのメッセージ・バッファを含む。マッピング機
構は、送信側アプリケーションのアドレッシング・モー
ドを調べて決定し、送信側アプリケーションのアドレッ
シング・モードをあらかじめ定めたアドレッシング・モ
ードに変換する。このマッピング機構は、メッセージを
送信側アプリケーションから受信側アプリケーション内
へコピーするメッセージ転送機構によって使用される。
このメッセージ転送機構は、その後、受信側アプリケー
ションにシグナルを送り、受信側アプリケーションのバ
ッファに通信されているメッセージをコピーするようド
ライバに頼む。この方法においては、通信されるメッセ
ージのコピーは、送信側アプリケーションから受信側ア
プリケーションへ渡されるが、その際に、受信側アプリ
ケーションが送信側アプリケーションのアドレッシング
・モードを知っている必要はない。
【００１０】本発明の目的および有利な点のより完全な
理解のためには、以下の詳細な説明および添付した図面
を参照されたい。
理解のためには、以下の詳細な説明および添付した図面
を参照されたい。
【００１１】
【発明の実施の形態】図１は、本発明の汎用的な通信機
構が利用できる典型的なコンピュータ・システムを図示
する。特に、図１は、個々のコンピュータ２０の集合を
図示するが、これはローカル・エリア・ネットワーク、
すなわち、ＬＡＮ２２へ接続してもよい。説明のため、
ローカル・エリア・ネットワークは適切なインターネッ
ト・サーバ・デバイス２４を通じて複数のリモート・コ
ンピュータ２６へ接続され、インターネット若しくは社
内ワイド・エリア・ネットワークの一部を形成してい
る。ここで示した典型的なシステムは、単に、本発明を
サポートする１つの可能なハードウェア・アーキテクチ
ャを示そうとするものであることを強調しておく。その
最も本質的な形態において、本発明は、単一のスタンド
アローン・コンピュータ上に実装することができる。た
とえば、ＬＡＮ２２へ接続されていないコンピュータ２
０のどれか１つである。ほかのコンピュータ・システム
・トポロジーも本願発明の範囲内で可能である。
構が利用できる典型的なコンピュータ・システムを図示
する。特に、図１は、個々のコンピュータ２０の集合を
図示するが、これはローカル・エリア・ネットワーク、
すなわち、ＬＡＮ２２へ接続してもよい。説明のため、
ローカル・エリア・ネットワークは適切なインターネッ
ト・サーバ・デバイス２４を通じて複数のリモート・コ
ンピュータ２６へ接続され、インターネット若しくは社
内ワイド・エリア・ネットワークの一部を形成してい
る。ここで示した典型的なシステムは、単に、本発明を
サポートする１つの可能なハードウェア・アーキテクチ
ャを示そうとするものであることを強調しておく。その
最も本質的な形態において、本発明は、単一のスタンド
アローン・コンピュータ上に実装することができる。た
とえば、ＬＡＮ２２へ接続されていないコンピュータ２
０のどれか１つである。ほかのコンピュータ・システム
・トポロジーも本願発明の範囲内で可能である。
【００１２】汎用的な通信機構の現在の好適実施形態
は、マイクロソフト・ウインドウズ・オペレーティング
・システムと動作するよう構成されている。本発明は、
このように、この文脈で説明されるが、本発明の原理は
ほかのオペレーティング・システムにおいても利用でき
る。たとえば、現在のウインドウズ・オペレーティング
・システムの将来のバリエーション、拡張、および、こ
れに代わるものである。したがって、説明のため、図１
はウインドウズ・オペレーティング・システムの３つの
バリアント(variant) 、すなわち、ウインドウズ３Ｘ
（２８で図示）、ウインドウズ９５（３０で図示）、お
よび、ウインドウズＮＴ（３２で図示）を図示する。ウ
インドウズ３Ｘオペレーティング・システムは、ＭＳ−
ＤＯＳオペレーティング・システムの上で動作するが、
これは図示する通りである。
は、マイクロソフト・ウインドウズ・オペレーティング
・システムと動作するよう構成されている。本発明は、
このように、この文脈で説明されるが、本発明の原理は
ほかのオペレーティング・システムにおいても利用でき
る。たとえば、現在のウインドウズ・オペレーティング
・システムの将来のバリエーション、拡張、および、こ
れに代わるものである。したがって、説明のため、図１
はウインドウズ・オペレーティング・システムの３つの
バリアント(variant) 、すなわち、ウインドウズ３Ｘ
（２８で図示）、ウインドウズ９５（３０で図示）、お
よび、ウインドウズＮＴ（３２で図示）を図示する。ウ
インドウズ３Ｘオペレーティング・システムは、ＭＳ−
ＤＯＳオペレーティング・システムの上で動作するが、
これは図示する通りである。
【００１３】以下に説明する通り、汎用的な通信機構に
よって情報を、オペレーティング・システム環境内で、
コンピュータ実装されたアプリケーションであってその
環境で動作するものの間で渡すことができるようにな
る。特に、汎用的な通信機構によって、これらのアプリ
ケーション自身が異なるメモリ・アドレッシング・モー
ドを利用していても、これらのアプリケーションが情報
を渡すことができるようになる。本発明を現在の好適形
態において説明する目的のため、３つの異なるアドレッ
シング・モードが図示されている。仮想８６、すなわ
ち、ＤＯＳアドレッシング・モード、ウインドウズ１６
ビット・アドレッシング・モード、および、ウインドウ
ズ３２ビット・アドレッシング・モードである。このよ
うに図１では、各コンピュータ２０は複数のアプリケー
ション・プログラムを、（それぞれの１つが図示され、
Ｖ−８６、Ｗ−１６およびＷ−３２と命名されている）
それぞれ動作させている。再び、汎用的な通信機構は１
つのコンピュータ若しくは複数のコンピュータの上に配
備することができ、アプリケーション・プログラムおよ
びこれらのプログラムのアドレッシング・モードの数
は、ここで図示したものに制限されないことを強調して
おく。汎用的な通信機構は、好ましくは、仮想デバイス
・ドライバ（ＶｘＤ）として実装され、これはマイクロ
ソフト・ウインドウズのプログラミング習慣(practice)
に従うものである。詳しくは、「マイクロソフト・デバ
イス・ドライバ・キット(Microsoft Device Driver Ki
t) 」および「マイクロソフト・デベロッパーズ・ネッ
トワーク(Microsoft Developer's Network) 」を参照さ
れたい。これは両方ともワシントン、レッドモンド(Red
mond) のマイクロソフト社から入手できる。以降に十分
に説明する通り、仮想デバイス・ドライバは、好ましく
は、コンピュータ２０のハード・ディスク３４上にイン
ストールされて、オペレーティング・システムへ仮想デ
バイス・ドライバとして結合する。オペレーティング・
システム環境内のアプリケーション・プログラムは、こ
の仮想デバイス・ドライバにアクセスしてその汎用的な
通信機構サービスを利用することができる。この汎用的
な通信機構は仮想デバイス・ドライバとして実装されて
いるので、アプリケーション・プログラムは、プログラ
ム自体の広範囲なプログラム修正を必要とせずに、これ
にアクセスすることができる。唯一の修正は、この仮想
デバイス・ドライバへの適切なファンクション・コール
を形成することである。
よって情報を、オペレーティング・システム環境内で、
コンピュータ実装されたアプリケーションであってその
環境で動作するものの間で渡すことができるようにな
る。特に、汎用的な通信機構によって、これらのアプリ
ケーション自身が異なるメモリ・アドレッシング・モー
ドを利用していても、これらのアプリケーションが情報
を渡すことができるようになる。本発明を現在の好適形
態において説明する目的のため、３つの異なるアドレッ
シング・モードが図示されている。仮想８６、すなわ
ち、ＤＯＳアドレッシング・モード、ウインドウズ１６
ビット・アドレッシング・モード、および、ウインドウ
ズ３２ビット・アドレッシング・モードである。このよ
うに図１では、各コンピュータ２０は複数のアプリケー
ション・プログラムを、（それぞれの１つが図示され、
Ｖ−８６、Ｗ−１６およびＷ−３２と命名されている）
それぞれ動作させている。再び、汎用的な通信機構は１
つのコンピュータ若しくは複数のコンピュータの上に配
備することができ、アプリケーション・プログラムおよ
びこれらのプログラムのアドレッシング・モードの数
は、ここで図示したものに制限されないことを強調して
おく。汎用的な通信機構は、好ましくは、仮想デバイス
・ドライバ（ＶｘＤ）として実装され、これはマイクロ
ソフト・ウインドウズのプログラミング習慣(practice)
に従うものである。詳しくは、「マイクロソフト・デバ
イス・ドライバ・キット(Microsoft Device Driver Ki
t) 」および「マイクロソフト・デベロッパーズ・ネッ
トワーク(Microsoft Developer's Network) 」を参照さ
れたい。これは両方ともワシントン、レッドモンド(Red
mond) のマイクロソフト社から入手できる。以降に十分
に説明する通り、仮想デバイス・ドライバは、好ましく
は、コンピュータ２０のハード・ディスク３４上にイン
ストールされて、オペレーティング・システムへ仮想デ
バイス・ドライバとして結合する。オペレーティング・
システム環境内のアプリケーション・プログラムは、こ
の仮想デバイス・ドライバにアクセスしてその汎用的な
通信機構サービスを利用することができる。この汎用的
な通信機構は仮想デバイス・ドライバとして実装されて
いるので、アプリケーション・プログラムは、プログラ
ム自体の広範囲なプログラム修正を必要とせずに、これ
にアクセスすることができる。唯一の修正は、この仮想
デバイス・ドライバへの適切なファンクション・コール
を形成することである。
【００１４】汎用的な通信機構をパッケージして配布す
る方法であってコンピュータ若しくはコンピュータ・シ
ステムにおいて配備するための方法は、数多くある。図
１は、３つの方法を図示する。汎用的な通信機構はフロ
ッピー・ディスク３６、ＣＤ−ＲＯＭ３８、若しくはほ
かの適切なデータ・ストレージ媒体で供給してもよい。
これら２つの媒体が図示されているが、これは、これら
が現在、ソフトウェア配布の最もポピュラーなモードだ
からである。これらが将来ほかのものになることは間違
いない。物理的に移動できる(transportable) メモリ・
デバイスによって配布することに加えて、汎用的な通信
機構も電子的に配布することができる。これは、図１に
おいて以下のようにダイアグラムで図示されている。通
信機構はハード・ディスク４０上にストアされ、その後
に、適切なファイル転送プロトコルを通じてハード・デ
ィスク４２へ通信リンク４４を介して転送される。ハー
ド・ディスク４２から汎用的な通信機構は、ハード・デ
ィスク４６へ転送され、デバイス２４を通じてハード・
ディスク３４へ送信することができる。一度ソース・ハ
ードウェア・ディスクらデスティネーション・ハード・
ディスクへ転送されると、ソース・ハード・ディスク上
のコピーは、希望する場合は、消去してもよい。
る方法であってコンピュータ若しくはコンピュータ・シ
ステムにおいて配備するための方法は、数多くある。図
１は、３つの方法を図示する。汎用的な通信機構はフロ
ッピー・ディスク３６、ＣＤ−ＲＯＭ３８、若しくはほ
かの適切なデータ・ストレージ媒体で供給してもよい。
これら２つの媒体が図示されているが、これは、これら
が現在、ソフトウェア配布の最もポピュラーなモードだ
からである。これらが将来ほかのものになることは間違
いない。物理的に移動できる(transportable) メモリ・
デバイスによって配布することに加えて、汎用的な通信
機構も電子的に配布することができる。これは、図１に
おいて以下のようにダイアグラムで図示されている。通
信機構はハード・ディスク４０上にストアされ、その後
に、適切なファイル転送プロトコルを通じてハード・デ
ィスク４２へ通信リンク４４を介して転送される。ハー
ド・ディスク４２から汎用的な通信機構は、ハード・デ
ィスク４６へ転送され、デバイス２４を通じてハード・
ディスク３４へ送信することができる。一度ソース・ハ
ードウェア・ディスクらデスティネーション・ハード・
ディスクへ転送されると、ソース・ハード・ディスク上
のコピーは、希望する場合は、消去してもよい。
【００１５】汎用的な通信機構のさらに詳細な説明をす
る前に、従来のウインドウズ・アドレッシング・モード
を概観しておくと役に立つだろう。図２を参照しよう。
これは、ウインドウズ・オペレーティング・システム環
境内で動作する３つのアプリケーション・プログラムを
図示する。特に、図２は、仮想８６アドレッシング・モ
ードで動作するＤＯＳアプリケーション４８、１６ビッ
ト・ウインドウズ・アプリケーション５０、および３２
ビット・ウインドウズ・アプリケーション５２を図示す
る。ここでの説明のため、ウインドウズ・オペレーティ
ング・システム５４は、ＭＳ−ＤＯＳオペレーティング
・システムの上にこれと組み合わせて示されている。以
前に説明した通り、ウインドウズ・オペレーティング・
システムの最近の変形（例えばウインドウズ９５やウイ
ンドウズＮＴ）は、分離したＭＳ−ＤＯＳオペレーティ
ング・システム層を必要としないようになっている。
る前に、従来のウインドウズ・アドレッシング・モード
を概観しておくと役に立つだろう。図２を参照しよう。
これは、ウインドウズ・オペレーティング・システム環
境内で動作する３つのアプリケーション・プログラムを
図示する。特に、図２は、仮想８６アドレッシング・モ
ードで動作するＤＯＳアプリケーション４８、１６ビッ
ト・ウインドウズ・アプリケーション５０、および３２
ビット・ウインドウズ・アプリケーション５２を図示す
る。ここでの説明のため、ウインドウズ・オペレーティ
ング・システム５４は、ＭＳ−ＤＯＳオペレーティング
・システムの上にこれと組み合わせて示されている。以
前に説明した通り、ウインドウズ・オペレーティング・
システムの最近の変形（例えばウインドウズ９５やウイ
ンドウズＮＴ）は、分離したＭＳ−ＤＯＳオペレーティ
ング・システム層を必要としないようになっている。
【００１６】図２に示す通り、ＤＯＳアプリケーション
４８は２０ビット・アドレスを使用してメモリにアクセ
スする。２０ビット・アドレスは、１６ビット・オフセ
ット・アドレス５８と１６ビット・セグメント・アドレ
ス６０とを組み合わせることにより計算され、２０ビッ
ト・リニア・アドレス６２に到来する。この２０ビット
・アドレスは、セグメント・アドレスを４ビット左へシ
フトしてからこれをオフセット・アドレスに加算するこ
とによって得られる。
４８は２０ビット・アドレスを使用してメモリにアクセ
スする。２０ビット・アドレスは、１６ビット・オフセ
ット・アドレス５８と１６ビット・セグメント・アドレ
ス６０とを組み合わせることにより計算され、２０ビッ
ト・リニア・アドレス６２に到来する。この２０ビット
・アドレスは、セグメント・アドレスを４ビット左へシ
フトしてからこれをオフセット・アドレスに加算するこ
とによって得られる。
【００１７】ＤＯＳアプリケーションと対照的に、１６
ビット・ウインドウズ・アプリケーション５０は３２ビ
ット・リニア・アドレスを使用するが、これは、以下の
ように決められる。１６ビット・セレクタ・アドレス６
４を使用してデスクリプタ表６６にアクセスする。デス
クリプタ表は、ここから３２ビット・ベース・アドレス
６８を得るためのルックアップ表である。このベース・
アドレスに対して１６ビット・オフセット７０が加算さ
れ、３２ビット・リニア・アドレス７２に到来する。
ビット・ウインドウズ・アプリケーション５０は３２ビ
ット・リニア・アドレスを使用するが、これは、以下の
ように決められる。１６ビット・セレクタ・アドレス６
４を使用してデスクリプタ表６６にアクセスする。デス
クリプタ表は、ここから３２ビット・ベース・アドレス
６８を得るためのルックアップ表である。このベース・
アドレスに対して１６ビット・オフセット７０が加算さ
れ、３２ビット・リニア・アドレス７２に到来する。
【００１８】前述したアドレッシング・モードのいずれ
とも対照的に、３２ビット・ウインドウズ・アプリケー
ション５２は、フラットな３２ビット・リニア・アドレ
ス７４を利用するが、これは、１６ビット最上位ワード
(most significant word：ＭＳＷ）および１６ビット最
下位ワード（least significant word：ＬＳＷ）からな
るものと考えてもよい。
とも対照的に、３２ビット・ウインドウズ・アプリケー
ション５２は、フラットな３２ビット・リニア・アドレ
ス７４を利用するが、これは、１６ビット最上位ワード
(most significant word：ＭＳＷ）および１６ビット最
下位ワード（least significant word：ＬＳＷ）からな
るものと考えてもよい。
【００１９】アプリケーション４８、５０、および５２
の間でメモリを渡すことは大変複雑であるが、これは、
これら３つのアプリケーションが全く異なるアドレッシ
ング・モードを使用するという事実による。同じアドレ
ッシング・モードの２つのアプリケーションの間では、
情報を渡すことは保護による制限を受けるが) 相対的に
単純であり、これは、単純にソースからデスティネーシ
ョンへコピーするか、もしくは、あるアプリケーション
がほかのアプリケーションのデータ・メモリへアクセス
できるように、ポインタを渡すことによってできる。し
かし、異なるアドレッシング・モードを利用しているア
プリケーションにおいては、この単純な情報の交換は、
これらの異なるアドレッシング・モードを考慮にいれな
い限り使用できない。これを行うための従来の方法は、
アプリケーション・プログラムを書くか修正して、
（ａ）それが通信している相手のアドレッシング・モー
ドを調べて決定し、（ｂ）適切なトランスレーションを
行ってそのデータが壊れないようにすることであった。
実際的に言えば、これは、全アプリケーション・プログ
ラムを、この通信機能を含むように特別に書く（もしく
は修正する）必要があることを意味する。これは、現在
のアプリケーション・プログラムの数が多いこと(pleth
ora)を考えると実際的ではない。
の間でメモリを渡すことは大変複雑であるが、これは、
これら３つのアプリケーションが全く異なるアドレッシ
ング・モードを使用するという事実による。同じアドレ
ッシング・モードの２つのアプリケーションの間では、
情報を渡すことは保護による制限を受けるが) 相対的に
単純であり、これは、単純にソースからデスティネーシ
ョンへコピーするか、もしくは、あるアプリケーション
がほかのアプリケーションのデータ・メモリへアクセス
できるように、ポインタを渡すことによってできる。し
かし、異なるアドレッシング・モードを利用しているア
プリケーションにおいては、この単純な情報の交換は、
これらの異なるアドレッシング・モードを考慮にいれな
い限り使用できない。これを行うための従来の方法は、
アプリケーション・プログラムを書くか修正して、
（ａ）それが通信している相手のアドレッシング・モー
ドを調べて決定し、（ｂ）適切なトランスレーションを
行ってそのデータが壊れないようにすることであった。
実際的に言えば、これは、全アプリケーション・プログ
ラムを、この通信機能を含むように特別に書く（もしく
は修正する）必要があることを意味する。これは、現在
のアプリケーション・プログラムの数が多いこと(pleth
ora)を考えると実際的ではない。
【００２０】本発明の汎用的な通信機構は、この問題
を、仮想デバイス・ドライバを通じて解決したが、これ
を通じて、アプリケーション・プログラムは、この仮想
デバイス・ドライバへの標準アプリケーション・プログ
ラム・インタフェース（ＡＰＩ）ファンクション・コー
ルを使用して通信を行う。図３に示す通り、デバイス・
ドライバ７６はウインドウズ・オペレーティング・シス
テム５４に連結され、デバイス・ドライバはアプリケー
ション・プログラム４８、５０、および、５２へ標準ウ
インドウズＡＰＩプロトコルを通じてアクセスできるよ
うになっている。デバイス・ドライバは、アプリケーシ
ョン・プログラム・インタフェース・モジュール７８を
有し、これによって、アプリケーション・プログラム
は、アプリケーション対アプリケーション通信を遂行す
るのに便利な複数のファンクションを呼び出すことがで
きるようになる。これらの関数は以下を備える。
を、仮想デバイス・ドライバを通じて解決したが、これ
を通じて、アプリケーション・プログラムは、この仮想
デバイス・ドライバへの標準アプリケーション・プログ
ラム・インタフェース（ＡＰＩ）ファンクション・コー
ルを使用して通信を行う。図３に示す通り、デバイス・
ドライバ７６はウインドウズ・オペレーティング・シス
テム５４に連結され、デバイス・ドライバはアプリケー
ション・プログラム４８、５０、および、５２へ標準ウ
インドウズＡＰＩプロトコルを通じてアクセスできるよ
うになっている。デバイス・ドライバは、アプリケーシ
ョン・プログラム・インタフェース・モジュール７８を
有し、これによって、アプリケーション・プログラム
は、アプリケーション対アプリケーション通信を遂行す
るのに便利な複数のファンクションを呼び出すことがで
きるようになる。これらの関数は以下を備える。
【００２１】レジスタ(REGISTER)：アプリケーションが
データを受信したいことをレジスタ（登録）する。
データを受信したいことをレジスタ（登録）する。
【００２２】デレジスタ(DEREGISTER)：アプリケーショ
ン対アプリケーション通信が完了したときに通信チャン
ネルを閉じる。
ン対アプリケーション通信が完了したときに通信チャン
ネルを閉じる。
【００２３】センド(SEND)：メッセージ若しくはほかの
情報を指定したレジスタ（登録）されたアプリケーショ
ンに送信する。
情報を指定したレジスタ（登録）されたアプリケーショ
ンに送信する。
【００２４】レシーブ(RECEIVE) ：受信側アプリケーシ
ョンへのメッセージ若しくはコピー情報を読む。
ョンへのメッセージ若しくはコピー情報を読む。
【００２５】スリープ(SLEEP) ：情報がアプリケーショ
ンへ送られてくるのを待つ間、これをブロックする。
ンへ送られてくるのを待つ間、これをブロックする。
【００２６】デバイス・ドライバ７６は、メッセージ・
ハンドラ・モジュール８０を有し、これは、実際にはア
プリケーションによってアプリケーション・プログラム
・インタフェース７８を通じて、リクエストされたファ
ンクションを実行する。メッセージ・ハンドラは、マッ
ピング機構８２を含み、これは、送信側アプリケーショ
ンのアドレッシング・モードを調べて決定して、そのア
ドレッシング・モードを、３２ビット・ウインドウズ・
アプリケーションのフラット・アドレスに対応するフラ
ットなアドレスにトランスレートするように構成されて
いる。このマッピング機構は、送信側アプリケーション
のアドレッシング・モードを、既存のウインドウズ・オ
ペレーティング・システム・パラメータを解釈すること
によって決定することができる。送信側アプリケーショ
ンは、この情報を提供するために特別にプログラムした
り、修正をしたりする必要はない。
ハンドラ・モジュール８０を有し、これは、実際にはア
プリケーションによってアプリケーション・プログラム
・インタフェース７８を通じて、リクエストされたファ
ンクションを実行する。メッセージ・ハンドラは、マッ
ピング機構８２を含み、これは、送信側アプリケーショ
ンのアドレッシング・モードを調べて決定して、そのア
ドレッシング・モードを、３２ビット・ウインドウズ・
アプリケーションのフラット・アドレスに対応するフラ
ットなアドレスにトランスレートするように構成されて
いる。このマッピング機構は、送信側アプリケーション
のアドレッシング・モードを、既存のウインドウズ・オ
ペレーティング・システム・パラメータを解釈すること
によって決定することができる。送信側アプリケーショ
ンは、この情報を提供するために特別にプログラムした
り、修正をしたりする必要はない。
【００２７】実際のアプリケーション対アプリケーショ
ン通信は、メッセージ・バッファを通じて処理される
が、これは、データ・ストア８４の一部をなし、デバイ
ス・ドライバによって管理されている。アプリケーショ
ンがアプリケーション対アプリケーション通信を開始(i
nitiate)するために（レジスタ・ファンクション・コー
ルを通じて）登録するたびに、リクエストされた通信用
のメッセージ・バッファが、リクエストされた通信につ
いてのほかの関連情報をストアするためのデータ構造体
の一部としてインスタンス化(instantiate) される。メ
ッセージ・ハンドラ８０は、転送機構８６を含み、これ
は、そのファンクション・コールを呼び出したアプリケ
ーション・プログラムからの必要な転送情報を取り出
す。この情報は、データ・ストアにストアされるが、メ
ッセージ・バッファはこのデータ・ストアの一部になっ
ている。転送機構８６は、マッピング機構８２を使用し
て、各アプリケーションのアドレッシング・モードを、
それが（レジスタ・ファンクション・コール経由で）登
録したときに、以降の使用のために記録する。送信側ア
プリケーションからの必要な情報を取り出してデータ・
ストア８４にストアした後で、転送機構は、つぎに、受
信側アプリケーションにシグナルを送るので、受信側ア
プリケーションは、（レシーブ・ファンクション・コー
ルを通じて）仮想デバイス・ドライバに、メッセージ・
バッファへアクセスして自分自身の使用のために情報を
コピーするよう頼むことができるようになる。
ン通信は、メッセージ・バッファを通じて処理される
が、これは、データ・ストア８４の一部をなし、デバイ
ス・ドライバによって管理されている。アプリケーショ
ンがアプリケーション対アプリケーション通信を開始(i
nitiate)するために（レジスタ・ファンクション・コー
ルを通じて）登録するたびに、リクエストされた通信用
のメッセージ・バッファが、リクエストされた通信につ
いてのほかの関連情報をストアするためのデータ構造体
の一部としてインスタンス化(instantiate) される。メ
ッセージ・ハンドラ８０は、転送機構８６を含み、これ
は、そのファンクション・コールを呼び出したアプリケ
ーション・プログラムからの必要な転送情報を取り出
す。この情報は、データ・ストアにストアされるが、メ
ッセージ・バッファはこのデータ・ストアの一部になっ
ている。転送機構８６は、マッピング機構８２を使用し
て、各アプリケーションのアドレッシング・モードを、
それが（レジスタ・ファンクション・コール経由で）登
録したときに、以降の使用のために記録する。送信側ア
プリケーションからの必要な情報を取り出してデータ・
ストア８４にストアした後で、転送機構は、つぎに、受
信側アプリケーションにシグナルを送るので、受信側ア
プリケーションは、（レシーブ・ファンクション・コー
ルを通じて）仮想デバイス・ドライバに、メッセージ・
バッファへアクセスして自分自身の使用のために情報を
コピーするよう頼むことができるようになる。
【００２８】さて、汎用的な通信機構の好適実施形態を
図４を参照して説明しよう。図４は、現在の好適実施形
態の仮想デバイス・ドライバとしてのソフトウェア構成
を図示する。図４は、好適実施形態のさまざまなサブシ
ステムの階層関係を示す。図４は、図３において説明さ
れた機能的コンポーネントを構成するソフトウェア・コ
ンポーネントを示す。
図４を参照して説明しよう。図４は、現在の好適実施形
態の仮想デバイス・ドライバとしてのソフトウェア構成
を図示する。図４は、好適実施形態のさまざまなサブシ
ステムの階層関係を示す。図４は、図３において説明さ
れた機能的コンポーネントを構成するソフトウェア・コ
ンポーネントを示す。
【００２９】図４を参照すると、汎用的な通信機構の主
要な部分は、カーネル・モジュール８８として実装され
ている。カーネル・モジュール８８は、ＡＰＩハンドラ
・モジュール９０とインタフェースしている。ＡＰＩハ
ンドラ・モジュールは、ＡＰＩインタフェース７８（図
３）を定義し、アプリケーション・プログラムとインタ
フェースする標準ウインドウズ・ドライバを確立する。
カーネル・モジュール８８は、汎用的な通信機構の残り
のファンクションを提供するが、これは、データ・スト
アやメッセージ・バッファ８４（図３）の管理を含む。
カーネル・モジュールは、階層的に、ブロック９２によ
って示されている、呼び出し可能なファンクションと、
ブロック９４によって示されている内部ファンクション
とのグループに再分割(subdevide) されている。呼び出
し可能なファンクションとして、アプリケーション・プ
ログラムがＡＰＩインタフェースを通じてリクエストす
ることができるファンクションを備える。これらは、レ
ジスタ・ファンクション９６と、デレジスタ・ファンク
ション９８と、センド・ファンクション１００と、レシ
ーブ・ファンクション１０２と、およびスリープ・ファ
ンクション１０とを含む。これら呼び出し可能なファン
クションのフローチャートは図に示されており、以下で
説明する。
要な部分は、カーネル・モジュール８８として実装され
ている。カーネル・モジュール８８は、ＡＰＩハンドラ
・モジュール９０とインタフェースしている。ＡＰＩハ
ンドラ・モジュールは、ＡＰＩインタフェース７８（図
３）を定義し、アプリケーション・プログラムとインタ
フェースする標準ウインドウズ・ドライバを確立する。
カーネル・モジュール８８は、汎用的な通信機構の残り
のファンクションを提供するが、これは、データ・スト
アやメッセージ・バッファ８４（図３）の管理を含む。
カーネル・モジュールは、階層的に、ブロック９２によ
って示されている、呼び出し可能なファンクションと、
ブロック９４によって示されている内部ファンクション
とのグループに再分割(subdevide) されている。呼び出
し可能なファンクションとして、アプリケーション・プ
ログラムがＡＰＩインタフェースを通じてリクエストす
ることができるファンクションを備える。これらは、レ
ジスタ・ファンクション９６と、デレジスタ・ファンク
ション９８と、センド・ファンクション１００と、レシ
ーブ・ファンクション１０２と、およびスリープ・ファ
ンクション１０とを含む。これら呼び出し可能なファン
クションのフローチャートは図に示されており、以下で
説明する。
【００３０】内部ファンクションはさまざまなサポート
・ファンクションを備え、これらは呼び出し可能なファ
ンクションから呼び出され利用される。説明のため、こ
れらのファンクションを、データ構造体管理ファンクシ
ョン１０６、データ構造体ルックアップ・ファンクショ
ン１０８、および、アドレス・マッピング・ファンクシ
ョン１１０として分類してある。カーネル・モジュール
は、データ・ストアおよびメッセージ・バッファ８４
（図３）を管理する。カーネル・モジュール・ソフトウ
ェアは、Ｃ言語のstruct形式のカーネル・データ構造体
１１２を定義するが、これは数々の異なる要素を備え
る。現在の好適なデータ構造体を付録に示す。
・ファンクションを備え、これらは呼び出し可能なファ
ンクションから呼び出され利用される。説明のため、こ
れらのファンクションを、データ構造体管理ファンクシ
ョン１０６、データ構造体ルックアップ・ファンクショ
ン１０８、および、アドレス・マッピング・ファンクシ
ョン１１０として分類してある。カーネル・モジュール
は、データ・ストアおよびメッセージ・バッファ８４
（図３）を管理する。カーネル・モジュール・ソフトウ
ェアは、Ｃ言語のstruct形式のカーネル・データ構造体
１１２を定義するが、これは数々の異なる要素を備え
る。現在の好適なデータ構造体を付録に示す。
【００３１】データ構造体管理ファンクション１０６
は、アプリケーションが（レジスタ・ファンクションを
呼び出して）レジスタ（登録）したとき、および、その
アプリケーションが（デレジスタ・ファンクションを呼
び出して）デレジスタしたときに、カーネル・データ構
造体のインスタンスを作成することの責任を負う。デー
タ構造体管理ファンクションは、汎用的な通信機構の操
作中に、データ・ストア内の情報の管理および更新も行
う。図４では、レジスタ・ファンクション９６およびデ
レジスタ・ファンクション９８は、それぞれ丸で囲んだ
１および２として、また、データ構造体ファンクション
１０６上に丸で囲んだ同様の数字として示されている。
これは、動作中にデータ構造体管理ファンクションの上
がレジスタおよびデレジスタ・ファンクションが動作中
にデータ構造体管理ファンクションを呼び出すことを示
している。同様の記述法は図４にわたって用いられてい
る。
は、アプリケーションが（レジスタ・ファンクションを
呼び出して）レジスタ（登録）したとき、および、その
アプリケーションが（デレジスタ・ファンクションを呼
び出して）デレジスタしたときに、カーネル・データ構
造体のインスタンスを作成することの責任を負う。デー
タ構造体管理ファンクションは、汎用的な通信機構の操
作中に、データ・ストア内の情報の管理および更新も行
う。図４では、レジスタ・ファンクション９６およびデ
レジスタ・ファンクション９８は、それぞれ丸で囲んだ
１および２として、また、データ構造体ファンクション
１０６上に丸で囲んだ同様の数字として示されている。
これは、動作中にデータ構造体管理ファンクションの上
がレジスタおよびデレジスタ・ファンクションが動作中
にデータ構造体管理ファンクションを呼び出すことを示
している。同様の記述法は図４にわたって用いられてい
る。
【００３２】データ構造体ルックアップ・ファンクショ
ン１０８は、データ・ストア内のデータにアクセスする
ために、（スリープ・ファンクションを除く) 呼び出し
可能なファンクションのそれぞれからアクセスされる。
データ構造体ルックアップ・ファンクションは、レジス
タ（登録）されたアプリケーションをそのアスキー(ASC
II) 名若しくは仮想メモリ・ハンドルによってルックア
ップするサービスを提供する。このルックアップ操作
は、汎用的な通信機構のルーチン動作の最中に実行され
る。
ン１０８は、データ・ストア内のデータにアクセスする
ために、（スリープ・ファンクションを除く) 呼び出し
可能なファンクションのそれぞれからアクセスされる。
データ構造体ルックアップ・ファンクションは、レジス
タ（登録）されたアプリケーションをそのアスキー(ASC
II) 名若しくは仮想メモリ・ハンドルによってルックア
ップするサービスを提供する。このルックアップ操作
は、汎用的な通信機構のルーチン動作の最中に実行され
る。
【００３３】アドレス・マッピング・ファンクション１
１０は、レジスタ・ファンクション９６によって、アプ
リケーションが（レジスタ・コマンドを呼び出すること
によって）レジスタ（登録）しようとするたびごとに呼
び出される。アドレス・マッピング・ファンクション１
１０は、マッピング機構８２（図３）の機能を提供す
る。
１０は、レジスタ・ファンクション９６によって、アプ
リケーションが（レジスタ・コマンドを呼び出すること
によって）レジスタ（登録）しようとするたびごとに呼
び出される。アドレス・マッピング・ファンクション１
１０は、マッピング機構８２（図３）の機能を提供す
る。
【００３４】前述の汎用的な通信機構の概要を留意し
て、これから、呼び出し可能なファンクションの説明
を、図５から図９のフローチャート図を参照して与えよ
う。
て、これから、呼び出し可能なファンクションの説明
を、図５から図９のフローチャート図を参照して与えよ
う。
【００３５】図５は、レジスタ・ファンクション９６の
内部動作を図示する。図５を参照すると、レジスタ・ル
ーチンはレジスタしようとしているアプリケーションの
ハンドルを得ることから始まる（ステップ２００）。次
に、このハンドルがフラットなアドレス・モードへマッ
プされる（ステップ２０２）。これが行われるのは、異
なるアプリケーションは、直接互いに互換性がない異な
るアドレッシング・モードを利用しているかもしれない
という事実を補うためである。アドレス・マッピング手
順の詳細は、「マップ・フラット」という題名のついた
擬似コード・リストに示してある。アプリケーション・
ハンドルをマップした後、このルーチンは、そのアプリ
ケーションによって提供されたハンドルが有効なものか
のベリファイに進む（ステップ２０４）。有効でない場
合は、エラー・メッセージが生成されてルーチンは終了
する。
内部動作を図示する。図５を参照すると、レジスタ・ル
ーチンはレジスタしようとしているアプリケーションの
ハンドルを得ることから始まる（ステップ２００）。次
に、このハンドルがフラットなアドレス・モードへマッ
プされる（ステップ２０２）。これが行われるのは、異
なるアプリケーションは、直接互いに互換性がない異な
るアドレッシング・モードを利用しているかもしれない
という事実を補うためである。アドレス・マッピング手
順の詳細は、「マップ・フラット」という題名のついた
擬似コード・リストに示してある。アプリケーション・
ハンドルをマップした後、このルーチンは、そのアプリ
ケーションによって提供されたハンドルが有効なものか
のベリファイに進む（ステップ２０４）。有効でない場
合は、エラー・メッセージが生成されてルーチンは終了
する。
【００３６】一度ハンドルがマップされてベリファイさ
れると、このルーチンはカーネル・データ構造体１１２
（図４）のインスタンスを生成して、レジスタ（登録）
しようとしているアプリケーションを表現する。この新
しく追加されたデータ要素に対するハンドルは、リンク
・リストに追加され、カーネル・データ構造体の一部と
して管理される（ステップ２０６）。新しいデータ要素
用の空間を割り当てた後、アプリケーション・ハンドル
およびアプリケーション状態が、新しく作成されたデー
タ要素の中にストアされる（ステップ２０８）。登録し
ようとしているアプリケーションは、以前のレジスタ・
ファンクション９６の呼び出しを通じて、以前にレジス
タ（登録）してある可能性がある。レジスタ・ファンク
ションは、これをステップ２１０でテストして、以前の
登録が見つかった場合は、以前の登録をステップ２１２
で破棄する。このようにして、カーネル・データ構造体
は最新のものに維持される。
れると、このルーチンはカーネル・データ構造体１１２
（図４）のインスタンスを生成して、レジスタ（登録）
しようとしているアプリケーションを表現する。この新
しく追加されたデータ要素に対するハンドルは、リンク
・リストに追加され、カーネル・データ構造体の一部と
して管理される（ステップ２０６）。新しいデータ要素
用の空間を割り当てた後、アプリケーション・ハンドル
およびアプリケーション状態が、新しく作成されたデー
タ要素の中にストアされる（ステップ２０８）。登録し
ようとしているアプリケーションは、以前のレジスタ・
ファンクション９６の呼び出しを通じて、以前にレジス
タ（登録）してある可能性がある。レジスタ・ファンク
ションは、これをステップ２１０でテストして、以前の
登録が見つかった場合は、以前の登録をステップ２１２
で破棄する。このようにして、カーネル・データ構造体
は最新のものに維持される。
【００３７】アプリケーション・ハンドルおよびアプリ
ケーション状態をストアすることに加えて、レジスタ・
ファンクションは、追加アプリケーション情報のコピー
も作成するが、これは、意図した受け手に対する通信メ
ッセージをポストするために必要である。これは、ステ
ップ２１４で実行される。特に、このルーチンは、ウイ
ンドウズの「PostMessage 」（ポストメッセージ）ルー
チンを実行するのに必要なセレクタおよびオフセットの
アドレス値のほか、「PostMessage 」用のウインドウズ
・ハンドルおよびそのルーチンのメッセージ番号をスト
アする。カーネルがメッセージのために予約すべきデー
タの量もまた、このときにストアされる。
ケーション状態をストアすることに加えて、レジスタ・
ファンクションは、追加アプリケーション情報のコピー
も作成するが、これは、意図した受け手に対する通信メ
ッセージをポストするために必要である。これは、ステ
ップ２１４で実行される。特に、このルーチンは、ウイ
ンドウズの「PostMessage 」（ポストメッセージ）ルー
チンを実行するのに必要なセレクタおよびオフセットの
アドレス値のほか、「PostMessage 」用のウインドウズ
・ハンドルおよびそのルーチンのメッセージ番号をスト
アする。カーネルがメッセージのために予約すべきデー
タの量もまた、このときにストアされる。
【００３８】ストレージ空間をカーネル・データ構造体
に従って割り当てて、アプリケーション対アプリケーシ
ョン通信を遂げるのに必要な適切な情報をストアすれ
ば、レジスタ・ルーチンはステップ２１６で終わる。
に従って割り当てて、アプリケーション対アプリケーシ
ョン通信を遂げるのに必要な適切な情報をストアすれ
ば、レジスタ・ルーチンはステップ２１６で終わる。
【００３９】デレジスタ・ルーチンは、図６に示されて
いるが、以前に遂げられたレジスタ処理を解消(decommi
ssion)する。デレジスタ・コマンドは、全管理ファンク
ションが実行され、レジスタ処理コマンドによって生成
されたカーネル・データ構造体インスタンスがリンク・
リスト・データ構造体から削除されたことを保証する。
このように、ステップ２１８において、デレジスタ（登
録解消）しようとしているアプリケーションのアプリケ
ーション・ハンドルが得られる。アプリケーションのプ
ライオリティが、そのアプリケーションがレジスタ（登
録）されている時間の間にある動作(operature) を通じ
てブースト（上昇）された場合、これはステップ２２０
で検出される。プライオリティが登録中にブーストされ
た場合、実行プライオリティをステップ２２２で調整し
て、アプリケーションをレジスタ処理する前の状態に置
く。それからカーネル・ハンドルはリンク・リストから
削除され（ステップ２２４）、このルーチンはステップ
２２６で終了する。カーネル・ハンドルをリンク・リス
トから削除すると、その結果、アプリケーションのレジ
スタ処理が解消され、その結果、レジスタ処理を通じて
管理されるレコードはもはや更新や検索のためにアクセ
スはできなくなる。
いるが、以前に遂げられたレジスタ処理を解消(decommi
ssion)する。デレジスタ・コマンドは、全管理ファンク
ションが実行され、レジスタ処理コマンドによって生成
されたカーネル・データ構造体インスタンスがリンク・
リスト・データ構造体から削除されたことを保証する。
このように、ステップ２１８において、デレジスタ（登
録解消）しようとしているアプリケーションのアプリケ
ーション・ハンドルが得られる。アプリケーションのプ
ライオリティが、そのアプリケーションがレジスタ（登
録）されている時間の間にある動作(operature) を通じ
てブースト（上昇）された場合、これはステップ２２０
で検出される。プライオリティが登録中にブーストされ
た場合、実行プライオリティをステップ２２２で調整し
て、アプリケーションをレジスタ処理する前の状態に置
く。それからカーネル・ハンドルはリンク・リストから
削除され（ステップ２２４）、このルーチンはステップ
２２６で終了する。カーネル・ハンドルをリンク・リス
トから削除すると、その結果、アプリケーションのレジ
スタ処理が解消され、その結果、レジスタ処理を通じて
管理されるレコードはもはや更新や検索のためにアクセ
スはできなくなる。
【００４０】センド・コマンドは図７のフローチャート
に示されている。センド・ファンクションは、まず、受
信側アプリケーションのレコードの位置をカーネル・デ
ータ構造体から探すが、これは、受信側アプリケーショ
ンの名前上でテキスト検索を実行することによって行わ
れる（ステップ２２８）。受信側アプリケーションに対
するエントリがデータ構造体の中に見つからない場合
は、エラー・メッセージが送信されてセンド・ルーチン
はリターンする。次に、ステップ２３０では、送信すべ
きメッセージがテストされ、受信側アプリケーションの
メッセージ・バッファのサイズを超していないことを確
認する。これは、送信すべきメッセージの長さを、カー
ネル・データ構造体１１２内のレコードの１つとして管
理されているメッセージバッファの記録されたサイズ
と、比較することによって行われる。メッセージがメッ
セージ・バッファ内に適合しない場合は、エラー・メッ
セージが生成され、センド・ルーチンはリターンする。
バッファ・サイズが超えていなかったとすると、ルーチ
ンは次に、メッセージ・バッファ内にやってくるメッセ
ージ用の十分な余裕があるかどうかを（ステップ２３２
で）テストする。この点について、メッセージ・バッフ
ァに、すでにアクセスを待っているデータが含まれてい
る場合は、その結果、全メッセージ・バッファが送信さ
れるメッセージをストアするのに利用できないことがあ
る。メッセージ・バッファがやってくるメッセージをホ
ールド（保持）できない場合は、「バッファ・フル(Buf
fer Full)」ビジー・シグナルが送られ（ステップ２３
２）、送信側アプリケーションは再度後で試すことがで
きるようになる。
に示されている。センド・ファンクションは、まず、受
信側アプリケーションのレコードの位置をカーネル・デ
ータ構造体から探すが、これは、受信側アプリケーショ
ンの名前上でテキスト検索を実行することによって行わ
れる（ステップ２２８）。受信側アプリケーションに対
するエントリがデータ構造体の中に見つからない場合
は、エラー・メッセージが送信されてセンド・ルーチン
はリターンする。次に、ステップ２３０では、送信すべ
きメッセージがテストされ、受信側アプリケーションの
メッセージ・バッファのサイズを超していないことを確
認する。これは、送信すべきメッセージの長さを、カー
ネル・データ構造体１１２内のレコードの１つとして管
理されているメッセージバッファの記録されたサイズ
と、比較することによって行われる。メッセージがメッ
セージ・バッファ内に適合しない場合は、エラー・メッ
セージが生成され、センド・ルーチンはリターンする。
バッファ・サイズが超えていなかったとすると、ルーチ
ンは次に、メッセージ・バッファ内にやってくるメッセ
ージ用の十分な余裕があるかどうかを（ステップ２３２
で）テストする。この点について、メッセージ・バッフ
ァに、すでにアクセスを待っているデータが含まれてい
る場合は、その結果、全メッセージ・バッファが送信さ
れるメッセージをストアするのに利用できないことがあ
る。メッセージ・バッファがやってくるメッセージをホ
ールド（保持）できない場合は、「バッファ・フル(Buf
fer Full)」ビジー・シグナルが送られ（ステップ２３
２）、送信側アプリケーションは再度後で試すことがで
きるようになる。
【００４１】メッセージ・バッファが送信されるメッセ
ージをホールドするのに十分であることが判明すると、
そのメッセージはその後メッセージ・バッファにステッ
プ２３４でコピーされる。次に、一連の決定が実行され
て、受信側アプリケーションに受信することを待ってい
るデータがあることを適切に通知する。これを達成する
ためのテクニックは、受信側アプリケーションのアドレ
ッシング・モードに依存する。ステップ２３６から２４
６は、これらの詳細を処理している。
ージをホールドするのに十分であることが判明すると、
そのメッセージはその後メッセージ・バッファにステッ
プ２３４でコピーされる。次に、一連の決定が実行され
て、受信側アプリケーションに受信することを待ってい
るデータがあることを適切に通知する。これを達成する
ためのテクニックは、受信側アプリケーションのアドレ
ッシング・モードに依存する。ステップ２３６から２４
６は、これらの詳細を処理している。
【００４２】特に、受信側アプリケーションが仮想８６
アプリケーションの場合、および、送信側アプリケーシ
ョンがウインドウズ・アプリケーションである場合は、
仮想８６アプリケーションのプライオリティがブースト
（上昇）されてこれが動作するようになる。これは、ス
テップ２３６および２３８においてテストされ処理され
る。受信側アプリケーションがウインドウズ・アプリケ
ーションの場合は、メッセージが受信側アプリケーショ
ンへポストされ、受信すべきデータがあることを、アラ
ート（警報）する。これは、システム仮想マシンを切り
替えることによって行う。これらのステップは、ステッ
プ２４０および２４２に図示されている。最後に、受信
側アプリケーションが仮想８６モード・アプリケーショ
ンである場合、手続きはこれを検出して、以前に送信さ
れた全てのスリープ・リクエストも完了できるようにな
り、アプリケーションがデータを受信できるようにな
る。これは、ステップ２４４び２４６に図示されてい
る。アプリケーションが、受信すべきデータがあること
を通知された後で、このルーチンはステップ２４８でリ
ターンする。
アプリケーションの場合、および、送信側アプリケーシ
ョンがウインドウズ・アプリケーションである場合は、
仮想８６アプリケーションのプライオリティがブースト
（上昇）されてこれが動作するようになる。これは、ス
テップ２３６および２３８においてテストされ処理され
る。受信側アプリケーションがウインドウズ・アプリケ
ーションの場合は、メッセージが受信側アプリケーショ
ンへポストされ、受信すべきデータがあることを、アラ
ート（警報）する。これは、システム仮想マシンを切り
替えることによって行う。これらのステップは、ステッ
プ２４０および２４２に図示されている。最後に、受信
側アプリケーションが仮想８６モード・アプリケーショ
ンである場合、手続きはこれを検出して、以前に送信さ
れた全てのスリープ・リクエストも完了できるようにな
り、アプリケーションがデータを受信できるようにな
る。これは、ステップ２４４び２４６に図示されてい
る。アプリケーションが、受信すべきデータがあること
を通知された後で、このルーチンはステップ２４８でリ
ターンする。
【００４３】スリープ・リクエストは、以下で十分に説
明するが、メッセージを仮想８６モードＤＯＳアプリケ
ーションへ送信することができるようになり、この際に
ＤＯＳアプリケーションは、これに送信されるメッセー
ジをポーリングする間、継続して動作する必要はない。
ポーリング・テクニックが使用できる間、動作するＤＯ
Ｓアプリケーションは、他で使用できたはずのプロセッ
サ・サイクルを消費してしまう。スリープ・リクエスト
によって、ＤＯＳアプリケーションは、メッセージを受
信するために起こされるか割り込まれるまで（不必要な
プロセッサ・サイクルをまったく消費せずに）スリープ
できるようになる。
明するが、メッセージを仮想８６モードＤＯＳアプリケ
ーションへ送信することができるようになり、この際に
ＤＯＳアプリケーションは、これに送信されるメッセー
ジをポーリングする間、継続して動作する必要はない。
ポーリング・テクニックが使用できる間、動作するＤＯ
Ｓアプリケーションは、他で使用できたはずのプロセッ
サ・サイクルを消費してしまう。スリープ・リクエスト
によって、ＤＯＳアプリケーションは、メッセージを受
信するために起こされるか割り込まれるまで（不必要な
プロセッサ・サイクルをまったく消費せずに）スリープ
できるようになる。
【００４４】レシーブ・ルーチンはセンド・ルーチンを
補完している。センド・ルーチンは、メッセージ・バッ
ファ内のデータのコピーを受信側アプリケーションのア
プリケーション・バッファへ渡す所で去り、レシーブ・
ルーチンが始まる。このルーチンは図８に示されてい
る。これはステップ２５０で、情報を受信しようとして
いるアプリケーションのハンドルを得ることによって始
まる。このルーチンは、カーネル・データ構造体のリン
ク・リスト・レコードを検索し、アプリケーションの場
所を名前によって調べる（ステップ２５２）。アプリケ
ーション名が見つからない場合は、エラーが報告されて
ルーチンはリターンする。次に、受信側アプリケーショ
ンのバッファ・サイズが、カーネル・メッセージ・バッ
ファ内にストアされたデータの現在のサイズと比較され
る（ステップ２５４）。アプリケーション・バッファが
小さすぎてメッセージ・バッファ内にストアされるメッ
セージを入れるのに十分でない場合は、エラーが報告さ
れてルーチンはリターンする。メッセージ・バッファ内
にストアされたデータの現在のサイズが０の場合は、受
信すべきものはなく、ルーチンは単に、０バイトの受信
するデータがあることを示してリターンする。これはス
テップ２５６および２５８に示されている。
補完している。センド・ルーチンは、メッセージ・バッ
ファ内のデータのコピーを受信側アプリケーションのア
プリケーション・バッファへ渡す所で去り、レシーブ・
ルーチンが始まる。このルーチンは図８に示されてい
る。これはステップ２５０で、情報を受信しようとして
いるアプリケーションのハンドルを得ることによって始
まる。このルーチンは、カーネル・データ構造体のリン
ク・リスト・レコードを検索し、アプリケーションの場
所を名前によって調べる（ステップ２５２）。アプリケ
ーション名が見つからない場合は、エラーが報告されて
ルーチンはリターンする。次に、受信側アプリケーショ
ンのバッファ・サイズが、カーネル・メッセージ・バッ
ファ内にストアされたデータの現在のサイズと比較され
る（ステップ２５４）。アプリケーション・バッファが
小さすぎてメッセージ・バッファ内にストアされるメッ
セージを入れるのに十分でない場合は、エラーが報告さ
れてルーチンはリターンする。メッセージ・バッファ内
にストアされたデータの現在のサイズが０の場合は、受
信すべきものはなく、ルーチンは単に、０バイトの受信
するデータがあることを示してリターンする。これはス
テップ２５６および２５８に示されている。
【００４５】先行するテストが実行された後、メッセー
ジ・バッファ内にストアされたデータは、アプリケーシ
ョン・バッファにステップ２６０でコピーされ、メッセ
ージはそのアプリケーションにリターンされ、どれだけ
のデータが送信されたかを知らせる（ステップ２６
２）。データがメッセージ・バッファからアプリケーシ
ョン・バッファへ転送されてしまうと、メッセージ・バ
ッファは、それ後ステップ２６４で空にされ、ルーチン
はステップ２６６でリターンする。
ジ・バッファ内にストアされたデータは、アプリケーシ
ョン・バッファにステップ２６０でコピーされ、メッセ
ージはそのアプリケーションにリターンされ、どれだけ
のデータが送信されたかを知らせる（ステップ２６
２）。データがメッセージ・バッファからアプリケーシ
ョン・バッファへ転送されてしまうと、メッセージ・バ
ッファは、それ後ステップ２６４で空にされ、ルーチン
はステップ２６６でリターンする。
【００４６】スリープ・ルーチンは図９に示されてい
る。以前に述べた通り、スリープ・ルーチンによってメ
ッセージを仮想８６ＤＯＳアプリケーションへ送ること
ができるようになり、その際に、メッセージをポーリン
グしてこれらのアプリケーションが常に動作する必要は
ない。スリープ・ルーチンは、より効率のよいメッセー
ジ処理テクニックを実装しており、ＤＯＳアプリケーシ
ョンは、これのためのメッセージが来るまでサスペンド
する。
る。以前に述べた通り、スリープ・ルーチンによってメ
ッセージを仮想８６ＤＯＳアプリケーションへ送ること
ができるようになり、その際に、メッセージをポーリン
グしてこれらのアプリケーションが常に動作する必要は
ない。スリープ・ルーチンは、より効率のよいメッセー
ジ処理テクニックを実装しており、ＤＯＳアプリケーシ
ョンは、これのためのメッセージが来るまでサスペンド
する。
【００４７】スリープ・ルーチンは、スリープ状態を宣
言しようとしているアプリケーションのハンドルを取得
してそのアプリケーションがレジスタ（登録）されてい
るかチェックすることにより始まる（ステップ２６
８）。このアプリケーションがレジスタされていない場
合は、エラー・メッセージが生成されこのルーチンはリ
ターンする。アプリケーションが現在オペレーティング
・システムの仮想マシン（これは「システム仮想マシ
ン」と呼ばれる) 内で動作している場合は、その後に、
スリープ・リクエストはステップ２７０で拒絶される。
これによって、アプリケーションは、システム仮想マシ
ンであって全ウインドウズ・アプリケーションがその中
に共存するマシンをロック・アップ(lock up) しないで
すむようになる。次に、ステップ２７２おいて、アプリ
ケーションのプライオリティがレジスタ（登録）されて
いる間にブーストされていた場合は、この状態が検出さ
れてアプリケーションのプライオリティがステップ２７
４で低くされる。これはシステムの性能と効率を向上さ
せる。
言しようとしているアプリケーションのハンドルを取得
してそのアプリケーションがレジスタ（登録）されてい
るかチェックすることにより始まる（ステップ２６
８）。このアプリケーションがレジスタされていない場
合は、エラー・メッセージが生成されこのルーチンはリ
ターンする。アプリケーションが現在オペレーティング
・システムの仮想マシン（これは「システム仮想マシ
ン」と呼ばれる) 内で動作している場合は、その後に、
スリープ・リクエストはステップ２７０で拒絶される。
これによって、アプリケーションは、システム仮想マシ
ンであって全ウインドウズ・アプリケーションがその中
に共存するマシンをロック・アップ(lock up) しないで
すむようになる。次に、ステップ２７２おいて、アプリ
ケーションのプライオリティがレジスタ（登録）されて
いる間にブーストされていた場合は、この状態が検出さ
れてアプリケーションのプライオリティがステップ２７
４で低くされる。これはシステムの性能と効率を向上さ
せる。
【００４８】先行する管理ステップに続いて、スリープ
・イベントがステップ２７６においてスケジュールされ
る。スリープ・イベントは、ＤＯＳアプリケーション
を、あらかじめ定めた（スリープ・ファンクション・コ
ールへの引数として指定された）ミリ秒数だけサスペン
ド状態に置くようにも、そのアプリケーションに対する
メッセージに起こされるまで無限時間サスペンド状態に
置くようにも、スケジュールすることができる。アプリ
ケーションをサスペンドされた「スリープ」状態に置い
た後で、ルーチンはステップ２７８でリターンする。
・イベントがステップ２７６においてスケジュールされ
る。スリープ・イベントは、ＤＯＳアプリケーション
を、あらかじめ定めた（スリープ・ファンクション・コ
ールへの引数として指定された）ミリ秒数だけサスペン
ド状態に置くようにも、そのアプリケーションに対する
メッセージに起こされるまで無限時間サスペンド状態に
置くようにも、スケジュールすることができる。アプリ
ケーションをサスペンドされた「スリープ」状態に置い
た後で、ルーチンはステップ２７８でリターンする。
【００４９】本発明の汎用的な通信機構は、オペレーテ
ィング・システム環境において動作する異なるアプリケ
ーションの間の通信問題を解決することにおいて、さま
ざまな用途がある。この点において、本発明を使用し
て、インターネット・トラフィック・セキュリティを実
装するために使用される鍵管理システムのアプリケーシ
ョン・コンポーネントの間の通信ができるようになる。
出願人は、インターネット・プロトコル用のシンプル鍵
管理（Simple Key management for Inernet Protocol：
ＳＫＩＰ）システムとして知られているパケット指向の
鍵配布システムを開発している。これは、インターネッ
ト・セキュリティ内の最も難しい問題の一つ、すなわ
ち、トラフィック暗号化鍵(traffic encryption key)を
確立し、変更する方法を大いに単純化する。
ィング・システム環境において動作する異なるアプリケ
ーションの間の通信問題を解決することにおいて、さま
ざまな用途がある。この点において、本発明を使用し
て、インターネット・トラフィック・セキュリティを実
装するために使用される鍵管理システムのアプリケーシ
ョン・コンポーネントの間の通信ができるようになる。
出願人は、インターネット・プロトコル用のシンプル鍵
管理（Simple Key management for Inernet Protocol：
ＳＫＩＰ）システムとして知られているパケット指向の
鍵配布システムを開発している。これは、インターネッ
ト・セキュリティ内の最も難しい問題の一つ、すなわ
ち、トラフィック暗号化鍵(traffic encryption key)を
確立し、変更する方法を大いに単純化する。
【００５０】ＳＫＩＰシステムは、ネットワーク内の各
プリンシパル(principal) が証明(certify) された公開
鍵を有する場合は、各プリンシパルは相互に認証(authe
nticate)された鍵であって計算可能な鍵を共有し、これ
は、ほかのプリンシパルの証書(certificate) の知識だ
けに基いて行われるという事実を利用している。公開鍵
は公開鍵証書の形式で配布されるので、２つの通信する
プリンシパルは相互に認証(authenticate)された秘密事
項(secret)を共有し、これは明示的に一方のプリンシパ
ルへは通信されない。各プリンシパルはその後この秘密
事項を計算するが、これは他方のプリンシパルの認定(i
dentity)および公開鍵サーティフィケートの知識に基い
て行われる。共有された秘密事項は、例えばディフィー
・ヘルマン(Diffie-Hellman)アルゴリズムを使用して計
算してもよい。ディフィー・ヘルマン・アルゴリズムの
情報については、Ｗ．ディフィーおよびＭ．ヘルマンの
「暗号解読法における新しい方向(New Directions in C
ryptography)」(IEEE Trans. Info. Theory 、IT-22 、
６４４〜６５４頁、１９７６年) を参照せよ。
プリンシパル(principal) が証明(certify) された公開
鍵を有する場合は、各プリンシパルは相互に認証(authe
nticate)された鍵であって計算可能な鍵を共有し、これ
は、ほかのプリンシパルの証書(certificate) の知識だ
けに基いて行われるという事実を利用している。公開鍵
は公開鍵証書の形式で配布されるので、２つの通信する
プリンシパルは相互に認証(authenticate)された秘密事
項(secret)を共有し、これは明示的に一方のプリンシパ
ルへは通信されない。各プリンシパルはその後この秘密
事項を計算するが、これは他方のプリンシパルの認定(i
dentity)および公開鍵サーティフィケートの知識に基い
て行われる。共有された秘密事項は、例えばディフィー
・ヘルマン(Diffie-Hellman)アルゴリズムを使用して計
算してもよい。ディフィー・ヘルマン・アルゴリズムの
情報については、Ｗ．ディフィーおよびＭ．ヘルマンの
「暗号解読法における新しい方向(New Directions in C
ryptography)」(IEEE Trans. Info. Theory 、IT-22 、
６４４〜６５４頁、１９７６年) を参照せよ。
【００５１】ＳＫＩＰテクニックに従って、個々のＩＰ
パケットは、ランダムに生成されたパケット鍵を使用し
て、暗号化（若しくは認証) される。パケット鍵を暗号
化するのに使用されるプロセスは、効率のためにキャッ
シュすることができ、トラフィック鍵（すなわちパケッ
ト鍵) を大変高速に修正することができるようになる
が、必要であれば、修正は、パケットごとの基本によっ
てもよい。これは、従来の公開鍵の操作の計算上のオー
バヘッドを大いに削減する。さらに、この鍵はパケット
内でそれ自体が通信されるので、ＩＰ層の下の擬似セッ
ション層のオーバヘッドと複雑さを招じる必要はない。
パケットは、ランダムに生成されたパケット鍵を使用し
て、暗号化（若しくは認証) される。パケット鍵を暗号
化するのに使用されるプロセスは、効率のためにキャッ
シュすることができ、トラフィック鍵（すなわちパケッ
ト鍵) を大変高速に修正することができるようになる
が、必要であれば、修正は、パケットごとの基本によっ
てもよい。これは、従来の公開鍵の操作の計算上のオー
バヘッドを大いに削減する。さらに、この鍵はパケット
内でそれ自体が通信されるので、ＩＰ層の下の擬似セッ
ション層のオーバヘッドと複雑さを招じる必要はない。
【００５２】マイクロソフト・ウインドウズ・プラット
フォーム上にＳＫＩＰ鍵管理システムを実装することに
は、典型的には、複数の異なるアプリケーションが含ま
れ、これは鍵マネージャと構成設定プログラムを含み、
これらは互いに通信する必要がある。
フォーム上にＳＫＩＰ鍵管理システムを実装することに
は、典型的には、複数の異なるアプリケーションが含ま
れ、これは鍵マネージャと構成設定プログラムを含み、
これらは互いに通信する必要がある。
【００５３】ＳＫＩＰシステムの鍵マネージャはバック
グラウンドで非同期に(asynchronously)動作するが、こ
れは問題をひきおこす。マイクロソフト・ウインドウズ
は「協調(cooperative) 」マルチタスク環境を提供する
が、ここではウインドウズ・アプリケーションはほかの
ウインドウズ・アプリケーションに対する制御を放棄す
るまで動作することができる。このように、動作中のウ
インドウズ・アプリケーションは、必要なときに鍵マネ
ージャが動作しないようにすることができる。
グラウンドで非同期に(asynchronously)動作するが、こ
れは問題をひきおこす。マイクロソフト・ウインドウズ
は「協調(cooperative) 」マルチタスク環境を提供する
が、ここではウインドウズ・アプリケーションはほかの
ウインドウズ・アプリケーションに対する制御を放棄す
るまで動作することができる。このように、動作中のウ
インドウズ・アプリケーションは、必要なときに鍵マネ
ージャが動作しないようにすることができる。
【００５４】本発明の汎用的な通信機構は、この問題を
解決するが、これは、鍵マネージャを仮想８６ＤＯＳア
プリケーションとして実装できるようにすることによっ
て行う。仮想８６ＤＯＳアプリケーションは、分離した
仮想マシン内で動作し、これらはウインドウズ・アプリ
ケーションとは分離してスケジュールされる。このよう
に仮想８６ＤＯＳ鍵マネージャは、非同期にバックグラ
ウンドに動作することができ、その際に並行実行するウ
インドウズ・アプリケーションによるプリエンプト(pre
empt) 処理は必要ない。
解決するが、これは、鍵マネージャを仮想８６ＤＯＳア
プリケーションとして実装できるようにすることによっ
て行う。仮想８６ＤＯＳアプリケーションは、分離した
仮想マシン内で動作し、これらはウインドウズ・アプリ
ケーションとは分離してスケジュールされる。このよう
に仮想８６ＤＯＳ鍵マネージャは、非同期にバックグラ
ウンドに動作することができ、その際に並行実行するウ
インドウズ・アプリケーションによるプリエンプト(pre
empt) 処理は必要ない。
【００５５】マイクロソフト・ウインドウズ環境でサポ
ートされているアドレッシング・モードの多様性に対し
て、汎用的な通信機構は、ＳＫＩＰ鍵管理システム作業
を行うための効率のよい解決方法を提供する。鍵マネー
ジャは、仮想８６ＤＯＳアプリケーションとして実装す
ることができ、この際に、システムのほかの部分がほか
の仮想８６ＤＯＳアプリケーション、１６ビット・ウイ
ンドウズ・アプリケーション、および３２ビット・ウイ
ンドウズ・アプリケーションとして実装されることから
制限されることはなく、これは特定のシステム要件に依
存する。これらのアプリケーション・コンポーネント
は、容易に、本発明の汎用的な通信機構のＡＰＩファン
クション・コール・サービスを通じて互いに通信するこ
とができる。
ートされているアドレッシング・モードの多様性に対し
て、汎用的な通信機構は、ＳＫＩＰ鍵管理システム作業
を行うための効率のよい解決方法を提供する。鍵マネー
ジャは、仮想８６ＤＯＳアプリケーションとして実装す
ることができ、この際に、システムのほかの部分がほか
の仮想８６ＤＯＳアプリケーション、１６ビット・ウイ
ンドウズ・アプリケーション、および３２ビット・ウイ
ンドウズ・アプリケーションとして実装されることから
制限されることはなく、これは特定のシステム要件に依
存する。これらのアプリケーション・コンポーネント
は、容易に、本発明の汎用的な通信機構のＡＰＩファン
クション・コール・サービスを通じて互いに通信するこ
とができる。
【００５６】本発明を現在の好適実施形態において説明
してきたが、請求の範囲に記載した本発明の精神から離
れずに前述のものに対するある種の変更は可能である。
してきたが、請求の範囲に記載した本発明の精神から離
れずに前述のものに対するある種の変更は可能である。
【００５７】以下は付録である。
【００５８】マップ・フラットの擬似コード 現在の仮想マシン・ハンドルを得る 渡されたアドレスからアドレスの上位１６ビットを（Ｓ
内に）得る アドレスの下位１６ビットを（変数Offset内に）得る 現在の仮想マシンがシステム仮想マシンでない場合であ
って、かつ、呼び出し側が仮想８６モードで動作してい
る場合は、 フラット・アドレス＝Ｓ＊１６＋ Offset ＋その現在の
仮想マシンに対する高位のリニア・アドレス そうでない場合は、呼出側のコード・セレクタに対する
デスクリプタを得る これがＢＩＧセグメントである場合はこれは３２ビット
呼出側である 呼出側のデータ・セレクタを得る データ・セレクタのデスクリプタを得る フラット・アドレス＝オフセット＋３２ビット・デスク
リプタ・ベース・アドレス そうでない場合は、Ｓに対するデスクリプタを得る フラット・アドレス＝オフセット＋３２ビット・デスク
リプタ・ベース・アドレス好ましいデータ構造体 struct kernhandle { struct kernhandle *next; /*リスト 内の次へのホ゜インタ */ unsigned char name[16]; /*ユーサ゛ に表示するアフ゜リケーション名 */ unsigned short postmsg o; /*ウイント゛ウス postmessage()のアト゛レス */ unsigned short postmsg s; unsigned short hwnd; /*このアフ゜リケーションのウイント゛ウス゛・ハント゛ル */ unsigned short msg2post; /*postmessage() 用のメッセーシ゛ 番号 */ unsigned long bufsize; /*アフ゜リケーションのハ゛ッファ・サイス゛ */ unsigned long cursize; /*ハ゛ッファ内で使用中のテ゛ータ の量 */ char *msgbuf; /*これのメッセーシ゛・ハ゛ッファへのホ゜インタ */ unsigned long hmsgbuf; /*msgbuf メモリ・ハント゛ル */ unsigned long numlost; /*オーハ゛ーフロー のために失なわれたメッセーシ゛ の数 */ VMHANDLE vm; /*アフ゜リケーションが動作する仮想マシン */ unsigned long status; /*アフ゜リケーションが動作するモート゛(V86, PM16, PM32)*/ unsigned long sleepsem; /*セマフォ・ハント゛ル */ unsigned long prio boosted; /*フ゜ライオリティ をすでに上昇したことを示すフラク゛ */};
内に）得る アドレスの下位１６ビットを（変数Offset内に）得る 現在の仮想マシンがシステム仮想マシンでない場合であ
って、かつ、呼び出し側が仮想８６モードで動作してい
る場合は、 フラット・アドレス＝Ｓ＊１６＋ Offset ＋その現在の
仮想マシンに対する高位のリニア・アドレス そうでない場合は、呼出側のコード・セレクタに対する
デスクリプタを得る これがＢＩＧセグメントである場合はこれは３２ビット
呼出側である 呼出側のデータ・セレクタを得る データ・セレクタのデスクリプタを得る フラット・アドレス＝オフセット＋３２ビット・デスク
リプタ・ベース・アドレス そうでない場合は、Ｓに対するデスクリプタを得る フラット・アドレス＝オフセット＋３２ビット・デスク
リプタ・ベース・アドレス好ましいデータ構造体 struct kernhandle { struct kernhandle *next; /*リスト 内の次へのホ゜インタ */ unsigned char name[16]; /*ユーサ゛ に表示するアフ゜リケーション名 */ unsigned short postmsg o; /*ウイント゛ウス postmessage()のアト゛レス */ unsigned short postmsg s; unsigned short hwnd; /*このアフ゜リケーションのウイント゛ウス゛・ハント゛ル */ unsigned short msg2post; /*postmessage() 用のメッセーシ゛ 番号 */ unsigned long bufsize; /*アフ゜リケーションのハ゛ッファ・サイス゛ */ unsigned long cursize; /*ハ゛ッファ内で使用中のテ゛ータ の量 */ char *msgbuf; /*これのメッセーシ゛・ハ゛ッファへのホ゜インタ */ unsigned long hmsgbuf; /*msgbuf メモリ・ハント゛ル */ unsigned long numlost; /*オーハ゛ーフロー のために失なわれたメッセーシ゛ の数 */ VMHANDLE vm; /*アフ゜リケーションが動作する仮想マシン */ unsigned long status; /*アフ゜リケーションが動作するモート゛(V86, PM16, PM32)*/ unsigned long sleepsem; /*セマフォ・ハント゛ル */ unsigned long prio boosted; /*フ゜ライオリティ をすでに上昇したことを示すフラク゛ */};
【００５９】
【発明の効果】本発明のユニバーサルな通信機構は、オ
ペレーティング・システム環境において動作する異なる
アプリケーションの間の通信問題を解決することにおい
て、さまざまな用途がある。
ペレーティング・システム環境において動作する異なる
アプリケーションの間の通信問題を解決することにおい
て、さまざまな用途がある。
【００６０】特に、マイクロソフト・ウインドウズ環境
でサポートされているアドレッシング・モードの多様性
に対して、ユニバーサルな通信機構は、ＳＫＩＰ鍵管理
システム作業を行うための効率のよい解決方法を提供す
る。
でサポートされているアドレッシング・モードの多様性
に対して、ユニバーサルな通信機構は、ＳＫＩＰ鍵管理
システム作業を行うための効率のよい解決方法を提供す
る。
【図１】本発明を実装することができるコンピュータ環
境の典型的なシステム・ブロック図である。
境の典型的なシステム・ブロック図である。
【図２】３つの異なるアプリケーション・プログラムの
メモリ・アドレッシング・モードを説明するブロック図
であり、メモリ・アドレッシング・モードが異なる場合
の直接アプリケーション対アプリケーション通信の問題
点を理解するために役立つ。
メモリ・アドレッシング・モードを説明するブロック図
であり、メモリ・アドレッシング・モードが異なる場合
の直接アプリケーション対アプリケーション通信の問題
点を理解するために役立つ。
【図３】汎用的な通信機構のサブシステム・ブロック図
であり、現在の好適実施形態に従った通信機構の主要な
コンポーネントの概要を与える。
であり、現在の好適実施形態に従った通信機構の主要な
コンポーネントの概要を与える。
【図４】図３の汎用的な通信機構の詳細なブロック図で
ある。
ある。
【図５】レジスタ(Register)・ルーチンのフローチャー
トである。
トである。
【図６】デレジスタ(Deregister)・ルーチンのフローチ
ャートである。
ャートである。
【図７】センド(Send)・ルーチンのフローチャートであ
る。
る。
【図８】レシーブ(Receive）・ルーチンのフローチャー
トである。
トである。
【図９】スリープ(Sleep）・ルーチンのフローチャート
である。
である。
２０ コンピュータ ２２ ローカル・エリア・ネットワーク ２４ インターネット・サーバ・デバイス ２６ リモート・コンピュータ ２８ ウインドウズ３Ｘ ３０ ウインドウズ９５ ３２ ウインドウズＮＴ ３４ ハード・ディスク ３６ フロッピー・ディスク ３８ ＣＤ−ＲＯＭ ４０ ハード・ディスク ４２ ハード・ディスク ４４ 通信リンク ４６ ハード・ディスク ４８ 仮想８６ＤＯＳアプリケーション ５０ １６ビット・ウインドウズ・アプリケーション ５２ ３２ビット・ウインドウズ・アプリケーション ５４ ウインドウズ・オペレーティング・システム ５８ １６ビット・オフセット・アドレス ６０ １６ビット・セグメント・アドレス ６２ ２０ビット・リンク・アドレス ６４ １６ビット・セレクタ ６６ デスクリプタ表 ６８ ３２ビット・ベース・アドレス ７０ １６ビット・オフセット ７２ ３２ビット・リニア・アドレス ７４ ３２ビット・リニア・アドレス ７６ デバイス・ドライバ ７８ ＡＰＩインターフェース ８０ メッセージ・ハンドラ ８２ マッピング機構 ８４ データ・ストアおよびメッセージ・バッファ ８６ 転送機構 ８８ カーネル・モジュール ９０ ＡＰＩハンドラ・モジュール ９２ 呼び出し可能ファンクション ９４ 内部ファンクション ９６ レジスタ ９８ デレジスタ １００ センド １０２ レシーブ １０４ スリープ １０６ データ構造体管理 １０８ データ構造体ルックアップ １１０ アドレス・マッピング １１２ カーネル・データ構造体
───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者 ジェイムズ ディー． デイヴィス アメリカ合衆国 01463 マサチューセッ ツ州 ペパール ワン メリマック ドラ イブ（番地なし) (72)発明者 マーク エス． ダイ アメリカ合衆国 93010 カリフォルニア 州 カマリロ ストーンメドウ コート 1393
Claims (45)
- 【請求項１】 オペレーティング・システム環境で動作
し、異なるメモリ・アドレッシング・モードを利用する
コンピュータに実装されたアプリケーションの間で、前
記環境内において情報を渡すための通信機構において、 前記オペレーティング・システム環境に結合され、あら
かじめ定めたファンクション・コールのセットを通じて
前記アプリケーションと通信するためのアプリケーショ
ン・プログラム・インタフェースを有するデバイス・ド
ライバと、 前記デバイス・ドライバは、前記ファンクション・コー
ルに応答するメッセージ・ハンドラ、および、少なくと
も２つの前記アプリケーションの間のバッファリングさ
れた通信を確立するためのメッセージ・バッファを有
し、１つのアプリケーションは受信側アプリケーション
で１つのアプリケーションは送信側アプリケーションで
あり、該送信側アプリケーションは、該受信側アプリケ
ーション用を意図した、あらかじめ定めた情報を発行
し、 前記メッセージ・ハンドラに結合され、前記送信側アプ
リケーションのアドレッシング・モードを調べて決める
ように、および、前記送信側アプリケーションのアドレ
ッシング・モードをあらかじめ定めたアドレッシング・
モードへ変換するように構成されたマッピング機構と、 前記メッセージ・ハンドラに結合され、前記マッピング
機構を使用して前記あらかじめ定めた情報を前記メッセ
ージ・バッファ内へコピーし、その後に、前記メッセー
ジ・バッファへアクセスして前記あらかじめ定めた情報
をコピーするように、前記受信側アプリケーションをシ
グナルするメッセージ転送機構とを備え、 前記あらかじめ定めた情報のコピーは該受信側アプリケ
ーションと該送信側アプリケーションとの間で渡され、
その際に該受信側アプリケーションは該送信側アプリケ
ーションのアドレッシング・モードを知る必要がないこ
とを特徴とする通信機構。 - 【請求項２】 請求項１に記載の通信機構において、 前記オペレーティング・システム環境は、第１のアドレ
ッシング・モードのアプリケーション・プログラムの実
行のための第１の仮想マシンと、第２のアドレッシング
・モードのアプリケーション・プログラムの実行のため
の第２の仮想マシンとをサポートし、および、 前記デバイス・ドライバは、バッファリングされた通信
を前記第１の仮想マシンで動作する第１のアプリケーシ
ョン・プログラムと前記第２の仮想マシンで動作する第
２のアプリケーション・プログラムとの間で確立するこ
とを特徴とする通信機構。 - 【請求項３】 請求項２に記載の通信機構において、前
記第１の仮想マシンがウインドウズ仮想マシンであるこ
とを特徴とする通信機構。 - 【請求項４】 請求項２に記載の通信機構において、前
記第２の仮想マシンがＤＯＳ仮想８６仮想マシンである
ことを特徴とする通信機構。 - 【請求項５】 請求項１に記載の通信機構において、 前記デバイス・ドライバは、バッファリングされた通信
を複数のアプリケーション間で確立し、および、 前記デバイス・ドライバは、メッセージ・バッファを前
記複数のアプリケーションのそれぞれに対して割り当て
ることを特徴とする通信機構。 - 【請求項６】 請求項１に記載の通信機構において、 前記メッセージ・ハンドラは、バッファリングされた通
信を確立しようとしている第１のアプリケーションによ
るレジスタ・ファンクション・コールに応答し、およ
び、 前記メッセージ・ハンドラは、前記レジスタ・ファンク
ション・コールに応答して、前記第１のアプリケーショ
ン用の第１のメッセージ・バッファを割り当てることを
特徴とする通信機構。 - 【請求項７】 請求項１に記載の通信機構において、 前記メッセージ・ハントラは、バッファリングされた通
信を終了しようとしている第１のアプリケーションによ
るデレジスタ・ファンクション・コールに応答し、 前記第１のアプリケーションは、対応する第１のメッセ
ージ・バッファを有し、および、 前記メッセージ・ハンドラは、前記デレジスタ・ファン
クション・コールに応答して、前記第１のメッセージ・
バッファの割り当てを解放することを特徴とする通信機
構。 - 【請求項８】 請求項１に記載の通信機構において、 前記メッセージ・ハンドラは、前記送信側アプリケーシ
ョンによるセンド・メッセージに応答し、および前記メ
ッセージ・ハンドラは、前記センド・ファンクション・
コールの応答において前記あらかじめ定めた情報を前記
メッセージ・バッファ内に置き、および、前記受信側ア
プリケーションへのメッセージをポストして前記受信側
アプリケーションを前記メッセージ・バッファにアクセ
スするようにシグナルすることを特徴とする通信機構。 - 【請求項９】 請求項１に記載の通信機構において、 前記受信側アプリケーションは、あらかじめ定めたアプ
リケーション・バッファを有し、 前記メッセージ・ハンドラは、前記受信側アプリケーシ
ョンによるレシーブ・ファンクション・コールに応答
し、および、 前記メッセージ・ハンドラは、前記レシーブ・ファンク
ション・コールに応答して、前記メッセージ・バッファ
にアクセスし、かつ、前記あらかじめ定めた情報を前記
アプリケーション・バッファ内へコピーすることを特徴
とする通信機構。 - 【請求項１０】 請求項１に記載の通信機構において、 前記メッセージ・ハンドラは、第１のアプリケーション
によるスリープ・ファンクション・コールに応答し、こ
こで、前記メッセージ・ハンドラは、前記第１のアプリ
ケーションに対して、バッファリングされた通信が前記
第１のアプリケーションと前記送信側アプリケーション
との間で確立されるまでそれ以降の操作をサスペンドさ
せ、その際に前記第１のアプリケーションは、前記受信
側アプリケーションとして作動していることを特徴とす
る通信機構。 - 【請求項１１】 請求項１に記載の通信機構であって、
さらに、 前記デバイス・ドライバによって管理されるデータ・ス
トアを備え、 前記データ・ストアは、前記送信側および受信側アプリ
ケーションのアドレッシング・モードをストアするため
のメモリ割り当てが含まれている、あらかじめ定めたデ
ータ構造にしたがって構成されることを特徴とする通信
機構。 - 【請求項１２】 請求項１に記載の通信機構であって、
さらに、前記デバイス・ドライバによって管理されるデ
ータ・ストアを備え、前記データ・ストアは、前記送信
側および受信側アプリケーションに対応するリスト内の
それぞれのエントリを有している、リンクされたリスト
として構成されることを特徴とする通信機構。 - 【請求項１３】 請求項１に記載の通信機構であって、
さらに、前記デバイス・ドライバによって管理されるデ
ータ・ストアを備え、前記データ・ストアは、前記送信
側および受信側アプリケーションの動作状態を上げるた
めのプライオリティをストアするメモリ割り当てが含ま
れている、あらかじめ定めたデータ構造にしたがって構
成されることを特徴とする通信機構。 - 【請求項１４】 請求項１に記載の通信機構であって、
さらに、前記デバイス・ドライバによって管理されるデ
ータ・ストアを備え、 前記データ・ストアは、前記受信側アプリケーションに
前記メッセージ・バッファにアクセスするようシグナル
するために使用され、あらかじめ定めたデータをストア
するメモリ割り当てが含まれている、あらかじめ定めた
データ構造にしたがって構成されることを特徴とする通
信機構。 - 【請求項１５】 請求項１に記載の通信機構であって、
さらに、前記デバイス・ドライバによって管理されるデ
ータ・ストアを備え、前記データ・ストアは前記メッセ
ージ・バッファを定義するあらかじめ定めたデータ構造
にしたがって構成されることを特徴とする通信機構。 - 【請求項１６】 異なるメモリ・アドレッシング・モー
ドを利用するコンピュータ実装されたアプリケーション
をサポートする種類のオペレーティング・システム環境
を有するコンピュータ・システムにおいて使用するため
の製品において、 前記オペレーティング・システム環境に接続するための
デバイス・ドライバを有するコンピュータ使用可能な配
布媒体であって、前記デバイス・ドライバは、前記アプ
リケーションとの通信をあらかじめ定めたファンクショ
ン・コールのセットを通じて提供するよう構成されたア
プリケーション・プログラム・インタフェースを有する
配布媒体と、 前記デバイス・ドライバは、前記ファンクション・コー
ルに応答するよう構成されたメッセージ・ハンドラを有
し、かつ、メッセージ・バッファを定義して少なくとも
２つのアプリケーションの間のバッファリングされた通
信をサポートするプログラム・コードを有し、 前記デバイス・ドライバは、前記メッセージ・ハンドラ
とのマッピング機構インタフェースを有し、および、前
記アプリケーションのアドレッシング・モードを調べて
決定して前記アドレッシング・モードをあらかじめ定め
たアドレッシング・モードへ変換するように構成され、 前記デバイス・ドライバは、前記メッセージ・ハンドラ
とのメッセージ転送機構インタフェースを有し、かつ、
情報を前記アプリケーションの少なくとも１つから前記
メッセージ・バッファ内へコピーし、その後、少なくと
も１つの前記アプリケーションに前記メッセージ・バッ
ファをアクセスして前記情報を得るようシグナルするよ
う構成されることを特徴とする製品。 - 【請求項１７】 請求項１６に記載の製品において、 前記オペレーティング・システム環境は、第１のアドレ
ッシング・モードのアプリケーション・プログラムのた
めの第１の仮想マシンと、第２のアドレッシング・モー
ドのアプリケーション・プログラムのための第２の仮想
マシンとをサポートし、および、 前記デバイス・ドライバは、バッファリングされた通信
を、前記第１の仮想マシン内で動作する第１のアプリケ
ーション・プログラムと、前記第２の仮想マシン内で動
作する第２のアプリケーション・プログラムとの間で確
立するよう構成されていることを特徴とする製品。 - 【請求項１８】 請求項１７に記載の製品において、前
記第１の仮想マシンはウインドウズ仮想マシンであるこ
とを特徴とする製品。 - 【請求項１９】 請求項１７に記載の製品において、前
記第２の仮想マシンはＤＯＳ仮想８６仮想マシンである
ことを特徴とする製品。 - 【請求項２０】 請求項１６に記載の製品において、前
記デバイス・ドライバは、複数のアプリケーションの間
のバッファリングされた通信を確立するよう構成され、
かつ、前記デバイス・ドライバは前記複数のアプリケー
ションのそれぞれのためにメッセージ・バッファを割り
当てるよう構成されていることを特徴とする製品。 - 【請求項２１】 請求項１６に記載の製品において、 前記メッセージ・ハンドラは、バッファリングされた通
信を確立しようとする第１のアプリケーションによるレ
ジスタ・ファンクション・コールに応答するためのプロ
グラム・コードを含み、および、 前記メッセージ・ハンドラは、前記レジスタ・ファンク
ション・コールに応答して、前記第１のアプリケーショ
ン用の第１のメッセージ・バッファを割り当てるように
構成されていることを特徴とする製品。 - 【請求項２２】 請求項１６に記載の製品において、前
記メッセージ・ハンドラは、バッファリングされた通信
を終了しようとしている第１のアプリケーションによる
デレジスタ・ファンクション・コールに応答するための
プログラム・コードを含み、かつ、前記メッセージ・ハ
ンドラは、前記デレジスタ・ファンクション・コールに
応答して、前記第１のアプリケーションに対応付けたメ
ッセージ・バッファの割り当てを解放するように構成さ
れていることを特徴とする製品。 - 【請求項２３】 請求項１６に記載の製品において、 前記メッセージ・ハンドラは第１のアプリケーションに
よるセンド・ファンクション・コールに対応するための
プログラム・コードを含み、および、 前記メッセージ・ハンドラは、前記第１のアプリケーシ
ョンからの情報を前記メッセージ・バッファ内に置き、
および、第２のアプリケーションへのメッセージをポス
トして前記第２のアプリケーションを前記メッセージ・
バッファにアクセスするようにシグナルすることによっ
て、前記センド・ファンクション・コールに応答するよ
うに構成されていることを特徴とする製品。 - 【請求項２４】 請求項１６に記載の製品において、前
記メッセージ・ハンドラは、第１のアプリケーションに
よるレシーブ・ファンクョン・コールに応答するための
プログラム・コードを含み、かつ、前記メッセージ・ハ
ンドラは、前記メッセージ・バッファにアクセスして情
報を前記アプリケーションへコピーすることによって、
前記レシーブ・ファンクション・コールに応答するよう
に構成されていることを特徴とする製品。 - 【請求項２５】 請求項１６に記載の製品において、前
記メッセージ・ハンドラは第１のアプリケーションによ
るスリープ・ファンクション・コールに応答するための
プログラム・コードを含み、および、前記メッセージ・
ハンドラは、前記スリープ・ファンクション・コールに
応答して、バッファリングされた通信が前記第１アプリ
ケーションと第２のアプリケーションとの間で確立され
るまで、前記第１のアプリケーションの動作をサスペン
ドするよう構成されていることを特徴とする製品。 - 【請求項２６】 請求項１６に記載の製品において、さ
らに、前記デバイス・ドライバによって管理されるデー
タ・ストアを確立するためのプログラム・コードを備
え、前記データ・ストアは、前記送信側および受信側ア
プリケーションのアドレッシング・モードをストアする
ためのメモリ割り当てを含む、あらかじめ定めたデータ
構造にしたがって構成されることを特徴とする製品。 - 【請求項２７】 請求項１６に記載の製品において、さ
らに、前記デバイス・ドライバによって管理されるデー
タ・ストアを確立するためのプログラム・コードを備
え、前記データ・ストアは、リンク・リストであって、
前記送信側および受信側アプリケーションに対応する該
リスト内のそれぞれのエントリを有するリンク・リスト
として構成されていることを特徴とする製品。 - 【請求項２８】 請求項１６に記載の製品において、さ
らに、前記デバイス・ドライバによって管理されるデー
タ・ストアを確立するためのプログラム・コードを備
え、前記データ・ストアは、前記送信側および受信側ア
プリケーションの動作状態を上げるためのプライオリテ
ィをストアするメモリ割り当てを含む、あらかじめ定め
たデータ構造にしたがって構成されることを特徴とする
製品。 - 【請求項２９】 請求項１６に記載の製品において、さ
らに、前記デバイス・ドライバによって管理されるデー
タ・ストアを確立するためのプログラム・コードを備
え、前記データ・ストアは、前記受信側アプリケーショ
ンを前記メモリ・バッファへアクセスするようシグナル
するのに使用されるあらかじめ定めたデータをストアす
るためのメモリ割り当てを含む、あらかじめ定めたデー
タ構造にしたがって構成されることを特徴とする製品。 - 【請求項３０】 請求項１６に記載の製品において、さ
らに、前記デバイス・ドライバによって管理されるデー
タ・ストアを確立するためのプログラム・コードを備
え、前記データ・ストアは、前記メッセージ・バッファ
を定義するためのあらかじめ定めたデータ構造にしたが
って構成されることを特徴とする製品。 - 【請求項３１】 オペレーティング・システム環境内に
おいて、前記環境内で動作し、異なるメモリ・アドレッ
シング・モードを利用するコンピュータ実装されたアプ
リケーションの間の通信を処理するための方法におい
て、 前記オペレーティング・システムに結合されたデバイス
・ドライバを提供し、および、アプリケーション・プロ
グラム・インタフェースに前記アプリケーションとあら
かじめ定めたファンクション・コールのセットを通じて
通信させるステップと、 第１のファンクション・コールに応答して、メッセージ
・バッファを確立して少なくとも２つの前記アプリケー
ションの間のバッファリングされた通信をサポートし、
１つのアプリケーションは送信側アプリケーションであ
り、１つのアプリケーションは受信側アプリケーション
であり、該送信側アプリケーションは、受信側アプリケ
ーションのためを意図したあらかじめ定めた情報を有す
るステップと、 前記送信側アプリケーションのアドレッシング・モード
を調べて決定し、該送信側アプリケーションのアドレッ
シング・モードをあらかじめ定めたアドレッシング・モ
ードへ変換するステップと、 前記送信側アプリケーションによる第２のファンクショ
ン・コールに応答して、前記あらかじめ定めた情報を前
記送信側アプリケーションから前記メッセージ・バッフ
ァへコピーし、および、前記受信側アプリケーションを
シグナルするステップと、および、 前記受信側アプリケーションによる第３のファンクショ
ン・コールに対する応答において、前記あらかじめ定め
た情報を前記メッセージ・バッファから前記送信側アプ
リケーションへコピーするステップとを備えることを特
徴とする方法。 - 【請求項３２】 請求項３１に記載の方法において、 前記オペレーティング・システム環境は第１のアドレッ
シング・モードのアプリケーションを実行するための第
１の仮想マシンと、第２のアドレッシング・モードのア
プリケーションを実行するための第２の仮想マシンとを
サポートし、および、 前記デバイス・ドライバは、バッファリングされた通信
を、前記第１の仮想マシン内で動作する第１のアプリケ
ーションと、前記第２の仮想マシン内で動作する第２の
アプリケーションとの間で確立することを特徴とする方
法。 - 【請求項３３】 請求項３２に記載の方法において、前
記第１の仮想マシンはウインドウズ仮想マシンであるこ
とを特徴とする方法。 - 【請求項３４】 請求項３２に記載の方法において、前
記第２の仮想マシンはＤＯＳ仮想８６仮想マシンである
ことを特徴とする方法。 - 【請求項３５】 請求項３１に記載の方法であって、さ
らに、複数のアプリケーションのそれぞれに対するメッ
セージ・バッファを割り当てるステップを備えたことを
特徴とする方法。 - 【請求項３６】 請求項３１に記載の方法において、 第１のファンクション・コールは、バッファリングされ
た通信を確立しようとしている第１のアプリケーション
によるレジスタファンクション・コールであり、 前記メッセージ・バッファを確立するステップは、前記
レジスタ・ファンクション・コールに応答して、前記第
１のアプリケーションのための第１のメッセージ・バッ
ファを確立するステップを含むことを特徴とする方法。 - 【請求項３７】 請求項３１に記載の方法であって、さ
らに、 バッファリングされた通信を終了しようとする第１のア
プリケーションによるデレジスタ・ファンクション・コ
ールに応答するステップを備え、 前記第１のアプリケーションは対応付けられた第１のメ
ッセージ・バッファを有し、 前記デレジスタ・ファンクション・コールに応答するス
テップは、前記第１のメッセージ・バッファの割り当て
を解放することによって実行されることを特徴とする方
法。 - 【請求項３８】 請求項３１に記載の方法において、第
２のファンクション・コールは、前記送信側アプリケー
ションによるセンド・ファンクション・コールであり、
前記受信側アプリケーションにシグナルする前記ステッ
プは、前記受信側アプリケーションへのメッセージを、
ポストして前記受信側アプリケーションを前記メッセー
ジ・バッファにアクセスするようにシグナルすることに
よって、実行されることを特徴とする方法。 - 【請求項３９】 請求項３１に記載の方法において、前
記受信側アプリケーションは、あらかじめ定めたアプリ
ケーション・バッファを有し、前記第３のファンクショ
ン・コールは、前記受信側アプリケーションによるレシ
ーブ・ファンクション・コールであり、前記あらかじめ
定めた情報を前記送信側アプリケーションへコピーする
前記ステップは、前記あらかじめ定めた情報を前記アプ
リケーション・バッファ内へコピーすることによって実
行されることを特徴とする方法。 - 【請求項４０】 請求項３１に記載の方法において、さ
らに、第１のアプリケーションによるスリープ・ファン
クション・コールに、前記第１のアプリケーションの動
作をバッファリングされた通信が前記第１のアプリケー
ションと前記送信側アプリケーションの間で確立される
までサスペンドことによって応答するステップを備え、
前記第１のアプリケーションは、前記受信側アプリケー
ションとして作動することを特徴とする方法。 - 【請求項４１】 請求項３１に記載の方法において、さ
らに、前記デバイス・ドライバによって管理されるデー
タ・ストアを割り当てるステップを備え、前記データ・
ストアは、前記送信側および受信側アプリケーションの
アドレッシング・モードをストアするためのメモリ割り
当てを含む、あらかじめ定めたデータ構造にしたがって
構成されることを特徴とする方法。 - 【請求項４２】 請求項３１に記載の方法において、さ
らに、 前記デバイス・ドライバによって管理されるデータ・ス
トアを割り当てるステップを備え、前記データ・ストア
は、前記送信側および受信側アプリケーションに対応す
る該リスト内のそれぞれのエントリを有するリンク・リ
ストとして構成されることを特徴とする方法。 - 【請求項４３】 請求項３１に記載の方法において、さ
らに、 前記デバイス・ドライバによって管理されるデータ・ス
トアを割り当てるステップを備え、 前記データ・ストアは、前記送信側および受信側アプリ
ケーションの動作状態を上げるためのプライオリティを
ストアするメモリ割り当てを含む、あらかじめ定めたデ
ータ構造にしたがって構成されることを特徴とする方
法。 - 【請求項４４】 請求項３１に記載の方法において、さ
らに、 前記デバイス・ドライバによって管理されるデータ・ス
トアを割り当てるステップを備え、 前記データ・ストアは、前記メッセージ・バッファにア
クセスするように前記受信側アプリケーションをシグナ
ルするために使用されるあらかじめ定めたデータをスト
アするためのメモリ割り当てを含む、あらかじめ定めた
データ構造にしたがって構成されることを特徴とする方
法。 - 【請求項４５】 請求項３１に記載の方法において、 前記デバイス・ドライバによって管理されるデータ・ス
トアを割り当てるステップを備え、 前記データ・ストアは、前記メッセージ・バッファを定
義する、あらかじめ定めたデータ構造にしたがって構成
されることを特徴とする方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/672,528 | 1996-07-02 | ||
| US08/672,528 US6535929B1 (en) | 1996-07-02 | 1996-07-02 | Universal communication mechanism for applications running in a multitasking environment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH1069391A true JPH1069391A (ja) | 1998-03-10 |
Family
ID=24698935
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP9177409A Pending JPH1069391A (ja) | 1996-07-02 | 1997-07-02 | マルチタスク環境において動作するアプリケーションのための汎用通信機構 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6535929B1 (ja) |
| EP (1) | EP0817030A3 (ja) |
| JP (1) | JPH1069391A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002288058A (ja) * | 2001-01-25 | 2002-10-04 | Yahoo Inc | 高性能クライアントサーバ通信システム |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0935192A1 (en) * | 1998-02-09 | 1999-08-11 | Sony Europa B.V. | Method and system for communication between application programs and a network |
| JP2001056766A (ja) | 1999-08-18 | 2001-02-27 | Denso Corp | マルチモジュールシステム及び対話システム |
| US6782537B1 (en) * | 1999-09-23 | 2004-08-24 | International Business Machines Corporation | Establishing a communicator across multiple processes in a multithreaded computing environment |
| EP1307000A4 (en) * | 2001-03-29 | 2007-07-04 | Sony Corp | INFORMATION PROCESSING APPARATUS |
| US7055152B1 (en) * | 2001-08-15 | 2006-05-30 | Microsoft Corporation | Method and system for maintaining buffer registrations in a system area network |
| US7552265B2 (en) * | 2002-01-23 | 2009-06-23 | Xerox Corporation | System and method for providing context information |
| US7367029B2 (en) * | 2002-08-01 | 2008-04-29 | Xerox Corporation | Method and system for handling data |
| US7478395B2 (en) * | 2002-09-23 | 2009-01-13 | Telefonaktiebolaget L M Ericsson (Publ) | Middleware application message/event model |
| EP1467282B1 (en) * | 2003-04-09 | 2008-10-01 | Jaluna SA | Operating systems |
| US8612992B2 (en) * | 2003-04-09 | 2013-12-17 | Jaluna Sa | Operating systems |
| EP1503286B1 (en) * | 2003-07-30 | 2014-09-03 | Jaluna SA | Multiple operating system networking |
| CN1922576A (zh) * | 2003-09-30 | 2007-02-28 | 扎鲁纳股份有限公司 | 操作系统 |
| US7099969B2 (en) * | 2003-11-06 | 2006-08-29 | Dell Products L.P. | Dynamic reconfiguration of PCI Express links |
| US8423643B2 (en) * | 2003-11-19 | 2013-04-16 | International Business Machines Corporation | Autonomic assignment of communication buffers by aggregating system profiles |
| US20050114549A1 (en) * | 2003-11-26 | 2005-05-26 | Durham David M. | Mechanism for extensible binary mappings for adaptable hardware/software interfaces |
| EP2392258B1 (en) | 2005-04-28 | 2014-10-08 | Proteus Digital Health, Inc. | Pharma-informatics system |
| US8646052B2 (en) * | 2008-03-31 | 2014-02-04 | Intel Corporation | Method and apparatus for providing a secure display window inside the primary display |
| US8271784B2 (en) | 2009-10-15 | 2012-09-18 | International Business Machines Corporation | Communication between key manager and storage subsystem kernel via management console |
| US9110793B2 (en) * | 2009-11-03 | 2015-08-18 | International Business Machines Corporation | Inner process |
| US20140012704A1 (en) | 2012-07-05 | 2014-01-09 | Google Inc. | Selecting a preferred payment instrument based on a merchant category |
| US9092767B1 (en) | 2013-03-04 | 2015-07-28 | Google Inc. | Selecting a preferred payment instrument |
| US9858572B2 (en) | 2014-02-06 | 2018-01-02 | Google Llc | Dynamic alteration of track data |
| CN110162415B (zh) * | 2019-05-05 | 2023-09-01 | 腾讯科技（深圳）有限公司 | 用于处理数据请求的方法、服务器、装置及存储介质 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5175855A (en) * | 1987-07-27 | 1992-12-29 | Laboratory Technologies Corporation | Method for communicating information between independently loaded, concurrently executing processes |
| DE68924040T2 (de) | 1988-10-24 | 1996-04-18 | Ibm | Verfahren zum Austauschen von Daten zwischen Programmen in einem Datenverarbeitungssystem. |
| EP0422310A1 (en) * | 1989-10-10 | 1991-04-17 | International Business Machines Corporation | Distributed mechanism for the fast scheduling of shared objects |
| US5604885A (en) * | 1991-02-01 | 1997-02-18 | Texas Instruments Incorporated | Apparatus and method enabling a computer to transfer control between two program segments that call one another but operate in different modes |
| US5327558A (en) * | 1992-04-30 | 1994-07-05 | Motorola, Inc. | Method for asynchronous application communication |
| EP0588046A1 (en) * | 1992-08-14 | 1994-03-23 | International Business Machines Corporation | IEEE standard 802.2 virtual device driver |
| US5341476A (en) | 1992-12-23 | 1994-08-23 | Abbott Laboratories | Dynamic data distribution network with sink and source files for particular data types |
| US5414848A (en) * | 1993-04-01 | 1995-05-09 | Intel Corporation | Method and apparatus for sharing a common routine stored in a single virtual machine with other virtual machines operating in a preemptive muli-tasking computer system |
| US5459869A (en) * | 1994-02-17 | 1995-10-17 | Spilo; Michael L. | Method for providing protected mode services for device drivers and other resident software |
| US5784615A (en) * | 1994-12-13 | 1998-07-21 | Microsoft Corporation | Computer system messaging architecture |
-
1996
- 1996-07-02 US US08/672,528 patent/US6535929B1/en not_active Expired - Lifetime
-
1997
- 1997-06-06 EP EP97303905A patent/EP0817030A3/en not_active Withdrawn
- 1997-07-02 JP JP9177409A patent/JPH1069391A/ja active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002288058A (ja) * | 2001-01-25 | 2002-10-04 | Yahoo Inc | 高性能クライアントサーバ通信システム |
| JP4504609B2 (ja) * | 2001-01-25 | 2010-07-14 | ヤフー！ インコーポレイテッド | 高性能クライアントサーバ通信システム |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0817030A2 (en) | 1998-01-07 |
| US6535929B1 (en) | 2003-03-18 |
| EP0817030A3 (en) | 1998-12-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH1069391A (ja) | マルチタスク環境において動作するアプリケーションのための汎用通信機構 | |
| CA2102747C (en) | Remote procedure call pooling with shared memory | |
| US5553242A (en) | Client/server connection sharing | |
| US6976174B2 (en) | Secure multiprotocol interface | |
| US7200695B2 (en) | Method, system, and program for processing packets utilizing descriptors | |
| US7478246B2 (en) | Method for providing a scalable trusted platform module in a hypervisor environment | |
| US8650569B2 (en) | User-level re-initialization instruction interception | |
| KR100612059B1 (ko) | 분할 처리 환경에서의 자원 조절을 위한 방법, 컴퓨팅 시스템 및 그에 관한 기록 매체 | |
| US5455953A (en) | Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket | |
| US7233984B2 (en) | Light weight file I/O over system area networks | |
| WO2018035856A1 (zh) | 实现硬件加速处理的方法、设备和系统 | |
| US6157959A (en) | Method and apparatus for providing portable kernel-mode support for fast interprocess communication | |
| JPH076091A (ja) | メモリスペースの使用を管理する方法及びコンピュータシステム | |
| JP2002342280A (ja) | 区分処理システム、区分処理システムにおけるセキュリティを設ける方法、およびそのコンピュータ・プログラム | |
| JPH11149456A (ja) | リモートオブジェクト呼出し用システム及び方法 | |
| JPH11312153A (ja) | オブジェクト・サ―バ間の作業負荷管理方法および装置 | |
| KR20040004554A (ko) | 분할 처리 환경에서의 공유 ｉ／ｏ | |
| JPH09223116A (ja) | 複数ミドルウェアに渡る分散オブジェクトの位置透過性 | |
| US8255913B2 (en) | Notification to task of completion of GSM operations by initiator node | |
| CA2149445A1 (en) | Separation and transmission control method and apparatus for a microkernal data processing system | |
| US9552225B2 (en) | Data processing system with data transmit capability | |
| US10397103B2 (en) | Data processing system with routing tables | |
| JPH06348512A (ja) | 資源管理コンピュータ・システム | |
| JP2002505477A (ja) | スタックベースのセキュリティ要求 | |
| GB2322719A (en) | Establishing a process using software agent control |