JP2014525622A - オペレーティングシステムのネイティブアプリケーションプログラミングインターフェイスのメタデータを用いた記述 - Google Patents

Abstract

ネイティブオペレーティングシステムアプリケーションプログラミングインターフェイス（ＡＰＩ）はメタデータを使用して記述され、そうした記述は標準フォーマットにおいて既知のロケーションに保管される。こうしたメタデータを使用しているＡＰＩ規定を保管することにより、他のアプリケーションは直ちにＡＰＩを特定して使用することができる。こうしたＡＰＩ表現を作成するために、開発期間中に、開発者はＡＰＩのシェイプを記述する。これらに限定されるわけではないが、クラス、インターフェイス、メソッド、プロパティ、イベント、パラメーター、構造、および、ＡＰＩにより規定された加算タイプを含んでいる。このＡＰＩ表現は、マシンで読取り可能なメタデータファイルを生成するツールによって処理される。マシンで読取り可能なメタデータファイルは、ＡＰＩ記述と同一の情報を含んでいる。しかしながら、人が著したものより、むしろ、フォーマットはマシンで読取るようにデザインされている。

Description

本発明は、オペレーティングシステムのネイティブアプリケーションプログラミングインターフェイスのメタデータを用いた記述に関する。

オペレーティングシステムは、典型的にいくつかのプログラミングインターフェイスを有しており、アプリケーションはオペレーティングシステムによってサポートされている機能性にアクセスすることができる。こうしたＡＰＩは、典型的にコンピュータープログラミング言語における名前付ファイルまたはオブジェクトを使用してオペレーティングシステムによって規定されている。例えば、Ｃプログラミング言語は、"interface.h"といった名前のヘッダーファイルを使用する。同様に、"P/Invoke"と呼ばれるＣ＃メカニズムにおいて、オペレーティングシステムＡＰＩにアクセスするためにシグネチャー（ｓｉｇｎａｔｕｒｅ）が使用されている。オペレーティングシステムＡＰＩを使用するコンピュータープログラムを書く人は、典型的にプログラムの中の名前付ＡＰＩファイル又はオブジェクトを参照し、または、プログラミング言語によって提供される別のメカニズムを使用する。プログラムは、例えば、そのＡＰＩによって規定されたファンクションに対するコール（ｃａｌｌ）を含んでいる。そのＡＰＩによって使用されている構文においてである。

こうしたやり方で規定されたＡＰＩは、それらが書き込まれた言語以外の言語によっては直接的にアクセスすることができない。他の言語の中に書き込まれたプログラムにアクセスできるようにするために、ＡＰＩはラップ（”ｗｒａｐｐｅｄ”）される。このラップは、典型的にはＡＰＩごと及び言語ごとに行われる必要があり、対象言語とＡＰＩとオペレーティングシステムの深い理解を要するものである。従って、多くのオペレーティングシステムＡＰＩは利用できない。

本概要は、以降の詳細な説明でより詳しく記述される本発明の概念について、簡素化された形式において代表的な概念の選択を紹介するものである。本概要は、特許請求された技術的事項の主要な特徴または本質的な特徴を特定することを意図するものではない。また、特許請求された技術的事項の範囲を限定するために使用されることを意図するものではない。

ネイティブオペレーティングシステムのアプリケーションプログラミングインターフェイス（ＡＰＩ）は、メタデータを使用して記述され、そうした記述は標準ファイルフォーマットで既知のロケーションに保管されている。こうしたメタデータを使用したＡＰＩ規定を保管することによって、他のアプリケーションは、直ちにＡＰＩを特定し、使用することができる。

