コンピューターで実施される方法であって:一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する情報に対するリクエストを受け取るステップと;前記一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する情報を取得するステップであり、前記オペレーティングシステムインターフェイスは抽象型システムを使用して記述されているステップと;前記一つまたはそれ以上の利用可能なオペレーティングシステムシステムに関連する一つまたはそれ以上の抽象型を判断するステップと;判断された個々の抽象型を、少なくとも一つの所定のプログラミング言語に関連するそれぞれのタイプにマップするステップと、を含む、ことを特徴とする方法。前記一つまたはそれ以上の抽象型を判断する前記ステップは、さらに、前記一つまたはそれ以上の抽象型に関連する振る舞いを判断するステップ、を含む、請求項1に記載の方法。前記一つまたはそれ以上の抽象型に関連する振る舞いを判断する前記ステップは、さらに、少なくとも一つのバイナリーコントラクトを通じて、振る舞いをプログラムで判断するステップ、を含む、請求項2に記載の方法。前記一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する前記情報は、さらに、階層的な情報を含んでいる、請求項1に記載の方法。前記情報は、少なくとも一つのインターフェイスに関するバージョン情報、前記少なくとも一つのインターフェイスに関する個々のパラメーターのデータタイプ、前記少なくとも一つのインターフェイスに関する前記個々のパラメーターのコール順序、を含む、請求項1に記載の方法。前記一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する情報を取得する前記ステップは、少なくとも一つのメタデータファイルからプログラムで情報を取得するステップを含む、請求項1に記載の方法。コンピューターで読取り可能なインストラクションを含む一つまたはそれ以上のコンピューターで読取り可能なストレージ媒体であって、前記インストラクションが実行されると:オペレーティングシステムに関連する機能性にプログラムでアクセスできるように構成されている、一つまたはそれ以上のアプリケーションプログラミングインターフェイスAPIと;前記一つまたはそれ以上のAPIに関連する一つまたはそれ以上のメタデータであり、前記メタデータは、前記一つまたはそれ以上のAPIに係る少なくとも一つの記述を含むように構成されており、前記少なくとも一つの記述は抽象型システムを使用している、メタデータと;前記一つまたはそれ以上のAPIをコールするための一つまたはそれ以上のマシンレベルのバイナリーコントラクトを含むように構成されている、一つまたはそれ以上のアプリケーションバイナリーインターフェイスABIモジュールと;前記抽象型システムの少なくとも一つのタイプを一つまたはそれ以上の所定のプログラミング言語の少なくとも一つのタイプにマップするように構成されている、一つまたはそれ以上の生成された言語プロジェクションモジュールと、を実行する、ことを特徴とするコンピューターで読取り可能なストレージ媒体。前記一つまたはそれ以上のコンピューターで読取り可能なストレージ媒体は、さらに、インストラクションを含み、前記インストラクションが実行されると:前記一つまたはそれ以上のメタデータファイルを通じて、前記少なくとも一つのAPIモジュールの中に含まれ、少なくとも一つのインターフェイスをプログラムで判断するように構成されている少なくとも一つのアプリケーション、を実行する、請求項7に記載のコンピューターで読取り可能なストレージ媒体。前記生成された言語プロジェクションモジュールは、前記一つまたはそれ以上のプログラミング言語にネイティブなやり方で、前記抽象型システムの少なくとも一つのタイプをエミュレートするように構成されている少なくとも一つのプロキシーを含んでいる、請求項7に記載のコンピューターで読取り可能なストレージ媒体。前記一つまたはそれ以上のAPIをコールするための前記バイナリーコントラクトは、前記抽象型システムの少なくとも一つのタイプに関する少なくとも一つの振る舞い定義を含んでいる、請求項7に記載のコンピューターで読取り可能なストレージ媒体。このことは、ときどき、インターフェイスがオペレーティングシステムの中にリリースされる時間と、そのインターフェイスがプログラムの中に包含される時間との間の遅延を結果として生じている。本概要は、以降の詳細な説明でより詳しく記述される本発明の概念について、簡素化された形式において代表的な概念の選択を紹介するものである。本概要は、特許請求された技術的事項の主要な特徴または本質的な特徴を特定することを意図するものではない。また、特許請求された技術的事項の範囲を限定するために使用されることを意図するものではない。種々の実施例は、プログラミング言語とは独立して、オペレーティングシステムに関する一つまたはそれ以上のインターフェイスを記述する能力を提供する。代替的又は追加的に、所定のプログラミング言語に関するコンパイラーは、独立したインターフェイス記述を所定のプログラミング言語にマップするように構成されてよい。いくつかの実施例において、アプリケーションは、オペレーティングシステムの一つまたはそれ以上のインターフェイスをプログラムで決定するように構成されてよい。いくつかの実施例は、オブジェクト志向object-orientedのやり方で、抽象型abstracttypeシステムを利用してオペレーティングシステムの一つまたはそれ以上のインターフェイスをモデル化する能力を提供する。いくつかの実施例において、拡張インターフェイス定義言語IDL:InterfaceDefinitionLanguageは、一つまたはそれ以上のインターフェイス間の関係を記述する文法を含んでよい。いくつかの実施例においては、抽象型システムに関する振る舞いを表すように、バイナリーコントラクトcontractが構成され得る。概要種々の実施例は、プログラミング言語とは独立して、オペレーティングシステムに関する一つまたはそれ以上のインターフェイスを記述する能力を提供する。抽象型システムは、インターフェイス定義言語IDLと組み合わされて、インターフェイスを記述、及び又は、定義するように構成されてよい。いくつかの実施例において、インターフェイスは、オブジェクト志向なやり方で記述され得る。代替的又は追加的に、プログラミングアプリケーションのランタイム環境は、言語とは独立したインターフェイス記述を、所定のランタイム環境における好適なコンストラクトconstructに対して動的に例えば、ランタイム実行の最中にマップするように構成されてよい。いくつかの実施例において、アプリケーションは、独立したインターフェイスの記述ををプログラムで決定するように構成されてよい。いくつかの場合において、独立したインターフェイスの記述は、マシンで読取り可能なフォーマットで保管され得る。後に続く説明において、オペレーティング環境というタイトルのセクションが備えられ、一つまたはそれ以上の実施例が使用され得る一つの環境を説明している。これに続いて、オペレーティングシステムのコンポーネントアクセスというタイトルのセクションは、複数のプログラミング言語がシステムコンポーネントに対してプログラムでアクセスできるアーキテクチャーを説明している。次に、抽象型システムを用いたオブジェクト志向言語のモデリングというタイトルのセクションでは、拡張IDLと併せて、オブジェクト志向なやり方でオペレーティングシステムインターフェイスを記述するために抽象型タイプシステムがどのように使用されるかを説明する。最後に、システム例というタイトルのセクションでは、一つまたはそれ以上の実施例を実行するために使用され得るシステム例を説明する。以降に説明される種々の実施例についての概要を提供してきたので、一つまたはそれ以上の実施例が実行され得るオペレーティング環境の例についてこれから検討する。オペレーティング環境図1は、本発明の一つまたはそれ以上の実施例に従ったオペレーティング環境を示しており、全般的に参照番号100である。環境100は、一つまたはそれ以上のプロセッサ104を有するコンピューターデバイス102、および、一つまたはそれ以上のコンピューターで読取り可能なストレージ媒体106を含んでいる。コンピューターで読取り可能なストレージ媒体は、例示であって限定するものではないが、コンピューターデバイスと典型的に関連する揮発性及び不揮発性メモリー及び又はストレージ媒体に係る全ての形式を含んでいる。そうした媒体は、ROM、RAM、フラッシュメモリー、ハードディスク、リムーバブル媒体、等を含んでよい。コンピューターデバイスの一つの所定の実施例が、以降の図5において示され、説明される。加えて、コンピューターデバイス102は、オペレーティングシステムOS108、および、関連するオペレーティングシステムインターフェイス110を含んでいる。これらは別個のモジュールとして示されているが、オペレーティングシステム108とオペレーティングシステムインターフェイス110は、本発明で請求される技術的事項の範囲を逸脱することなく、別個のモジュール、結合したモジュール、または、あらゆる組み合わせとして実施し得ることが正しく理解されるべきである。オペレーティングシステム108は、コンピューターデバイス102のソフトウェア及び又はハードウェアリソースを管理するように構成された機能性を表している。オペレーティングシステムインターフェイス110は、オペレーティングシステム108によって提供されるサービス及び又は機能性に対してプログラムでアクセスすることを表している。メモリー管理、ファイル管理、サービス、機能、リソース管理、周辺機器管理、等といったものである。コンピューターデバイス102は、また、記述的言語ファイル112を含んでおり、一つまたはそれ以上のインターフェイスを記述するように構成されている一つまたはそれ以上のファイルを表している。いくつかの実施例において、インターフェイスは、オペレーティングシステムインターフェイス110といった、オペレーティングシステムに関連付けられ得る。記述的言語ファイルは、あらゆる好適な記述、マークアップ言語、及び又は、文法を使用してインターフェイスを記述することができる。インターフェイス定義言語IDL、拡張マークアップ言語XML、等を用いるものである。加えて、コンピューターデバイス102は、また、一つまたはそれ以上のエディター/コンパイラーモジュール114を含んでいる。いくつかの実施例において、エディター/コンパイラーモジュール114は、記述的言語ファイル112を読み出し、及び又は、解釈して、ファイル112に基づいて、一つまたはそれ以上のバイナリーメタデータファイル116といった、出力を生成する機能性を表している。バイナリーメタデータファイル116は、オペレーティングシステムインターフェイス110及び又はオペレーティングシステム108に関する情報を含んでいる一つまたはそれ以上のマシンで読取り可能なファイルを表している。情報は、入力パラメータータイプ、パラメーターコールオーダー、インターフェイス間の関係、等である。代替的又は追加的に、エディター/コンパイラーモジュール114は、一つまたはそれ以上のソースコード118を読み出し、及び又は、解読する機能性を表している。ソースコードファイル118は、少なくとも一つのプログラミング言語に関するプログラミングステートメントを含む一つまたはそれ以上のファイルに対応している。エディター/コンパイラーモジュール114は、ソースコード118を解釈して、そのソースコードに基づいてマシンで実行可能なコードを生成する。コンピューターデバイス102は、あらゆる好適なコンピューターデバイスとして実施され得る。例示であって限定するものではないが、デスクトップコンピューター、ポータブルコンピューター、ノートブックコンピューター、パーソナルデジタルアシスタントPDAといったハンドヘルドコンピューター、携帯電話、等といったものである。オペレーティング環境の実施例について説明してきたので、一つまたはそれ以上のプログラミング言語に対して、オペレーティングシステムコンポーネントをプログラムで公開することについてこれから検討する。オペレーティングシステムのコンポーネントアクセスコンピューターデバイス上で実行されているアプリケーションは、しばしば、そのコンピューターデバイス上で稼働しているオペレーティングシステムに備えられた機能を利用している。オペレーティングシステムは、コンピューターデバイス上で関連のリソースに対する簡素なアクセスを可能にし、同様に、サービスを提供する。ときどき、これらの機能、サービス、及び又は、リソースは、プログラムでアクセスされ得る。しかしながら、オペレーティングシステムが、こうした機能性を、アプリケーションが書かれたプログラミング言語とは異なるプログラミング言語フォーマットにおいて、公開する場合に、プログラマーは、典型的に、異なるプログラミング言語間での転換を援助するラッパー関数を書くであろう。例えば、フラットで、エクスポートされた、C関数として、書かれ、及び又は、公開されたインターフェイスを検討する。Cスタイル関数の使用を望んでいるCまたはビジュアルベーシックのプログラマーは、それらのプログラミング言語が成功裡にCスタイル関数をコールできるようにするために、特別なステートメント及び又は追加コードを含んでよい。結果として、公開されたインターフェイスとは異なるプログラミング言語で書かれたアプリケーションは、追加的なステートメント及び又はラッパー関数が書かれるまでは、インターフェイスに対してアクセスできない。種々の実施例は、プログラミング言語とは独立して、オペレーティングシステムに関する一つまたはそれ以上のインターフェイスを記述する能力を備えている。プログラム言語とは独立したインターフェイスを記述することで、複数のプログラミング言語がインターフェイスに対して容易にアクセスすることができる。プログラミング言語がインターフェイスに係る言語とは独立した記述をどのように解釈するか学習した場合、この知識は、言語とは独立した記述を使用する既存及び将来のインターフェイスについて適用することができる。いくつかの実施例において、インターフェイスは、抽象型システムを使用して記述することができる。同様に、所定のプログラミング言語、または、関連のプログラミング言語コンパイラーは、インターフェイスを解釈及び又はアクセスするために、抽象型システムを関連するタイプのシステムに対してマップし得る。図2は、アーキテクチャー200を示しているが、一つまたはそれ以上の実施例と関連して検討する。アーキテクチャー200は、コンピューターデバイス上で実行されるように構成されたオペレーティングシステム202を含んでいる。簡素化の目的のために、オペレーティングシステム202は、その全体が示されていないことを理解すべきである。オペレーティングシステム202は、コンピューターデバイスと関連するリソースを管理するように構成された一つまたはそれ以上のオペレーティングシステムコンポーネント204を含んでいる。いくつかの実施例においてオペレーティングシステムコンポーネント204は、リソースに対するプログラムのアクセスを提供することができる。リソース管理に関する一つまたはそれ以上のサービス及び又は機能も同様に提供し得る。オペレーティングシステムコンポーネント204は、また、オペレーティングシステム202に関するベーシックエレメントを、そのベーシックエレメントから作成された複雑なエレメントと同様に、含むことができる。いくつかの実施例において、オペレーティングシステムコンポーネント204は、APIといった、一つまたはそれ以上のインターフェイスを介して公開され得る。この実施例において、オペレーティングシステム202は、新たなAPIファミリー206、COMベースのAPIファミリー208、および、フラットエクスポートベースのAPIファミリー210を含んでいる。新たなAPIファミリー206は、以下に詳しく説明されるように、機能性つまり、クラス、インターフェイス、メソッド、プロパティ、イベント、等が、抽象型システムを使用して直接的に記述されている、一つまたはそれ以上の関連するAPIを表している。COMベースのAPIファミリー208は、コンポーネントオブジェクトモデルCOMタイプシステムを使用して機能性が記述されている一つまたはそれ以上のAPIを表している。フラットエクスポートベースのAPIファミリー210は、メソッド署名つまり、メソッド名、コールコンベンション、メソッドアーギュメントargumentの数とタイプ、を含むメソッド署名を使用して機能性が記述されている一つまたはそれ以上のAPIを表している。フラットエクスポートベースのAPIは、さらに、名前によってだけ識別されるAPIを表しており、クラスの中に、及び又は、オブジェクト志向のやり方では、配置されない。どのAPIが利用可能であるか判断したいプログラマーは、手動、及び又は、プログラムでそれぞれのAPIの記述にアクセスすることができる。例えば、新たなAPIファミリー206に対してどんなインターフェイスが存在するか、そして、それらをどのようにコールするかを判断するために、プログラマーは、関連のメタデータ212にアクセスすることができる。COMベースのAPIファミリー208とフラットエクスポートベースのAPIファミリー210は、それぞれに、メタデータ214と216において、関連する言語独立タイプのシステムの記述を有している。一方で、プログラマーは、最初に、言語独立タイプのシステム記述をCOMベース及び又はフラットエクスポートベースのAPIに対してマップするためにラッパーコードを書く。メタデータ212、214、および、216は、関連するインターフェイスの種々の態様を記述する情報を含むように構成されてよい。バージョン情報、どの方法が利用可能か、どのパラメーターをインターフェイスが獲得するか、パラメーターのデータタイプ、パラメーターをパスする順序、等といった情報である。いくつかの実施例において、メタデータは、インターフェイスに関連する階層的な情報を含んでよい。インターフェイス間の関係を記述している情報、及び又は、オブジェクト志向のやり方でインターフェイスを記述している情報といったものである。メタデータは、クラス記述、クラスの関連する方法とパラメーター、等を含むように構成されてよい。いくつかの実施例において、一つまたはそれ以上のIDLファイルは、こうした記述のいくつかを含むように拡張され、一つまたはそれ以上のメタデータファイルの生成において使用され得る。いくつかの場合において、メタデータは、以降に詳しく説明されるように、少なくとも部分的には、一つまたはそれ以上のIDLファイルに基づくものであり得る。オペレーティングシステム202は、また、アプリケーションバイナリーインターフェイスABI218を含んでいる。ABIは、マシンレベルで、ファンクション、メソッド、API、等をコールするためのバイナリーコントラクトbainarycontractを記述する。バイナリーコントラクトは、ファンクションに関する識別子又は名前、ファンクションをコールするために使用される署名、パラメーターに関連するファンクション及び又はデータタイプに対してパスされるパラメーターの順序、等を含んでいる。代替的又は追加的に、バイナリーコントラクトは、型システムの少なくとも一つのタイプに関連する振る舞いを公開するための定義及び又は規則を含んでよい。典型的に、バイナリーコードに関連し、及び又は、バイナリーコントラクトによって定義される振る舞いは、変化しない。例えば、バイナリーコントラクトの署名及び又は識別子が一定のままである場合、コントラクトの関連する振る舞いも同様に一定のままである。アプリケーションバイナリーインターフェイス218は、他のアプリケーションによって信頼して実施され得るバイナリーを通じて公開される機能性を表している。この実施例において、アプリケーションバイナリーインターフェイス218は、オペレーティングシステムコンポーネント204に関連するインターフェイス、ベースタイプ、および、ベースパターンを含んでいる。アプリケーション220といった、オペレーティングシステム202の外部の一つまたはそれ以上のアプリケーションは、一つまたはそれ以上のアプリケーションバイナリーインターフェイス218を介してオペレーティングシステム204にアクセスできる。アプリケーション220は、HTML、JavaScript、VisualBasic、C、C、等といった、一つまたはそれ以上のプログラミング言語から生成される一つまたはそれ以上のアプリケーションを含んでいる。いくつかの実施例において、アプリケーション220は、オペレーティングシステムコンポーネントへの一つまたはそれ以上のコールを含んでいる。いくつかの場合では、アプリケーション220は、最初に、何のインターフェイスが利用可能であるかをプログラムで判断し、次に、一つまたはそれ以上の判断されたインターフェイスへのコールを行うように構成されてよい。いくつかの場合では、アプリケーション220は、アプリケーションバイナリーインターフェイス218を通じてインターフェイスにアクセスする。以下に詳しく説明されるように、一つまたはそれ以上の生成された言語プロジェクションモジュール222からの手助けを伴うものである。一つまたはそれ以上の実施例において、生成された言語プロジェクションモジュール222は、抽象型システム定義を所定のプログラミング言語に対してマップする。あらゆる好適なプログラミング言語がマップされ得るが、実施例は上記に提供されている。いくつかの実施例において、生成された言語プロジェクションモジュールは、それぞれのプログラミング言語に対して唯一つであり得る。他の実施例において、生成された言語プロジェクションモジュールは、多目的のものであり、複数のプログラミング言語によって利用され得る。マッピングにより、抽象型システムを使用して記述される現在及び将来のインターフェイスは、追加のプログラミングステートメントつまり、ラッパー関数なしで、所定のプログラミング言語にアクセスすることができる。マッピングにより、さらに、所定のプログラミング言語は、その所定のプログラミング言語のネイティブなやり方でインターフェイスをコールすることができる。クラス、データタイプ、ファンクションポインター、ストラクチャー、等といった、あらゆる好適な情報のタイプはマップされ得る。プログラマーがオペレーティングシステムコンポーネントへのアクセスを望む実施例について検討する。アプリケーション220といった、アプリケーションを書くときに、プログラマーは、少なくとも一つの所定のプログラミング言語に関するエディター/コンパイラーでソースコードを生成する。エディター/コンパイラーは、オペレーティングシステムに関連する何のインターフェイス及び又はAPIが利用可能であるかに関する情報を取得するために、メタデータファイルにアクセスするように構成されてよい。例えば、いくつかの実施例において、プログラマーが、オペレーティングシステムコンポーネントの一部として実施されるクラスへのコールを含むコード行を書くと、エディター/コンパイラーは、そのクラスに関連するメタデータを問い合わせすることができ、何のメソッド、プロパティ、等がクラスに関連するかのリストをプログラマーに返す。リストは、あらゆる種類の情報を含むことができる。情報は、関連メソッド、及び又は、クラスのプロパティ、等である。代替的又は追加的に、リストは、利用可能なクラスのリストを含んでいる。いくつかの実施例において、情報は、選択のためにユーザーに対するインターフェイスの適切なメソッド、プロパティ、等を視覚的に示すように構成されたオートコンプリーションauto-completion機能の一部として提供され得る。メソッド及び又はプロパティの選択に際して、コンパイラー/エディターは、より効率的で正確なソースコードの生成のために、ソースコードの中に対応する文法を挿入することができる。いくつかの実施例において、プログラマーは、オペレーティングシステムコンポーネントのクラスオブジェクトをインスタンス化するように構成されたソースコードを書いてよい。ランタイムにおいてコールされた場合、オペレーティングシステムは、コーリングコードに返すために、クラスのインスタンスを動的に作成する。しかしながら、コードリングコードに返されたインスタンスは、抽象的なオブジェクトabstractobjetであるか、以降に詳しく説明されるように、オペレーティングシステムコンポーネントに関連する抽象型システムにおいて記述されるオブジェクトであり得る。抽象オブジェクトタイプとコーリングコードに関するプログラミング言語の具体的なデータタイプとの間をブリッジするために、コンパイラーは、抽象オブジェクトを関連のプログラミング言語における類似のタイプに変換及び又はマップするように構成され得る。生成された言語プロジェクションモジュール22を通じてといったことである。いくつかの場合には、オペレーティングシステムコンポーネントの抽象オブジェクトと、プログラミング言語に関する具体的なオブジェクトとの間でコールをブリッジするためにプロキシーproxyが使用され得る。オペレーティングシステムコンポーネントクラスの振る舞いをエミュレートするように構成されたプロキシーを検討する。いくつかの場合には、プロキシーは、クラスの関連するタイプ、メソッド、プロパティ、イベント、等のスタブstubを含むように作成され得る。プロキシーは、コーリングコードに係るプログラミング言語で構成され、従って、コーリングコードに対してネイティブなやり方でコーリングコードがプロキシーにアクセスすることができる。スタブは、これらのコールをオペレーティングシステムに対してかつ、オペレーティングシステムから変換及び又はマップするための好適な知識及び又はコードを含み得る。例えば、いくつかの実施例において、プロキシーはアプリケーションバイナリーインターフェイス218と通信することができる。いくつかの実施例において、プログラミング言語は、上述のように、抽象型をプログラミング言語にネイティブなタイプにマップするためのラッパー関数及び又はプロキシーを差し挟むことができる。プログラミング言語のエディター/コンパイラーは、以下のように構成され得る。すなわち、メタデータファイル212、214、および、216といった、メタデータを読み出し、何の抽象型が使用されているか判断し、抽象型を関連するプログラミング言語における一つまたはそれ以上の類似のタイプにマップし、かつ、関連のラッパー関数及び又はプロキシーをオペレーティングシステムコンポーネントに関連する抽象型に知らせる。それぞれのタイプに対するマッピングがプログラミング言語と抽象型システムとの間に一旦存在すれば、抽象型システムによって定義されるあらゆる現行又は将来のインターフェイスは、プログラマーからの追加的なコーディングを必要としないで、プログラミング言語によって自動的にアクセスすることができる。実施例として図3を検討する。図3は、本発明の一つまたはそれ以上の実施例に従った方法におけるステップを説明するフローチャートである。本方法は、あらゆる好適なハードウェア、ソフトウェア、または、それらの組み合わせによって実行され得る。少なくともいくつかの実施例において、本発明の態様は、エディター/コンパイラー114といった、コンピューターデバイス102上で稼働しているソフトウェアによって実行される。ステップ302では、利用可能なオペレーティングシステムインターフェイスに関する情報に対するリクエストを受け取る。例えば、リクエストは、何のインターフェイスが利用可能であるか、及び又は、利用可能なインストラクションに関する他の情報を要求するように構成されてよい。このことは、あらゆる好適なやり方で達成されてよい。いくつかの実施例において、リクエストは、ソースコードによって自動的に生成され得るが、そのソースコードは開発されているものである。コードエディターは、オペレーティングシステムインターフェイス及び又はコンポーネントに対するコールを特定することができ、かつ、特定の際に、オペレーティングシステムインターフェイスに関して利用可能なメソッド、プロパティ、等を求めるリクエストを送付することができる。いくつかの実施例において、リクエストは、ドロップダウンメニュー、ラジオボタン、等の選択を介して手動で生成され得る。リクエストは、全ての利用可能なオペレーティングシステムインターフェイス、いくつかの利用可能なオペレーティングシステムインターフェイス、個々のオペレーティングシステムインターフェイス、または、それらのあらゆる組み合わせに関する情報を要求するように構成されてよい。いくつかの実施例において、リクエストは、図2のアプリケーション220といった、稼働しているアプリケーションを介して生成され得る。ステップ304では、一つまたはそれ以上のオペレーティングシステムインターフェイスに関する情報を取得する。例えば、いくつかの実施例において、オペレーティングシステムは、情報を求めて問い合わせされ得る。代替的又は追加的に、情報は、一つまたはそれ以上のメタデータファイルの中に含まれてよく、そのメタデータファイルのクエリquery及び又は読み出しによって獲得され得る。上記及び下記に説明するように、メタデータファイルは、マシンで読取り可能なフォーマットであってよく、インターフェイスに伴うオブジェクト関係フォーメーションといった、階層的な情報を含んでいる。ステップ306では、獲得した情報に応じて、一つまたはそれ以上のオペレーティングシステムインターフェイスに関する一つまたはそれ以上の抽象型を判断する。上述のように、いくつかの実施例において、オペレーティングシステムインターフェイスは、抽象型システムの使用を通じて、所定のプログラミング言語とは独立して記述され得る。一つまたはそれ以上のオペレーティングシステムインターフェイスに伴う一つまたはそれ以上の抽象型の判断に応じて、ステップ308では、一つまたはそれ以上の抽象型のそれぞれが、所定のプログラミング言語に関するタイプに対してマップされる。OpenPickerランタイムクラスruntimeclassに対するABIを記述しているインターフェイス記述言語に係る実施例を検討する。OpenPickerランタイムクラスの中には、FileItemオブジェクトの集合をリターンするように構成されたPickMultipleItemsが含まれている。この所定の実施例においては、以下のように、FileItemクラスは、Name値を有するFileItemPropertiesをリターンするように構成されたGetPropertiesメソッドを含んでいる。runtimeclassOpenPickerinterfaceIOpenPickerinterfaceIOpenPickerIInspectableHRESULTPickMultipleItemsinterfaceIFileItemIInspectableHRESULTGetPropertiesinterfaceIFileItemPropertiesIInspectablepropgetHRESULTNameいくつかの実施例において、C言語コンパイラーは、記述をC言語構造体にマップすることができる。記述を言語特定の構造体に対してマッピングすることにより、以下に示すように、オペレーティングシステムインターフェイスは、Cプログラミング言語に対してネイティブなやり方でアクセスされ得る。OpenPickerpickernewOpenPickervaritemspickerPickMultipleItemsforeachDisplayNameさらに別の実施例において、言語とは独立な方法で定義された構造は、JavaScriptオブジェクトに対してマップされ得る。以下のように定義されるFrameRate構造の実施例を検討する。typedefstructFrameRateUNIT32NumeratorUNIT32DenominatorFrameRateFrameRate構造は、2つのUNIT32フィールドを含んでいる。すなわち、NumeratorとDenominatorである。FrameRate構造は、言語とは独立した用語を使用して定義されているので、JavaScriptを通じてアクセスされるといった、好適なマッピングを使用している場合に、本構造は、種々の言語特定のプログラミングによってアクセスされ得る。しかしながら、JavaScriptは、フィールドを含む構造のコンセプト、または、符号なしunsigned32ビット整数のコンセプトを含んでいない。代わりに、JavaScriptは、プロパティを伴うオブジェクトのコンセプトとナンバーNumberのコンセプトを含んでいる。この実施例において、上記の構造定義は、Numerator及びDenominatorと名付けられた2つのプロパティを伴うオブジェクトであり得る。両方のNumberタイプは以下のとおりである。JavaScriptuseoftheabovevarframeratevideoTypeFramerateGetaframerateobjectvarratioframerateNumeraotframerateDenominator一つまたはそれ以上のプログラミング言語に対するオペレーティングシステムコンポーネントのプログラムでの公開を検討してきたので、これから、一つまたはそれ以上の実施例に従って、抽象型システムを伴うオブジェクト志向言語のモデリングについて検討する。抽象型システムを用いたオブジェクト志向言語のモデリングオペレーティングシステムインターフェイスが、所定のプログラミング言語を使用して定義されている場合、インターフェイスに関するパラメーターは、所定のプログラミング言語のデータタイプによって特徴付けられる。つまり、インターフェイスのコーラーcallerは、所定のプログラミング言語がどのようにデータタイプを定義しているかに準じている。インターフェイスとして所定のプログラミング言語で書かれたプログラムにとって、データタイプに準じることはありふれたことである。プログラムは、同一のデータタイプ定義を有しているからである。所定のプログラミング言語で書かれておらず、インターフェイスをコールするプログラムは、ときどき、データタイプに準じるための能力を減じてしまう。例えば、異なるプログラミング言語からインターフェイスをコールするプログラマーは、異なるプログラミング言語間、及び又は、データタイプ間において、変換及び又はブリッジを行うためのコードを追加してよい。結果として、データタイプ間をブリッジするプロセスは、しばしば、コールしているプログラミング言語のデータタイプに固有の機能性を減じてしまう。加えて、この変換は、ときどき、複雑であり、いくつかの場合においては、異なるプログラミング言語がオブジェクトが何であるかについて異なるコンセプトを有しているとすれば、現実性が無いものとなり得る。種々の実施例は、オブジェクト志向のやり方で、抽象型システムを利用してオペレーティングシステムの一つまたはそれ以上のインターフェイスをモデル化するための能力を提供する。いくつかの実施例において、拡張IDLは、一つまたはそれ以上のインターフェイス間の関係を記述するための文法を含んでよい。代替的又は追加的に、拡張IDLは、どのようにインターフェイスが記述及び又は定義され得るかを支配する規則を含み得る。いくつかの実施例において、バイナリーコントラクトは、抽象型システムに関する振る舞いを公開するように構成され、さらに、集められたデータタイプに伴う情報を含むように構成され得る。オブジェクト志向モデルは、クラス階級制を使用してオブジェクトを記述する。ここで、クラスは、メソッド、プロパティ、インヘリタンスinheritance等を含んでよい。典型的には、必ずしも必要でないが、オブジェクト志向クラスは一つまたはそれ以上のコンストラクタconstructorを含んでいる。。コンストラクタは、クラス機能であり、コールされるとき、使用されるメモリーの中にクラスのインスタンス/オブジェクトを作成する。クラスのコンストラクタのいくつかは、作成されたインスタンス/オブジェクトの使用に備える追加のコードを含んでいる。例えば、追加のコードは、クラスのメンバー変数の初期化、クラスの関連するスタートアップルーチンの実行、等をすることができる。デフォルトのコンストラクタは入力パラメーターを有していないが、一方、デフォルトでないコンストラクタは一つまたはそれ以上の入力パラメーターを有している。いくつかの実施例において、オペレーティングシステムコンポーネントの一つまたはそれ以上のコンストラクタは、所定の実施、及び又は、デザインに従うように制約され得る。所定の実施に従うことによって、コンストラクタのコーラーは、そのコンストラクタ、及び又は、結果とし生じるオブジェクトがどのように振る舞うかに依存し得る。例えば、オペレーティングシステムコンポーネントのデフォルトコンストラクタは、クラスファクトリーオブジェクトのIActivationFactoryインターフェイスに係るActivateInstanceメソッドのデフォルトコンストラクタについて、制約及び又はマップされ得る。クラスファクトリーオブジェクトは、作成されるオブジェクトの正確なクラスを規定することなく、オブジェクトを作成するようにモデル化されたデザインパターンである。クラスファクトリーモデルを使用することにより、デフォルトコンストラクタは、十分なレベルの抽象化を維持することができる。オペレーティングシステムコンポーネントのデフォルトでないコンストラクタは、また、クラスファクトリーの代替のインターフェイスといった、一つまたはそれ以上の特別に指定されたインターフェイス上に置かれるように制約され得る。インターフェイスの記述を規定する一つのやり方は、IDL及び又はXMLのような拡張記述言語といった、記述的な言語の使用を通じたものである。いくつかの実施例において、拡張記述言語は、オペレーティングシステムコンポーネントの一つまたはそれ以上のコンストラクタインターフェイスを記述及び又は指定する能力を可能にするように構成されてよい。例えば、以下に説明するように、Compressorクラスを検討する。この実施例において、Compressorクラスは、クラスに関するデフォルトでないコンストラクタメソッドの少なくとも一つの定義を含むICompressorFactoryインターフェイスを宣言する。versionactivatableruntimeclassCompressordefaultinterfaceICompressorversionuuidinterfaceICompressorFactoryIlnspectableHRESULTCreateCompressorオブジェクト志向クラスは、少なくとも一つの静的メソッド、少なくとも一つの静的プロパティ、少なくとも一つの静的イベント、または、これらのあらゆる組み合わせを含むように構成されてよい。コンストラクタに係る定義の制約と同様に、静的メソッド、静的プロパティ、及び又は、静的イベントは、一つまたはそれ以上の特に指定されたインターフェイスに従うようにデザインされ得る。静的メソッド、プロパティ、および、イベントを宣言するCallControlクラスの実施例を検討する。この実施例において、静的メソッド、プロパティ、および、イベントは、CallControlStaticsインターフェイスにおいて、以下のように定義される。versionuuidexclusivetointerfaceICallControlStaticsIlnspectableHRESULTGetDefaultHRESULTFromIdRuntimeclassesversionstaticruntimeclassCallControldefaultinterfaceICallControlオブジェクト志向クラスは、少なくとも一つのインスタンスメソッド、少なくとも一つのインスタンスプロパティ、少なくとも一つのインスタンスイベント、または、これらのあらゆる組み合わせを含むように構成されてよい。インスタンスメンバーメソッド、プロパティ、および、イベントは、クラスの所定のインスタンス上で動作し、一方、静的なメンバーはクラスの全てのメンバーによって共有される。クラスは、一つまたはそれ以上の特に指定されたインターフェイスに従うようにデザインされ得る。関連するインスタンスメソッド、プロパティ、および、イベントがICallControlインターフェイスにおいて定義されることをCallControlクラスが宣言する上記の実施例といったインターフェイスである。いくつかの実施例において、一つまたはそれ以上のオペレーティングシステムコンポーネントは、クラスファクトリーデザインパターンの後/上にこれらのインターフェイスをモデル化/実施することができる。所定のプログラミング言語が、言語固有のコンストラクタ、静的又はインスタンスメンバー、言語プロジェクションモジュール、図2に係る生成された言語プロジェクションモジュールといったもの、をコールするかどうかは、プログラミング言語固有のコールを好適なクラスファクトリーオブジェクト又はインスタンスに関する好適なメソッド及び又はインターフェイスに対してマップすることができる。いくつかの実施例において、クラスファクトリーオブジェクトは、オペレーティングシステムコンポーネント及び又はランタイムクラスと関連している。例えば、ランタイムクラスのインスタンスを作成するようにコンパイラーに指示しているコードのメソッド署名を、クラスファクトリーオブジェクトの好適なコンストラクタインターフェイスメソッドに調和させることができる。さらに別の実施例において、言語プロジェクションモジュールは、静的メソッドをコールするようにコンパイラーに指示している言語固有のメソッド署名を、オペレーティングシステムコンポーネントに関連する静的インターフェイス上の好適な整合インターフェイスメソッドに調和させるように構成され得る。さらに別の実施例において、、言語プロジェクションモジュールは、インスタンスメソッドをコールするようにコンパイラーに指示している言語固有のメソッド署名を、オペレーティングシステムコンポーネントの所定のインスタンスに関連するインターフェイス上の好適な整合インターフェイスメソッドに調和させるように構成され得る。いくつかの実施例において、IDLコンパイラーは、少なくとも一つのオペレーティングシステムコンポーネントインターフェイス記述に関連する一つまた生成するように構成され得る。あらゆる好適な情報のタイプが拡張IDLファイルの中に含まれてよい。タイプ、メソッド、プロパティ、イベント、および、関連のオペレーティングシステムコンポーネントのインターフェイスを記述している情報といったものである。いくつかの場合には、コンパイラーは、マシンで読取り可能なメタデータファイルを生成することができる。一つまたはそれ以上のアプリケーションは、何のインターフェイスが利用可能であるかをプログラムで判断するための関連のマシンで読取り可能なファイル、インターフェイスに係る関連の記述及び又は宣言、インターフェイスに係るパラメーターのデータタイプ、等を読み出すように構成され得る。一つまたはそれ以上のアプリケーションは、あらゆる好適なプログラミング言語で書かれてよく、実施例が上記に提供されている。いくつかの実施例において、IDLコンパイラーは、タイプ、メソッド、プロパティ、イベント、及び又は、インターフェイスに関連する一つまたはそれ以上のコミュニケーションプロキシー及び又はコードスタブを生成することができる。コミュニケーションプロキシー及び又はコードスタブは、オペレーティングシステムコンポーネントによるアクセスのために追加的に構成され得る。図4について検討する。図4は、本発明の一つまたはそれ以上の実施例に従って、拡張IDLファイル402、コンパイラー404、および、メタデータファイル406との間の関係を示している。ここで、拡張IDLファイル402は、メタデータファイル406を生成するために、コンパイラー4040によって受け取られ、処理される。少なくともいくつかの実施例において、関係図に示されたモジュールは、コンピューターデバイス102上で動作する、ソフトウェア、ハードウェア、または、エディター/コンパイラーモジュール114といった、これらのあらゆる組み合わせとして実施例され得る。図示され説明される実施例において、拡張IDLファイル402は、オペレーティングシステムAPIといった、一つまたはそれ以上のオペレーティングシステムコンポーネントインターフェイスを定義する一つまたはそれ以上のファイルを含んでよい。オペレーティングシステムコンポーネントのあらゆる好適なタイプが記述され得る。ファイルオブジェクト/クラス、ストリングオブジェクト/クラス、グラフィックオブジェクト/クラス、カルチャーオブジェクト/クラス、等といったものである。それぞれのオブジェクトは、オブジェクト志向クラスに関連付けされ得るメソッド、プロパティ、インヘリタンス情報、等を含んでよい。拡張IDLは、一つまたはそれ以上のインターフェイス間の関係に係るこれらのタイプが記述できるようにする文法を含み得る。いくつかの実施例において、抽象型システムは、種々のデータタイプをサポート及び又は記述するように構成され得る。例えば、メソッドインターフェイスは、全てのインターフェイスがオブジェクトのインスタンス上で動作するという物理的な要求をマップするように定義され得る。別の実施例において、抽象型システムは、プログラミング言語とコンポーネント境界をまたいでコールされ得るようにファンクションポインターを定義するために使用されてよい。第1のコンポーネントは、ファンクションポインター、または、デリゲートdelegateから生じてよく、メソッドに結び付けられている。デリゲートは、次に、バイナリーコンピレーションcompilation境界をまたいで任意のプログラミング言語で書かれた第2のコンポーネントに対してパスpassされ、実施される。種々の実施例によって、拡張IDLは、これらのデータタイプを定義及び又は記述することができ、データタイプを集合体の型の中へ混ぜ合わせるのと同様に、基本的なデータタイプを構成するための規則を定義することができる。図示され説明される実施例において、コンパイラー404は、拡張IDLファイル402といった、一つまたはそれ以上の入力ファイルを受け容れ、一つまたはそれ以上のメタデータファイル406を生成する。メタデータファイル406は、自動アクセスのための構成されてよい。例えば、メタデータファイルは、マシンで読取り可能なフォーマットで保管され得る。いくつかの実施例において、メタデータファイル406は、一つまたはそれ以上のオペレーティングシステムコンポーネントと関連している。代替的又は追加的に、コンパイラー404は、上述のように、スタブアウトstubbedoutコミュニケーションプロキシーを生成することができる。アプリケーション408は、何のAPIが利用可能であるかを動的に判断することができる。メタデータファイル406の読み出しを通じて、といったものである。いくつかの実施例において、アプリケーション408は、図1に係るエディター/コンパイラーとして構成され得る。メタデータファイル406を通じて、アプリケーションは、機能性について以降のバージョンが存在するかどうか、どんなパラメーターをAPIが取るか、を判断し、同様に、ランタイムにおいてAPIの何の機能性が存在するかをユーザーに知らせることができる。従って、抽象型システムを用いてAPIを記述することと同様に、APIの記述をマシンで読取り可能なフォーマットに含めることによって、抽象型システムと所定のプログラミング言語との間のマッピングをサポートするアプリケーション及び又は言語は、プログラマーからの少ない労力でAPIに容易にアクセスできる。抽象型システムを用いたオブジェクト志向言語のモデル化について検討してきたので、これから、一つまたはそれ以上の実施例に従ったシステム例について検討する。システム例図5は、上述の種々の実施例を実行するために利用され得るコンピューターデバイス500を例示している。コンピューターデバイス500は、例えば、図1に係るコンピューターデバイス、または、あらゆる他の好適なコンピューターデバイスであってよい。コンピューターデバイス500は、一つまたはそれ以上のプロセッサ又は処理ユニット502、一つまたはそれ以上のメモリー及び又はストレージコンポーネント504、一つまたはそれ以上の入力/出力I/Oデバイス506、および、種々のコンポーネントとデバイスがお互いにコミュニケーションできるようにするバス508、を含んでいる。バス508は、バス構成のいくつかのタイプに係るあらゆる一つまたはそれ以上のものを表しており、メモリーバス又はメモリーコントローラー、ペリフェラルバス、加速グラフィックポート、および、あらゆる種類のバスアーキテクチャーを使用しているプロセッサ又はローカルバス、を含んでいる。バス508は、有線及び又は無線バスを含んでよい。メモリー/ストレージコンポーネント504は、一つまたはそれ以上のコンピューターストレージ媒体を表している。コンポーネント504は、揮発性媒体ランダムアクセスメモリーRAMといったもの、及び又は、不揮発性媒体読み出し専用メモリーROM、フラッシュメモリー、光ディスク、磁気ディスク、等といったものを含み得る。コンポーネント504は、固定媒体例えば、RAM、ROM、固定ハードドライブ、等を、リムーバブル媒体例えば、フラッシュメモリードライブ、リムーバブルハードドライブ、光ディスク、等と同様に含んでよい。一つまたはそれ以上の入力/出力デバイス506により、ユーザーは、コンピューターデバイス500に対してコマンド及び情報を入力することができ、また、情報をユーザー及び又は他のコンポーネントまたはデバイスに対して示すことができる。入力デバイスの実施例は、キーボード、カーソルコントロールデバイス例えば、マウス、マイクロフォン、スキャナー、等を含んでいる。出力デバイスの実施例は、ディスプレイ装置例えば、モニター又はプロジェクター、スピーカー、プリンター、ネットワークカード、等を含んでいる。種々の技術が、ソフトウェアまたはプログラムモジュールの一般的な内容で、ここにおいて説明された。一般的に、ソフトウェアは、ルーチン、プログラム、アプリケーション、オブジェクト、コンポーネント、データ構造、などといった所定のタスクを実行するもの、または所定の抽象的なデータタイプを実行するものを含む。これらのモジュールおよび技術の実施は、コンピューターで読み取り可能な媒体のいくつかの形式で保管され、または媒体にわたり伝送される。コンピューターで読み取り可能な媒体は、コンピューティングデバイスによってアクセスすることができる、あらゆる利用可能な媒体またはメディアであってよい。実施例として、かつ、限定するものではなく、コンピューターで読み取り可能な媒体は、コンピューターで読取り可能なストレージ媒体computer-readablestorgaemediaを含み得る。コンピューターで読取り可能なストレージ媒体は、コンピューターで読み取り可能なインストラクション、データ構造、プログラムモジュール、または、他のデータといった情報を保管するためのあらゆる方法または従来技術において実施される、揮発性および不揮発性媒体、取出し可能および取出し不能媒体を含む。コンピューターで読取り可能なストレージ媒体は、これらに限定されるわけではないが、RAM、ROM、EEPROM、フラッシュメモリー、または他のメモリー技術、CD-ROM、デジタル多目的ディスクDVD、磁気カセット、磁気テープ、磁気ディスクストレージまたは磁気ストレージデバイス、または、所望の情報を保管するために使用でき、コンピューターによってアクセスされ得る他のあらゆる媒体、を含んでいる。結論種々の実施例が、プログラミング言語とは独立して、オペレーティングシステムに関連する一つまたはそれ以上のインターフェイスを記述するための能力を提供する。代替的又は追加的に、所定のプログラミング言語に関連するコンパイラーは、独立したインターフェイス記述をプログラミング言語に特有な好適なコンストラクトに対してマップするように構成され得る。いくつかの実施例において、アプリケーションは、オペレーティングシステムの一つまたはそれ以上のインターフェイスをプログラムで判断するように構成され得る。技術的事項が構造的特徴及び/又は方法論的アクトに特有の言葉で説明されてきたが、添付の特許請求の範囲において定められる技術的事項は、上述された特定の特徴またはアクトに必ずしも限定される必要はないことが理解されるべきである。むしろ、上述の特定の特徴およびアクトは、請求項に係る発明の実施例として開示されたものである。