(57)【特許請求の範囲】
【請求項１】
コンピューターで実施される方法であって：
一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する情報に対するリクエストを受け取るステップと；
前記一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する情報を取得するステップであり、前記オペレーティングシステムインターフェイスは抽象型システムを使用して記述されており、
前記抽象型システムは、所定のプログラミング言語から独立したインターフェイスの記述ができるように構成されており、
オペレーティングシステムの少なくとも一つの記述は、コールしているパラメータータイプの記述を含んでいる、ステップと；
少なくとも一つのバイナリーコントラクトを使用して前記一つまたはそれ以上の利用可能なオペレーティングシステムに関連する一つまたはそれ以上の抽象型システムをプログラムで判断するステップであり、
前記一つまたはそれ以上の抽象型システムを判断することは、前記一つまたはそれ以上の抽象型システムに関連する振る舞いを判断することを含み、
前記バイナリーコントラクトは、マシンレベルの定義を含むように構成されている、ステップと；
判断された個々の抽象型システムを、少なくとも一つの所定のプログラミング言語に関連するそれぞれのタイプにマップするステップと、を含む、
ことを特徴とする方法。
【請求項２】
前記一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する前記情報は、さらに、階層的な情報を含んでいる、
請求項１に記載の方法。
【請求項３】
前記情報は、少なくとも一つのインターフェイスに関するバージョン情報、前記少なくとも一つのインターフェイスに関する個々のパラメーターのデータタイプ、前記少なくとも一つのインターフェイスに関する前記個々のパラメーターのコール順序、を含む、
請求項１に記載の方法。
【請求項４】
前記一つまたはそれ以上の利用可能なオペレーティングシステムインターフェイスに関連する情報を取得する前記ステップは、少なくとも一つのメタデータファイルからプログラムで情報を取得するステップを含む、
請求項１に記載の方法。
【請求項５】
前記バイナリーコントラクトは、一つまたはそれ以上のファンクションの署名を含む、
請求項１に記載の方法。
【請求項６】
前記バイナリーコントラクトは、一つまたはそれ以上のファンクションの名前を含む、
請求項５に記載の方法。
【請求項７】
コンピューターで読取り可能なインストラクションを含む一つまたはそれ以上のコンピューターで読取り可能なストレージ媒体であって、
少なくとも一つのプロセッサによる前記インストラクションの実行に応じて：
オペレーティングシステムに関連する機能性にプログラムでアクセスできるように構成されている、一つまたはそれ以上のアプリケーションプログラミングインターフェイス（ＡＰＩ）と；
前記一つまたはそれ以上のＡＰＩに関連する一つまたはそれ以上のメタデータであり、前記メタデータは、前記一つまたはそれ以上のＡＰＩに係る少なくとも一つの記述を含むように構成されており、前記少なくとも一つの記述は前記一つまたはそれ以上のＡＰＩへのプログラムのアクセスを記述する、メタデータと；
前記一つまたはそれ以上のＡＰＩをコールするための一つまたはそれ以上のマシンレベルのバイナリーコントラクトを含むように構成されている、一つまたはそれ以上のアプリケーションバイナリーインターフェイス（ＡＢＩ）モジュールと；
抽象型システムの少なくとも一つのタイプを一つまたはそれ以上の所定のプログラミング言語の少なくとも一つのタイプにマップするように構成されている、一つまたはそれ以上の生成された言語プロジェクションモジュールであり、
前記抽象型システムは、所定のプログラミング言語から独立したインターフェイスの記述ができるように構成されており、前記ＡＰＩに関連するコールしているパラメータータイプの記述を含んでいる、モジュールと、
を実行する、
ことを特徴とするコンピューターで読取り可能なストレージ媒体。
【請求項８】
前記一つまたはそれ以上のコンピューターで読取り可能なストレージ媒体は、さらに、インストラクションを含み、
少なくとも一つのプロセッサによる前記インストラクションの実行に応じて：
前記一つまたはそれ以上のメタデータファイルを通じて、前記少なくとも一つのＡＰＩモジュールの中に含まれ、少なくとも一つのインターフェイスをプログラムで判断するように構成されている少なくとも一つのアプリケーション、を実行する、
請求項７に記載のコンピューターで読取り可能なストレージ媒体。
【請求項９】
前記生成された言語プロジェクションモジュールは、前記一つまたはそれ以上のプログラミング言語にネイティブなやり方で、前記抽象型システムの少なくとも一つのタイプをエミュレートするように構成されている少なくとも一つのプロキシーを含んでいる、
請求項７に記載のコンピューターで読取り可能なストレージ媒体。
【請求項１０】
前記一つまたはそれ以上のＡＰＩをコールするための前記バイナリーコントラクトは、前記抽象型システムの少なくとも一つのタイプに関する少なくとも一つの振る舞い定義を含んでいる、請求項７に記載のコンピューターで読取り可能なストレージ媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ランタイムシステムに関する。
【背景技術】
【０００２】
今日のコンピューターは、しばしば、ハードウェア及びソフトウェアリソースへのアクセスを管理するためのオペレーティングシステム含んでいる。同様に、オペレーティングシステムは、アプリケーションプログラミングインターフェイス（ＡＩＰ）といった、種々のタイプのインターフェイスを含んでおり、プログラマー及び/又はアプリケーションが、こうしたリソースにアクセスすることができる。いくつかの場合において、インターフェイスは、念頭にある所定のプログラミング言語を用いてプログラムされる。クライアントアプリケーションが所定のプログラミング言語で書かれている場合、クライアントアプリケーションは、その所定のプログラミング言語にネイティブ（ｎａｔｉｖｅ）なやり方でインターフェイスにアクセスすることができる。しかしながら、クライアントアプリケーションが、インターフェイスとは異なる言語で書かれている場合は、そのインターフェイスを招き入れるために、ときどき、追加的なコード及び/又はラッパー関数（ｗｒａｐｐｅｒ  ｆｕｎｃｔｉｏｎ）を利用することになってしまう。
【０００３】
典型的に、インターフェイスは、オペレーティングシステムに対して外部で記述される。インターフェイスを成功裡にコール（ｃａｌｌ）するためには、ラッパー関数を書くことと同様に、プログラマーは、何のインターフェイスが利用可能であるか、関連するコールパラメーターは何であるか、等を判断するために、外部の文書を調査する。オペレーティングシステムの新しいバージョンは、新たなインターフェイス、古いインターフェイスに対する変更を、廃止したインターフェイスの除去と同様に、含むことができる。従って、現行のＡＰＩセットを維持するために、プログラマーは、オペレーティングシステムの新たなバージョンそれぞれについて、外部の文書を調査する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
このことは、ときどき、インターフェイスがオペレーティングシステムの中にリリースされる時間と、そのインターフェイスがプログラムの中に包含される時間との間の遅延を結果として生じている。
【課題を解決するための手段】
【０００５】
本概要は、以降の詳細な説明でより詳しく記述される本発明の概念について、簡素化された形式において代表的な概念の選択を紹介するものである。本概要は、特許請求された技術的事項の主要な特徴または本質的な特徴を特定することを意図するものではない。また、特許請求された技術的事項の範囲を限定するために使用されることを意図するものではない。
【０００６】
種々の実施例は、プログラミング言語とは独立して、オペレーティングシステムに関する一つまたはそれ以上のインターフェイスを記述する能力を提供する。代替的又は追加的に、所定のプログラミング言語に関するコンパイラーは、独立したインターフェイス記述を所定のプログラミング言語にマップするように構成されてよい。いくつかの実施例において、アプリケーションは、オペレーティングシステムの一つまたはそれ以上のインターフェイスをプログラムで決定するように構成されてよい。
【０００７】
いくつかの実施例は、オブジェクト志向（ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄ）のやり方で、抽象型（ａｂｓｔｒａｃｔ  ｔｙｐｅ）システムを利用してオペレーティングシステムの一つまたはそれ以上のインターフェイスをモデル化する能力を提供する。いくつかの実施例において、拡張インターフェイス定義言語（ＩＤＬ：Ｉｎｔｅｒｆａｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ）は、一つまたはそれ以上のインターフェイス間の関係を記述する文法を含んでよい。いくつかの実施例においては、抽象型システムに関する振る舞いを表すように、バイナリーコントラクト（ｃｏｎｔｒａｃｔ）が構成され得る。
【図面の簡単な説明】
【０００８】
類似の機能を参照するために、全ての図面にわたって同一の番号が使用されている。
【図１】図１は、本発明の一つまたはそれ以上の実施例に従って、ここにおいて説明された種々の原理が使用され得る、オペレーティング環境を示している。
【図２】図２は、本発明の一つまたはそれ以上の実施例に従ったアーキテクチャーを示している。
【図３】図３は、本発明の一つまたはそれ以上の実施例に従った方法におけるステップを説明するフローチャートである。
【図４】図４は、本発明の一つまたはそれ以上の実施例に従った関係の模式図を示している。
【図５】図５は、本発明の一つまたはそれ以上の実施例を実行するために利用され得るシステム例を示している。
【発明を実施するための形態】
【０００９】
概要
種々の実施例は、プログラミング言語とは独立して、オペレーティングシステムに関する一つまたはそれ以上のインターフェイスを記述する能力を提供する。抽象型システムは、インターフェイス定義言語（ＩＤＬ）と組み合わされて、インターフェイスを記述、及び/又は、定義するように構成されてよい。いくつかの実施例において、インターフェイスは、オブジェクト志向なやり方で記述され得る。代替的又は追加的に、プログラミングアプリケーションのランタイム環境は、言語とは独立したインターフェイス記述を、所定のランタイム環境における好適なコンストラクト（ｃｏｎｓｔｒｕｃｔ）に対して動的に（例えば、ランタイム実行の最中に）マップするように構成されてよい。いくつかの実施例において、アプリケーションは、独立したインターフェイスの記述ををプログラムで決定するように構成されてよい。いくつかの場合において、独立したインターフェイスの記述は、マシンで読取り可能なフォーマットで保管され得る。
【００１０】
後に続く説明において、「オペレーティング環境」というタイトルのセクションが備えられ、一つまたはそれ以上の実施例が使用され得る一つの環境を説明している。これに続いて、「オペレーティングシステムのコンポーネントアクセス」というタイトルのセクションは、複数のプログラミング言語がシステムコンポーネントに対してプログラムでアクセスできるアーキテクチャーを説明している。次に、「抽象型システムを用いたオブジェクト志向言語のモデリング」というタイトルのセクションでは、拡張ＩＤＬと併せて、オブジェクト志向なやり方でオペレーティングシステムインターフェイスを記述するために抽象型タイプシステムがどのように使用されるかを説明する。最後に、「システム例」というタイトルのセクションでは、一つまたはそれ以上の実施例を実行するために使用され得るシステム例を説明する。
【００１１】
以降に説明される種々の実施例についての概要を提供してきたので、一つまたはそれ以上の実施例が実行され得るオペレーティング環境の例についてこれから検討する。
【００１２】
オペレーティング環境
図１は、本発明の一つまたはそれ以上の実施例に従ったオペレーティング環境を示しており、全般的に参照番号１００である。環境１００は、一つまたはそれ以上のプロセッサ１０４を有するコンピューターデバイス１０２、および、一つまたはそれ以上のコンピューターで読取り可能なストレージ媒体１０６を含んでいる。コンピューターで読取り可能なストレージ媒体は、例示であって限定するものではないが、コンピューターデバイスと典型的に関連する揮発性及び不揮発性メモリー及び/又はストレージ媒体に係る全ての形式を含んでいる。そうした媒体は、ＲＯＭ、ＲＡＭ、フラッシュメモリー、ハードディスク、リムーバブル媒体、等を含んでよい。コンピューターデバイスの一つの所定の実施例が、以降の図５において示され、説明される。
【００１３】
加えて、コンピューターデバイス１０２は、オペレーティングシステム（ＯＳ）１０８、および、関連するオペレーティングシステムインターフェイス１１０を含んでいる。これらは別個のモジュールとして示されているが、オペレーティングシステム１０８とオペレーティングシステムインターフェイス１１０は、本発明で請求される技術的事項の範囲を逸脱することなく、別個のモジュール、結合したモジュール、または、あらゆる組み合わせとして実施し得ることが正しく理解されるべきである。オペレーティングシステム１０８は、コンピューターデバイス１０２のソフトウェア及び/又はハードウェアリソースを管理するように構成された機能性を表している。オペレーティングシステムインターフェイス１１０は、オペレーティングシステム１０８によって提供されるサービス及び/又は機能性に対してプログラムでアクセスすることを表している。メモリー管理、ファイル管理、サービス、機能、リソース管理、周辺機器管理、等といったものである。
【００１４】
コンピューターデバイス１０２は、また、記述的言語ファイル１１２を含んでおり、一つまたはそれ以上のインターフェイスを記述するように構成されている一つまたはそれ以上のファイルを表している。いくつかの実施例において、インターフェイスは、オペレーティングシステムインターフェイス１１０といった、オペレーティングシステムに関連付けられ得る。記述的言語ファイルは、あらゆる好適な記述、マークアップ言語、及び/又は、文法を使用してインターフェイスを記述することができる。インターフェイス定義言語（ＩＤＬ）、拡張マークアップ言語（ＸＭＬ）、等を用いるものである。
【００１５】
加えて、コンピューターデバイス１０２は、また、一つまたはそれ以上のエディター／コンパイラーモジュール１１４を含んでいる。いくつかの実施例において、エディター／コンパイラーモジュール１１４は、記述的言語ファイル１１２を読み出し、及び/又は、解釈して、ファイル１１２に基づいて、一つまたはそれ以上のバイナリーメタデータファイル１１６といった、出力を生成する機能性を表している。バイナリーメタデータファイル１１６は、オペレーティングシステムインターフェイス１１０及び/又はオペレーティングシステム１０８に関する情報を含んでいる一つまたはそれ以上のマシンで読取り可能なファイルを表している。情報は、入力パラメータータイプ、パラメーターコールオーダー、インターフェイス間の関係、等である。
【００１６】
代替的又は追加的に、エディター／コンパイラーモジュール１１４は、一つまたはそれ以上のソースコード１１８を読み出し、及び/又は、解読する機能性を表している。ソースコードファイル１１８は、少なくとも一つのプログラミング言語に関するプログラミングステートメントを含む一つまたはそれ以上のファイルに対応している。エディター／コンパイラーモジュール１１４は、ソースコード１１８を解釈して、そのソースコードに基づいてマシンで実行可能なコードを生成する。
【００１７】
コンピューターデバイス１０２は、あらゆる好適なコンピューターデバイスとして実施され得る。例示であって限定するものではないが、デスクトップコンピューター、ポータブルコンピューター、ノートブックコンピューター、パーソナルデジタルアシスタント（ＰＤＡ）といったハンドヘルドコンピューター、携帯電話、等といったものである。
【００１８】
オペレーティング環境の実施例について説明してきたので、一つまたはそれ以上のプログラミング言語に対して、オペレーティングシステムコンポーネントをプログラムで公開することについてこれから検討する。
【００１９】
オペレーティングシステムのコンポーネントアクセス
コンピューターデバイス上で実行されているアプリケーションは、しばしば、そのコンピューターデバイス上で稼働しているオペレーティングシステムに備えられた機能を利用している。オペレーティングシステムは、コンピューターデバイス上で関連のリソースに対する簡素なアクセスを可能にし、同様に、サービスを提供する。ときどき、これらの機能、サービス、及び/又は、リソースは、プログラムでアクセスされ得る。しかしながら、オペレーティングシステムが、こうした機能性を、アプリケーションが書かれたプログラミング言語とは異なるプログラミング言語フォーマットにおいて、公開する場合に、プログラマーは、典型的に、異なるプログラミング言語間での転換を援助するラッパー関数を書くであろう。例えば、フラットで、エクスポートされた、「Ｃ」関数として、書かれ、及び/又は、公開されたインターフェイスを検討する。「Ｃ」スタイル関数の使用を望んでいるＣ＃またはビジュアルベーシックのプログラマーは、それらのプログラミング言語が成功裡に「Ｃ」スタイル関数をコールできるようにするために、特別なステートメント及び/又は追加コードを含んでよい。結果として、公開されたインターフェイスとは異なるプログラミング言語で書かれたアプリケーションは、追加的なステートメント及び/又はラッパー関数が書かれるまでは、インターフェイスに対してアクセスできない。
【００２０】
種々の実施例は、プログラミング言語とは独立して、オペレーティングシステムに関する一つまたはそれ以上のインターフェイスを記述する能力を備えている。プログラム言語とは独立したインターフェイスを記述することで、複数のプログラミング言語がインターフェイスに対して容易にアクセスすることができる。プログラミング言語がインターフェイスに係る言語とは独立した記述をどのように解釈するか学習した場合、この知識は、言語とは独立した記述を使用する既存及び将来のインターフェイスについて適用することができる。いくつかの実施例において、インターフェイスは、抽象型システムを使用して記述することができる。同様に、所定のプログラミング言語、または、関連のプログラミング言語コンパイラーは、インターフェイスを解釈及び/又はアクセスするために、抽象型システムを関連するタイプのシステムに対してマップし得る。
【００２１】
図２は、アーキテクチャー２００を示しているが、一つまたはそれ以上の実施例と関連して検討する。アーキテクチャー２００は、コンピューターデバイス上で実行されるように構成されたオペレーティングシステム２０２を含んでいる。簡素化の目的のために、オペレーティングシステム２０２は、その全体が示されていないことを理解すべきである。オペレーティングシステム２０２は、コンピューターデバイスと関連するリソースを管理するように構成された一つまたはそれ以上のオペレーティングシステムコンポーネント２０４を含んでいる。いくつかの実施例においてオペレーティングシステムコンポーネント２０４は、リソースに対するプログラムのアクセスを提供することができる。リソース管理に関する一つまたはそれ以上のサービス及び/又は機能も同様に提供し得る。オペレーティングシステムコンポーネント２０４は、また、オペレーティングシステム２０２に関するベーシックエレメントを、そのベーシックエレメントから作成された複雑なエレメントと同様に、含むことができる。
【００２２】
いくつかの実施例において、オペレーティングシステムコンポーネント２０４は、ＡＰＩといった、一つまたはそれ以上のインターフェイスを介して公開され得る。この実施例において、オペレーティングシステム２０２は、新たなＡＰＩファミリー２０６、ＣＯＭベースのＡＰＩファミリー２０８、および、フラットエクスポートベースのＡＰＩファミリー２１０を含んでいる。新たなＡＰＩファミリー２０６は、以下に詳しく説明されるように、機能性（つまり、クラス、インターフェイス、メソッド、プロパティ、イベント、等）が、抽象型システムを使用して直接的に記述されている、一つまたはそれ以上の関連するＡＰＩを表している。ＣＯＭベースのＡＰＩファミリー２０８は、コンポーネントオブジェクトモデル（ＣＯＭ）タイプシステムを使用して機能性が記述されている一つまたはそれ以上のＡＰＩを表している。フラットエクスポートベースのＡＰＩファミリー２１０は、メソッド署名（つまり、メソッド名、コールコンベンション、メソッドアーギュメント（ａｒｇｕｍｅｎｔ）の数とタイプ、を含むメソッド署名）を使用して機能性が記述されている一つまたはそれ以上のＡＰＩを表している。フラットエクスポートベースのＡＰＩは、さらに、名前によってだけ識別されるＡＰＩを表しており、クラスの中に、及び/又は、オブジェクト志向のやり方では、配置されない。どのＡＰＩが利用可能であるか判断したいプログラマーは、手動、及び/又は、プログラムでそれぞれのＡＰＩの記述にアクセスすることができる。例えば、新たなＡＰＩファミリー２０６に対してどんなインターフェイスが存在するか、そして、それらをどのようにコールするかを判断するために、プログラマーは、関連のメタデータ２１２にアクセスすることができる。ＣＯＭベースのＡＰＩファミリー２０８とフラットエクスポートベースのＡＰＩファミリー２１０は、それぞれに、メタデータ２１４と２１６において、関連する言語独立タイプのシステムの記述を有している。一方で、プログラマーは、最初に、言語独立タイプのシステム記述をＣＯＭベース及び/又はフラットエクスポートベースのＡＰＩに対してマップするためにラッパーコードを書く。
【００２３】
メタデータ２１２、２１４、および、２１６は、関連するインターフェイスの種々の態様を記述する情報を含むように構成されてよい。バージョン情報、どの方法が利用可能か、どのパラメーターをインターフェイスが獲得するか、パラメーターのデータタイプ、パラメーターをパスする順序、等といった情報である。いくつかの実施例において、メタデータは、インターフェイスに関連する階層的な情報を含んでよい。インターフェイス間の関係を記述している情報、及び/又は、オブジェクト志向のやり方でインターフェイスを記述している情報といったものである。メタデータは、クラス記述、クラスの関連する方法とパラメーター、等を含むように構成されてよい。いくつかの実施例において、一つまたはそれ以上のＩＤＬファイルは、こうした記述のいくつかを含むように拡張され、一つまたはそれ以上のメタデータファイルの生成において使用され得る。いくつかの場合において、メタデータは、以降に詳しく説明されるように、少なくとも部分的には、一つまたはそれ以上のＩＤＬファイルに基づくものであり得る。
【００２４】
オペレーティングシステム２０２は、また、アプリケーションバイナリーインターフェイス（ＡＢＩ）２１８を含んでいる。ＡＢＩは、マシンレベルで、ファンクション、メソッド、ＡＰＩ、等をコールするためのバイナリーコントラクト（ｂａｉｎａｒｙ  ｃｏｎｔｒａｃｔ）を記述する。バイナリーコントラクトは、ファンクションに関する識別子又は名前、ファンクションをコールするために使用される署名、パラメーターに関連するファンクション及び/又はデータタイプに対してパスされるパラメーターの順序、等を含んでいる。代替的又は追加的に、バイナリーコントラクトは、型システムの少なくとも一つのタイプに関連する振る舞いを公開するための定義及び/又は規則を含んでよい。典型的に、バイナリーコードに関連し、及び/又は、バイナリーコントラクトによって定義される振る舞いは、変化しない。例えば、バイナリーコントラクトの署名及び/又は識別子が一定のままである場合、コントラクトの関連する振る舞いも同様に一定のままである。
【００２５】
アプリケーションバイナリーインターフェイス２１８は、他のアプリケーションによって信頼して実施され得るバイナリーを通じて公開される機能性を表している。この実施例において、アプリケーションバイナリーインターフェイス２１８は、オペレーティングシステムコンポーネント２０４に関連するインターフェイス、ベースタイプ、および、ベースパターンを含んでいる。アプリケーション２２０といった、オペレーティングシステム２０２の外部の一つまたはそれ以上のアプリケーションは、一つまたはそれ以上のアプリケーションバイナリーインターフェイス２１８を介してオペレーティングシステム２０４にアクセスできる。
【００２６】
アプリケーション２２０は、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ(登録商標)、Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｃ＃、Ｃ＋＋、等といった、一つまたはそれ以上のプログラミング言語から生成される一つまたはそれ以上のアプリケーションを含んでいる。いくつかの実施例において、アプリケーション２２０は、オペレーティングシステムコンポーネントへの一つまたはそれ以上のコールを含んでいる。いくつかの場合では、アプリケーション２２０は、最初に、何のインターフェイスが利用可能であるかをプログラムで判断し、次に、一つまたはそれ以上の判断されたインターフェイスへのコールを行うように構成されてよい。いくつかの場合では、アプリケーション２２０は、アプリケーションバイナリーインターフェイス２１８を通じてインターフェイスにアクセスする。以下に詳しく説明されるように、一つまたはそれ以上の生成された言語プロジェクションモジュール２２２からの手助けを伴うものである。
【００２７】
一つまたはそれ以上の実施例において、生成された言語プロジェクションモジュール２２２は、抽象型システム定義を所定のプログラミング言語に対してマップする。あらゆる好適なプログラミング言語がマップされ得るが、実施例は上記に提供されている。いくつかの実施例において、生成された言語プロジェクションモジュールは、それぞれのプログラミング言語に対して唯一つであり得る。他の実施例において、生成された言語プロジェクションモジュールは、多目的のものであり、複数のプログラミング言語によって利用され得る。マッピングにより、抽象型システムを使用して記述される現在及び将来のインターフェイスは、追加のプログラミングステートメント（つまり、ラッパー関数）なしで、所定のプログラミング言語にアクセスすることができる。マッピングにより、さらに、所定のプログラミング言語は、その所定のプログラミング言語のネイティブなやり方でインターフェイスをコールすることができる。クラス、データタイプ、ファンクションポインター、ストラクチャー、等といった、あらゆる好適な情報のタイプはマップされ得る。
【００２８】
プログラマーがオペレーティングシステムコンポーネントへのアクセスを望む実施例について検討する。アプリケーション２２０といった、アプリケーションを書くときに、プログラマーは、少なくとも一つの所定のプログラミング言語に関するエディター／コンパイラーでソースコードを生成する。エディター／コンパイラーは、オペレーティングシステムに関連する何のインターフェイス及び/又はＡＰＩが利用可能であるかに関する情報を取得するために、メタデータファイルにアクセスするように構成されてよい。例えば、いくつかの実施例において、プログラマーが、オペレーティングシステムコンポーネントの一部として実施されるクラスへのコールを含むコード行を書くと、エディター／コンパイラーは、そのクラスに関連するメタデータを問い合わせすることができ、何のメソッド、プロパティ、等がクラスに関連するかのリストをプログラマーに返す。リストは、あらゆる種類の情報を含むことができる。情報は、関連メソッド、及び/又は、クラスのプロパティ、等である。代替的又は追加的に、リストは、利用可能なクラスのリストを含んでいる。いくつかの実施例において、情報は、選択のためにユーザーに対するインターフェイスの適切なメソッド、プロパティ、等を視覚的に示すように構成されたオートコンプリーション（ａｕｔｏ−ｃｏｍｐｌｅｔｉｏｎ）機能の一部として提供され得る。メソッド及び/又はプロパティの選択に際して、コンパイラー／エディターは、より効率的で正確なソースコードの生成のために、ソースコードの中に対応する文法を挿入することができる。
【００２９】
いくつかの実施例において、プログラマーは、オペレーティングシステムコンポーネントのクラスオブジェクトをインスタンス化するように構成されたソースコードを書いてよい。ランタイムにおいてコールされた場合、オペレーティングシステムは、コーリングコードに返すために、クラスのインスタンスを動的に作成する。しかしながら、コードリングコードに返されたインスタンスは、「抽象的なオブジェクト（”ａｂｓｔｒａｃｔ  ｏｂｊｅｔ”）」であるか、以降に詳しく説明されるように、オペレーティングシステムコンポーネントに関連する抽象型システムにおいて記述されるオブジェクトであり得る。抽象オブジェクトタイプとコーリングコードに関するプログラミング言語の具体的なデータタイプとの間をブリッジするために、コンパイラーは、抽象オブジェクトを関連のプログラミング言語における類似のタイプに変換及び/又はマップするように構成され得る。生成された言語プロジェクションモジュール２２を通じてといったことである。いくつかの場合には、オペレーティングシステムコンポーネントの抽象オブジェクトと、プログラミング言語に関する具体的なオブジェクトとの間でコールをブリッジするためにプロキシー（ｐｒｏｘｙ）が使用され得る。
【００３０】
オペレーティングシステムコンポーネントクラスの振る舞いをエミュレートするように構成されたプロキシーを検討する。いくつかの場合には、プロキシーは、クラスの関連するタイプ、メソッド、プロパティ、イベント、等のスタブ（ｓｔｕｂ）を含むように作成され得る。プロキシーは、コーリングコードに係るプログラミング言語で構成され、従って、コーリングコードに対してネイティブなやり方でコーリングコードがプロキシーにアクセスすることができる。スタブは、これらのコールをオペレーティングシステムに対して（かつ、オペレーティングシステムから）変換及び/又はマップするための好適な知識及び/又はコードを含み得る。例えば、いくつかの実施例において、プロキシーはアプリケーションバイナリーインターフェイス２１８と通信することができる。
【００３１】
いくつかの実施例において、プログラミング言語は、上述のように、抽象型をプログラミング言語にネイティブなタイプにマップするためのラッパー関数及び/又はプロキシーを差し挟むことができる。プログラミング言語のエディター／コンパイラーは、以下のように構成され得る。すなわち、メタデータファイル２１２、２１４、および、２１６といった、メタデータを読み出し、何の抽象型が使用されているか判断し、抽象型を関連するプログラミング言語における一つまたはそれ以上の類似のタイプにマップし、かつ、関連のラッパー関数及び/又はプロキシーをオペレーティングシステムコンポーネントに関連する抽象型に知らせる。それぞれのタイプに対するマッピングがプログラミング言語と抽象型システムとの間に一旦存在すれば、抽象型システムによって定義されるあらゆる現行又は将来のインターフェイスは、プログラマーからの追加的なコーディングを必要としないで、プログラミング言語によって自動的にアクセスすることができる。
【００３２】
実施例として図３を検討する。図３は、本発明の一つまたはそれ以上の実施例に従った方法におけるステップを説明するフローチャートである。本方法は、あらゆる好適なハードウェア、ソフトウェア、または、それらの組み合わせによって実行され得る。少なくともいくつかの実施例において、本発明の態様は、エディター／コンパイラー１１４といった、コンピューターデバイス１０２上で稼働しているソフトウェアによって実行される。
【００３３】
ステップ３０２では、利用可能なオペレーティングシステムインターフェイスに関する情報に対するリクエストを受け取る。例えば、リクエストは、何のインターフェイスが利用可能であるか、及び/又は、利用可能なインストラクションに関する他の情報を要求するように構成されてよい。このことは、あらゆる好適なやり方で達成されてよい。いくつかの実施例において、リクエストは、ソースコードによって自動的に生成され得るが、そのソースコードは開発されているものである。コードエディターは、オペレーティングシステムインターフェイス及び/又はコンポーネントに対するコールを特定することができ、かつ、特定の際に、オペレーティングシステムインターフェイスに関して利用可能なメソッド、プロパティ、等を求めるリクエストを送付することができる。いくつかの実施例において、リクエストは、ドロップダウンメニュー、ラジオボタン、等の選択を介して手動で生成され得る。リクエストは、全ての利用可能なオペレーティングシステムインターフェイス、いくつかの利用可能なオペレーティングシステムインターフェイス、個々のオペレーティングシステムインターフェイス、または、それらのあらゆる組み合わせに関する情報を要求するように構成されてよい。いくつかの実施例において、リクエストは、図２のアプリケーション２２０といった、稼働しているアプリケーションを介して生成され得る。
【００３４】
ステップ３０４では、一つまたはそれ以上のオペレーティングシステムインターフェイスに関する情報を取得する。例えば、いくつかの実施例において、オペレーティングシステムは、情報を求めて問い合わせされ得る。代替的又は追加的に、情報は、一つまたはそれ以上のメタデータファイルの中に含まれてよく、そのメタデータファイルのクエリ（ｑｕｅｒｙ）及び/又は読み出しによって獲得され得る。上記及び下記に説明するように、メタデータファイルは、マシンで読取り可能なフォーマットであってよく、インターフェイスに伴うオブジェクト関係フォーメーションといった、階層的な情報を含んでいる。
【００３５】
ステップ３０６では、獲得した情報に応じて、一つまたはそれ以上のオペレーティングシステムインターフェイスに関する一つまたはそれ以上の抽象型を判断する。上述のように、いくつかの実施例において、オペレーティングシステムインターフェイスは、抽象型システムの使用を通じて、所定のプログラミング言語とは独立して記述され得る。一つまたはそれ以上のオペレーティングシステムインターフェイスに伴う一つまたはそれ以上の抽象型の判断に応じて、ステップ３０８では、一つまたはそれ以上の抽象型のそれぞれが、所定のプログラミング言語に関するタイプに対してマップされる。
【００３６】
ＯｐｅｎＰｉｃｋｅｒランタイムクラス（ｒｕｎｔｉｍｅ  ｃｌａｓｓ）に対するＡＢＩを記述しているインターフェイス記述言語に係る実施例を検討する。ＯｐｅｎＰｉｃｋｅｒランタイムクラスの中には、ＦｉｌｅＩｔｅｍオブジェクトの集合をリターンするように構成されたＰｉｃｋＭｕｌｔｉｐｌｅＩｔｅｍｓが含まれている。この所定の実施例においては、以下のように、ＦｉｌｅＩｔｅｍクラスは、Ｎａｍｅ値を有するＦｉｌｅＩｔｅｍＰｒｏｐｅｒｔｉｅｓをリターンするように構成されたＧｅｔＰｒｏｐｅｒｔｉｅｓメソッドを含んでいる。
runtimeclass  OpenPicker{
interface  IOpenPicker;
}
interface  IOpenPicker:IInspectable{
HRESULT  PickMultipleItems([out,retval]IVentor<IFileItem*>*folder);
}
interface  IFileItem:IInspectable{
HRESULT  GetProperties([out,retval]FileItemProperties**retVal);
}
interface  IFileItemProperties:IInspectable{
[propget]HRESULT  Name([out,retval]HSTRING*value);
}
【００３７】
いくつかの実施例において、Ｃ＃言語コンパイラーは、記述をＣ＃言語構造体にマップすることができる。記述を言語特定の構造体に対してマッピングすることにより、以下に示すように、オペレーティングシステムインターフェイスは、Ｃ＃プログラミング言語に対してネイティブなやり方でアクセスされ得る。
OpenPicker  picker=new  OpenPicker();
var  items=picker.PickMultipleItems();
foreach(FileItem  item  in  items){
Display(item.GetProperties().Name);
}
【００３８】
さらに別の実施例において、言語とは独立な方法で定義された構造は、ＪａｖａＳｃｒｉｐｔオブジェクトに対してマップされ得る。以下のように定義されるＦｒａｍｅＲａｔｅ構造の実施例を検討する。
typedef  struct  FrameRate{
UNIT32  Numerator;
UNIT32  Denominator;
}FrameRate;
【００３９】
ＦｒａｍｅＲａｔｅ構造は、２つのＵＮＩＴ３２フィールドを含んでいる。すなわち、ＮｕｍｅｒａｔｏｒとＤｅｎｏｍｉｎａｔｏｒである。ＦｒａｍｅＲａｔｅ構造は、言語とは独立した用語を使用して定義されているので、ＪａｖａＳｃｒｉｐｔを通じてアクセスされるといった、好適なマッピングを使用している場合に、本構造は、種々の言語特定のプログラミングによってアクセスされ得る。しかしながら、ＪａｖａＳｃｒｉｐｔは、フィールドを含む構造のコンセプト、または、符号なし（ｕｎｓｉｇｎｅｄ）３２ビット整数のコンセプトを含んでいない。代わりに、ＪａｖａＳｃｒｉｐｔは、プロパティを伴うオブジェクトのコンセプトとナンバー（Ｎｕｍｂｅｒ）のコンセプトを含んでいる。この実施例において、上記の構造定義は、Ｎｕｍｅｒａｔｏｒ及びＤｅｎｏｍｉｎａｔｏｒと名付けられた２つのプロパティを伴うオブジェクトであり得る。両方のＮｕｍｂｅｒタイプは以下のとおりである。
//JavaScript  use  of  the  above
var  framerate=videoType.Framerate;//Get  ａ  framerate  object
var  ratio=framerate.Numeraot/framerate.Denominator;
【００４０】
一つまたはそれ以上のプログラミング言語に対するオペレーティングシステムコンポーネントのプログラムでの公開を検討してきたので、これから、一つまたはそれ以上の実施例に従って、抽象型システムを伴うオブジェクト志向言語のモデリングについて検討する。
【００４１】
抽象型システムを用いたオブジェクト志向言語のモデリング
オペレーティングシステムインターフェイスが、所定のプログラミング言語を使用して定義されている場合、インターフェイスに関するパラメーターは、所定のプログラミング言語のデータタイプによって特徴付けられる。つまり、インターフェイスのコーラー（ｃａｌｌｅｒ）は、所定のプログラミング言語がどのようにデータタイプを定義しているかに準じている。インターフェイスとして所定のプログラミング言語で書かれたプログラムにとって、データタイプに準じることはありふれたことである。プログラムは、同一のデータタイプ定義を有しているからである。所定のプログラミング言語で書かれておらず、インターフェイスをコールするプログラムは、ときどき、データタイプに準じるための能力を減じてしまう。例えば、異なるプログラミング言語からインターフェイスをコールするプログラマーは、異なるプログラミング言語間、及び/又は、データタイプ間において、変換及び/又はブリッジを行うためのコードを追加してよい。結果として、データタイプ間をブリッジするプロセスは、しばしば、コールしているプログラミング言語のデータタイプに固有の機能性を減じてしまう。加えて、この変換は、ときどき、複雑であり、いくつかの場合においては、異なるプログラミング言語がオブジェクトが何であるかについて異なるコンセプトを有しているとすれば、現実性が無いものとなり得る。
【００４２】
種々の実施例は、オブジェクト志向のやり方で、抽象型システムを利用してオペレーティングシステムの一つまたはそれ以上のインターフェイスをモデル化するための能力を提供する。いくつかの実施例において、拡張ＩＤＬは、一つまたはそれ以上のインターフェイス間の関係を記述するための文法を含んでよい。代替的又は追加的に、拡張ＩＤＬは、どのようにインターフェイスが記述及び/又は定義され得るかを支配する規則を含み得る。いくつかの実施例において、バイナリーコントラクトは、抽象型システムに関する振る舞いを公開するように構成され、さらに、集められたデータタイプに伴う情報を含むように構成され得る。
【００４３】
オブジェクト志向モデルは、クラス階級制を使用してオブジェクトを記述する。ここで、クラスは、メソッド、プロパティ、インヘリタンス（ｉｎｈｅｒｉｔａｎｃｅ）等を含んでよい。典型的には、必ずしも必要でないが、オブジェクト志向クラスは一つまたはそれ以上のコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）を含んでいる。。コンストラクタは、クラス機能であり、コールされるとき、使用されるメモリーの中にクラスのインスタンス／オブジェクトを作成する。クラスのコンストラクタのいくつかは、作成されたインスタンス／オブジェクトの使用に備える追加のコードを含んでいる。例えば、追加のコードは、クラスのメンバー変数の初期化、クラスの関連するスタートアップルーチンの実行、等をすることができる。デフォルトのコンストラクタは入力パラメーターを有していないが、一方、デフォルトでないコンストラクタは一つまたはそれ以上の入力パラメーターを有している。
【００４４】
いくつかの実施例において、オペレーティングシステムコンポーネントの一つまたはそれ以上のコンストラクタは、所定の実施、及び/又は、デザインに従うように制約され得る。所定の実施に従うことによって、コンストラクタのコーラーは、そのコンストラクタ、及び/又は、結果とし生じるオブジェクトがどのように振る舞うかに依存し得る。例えば、オペレーティングシステムコンポーネントのデフォルトコンストラクタは、クラスファクトリーオブジェクトのＩＡｃｔｉｖａｔｉｏｎＦａｃｔｏｒｙインターフェイスに係るＡｃｔｉｖａｔｅＩｎｓｔａｎｃｅメソッドのデフォルトコンストラクタについて、制約及び/又はマップされ得る。クラスファクトリーオブジェクトは、作成されるオブジェクトの正確なクラスを規定することなく、オブジェクトを作成するようにモデル化されたデザインパターンである。クラスファクトリーモデルを使用することにより、デフォルトコンストラクタは、十分なレベルの抽象化を維持することができる。オペレーティングシステムコンポーネントのデフォルトでないコンストラクタは、また、クラスファクトリーの代替のインターフェイスといった、一つまたはそれ以上の特別に指定されたインターフェイス上に置かれるように制約され得る。
【００４５】
インターフェイスの記述を規定する一つのやり方は、ＩＤＬ及び/又はＸＭＬのような拡張記述言語といった、記述的な言語の使用を通じたものである。いくつかの実施例において、拡張記述言語は、オペレーティングシステムコンポーネントの一つまたはそれ以上のコンストラクタインターフェイスを記述及び/又は指定する能力を可能にするように構成されてよい。例えば、以下に説明するように、Ｃｏｍｐｒｅｓｓｏｒクラスを検討する。この実施例において、Ｃｏｍｐｒｅｓｓｏｒクラスは、クラスに関するデフォルトでないコンストラクタメソッドの少なくとも一つの定義を含むＩＣｏｍｐｒｅｓｓｏｒＦａｃｔｏｒｙインターフェイスを宣言する。
[version(NTDDI_WIN8),  activatable(ICompressorFactory,  NTDDI_WIN8)]
runtimeclass  Compressor  {
[default]  interface  ICompressor;  
}
[version(NTDDI_WrN8),  uuid(5F3D96A4-2CFB-442C-A8BA-D7Dl  lB039DA0)]  interface  ICompressorFactory  :  Ilnspectable  {
HRESULT  CreateCompressor([in]  Windows.  Foundation.IOutputStream*
UnderlyingStream,  [in]  CompressAlgorithm  Algorithm,  [out,  retval]  Compressor
**CreatedCompressor);
}
【００４６】
オブジェクト志向クラスは、少なくとも一つの静的メソッド、少なくとも一つの静的プロパティ、少なくとも一つの静的イベント、または、これらのあらゆる組み合わせを含むように構成されてよい。コンストラクタに係る定義の制約と同様に、静的メソッド、静的プロパティ、及び/又は、静的イベントは、一つまたはそれ以上の特に指定されたインターフェイスに従うようにデザインされ得る。静的メソッド、プロパティ、および、イベントを宣言するＣａｌｌＣｏｎｔｒｏｌクラスの実施例を検討する。この実施例において、静的メソッド、プロパティ、および、イベントは、ＣａｌｌＣｏｎｔｒｏｌＳｔａｔｉｃｓインターフェイスにおいて、以下のように定義される。
[version(NTDDI_WTN8),  uuid("03945AD5-85AB-40E1-AF19-56C94303B019"),  exclusiveto(CallControl)]
interface  ICallControlStatics:  Ilnspectable
{
HRESULT  GetDefault([out,  retval]  CallControl**callControl);
HRESULT  FromId([in]  HSTRTNG  devicelnterfaceld,  [out,  retval]  CallControl**callControl);
}
//Runtime  classes
[version(TDDI_WIN8),
static(ICallControlStatics,  NTDDI_WIN8)]
runtimeclass  CallControl  {
[default]  interface  ICallControl;
}
【００４７】
オブジェクト志向クラスは、少なくとも一つのインスタンスメソッド、少なくとも一つのインスタンスプロパティ、少なくとも一つのインスタンスイベント、または、これらのあらゆる組み合わせを含むように構成されてよい。インスタンスメンバー（メソッド、プロパティ、および、イベント）は、クラスの所定のインスタンス上で動作し、一方、静的なメンバーはクラスの全てのメンバーによって共有される。クラスは、一つまたはそれ以上の特に指定されたインターフェイスに従うようにデザインされ得る。関連するインスタンスメソッド、プロパティ、および、イベントがＩＣａｌｌＣｏｎｔｒｏｌインターフェイスにおいて定義されることをＣａｌｌＣｏｎｔｒｏｌクラスが宣言する上記の実施例といったインターフェイスである。いくつかの実施例において、一つまたはそれ以上のオペレーティングシステムコンポーネントは、クラスファクトリーデザインパターンの後／上にこれらのインターフェイスをモデル化／実施することができる。
【００４８】
所定のプログラミング言語が、言語固有のコンストラクタ、静的又はインスタンスメンバー、言語プロジェクションモジュール、図２に係る生成された言語プロジェクションモジュールといったもの、をコールするかどうかは、プログラミング言語固有のコールを好適なクラスファクトリーオブジェクト又はインスタンスに関する好適なメソッド及び/又はインターフェイスに対してマップすることができる。いくつかの実施例において、クラスファクトリーオブジェクトは、オペレーティングシステムコンポーネント及び/又はランタイムクラスと関連している。例えば、ランタイムクラスのインスタンスを作成するようにコンパイラーに指示しているコードのメソッド署名を、クラスファクトリーオブジェクトの好適なコンストラクタインターフェイスメソッドに調和させることができる。さらに別の実施例において、言語プロジェクションモジュールは、静的メソッドをコールするようにコンパイラーに指示している言語固有のメソッド署名を、オペレーティングシステムコンポーネントに関連する静的インターフェイス上の好適な整合インターフェイスメソッドに調和させるように構成され得る。さらに別の実施例において、、言語プロジェクションモジュールは、インスタンスメソッドをコールするようにコンパイラーに指示している言語固有のメソッド署名を、オペレーティングシステムコンポーネントの所定のインスタンスに関連するインターフェイス上の好適な整合インターフェイスメソッドに調和させるように構成され得る。
【００４９】
いくつかの実施例において、ＩＤＬコンパイラーは、少なくとも一つのオペレーティングシステムコンポーネントインターフェイス記述に関連する一つまた生成するように構成され得る。あらゆる好適な情報のタイプが拡張ＩＤＬファイルの中に含まれてよい。タイプ、メソッド、プロパティ、イベント、および、関連のオペレーティングシステムコンポーネントのインターフェイスを記述している情報といったものである。いくつかの場合には、コンパイラーは、マシンで読取り可能なメタデータファイルを生成することができる。一つまたはそれ以上のアプリケーションは、何のインターフェイスが利用可能であるかをプログラムで判断するための関連のマシンで読取り可能なファイル、インターフェイスに係る関連の記述及び/又は宣言、インターフェイスに係るパラメーターのデータタイプ、等を読み出すように構成され得る。一つまたはそれ以上のアプリケーションは、あらゆる好適なプログラミング言語で書かれてよく、実施例が上記に提供されている。
【００５０】
いくつかの実施例において、ＩＤＬコンパイラーは、タイプ、メソッド、プロパティ、イベント、及び/又は、インターフェイスに関連する一つまたはそれ以上のコミュニケーションプロキシー及び/又はコードスタブを生成することができる。コミュニケーションプロキシー及び/又はコードスタブは、オペレーティングシステムコンポーネントによるアクセスのために追加的に構成され得る。
【００５１】
図４について検討する。図４は、本発明の一つまたはそれ以上の実施例に従って、拡張ＩＤＬファイル４０２、コンパイラー４０４、および、メタデータファイル４０６との間の関係を示している。ここで、拡張ＩＤＬファイル４０２は、メタデータファイル４０６を生成するために、コンパイラー４０４０によって受け取られ、処理される。少なくともいくつかの実施例において、関係図に示されたモジュールは、コンピューターデバイス１０２上で動作する、ソフトウェア、ハードウェア、または、エディター／コンパイラーモジュール１１４といった、これらのあらゆる組み合わせとして実施例され得る。
【００５２】
図示され説明される実施例において、拡張ＩＤＬファイル４０２は、オペレーティングシステムＡＰＩといった、一つまたはそれ以上のオペレーティングシステムコンポーネントインターフェイスを定義する一つまたはそれ以上のファイルを含んでよい。オペレーティングシステムコンポーネントのあらゆる好適なタイプが記述され得る。ファイルオブジェクト／クラス、ストリングオブジェクト／クラス、グラフィックオブジェクト／クラス、カルチャーオブジェクト／クラス、等といったものである。それぞれのオブジェクトは、オブジェクト志向クラスに関連付けされ得るメソッド、プロパティ、インヘリタンス情報、等を含んでよい。拡張ＩＤＬは、一つまたはそれ以上のインターフェイス間の関係に係るこれらのタイプが記述できるようにする文法を含み得る。
【００５３】
いくつかの実施例において、抽象型システムは、種々のデータタイプをサポート及び/又は記述するように構成され得る。例えば、メソッドインターフェイスは、全てのインターフェイスがオブジェクトのインスタンス上で動作するという物理的な要求をマップするように定義され得る。別の実施例において、抽象型システムは、プログラミング言語とコンポーネント境界をまたいでコールされ得るようにファンクションポインターを定義するために使用されてよい。第１のコンポーネントは、ファンクションポインター、または、デリゲート（ｄｅｌｅｇａｔｅ）から生じてよく、メソッドに結び付けられている。デリゲートは、次に、バイナリーコンピレーション（ｃｏｍｐｉｌａｔｉｏｎ）境界をまたいで任意のプログラミング言語で書かれた第２のコンポーネントに対してパス（ｐａｓｓ）され、実施される。種々の実施例によって、拡張ＩＤＬは、これらのデータタイプを定義及び/又は記述することができ、データタイプを集合体の型の中へ混ぜ合わせるのと同様に、基本的なデータタイプを構成するための規則を定義することができる。
【００５４】
図示され説明される実施例において、コンパイラー４０４は、拡張ＩＤＬファイル４０２といった、一つまたはそれ以上の入力ファイルを受け容れ、一つまたはそれ以上のメタデータファイル４０６を生成する。メタデータファイル４０６は、自動アクセスのための構成されてよい。例えば、メタデータファイルは、マシンで読取り可能なフォーマットで保管され得る。いくつかの実施例において、メタデータファイル４０６は、一つまたはそれ以上のオペレーティングシステムコンポーネントと関連している。代替的又は追加的に、コンパイラー４０４は、上述のように、スタブアウト（ｓｔｕｂｂｅｄ  ｏｕｔ）コミュニケーションプロキシーを生成することができる。
【００５５】
アプリケーション４０８は、何のＡＰＩが利用可能であるかを動的に判断することができる。メタデータファイル４０６の読み出しを通じて、といったものである。いくつかの実施例において、アプリケーション４０８は、図１に係るエディター／コンパイラーとして構成され得る。メタデータファイル４０６を通じて、アプリケーションは、機能性について以降のバージョンが存在するかどうか、どんなパラメーターをＡＰＩが取るか、を判断し、同様に、ランタイムにおいてＡＰＩの何の機能性が存在するかをユーザーに知らせることができる。従って、抽象型システムを用いてＡＰＩを記述することと同様に、ＡＰＩの記述をマシンで読取り可能なフォーマットに含めることによって、抽象型システムと所定のプログラミング言語との間のマッピングをサポートするアプリケーション及び/又は言語は、プログラマーからの少ない労力でＡＰＩに容易にアクセスできる。
【００５６】
抽象型システムを用いたオブジェクト志向言語のモデル化について検討してきたので、これから、一つまたはそれ以上の実施例に従ったシステム例について検討する。
【００５７】
システム例
図５は、上述の種々の実施例を実行するために利用され得るコンピューターデバイス５００を例示している。コンピューターデバイス５００は、例えば、図１に係るコンピューターデバイス、または、あらゆる他の好適なコンピューターデバイスであってよい。
【００５８】
コンピューターデバイス５００は、一つまたはそれ以上のプロセッサ又は処理ユニット５０２、一つまたはそれ以上のメモリー及び/又はストレージコンポーネント５０４、一つまたはそれ以上の入力／出力（Ｉ／Ｏ）デバイス５０６、および、種々のコンポーネントとデバイスがお互いにコミュニケーションできるようにするバス５０８、を含んでいる。バス５０８は、バス構成のいくつかのタイプに係るあらゆる一つまたはそれ以上のものを表しており、メモリーバス又はメモリーコントローラー、ペリフェラルバス、加速グラフィックポート、および、あらゆる種類のバスアーキテクチャーを使用しているプロセッサ又はローカルバス、を含んでいる。バス５０８は、有線及び/又は無線バスを含んでよい。
【００５９】
メモリー／ストレージコンポーネント５０４は、一つまたはそれ以上のコンピューターストレージ媒体を表している。コンポーネント５０４は、揮発性媒体（ランダムアクセスメモリー（ＲＡＭ）といったもの）、及び/又は、不揮発性媒体（読み出し専用メモリー（ＲＯＭ）、フラッシュメモリー、光ディスク、磁気ディスク、等といったもの）を含み得る。コンポーネント５０４は、固定媒体（例えば、ＲＡＭ、ＲＯＭ、固定ハードドライブ、等）を、リムーバブル媒体（例えば、フラッシュメモリードライブ、リムーバブルハードドライブ、光ディスク、等）と同様に含んでよい。
【００６０】
一つまたはそれ以上の入力／出力デバイス５０６により、ユーザーは、コンピューターデバイス５００に対してコマンド及び情報を入力することができ、また、情報をユーザー及び/又は他のコンポーネントまたはデバイスに対して示すことができる。入力デバイスの実施例は、キーボード、カーソルコントロールデバイス（例えば、マウス）、マイクロフォン、スキャナー、等を含んでいる。出力デバイスの実施例は、ディスプレイ装置（例えば、モニター又はプロジェクター）、スピーカー、プリンター、ネットワークカード、等を含んでいる。
【００６１】
種々の技術が、ソフトウェアまたはプログラムモジュールの一般的な内容で、ここにおいて説明された。一般的に、ソフトウェアは、ルーチン、プログラム、アプリケーション、オブジェクト、コンポーネント、データ構造、などといった所定のタスクを実行するもの、または所定の抽象的なデータタイプを実行するものを含む。これらのモジュールおよび技術の実施は、コンピューターで読み取り可能な媒体のいくつかの形式で保管され、または媒体にわたり伝送される。コンピューターで読み取り可能な媒体は、コンピューティングデバイスによってアクセスすることができる、あらゆる利用可能な媒体またはメディアであってよい。実施例として、かつ、限定するものではなく、コンピューターで読み取り可能な媒体は、「コンピューターで読取り可能なストレージ媒体（“ｃｏｍｐｕｔｅｒ−ｒｅａｄａｂｌｅ  ｓｔｏｒｇａｅ  ｍｅｄｉａ”）」を含み得る。
【００６２】
「コンピューターで読取り可能なストレージ媒体」は、コンピューターで読み取り可能なインストラクション、データ構造、プログラムモジュール、または、他のデータといった情報を保管するためのあらゆる方法または従来技術において実施される、揮発性および不揮発性媒体、取出し可能および取出し不能媒体を含む。コンピューターで読取り可能なストレージ媒体は、これらに限定されるわけではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリー、または他のメモリー技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）、磁気カセット、磁気テープ、磁気ディスクストレージまたは磁気ストレージデバイス、または、所望の情報を保管するために使用でき、コンピューターによってアクセスされ得る他のあらゆる媒体、を含んでいる。
【００６３】
結論
種々の実施例が、プログラミング言語とは独立して、オペレーティングシステムに関連する一つまたはそれ以上のインターフェイスを記述するための能力を提供する。代替的又は追加的に、所定のプログラミング言語に関連するコンパイラーは、独立したインターフェイス記述をプログラミング言語に特有な好適なコンストラクトに対してマップするように構成され得る。いくつかの実施例において、アプリケーションは、オペレーティングシステムの一つまたはそれ以上のインターフェイスをプログラムで判断するように構成され得る。
【００６４】
技術的事項が構造的特徴及び／又は方法論的アクトに特有の言葉で説明されてきたが、添付の特許請求の範囲において定められる技術的事項は、上述された特定の特徴またはアクトに必ずしも限定される必要はないことが理解されるべきである。むしろ、上述の特定の特徴およびアクトは、請求項に係る発明の実施例として開示されたものである。
【図１】
0005933002.tif 000002
【図２】
0005933002.tif 000003
【図３】
0005933002.tif 000004
【図４】
0005933002.tif 000005
【図５】
0005933002.tif 000006