こうしたＡＰＩ表現を作成するために、開発の最中に、開発者はＡＰＩのシェイプ（ｓｈａｐｅ）を記述する。それは、（これらに限定されるわけではないが、）クラス、インターフェイス、メソッド、プロパティ、イベント、パラメーター、構造体、および、ＡＰＩで規定される列挙型（ｅｎｕｍｅｒａｔｅｄ ｔｙｐｅ）を含んでいる。このＡＰＩ記述はツールによって処理され、マシンで読取り可能なメタデータが生成される。マシンで読取り可能なメタデータファイルは、ＡＰＩ記述と同一の情報を含んでいる。しかしながら、それは人が著したものより、むしろマシンで読み取られるようにデザインされたフォーマットである。例えば、このマシンで読取り可能なメタデータファイルは、ＥＣＭＡ−３３５ ＣＬＩフォーマットで保管されてよい。

オペレーティングシステムが創作されるとき、それぞれのＡＰＩ記述は全て、それぞれのメタデータファイルの中にコンパイルされる。これらのメタデータファイルは一緒に結合され、システムの中で利用可能な全てのＡＰＩに関する包括的な情報を提供する。この結合されたメタデータは、インストールのためのオペレーティングシステムイメージ（つまり、コンパイルされたバイナリーファイル）の中に含まれている。例えば、結合されたシステムメタデータは、ＥＣＭＡ−３３５ ＣＬＩフォーマットで、一連のメタデータファイルの中に保管されてよい。しかし、本発明にとって特定のフォーマットであることは重要ではない。このようにして、オペレーティングシステム及びそのＡＰＩは、自己記述的（ｓｅｌｆ−ｄｅｓｃｒｉｂｉｎｇ）である。

メタデータと独立してプログラミング言語によって完全に記述されるＡＰＩに対するオペレーティングシステムを有することにより、言語投射を創作することができる。メタデータを読み出すことができ、別のプログラミング言語においてＡＰＩを実施するアプリケーションである。例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）インタープリター（ｉｎｔｅｒｐｒｅｔｅｒ）は、こうした言語投射を含むことができ、ＪａｖａＳｃｒｉｐｔプログラムによるオペレーティングシステムのＡＰＩへのアクセスを自動的に提供することができる。コンパイルされた言語におけるプログラムは、コンパイラーによる同様なアクセスを備えることができ、こうした言語投射を含んでいる。後に続くリリース（ｒｅｌｅａｓｅ）において、オペレーティングシステムが新たなＡＰＩを追加する場合、新たなリリースと供に配布されるメタデータにより、アプリケーションは、インタープリター又はコンパイラーへ変更することなく、即座に新たな機能性を利用することができる。

従って、一つの態様において、コンピューターのオペレーティングシステムは、コンピューターストレージメディア上に保管されたコンピュータープログラムインストラクションを含んでいる。インストラクションは、プロセッサデバイスによって処理されると、オペレーティングシステムを実施するオペレーションを実行するようにプロセッサに指示する。オペレーティングシステムは、アプリケーションプログラムによってアクセス可能な一つまたはそれ以上のアプリケーションプログラミングインターフェイスを有しており、アプリケーションプログラムに対してオペレーティングシステムによって実施される機能性へのアクセスを提供する。メタデータファイルは、マシンで読取り可能なプログラミング言語の独立したフォーマットにおいて、アプリケーションプログラミングインターフェイスの名前付きエレメントを記述する。名前付きエレメントは、あらゆる種類のデータタイプであってよく、また、含んでよい。ベーシックタイプ、列挙型、構造体、デリゲート、インターフェイス、クラス、メソッド、プロパティ、および、イベントといったものである。メタデータファイルは、アプリケーションプログラミングインターフェイスのそれぞれの名前付きエレメントに対して、名前空間の中に配置される識別子（またはタイプ名）を含んでよい。

以降の説明においては、添付の図面が参照される。図面は、明細書の一部を構成しており、説明図として、本技術に係る所定の実施例が示されている。本発明開示の範囲を逸脱することなく、他の実施例が使用され、構成の変更がなされ得ることが理解されるべきである。

図１は、アプリケーションプログラミングインターフェイスを記述するメタデータを伴うオペレーティングシステムの実施例に係るブロックダイヤグラムである。 図２は、アプリケーションプログラミングインターフェイスを記述するメタデータを伴うオペレーティングシステムを作成するための開発ツールに係る実施例を説明するフローチャートである。 図３は、メタデータを生成するためにＡＰＩ記述ファイルがどのようにプロセスされるかを説明するフローチャートである。 図４は、こうしたシステムが実施されるコンピューターデバイスの実施例に係るブロックダイヤグラムである。

以降のセクションは、そうしたオペレーティングシステムが実施されるコンピューター環境の実施例を提供する。

図１を参照すると、コンピューターシステム１００は、オペレーティングシステム１０２を含んでおり、コンピューターハードウェアとの組み合せにおいて（図４参照）、種々のアプリケーション１０４が実行されるプラットフォームを提供する。アプリケーションは、オペレーティングシステムによって管理されたプロセスとして実行され、ファイル等といった、オペレーティングシステムによって管理されたコンピューターシステムのリソースを使用し、または、そうでなければ有している。

オペレーティングシステムは、アプリケーション１０４によってアクセスされるいくつかのアプリケーションプログラミングインターフェイス１０６を提供する。こうしたＡＰＩ１０６は、一つまたはそれ以上のメタデータファイル１０８によって記述される。メタデータファイル１０８は、マシンで読取り可能であり、オペレーティングシステムのＡＰＩに係るプログラミング言語の独立した表現である。以下に説明するように、こうしたメタデータファイルはＡＰＩ記述ファイルから自動的に作成することができ、従って、マシンで読取り可能な、オペレーティングシステムのサーフェス（ｓｕｒｆａｃｅ）、または全てのＡＰＩ、に係るプログラミング言語の独立した記述を自動的に生成することができる。こうしたメタデータファイルは、言語コンパイラー及び/又はインタープリター（図示なし）と結合されて、オペレーティングシステムのＡＰＩが自然で自動的な方法でプログラミング言語の中に投射されるやり方において、アプリケーション１０４が開発できるようにしている。

このコンテクスト（ｃｏｎｔｅｘｔ）で、図２と図３に関してこうしたオペレーティングシステムの実施例がより詳細に説明される。

図２において、アプリケーションハイパーバイザー発明のデータフローの実施例が示されている。アプリケーションプログラミングインターフェイス記述ファイル２００は、開発プロセスの最中に開発者によって規定される。開発プロセスは、つまり、オペレーティングシステムを実施するコードを書くプロセスである。

ビルドツール（ｂｕｉｌｄ ｔｏｏｌ）２０２は、オペレーティングシステムのためのコードをコンピューターシステム上にインストールされるよう実行可能にコンパイルするために使用されるが、ＡＰＩ記述をファイルを処理してメタデータファイル２０４を生成する。最後に、ビルドツール２０２は、メタデータファイル２０４を複合メタファイル２０６へと結合する。

ビルドツール２０２のあらゆる実施は、プログラミング言語及びＡＰＩ記述ファイル２００に対するあらゆる規格に基づいている。こうしたＡＰＩ記述ファイル２００は、ファンクション、または、オブジェクトクラス、または、データ構造であるインターフェイスを規定することができ、一つまたはそれ以上のメソッド、イベント、プロパティ、パラメーター、データタイプ、パラメーター順序、例外、および、そうしたインターフェイスなどといったものを規定することができる。ビルドツールは、こうしたＡＰＩ記述ファイルをパース（ｐａｒｓｅ）し、インターフェイスの特性を特定して、マシンで読取り可能で、プログラミング言語と独立したフォーマットにおけるそうした特性を表すデータをメタデータファイルの中に保管する。

図３は、ビルドツールによって実行されるプロセスの一般的な実施例を示している。ビルドツールは、ＡＰＩ記述ファイルにアクセスする３００。ＡＰＩ記述ファイルを処理して３０２、クラス、メソッド、データタイプ、プロパティ、イベント、例外、等といったようなＡＰＩの名前付きエレメントを特定する。特定された名前付きエレメントは、そのメタデータ表現に対してマップされる。このメタデータ表現は、ＡＰＩ記述ファイルに対応するメタデータファイルの中に保管される。ＡＰＩ記述ファイルが完全に処理されるまで、３０８で決定されるように、ステップ３０２からステップ３０８が繰り返される。ＡＰＩ記述ファイルの処理の後で、別のＡＰＩファイルが（もしあれば、ステップ３１０で判断されるように）アクセスされて、そのファイルに対してステップ３０２からステップ３０８が繰り返される。全てのＡＰＩ記述ファイルの処理が完了したすると、復号メタデータファイルが作成される３１２。例えば、結合されたシステムメタデータはＥＣＭＡ−３３５ ＣＬＩフォーマットで一連のメタデータファイルの中に保管されてよいが、本発明にとって特定のフォーマットは需要ではない。この復号メタデータファイルは、このよにうに、完結していて、自動的で、オペレーティングシステムのサーフェス、つまり利用可能なインターフェイス、に係るプログラミング言語を提供する。

ステップ３０４で使用できるマッピング（ｍａｐｐｉｎｇ）の実施例についてこれから説明する。ＡＰＩにおける名前付きエレメントを表現するために使用されるメタデータの形式と構造の両方に関して、他のマッピングも可能であることが理解されるべきである。この実施例において、ＡＰＩ記述ファイルをメタデータに対してマップすることは、最初に、そのＡＰＩ記述ファイルにおける名前付きエレメントを特定することを含んでいる。名前付きエレメントは、ベーシックタイプ、列挙型、構造体、デリゲート、インターフェイス、クラス、メソッド、プロパティ、および、イベントといった、あらゆる種類のデータタイプであってよく、または、含んでよい。

この実施例において、それぞれの名前付きエレメントは、あらゆる種類のデータタイプであってよく、または、含んでよく、名前空間の中に配置された識別子を有している。２つの名前付きエレメントは、それらが分離した名前空間に存在している限りは、同一の識別子を有することができる。ＡＰＩを規定するＡＰＩファイルが、パラメーター又はストラクトフィールドにおけるといった、名前付きエレメントを使用する場合、ファイルの作成者は、完全に名前空間により認定された名前又はショート識別子を使用することができる。ショート識別子が使用される場合、現行の名前空間スコープ（ｓｃｏｐｅ）上にショート識別子を付け加えることにより、完全に名前空間により認定された名前が使用される。このメカニズムを使用すれば、メタデータにおいて名前が不明確になることはない。メタデータにおいて名前空間ブロックを使用することができ、これらのブロックはネストされて（ｎｅｓｔｅｄ）よい。ブロックの中のそれぞれの名前付きエレメント上に名前空間を宣言することを避けるためである。名前付きエレメントは、属性と供にタグ（ｔａｇ）され得る。属性の実施例は、これらに限定されるわけではないが、バージョン番号、簡素なフラグを含んでおり、パラメーターにおける追加の情報を含んでもよい。

表現の詳細の実施例にこれから移ると、基本的なタイプの名前付きエレメントは、その基本的なタイプと一貫したキーワードによって表現され得る。ブール（Ｂｏｏｌｅａｎ）、バイト、ダブル、フロート（ｆｌｏａｔ）、イント（ｉｎｔ）、ロング、ショート、キャラクター、文字列（ｓｔｒｉｎｇ）、グローバル一意識別子（ｇｕｉｄ）、ハンドル、エラーステイタス、等であり、ＡＰＩ記述ファイルの中で使用される識別子が続く。例えば、「アンサー（”ａｎｓｗｅｒ”）」と呼ばれる値を表すブール値は、以下のように表現される。

「ブールアンサー（”Ｂｏｏｌｅａｎ Ａｎｓｗｅｒ”）」
アレイの表現の実施例は、以下のとおりである。”ａｒｒａｙ”といった、キーワードの一般的な形式を有し、識別子が続く。これに、ポインターとアレイの中のエレメントの数である２つの値が続く。例えば、以下のようである。

array [identifier]
{
[pointer]
[number of elements]
]

列挙型（”Ｅｎｕｍ”）表現の実施例は以下のとおりである。最初に、列挙型であることを特定するキーワード”ｅｎｕｍ”を伴う一般的な形式を有し、識別子が続く。識別子に、ｅｎｕｍ値の集まりが続く。全てのタイプと同じように、ｅｎｕｍ識別子は、それらが含まれる名前空間の中で唯一のものである。しかしながら、ｅｎｕｍ値識別子は、ｅｎｕｍ自身の中でのみ唯一のものであり得る。

enum [identifier]
{
[value 1 identifier] [optional:=value], ...
[value n identifier] [optional:=value]
}

例えば、トランプカードのランク付けを利用すると以下のようである。
enum CardRank
{
Ace=1,
Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King
}

簡素なデータ構造タイプ（”ｓｔｒｕｃｔ”）表現の実施例は以下のとおりである。最初に、構造タイプ指定子を伴う一般的な形式を有し、フィールドの集まりが続く。それぞれのフィールドは、タイプと識別子を有している。全てのタイプと同じように、ストラクト識別子は、それらが含まれる名前空間の中で唯一のものである。しかしながら、ストラクトフィールド識別子は、ストラクト自身の中でのみ唯一のものであり得る。

[version([version number])]
struct [struct.identifier]
{
[field[l] type] [field[l] identifier];
[field[n] type] [field[n] identifier];
};

マウスイベントのための引数に対するストラクトの所定の実施例としては、以下のものがある。
[version(OS.version.number)]
struct MouseEventArgs
{
MouseButtons Buttons;
unsigned int Clicks;
unsigned int Delta;
Point Location;
}

インターフェイスの表現の実施例は、メソッド、プロパティ、または、イベントの集まりである。メソッドの実施は、インターフェイスを実施するクラスにおいて行うことができる。共通の属性に加えて、インターフェイスは、指定されるべきＵＵＩＤ属性を使用する。インターフェイスは、別のインターフェイスを「要求（”ｒｅｑｕｉｒｅ”）」できる。このことは、コンポーネントが与えられたインターフェイスを実施する場合に、同一のコンポーネントによって全ての「要求された（”ｒｅｑｕｉｒｅｄ”）」インターフェイスも、また、実施されることを示している。インターフェイスを表現する規則の実施例は以下のとおりである。

interface:
|attributes "interface"IDENTIFIER':'IDENTIFER requires '{'interface_member_list'}'
requires:
|<empty>
|"requires"interface_list
interface_list:
|IDENTIFIER
|IDENTIFIER "," interface_list
interface_member_list:
|<empty>
|interface_member
|interface_member interface_member_list
interface_member:
|method
|property
|event

この実施例において、インターフェイスの表現の終わりは、メソッド、プロパティ、及び/又は、イベントである。この例で、インターフェイスは、ゼロ以上のパラメーターを取得して一つのタイプをリターンするメソッドを含んでよい。メソッドのリターンタイプはＨＲＥＳＵＬＴである。パラメーターは、名前とタイプを有している。パラメーターは、〔ｉｎ〕または〔ｏｕｔ〕属性のいずれかを用いてマーク付けされる。入力及び出力パラメーターはあらゆる数量であり得る。パラメーターは、全てのＲＩＤＬ−ｓｕｐｐｏｒｔｅｄポインタータイプに対して、入力と出力の両方であるとしてマーク付けされ得る。一つの出力パラメーターは、ＨＲＥＳＵＬＴリターン値を例外にマップする言語に対して、任意的に〔ｒｅｔｖａｌ〕を用いてマーク付けされ得る。インターフェイスの中のメソッドの名前は唯一のものである。

この実施例においては、また、プロパティはフィールドと類似してよい。しかし、アクセスするために使用されるプット（ｐｕｔ）及びゲット（ｇｅｔ）オペレーションの入力及び出力パラメーターに関連している。

インターフェイスは、イベント、何かが発生したときに興味のあるパティーに知らせるインターフェイスのためのメカニズムをサポートしている。表現は、追加メソッドの指定と削除メソッドの指定を含んでいる。追加メソッドは、イベントデリゲート（ｄｅｌｅｇａｔｅ）タイプの入力パラメーターである第１パラメーターとＥｖｅｎＲｅｇｉｓｔｒａｔｉｏｎＴｏｋｅｎタイプの出力パラメーターである第２パラメーターを有している。削除メソッドは、ＥｖｅｎＲｅｇｉｓｔｒａｔｉｏｎＴｏｋｅｎタイプの入力パラメーターである第１パラメーターを有している。イベントに対するイベントデリゲートタイプ自身は、イベントソース（ｓｏｕｒｃｅ）へのインターフェイスポインターである第１パラメーターを有している。つまり、このイベントを送付するオブジェクトである。以下は、デリゲートタイプＭｏｕｓｅＥｖｅｎｔＨａｎｄｌｅｒが、インターフェイスイベントを宣言するためにどのように使用され得るかを示す実施例である。

[eventadd] HRESULT MouseMove(
[in] MouseEventHandler*pMouse,
[out] EventRegistrationToken* oken);
[eventremove] HRESULT MouseMove(
[in] EventRegistrationToken token).

デリゲートは、一つのメソッドのＩｎｖｏｋｅを伴うインターフェイスとして表現することができ、その署名はデリゲート仕様の署名と一致している。メソッドは、一つのリターンタイプとゼロ以上のパラメーターを有している。デリゲートのリターンタイプはＨＲＥＳＵＬＴである。パラメーターは、名前とタイプを有している。パラメーターは、出力又は入力のいずれかであるとしてマーク付けされる。入力及び出力パラメーターはあらゆる数量であり得る。一つの出力パラメーターは、ＨＲＥＳＵＬＴリターン値を例外にマップする言語に対するリターン値として、任意的にマーク付けされ得る。デリゲートを表現する規則実施例は以下のとおりである。

delegate:
|delegate_attributes"delegate"TYPE_IDENTIFIER IDENTIFIER'('parameter_list')'!;'

上述のものは、メタデータから独立したプログラミング言語においてＡＰＩのエレメントがどのように表現され得るかの単なる実施例であることが理解されるべきである。種々のメタデータ表現を使用することができる。

ＡＰＩがメタデータから独立したプログラミング言語によって完全に記述されているオペレーティングシステムを有することにより、言語投射を創作することができる。言語投射は、メタデータを読み出して、別のプログラミング言語においてＡＰＩを実施するアプリケーションである。例えば、ＪａｖａＳｃｒｉｐｔインタープリターは、そうした言語投射を含み、オペレーティングシステムＡＰＩへのＪａｖａＳｃｒｉｐｔプログラムによるアクセスを自動的に提供することができる。コンパイルされた言語におけるプログラムは、コンパイラーによって同様なアクセスを提供することができ、そうした言語投射を含んでいる。

実施例について説明してきたので、そうしたシステムが動作するようにデザインされたコンピューター環境の実施例についてこれから説明する。以降の記載は、このシステムが実施され得る好適なコンピューター環境について簡潔で一般的な説明を提供するように意図されたものである。システムは、数多くの汎用又は専用コンピューターハードウェア構成を用いて実施することができる。好適なよく知られたコンピューターデバイスの実施例は、これらに限定されるわけではないが、以下のものを含んでいる。パーソナルコンピューター、サーバーコンピューター、ハンドヘルド又はラップトップデバイス（例えば、メディアプレーヤー、ノートブックコンピューター、携帯電話、パーソナルデータアシスタント、ボイスレコーダー）、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、ゲームコンソール、プログラム可能な家電、ノートブックＰＣ、ミニコンピューター、メインフレームコンピューター、上記のあらゆるシステム又はデバイスを含む分散コンピューティング環境、等である。

図４は、好適なコンピューターシステム環境の実施例を示している。コンピューターシステム環境は、好適なコンピューター環境の単なる一例であって、こうしたコンピューター環境の使用範囲又は機能性に関していかなる限定も意図するものではない。コンピューター環境は、オペレーション環境の中に示されたあらゆる一つのコンポーネント又はその組み合わせに関していかなる依存も要求も有しないものとして理解されるべきである。

図４に関して、コンピューター環境の実施例は、コンピューターマシン４００といった、コンピューターマシンを含んでいる。最も基本的な構成において、コンピューターマシン４００は、典型的に、少なくとも一つのプロセッサユニット４０２とメモリー４０４を含んでいる。コンピューターデバイスは、複数のプロセッサユニット、及び/又は、グラフィックプロセッサユニット４２０といった追加のコプロセッサユニット（ｃｏ−ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）を含んでよい。コンピューターデバイスのまさにその構成とタイプに基づいて、メモリー４０４は、揮発性（ＲＡＭといったもの）、不揮発性（ＲＯＭ、フラッシュメモリー、等といったもの）、または、これら２つのいくつかの組み合わせであってよい。この最も基本的な構成は、破線４０６によって図４の中に示されている。加えて、コンピューターマシン４００は、また、追加の特性／機能性を有し得る。例えば、コンピューターマシン４００は、また、追加ストレージ（リムーバブル及び/又は非リムーバブルのもの）を含んでよい。これらに限定されるわけではないが、磁気又は光ディスク又はテープを含んでいる。こうした追加ストレージは、リムーバブルストレージ４０８及び非リムーバブルストレージ４１０として図４の中に示されている。コンピューターストレージメディアは、揮発性と不揮発性、リムーバブルと非リムーバブルメディアを含んでおり、コンピュータープログラムインストラクション、データ構造、プログラムモジュール、または、他のデータといった情報を保管するためのあらゆる方法又は技術において実施される。メモリー４０４、リムーバブルストレージ４０８及び非リムーバブルストレージ４１０は、全てコンピューターストレージメディアの実施例である。コンピューターストレージメディアは、これらに限定されるわけではないが、以下のものを含んでいる。ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または、所望の情報を保管するために使用でき、コンピューターマシン４００によってアクセスされ得る他のあらゆるメディア、である。

コンピューターマシン４００は、また、コミュニケーション接続４１２を含んでおり、デバイスは他のデバイスとコミュニケーションすることができる。コミュニケーション接続４１２は、コミュニケーションメディアの実施例である。コミュニケーションメディアは、典型的に、コンピュータープログラムインストラクション、データ構造、プログラムモジュール、または、キャリア波又は他の伝送メカニズムといった変調されたデータ信号における他のデータを保持しており、あらゆる情報伝達メディアを含んでいる。用語「変調されたデータ信号（”ｍｏｄｕｌａｔｅｄ ｄａｔａ ｓｉｇｎａｌ”）」は、一つまたはそれ以上の特性セットを有する信号、または、信号におけるエンコード情報に関して、そうしたやり方で変換された信号を意味しており、それによって、信号の受信装置の構成または状態が変化している。実施例として、そして限定ではなく、コミュニケーションメディアは、有線ネットワーク又はダイレクト有線接続、および、音声、ＲＦ、赤外線、又は他の無線メディアといった無線メディアを含んでいる。

コンピューターマシン４００は、ディスプレイ、キーボード、マウス、ペン、カメラ、タッチ入力デバイス、等といった種々の入力デバイス４１４を有してよい。スピーカー、プリンター、等といった出力デバイス４１６も、また、含まれてよい。こうしたデバイスの全ては従来技術としてよく知られており、ここにおいて長らく説明することを要しないものである。

アプリケーションプログラミングインターフェイスを記述するメタデータを伴うこうしたオペレーティングシステムは、ソフトウェアの一般的なコンテクスト（ｃｏｎｔｅｘｔ）において実施され得る。プログラムモジュールといった、コンピューターで実行可能なインストラクション及び／又はコンピューターで解釈されるインストラクションを含み、コンピューターマシンによって処理されるものである。一般的に、プログラムモジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含み、プロセッサユニットによって処理されると、プロセッサユニットに対して所定のタスク又は所定の抽象的なデータタイプを実行するように指示する。このシステムは、分散コンピューター環境において実施されてもよい。タスクは、コミュニケーションネットワークを通じてリンクされた離れたプロセッサデバイスによって実行される。分散コンピューター環境において、プログラムモジュールは、メモリストレージデバイスを含むローカル及びリモート両方のコンピューターストレージメディアの中に存在し得る。

添付の請求項のプリアンブルにおける用語「製造方法」、「プロセス」、「マシン」、および、「組み合せ」は、米国特許法第１０１条におけるこれらの用語の使用によって規定される特許可能な技術的事項の範囲内にあるものと考えられる技術的事項に請求項を限定するように意図されたものである。

ここにおいて説明されたあらゆる又は全ての前出の代替的な実施例は、追加のハイブリッドな実施例を形成するために望まれるあらゆる組み合せにおいて使用され得るものである。添付の請求項において定められる技術的事項は、上述の所定の実施例に必ずしも限定されるものではないことが理解されるべきである。上述の所定の実施例は、単なる例として開示されたものである。

Claims (10)

1. コンピューターマシンであって：
   プロセッサと；
   一つまたはそれ以上のコンピューターストレージメディアと；
   前記プロセッサによって処理されるときに、オペレーションを実行するように前記プロセッサに指示し、前記コンピューターストレージメディア上に保管されたコンピュータープログラムインストラクションであり、
   前記インストラクションは、オペレーティングシステムを提供するオペレーションを含み、それを通じてアプリケーションが前記コンピューターマシンのリソースにアクセスする、
   インストラクションと、を含み、
   前記オペレーティングシステムは、
   アプリケーションプログラムによってアクセス可能な一つまたはそれ以上のプログラミングインターフェイスであり、前記アプリケーションプログラムに対して前記オペレーティングシステムによって実施される機能性に対するアクセスを提供するためのプログラミングインターフェイスを提供し、
   前記アプリケーションプログラミングインターフェイスのそれぞれが関連のメタデータを有しており、
   前記メタデータファイルは、マシンで読取り可能なプログラミング言語の独立したフォーマットにおいて、前記アプリケーションプログラミングインターフェイスのエレメントを記述する、
   ことを特徴とするコンピューターマシン。
2. 前記メタデータファイルは、前記アプリケーションプログラミングインターフェイスの名前付きエレメントに対する、名前空間の中に配置された識別子を含んでいる、
   請求項１に記足のコンピューターマシン。
3. 前記名前付きエレメントは、一式の基本的なデータタイプのうちの一つである、
   請求項２に記載のコンピューターマシン。
4. 前記名前付きエレメントは、さらに、
   インターフェイス、メソッド、プロパティ、および、イベントのうちの一つである、
   請求項３に記載のコンピューターマシン。
5. 前記名前付きエレメントは、さらに、
   データ構造、列挙型、および、アレイのうちの一つである、
   請求項３に記載のコンピューターマシン。
6. コンピューターで実施される方法であって：
   アプリケーションプログラムに対してオペレーティングシステムによって実施される機能性に対するアクセスを提供するためのアプリケーションプログラミングインターフェイスを規定するデータファイルを受け取るステップと；
   前記アプリケーションプログラミングインターフェイスに対して関連するメタデータファイルを生成するステップであり、前記メタデータは、マシンで読取り可能なプログラミング言語の独立したフォーマットにおいて、前記アプリケーションプログラミングインターフェイスのエレメントを記述するステップと；
   前記オペレーティングシステムの一部として前記メタデータファイルを保管するステップと、を含む、
   ことを特徴とする方法。
7. 前記メタデータは、前記アプリケーションプログラミングインターフェイスの名前付きエレメントに対する、名前空間の中に配置された識別子を含む、
   請求項６に記載の方法。
8. 前記名前付きエレメントは、一式の基本的なデータタイプのうちの一つである、
   請求項７に記載の方法。
9. 前記名前付きエレメントは、さらに、インターフェイス、メソッド、プロパティ、および、イベントのうちの一つである、
   請求項８に記載の方法。
10. 前記名前付きエレメントは、さらに、データ構造である、
    請求項８に記載の方法。

Images