(57)【要約】      （修正有）【課題】アプリケーション・プログラム・インタフェース（ＡＰＩ）モジュールの開発反復における同期化を容易にする。【解決手段】ソフトウエア開発用のユーティリティー・プログラム３３０は、エミュレートされたプラットフォームにおけるアプリケーション・プログラム・インターフェースのための同期化された翻訳モジュール３４０を生成する。このユーティリティーは、一般化された機能コード、特別な目的コードを有する例外テンプレート３５２、及びエミュレートされたプラットフォームからデータタイプを変換するタイプ・テンプレート３５３を有する反復機能テンプレート３５１から翻訳モジュール３４０を作成する。【選択図】図３
2005100437.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォームされたデジタル・コンピュータにおいて、上記デジタル・コンピュータは確認手段（３３０）、選定手段（３３０）、テンプレートを記憶した記憶手段および情報処理手段を有し、
インターフェース・モジュール(２５１、２５２)を上記確認手段により確認するステップ（４１０）、
上記インターフェース・モジュールを表すソース・コード・ファイルを上記選定手段により選定するステップ(４０３)、
上記インターフェース・モジュールの機能を実行する第２プラットフォームにおいて実行可能なコードを含み、上記選択手段により選択されたソース・コード・ファイルに対応する翻訳モジュール（２６０、３４０）を上記情報処理手段により生成するステップ（４２０−４５１）、及び多くのインターフェース及び翻訳モジュールに対し、上記ステップを繰り返すステップを含む方法であって、上記翻訳モジュールを生成するステップは、
上記インターフェース・モジュールから、上記インターフェース・モジュールによって実行される１つ以上の機能を表すデータを抽出するステップ（４３０）、
上記インターフェース・モジュール機能を、少なくとも１部が上記第２プラットフォーム用に書込まれた一般化されたプログラム・コードを含む、上記記憶手段に記憶されたテンプレートのグループ（３５０）に照合するとともに、上記グループから、少なくとも１つの適合するテンプレート（３５１）を選定するステップ（４３０）、及び
上記選定されたテンプレートに関し、上記テンプレートにおける上記一般化されたプログラム・コードを、上記翻訳モジュールにおける上記インターフェース・モジュールの機能を実行する専用化されたプログラム・コードに変換するステップ（４３１）を含み、
上記翻訳はＡＰＩ呼び出しの変換であることを特徴とする方法。
【請求項２】
上記インターフェース・モジュールは、異なるタイプのグループの少なくとも１つを有するパラメータを受渡すとともに、
上記１つ又は複数のパラメータは、異なるタイプのテンプレートのグループ（３５３）の少なくとも１つに適合し、且つ
上記翻訳モジュールのコードの１部は、上記適合するタイプのテンプレートから作成されることを特徴とする請求項１に記載の方法。
【請求項３】
上記記憶手段は例外テンプレートをも記憶しており、上記翻訳モジュールを生成するステップは、
特定のインターフェース・モジュールを認識するステップ、及び
上記記憶手段に記憶された例外テンプレートを、上記選定されたテンプレートの代わりとするステップを更に含むことを特徴とする請求項１に記載の方法。
【請求項４】
上記特定のインターフェース・モジュールは、前記記憶手段に記憶された例外リストを前記情報処理手段により読取ることによって認識されることを特徴とする請求項２に記載の方法。
【請求項５】
上記デジタル・コンピュータは決定手段および組み込み手段をさらに有し、上記テンプレート（３５１）の１つは、コード・テンプレート（３５４）のグループの１つの名前を特定することを上記決定手段により決定するステップ、及び
上記１つのテンプレートが、翻訳モジュール用のコードを備える場合は、常に、上記１つのテンプレートに、上記特定されたコード・テンプレートからのソース・コードを上記組み込み手段により組込むステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
コンピュータシステムにおいて、第１のプラットフォームにおいて実行されるインターフェース・モジュールのセット（２５１、２５２）を、上記インターフェース・モジュールの機能の１つに対応して実行する、但し、第２プラットフォームにおいて実行する翻訳モジュールのセット（２６０、３４０）に変換するためのテンプレートのセット（３５０）を有するとともに、上記インターフェース・モジュールは、上記インターフェース・モジュールによってエクスポートされた機能の名前を含む、関連付けられたヘッダ・ファイル（３１４）を有し、上記コンピュータシステムは、上記テンプレートを記憶した記憶手段およびジェネレータ手段（３３０）とを有し、
上記テンプレートは、第２プラットフォームにおいて機能を実行するための一般化されたコードを含み、更に
上記ジェネレータ手段は、上記ヘッダ・ファイルにエクスポートされた機能の名前に従って、特定の上記インターフェースのファイルを、少なくとも１つの上記テンプレートに照合し、適合した１つ又は複数の、上記記憶手段に記憶されたテンプレートを拡張し、上記第２プラットフォームにおいて上記インターフェース・モジュールの機能を実行するための翻訳モジュールにソース・コードを作成し、上記翻訳はＡＰＩ呼び出しの変換であり、
上記ジェネレータ手段は、あるファイルが、例外ファイルとして認識された際は，上記特定のインターフェース・ファイルの照合を迂回するようにしたことを特徴とするシステム。
【請求項７】
上記システムは、選定手段および拡張手段を有し、上記記憶手段には例外テンプレートが記憶されており、該選定手段により上記特定のインターフェース・ファイルに対する例外テンプレートを選定し、上記拡張手段により上記例外テンプレートを、上記第２プラットフォームに対するコードに拡張するようにしたことを特徴とする請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子データ処理に係り、より具体的には、あるプラットフォーム用に書込まれたアプリケーション・プログラムを、異なるプラットフォームでも実行できるようにするエミュレータとともに使用され、アプリケーション・プログラム・インターフェース（ＡＰＬｓ）を、あるプラットフォームから他のプラットフォームに翻訳する翻訳コード・モジュールのセットを生成するためのソフトウェアツールに関する。
【背景技術】
【０００２】
今日、アプリケーション・プログラムは、それらが実行されるコンピュータシステムのハードウェアに対し、直接的にインターフェースされることはほとんどない。その代わり、アプリケーション・プログラム・インターフェース（ＡＰＩｓ）が、ハードウェアを制御するコード・モジュール、又はまだ下位層に置かれたプログラムされたインターフェースを呼出す。大半のＡＰＩコード・モジュールは、オペレーティング・システム（ＯＳ）内に在り、その他のものは、基本入出力システム（ＢＩＯＳ）、或いは他の場所に存在する。ＡＰＩ機能を果たすコード・モジュールは、通常、数十、数百に近いＡＰＩ機能を実行するためのルーチンを各々含む自立構造をした複数のダイナミック・・ライブラリ（ＤＬＬ）ファイル内に存在する。
【０００３】
あるコンピュータの中央演算処理装置用に書込まれたアプリケーション・プログラムを実行するには、オペレーティング・システム、つまり、もう１つのプラットフォームである他のプラットフォームは、エミュレータ、シミュレータ、インタープリタ、又はトランスレータのような、色々知られているプログラムを必要とし、このプログラムによって、命令、データ・フォーマット、アプリケーション・プログラム・インターフェース（ＡＰＩｓ）、及びアプリケーションの他の特性を、その原プラットフォームのものから、該エミュレータが実行される固有プラットフォームの特性に変換する。原プラットフォームが交換される時にも、元から在るアプリケーションは、新しいプラットフォームにおいても実行され続けなくてはならない。プログラムが、抽象的なプラットフォームに書込まれている場合には、この抽象的なプラットフォームを扱う各々の固有プラットフォームにエミュレータを書込むたけで、同じアプリケーションを多くの異なるプラットフォームにおいて実行させることが可能である。
【０００４】
エミュレータのサブシステムは、一般的に、２つの構成要素を有する。エミュレータ自身は、そのアプリケーションからの原中央演算処理装置への命令を、新しいプラットフォームの中央演算処理装置に相応しい複数の又は複数グループの命令に変換する。ＡＰＩ翻訳層は、固有プラットフォーム用に書込まれたＡＰＩｓに対する呼出しにエミュートされている原プラットフォームからのＡＰＩ呼出しを「サンク（ｔｈｕｎｋ）」する。つまり、ＡＰＩ翻訳層は、エミュレートされたプラットフォーム用に書込まれたアプリケーションによって作られたＡＰＩ呼出しを遮り、それらの引数を、原プラットフォームの呼出し変換から、固有プラットフォームの呼出し変換へと変換することによって、ＡＰＩ機能を実行するに相応しい固有プラットフォーム・モジュールを呼出す。
【０００５】
従来の手法では、新しいＡＰＩ及び修正されたＡＰＩ用の手書きサンク・コードが使用されている。しかし、ＡＰＩセットは、オペレーティング・システムの進歩とともに、日々変化する可能性がある。また、ＡＰＩの数も、非常に多くなる可能性がある。例えば、マイクロソフト・ウインドウズＮＴのオペレーティング・システムは、４２の異なるＤＬＬモジュールにおいて３５００を越すＡＰＩを含んでいる。従って、手作業による個々のＡＰＩ翻訳コードの作成は、益々非現実的なものとなっている。益々短くなる商品サイクルは、この問題を倍化している。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
いくらかのインターフェース・モジュール、つまりサンクは、個々のＡＰＩの各々に対し手書きによる記述によって生成されてきた。しかし、これらは、複数のＡＰＩ自身から分離した状態に維持されなくてはならず、コスト的に余分な努力が必要とされる。また、インターフェース・モジュールは、「同期化」の問題に苦しんでおり、１つ以上のモジュールが、ある開発反復から次のものへの更新を、うっかりして忘れた場合には、それらのダウン層コードは、ＡＰＩを翻訳し損なう可能性があり、つまりシステムを破壊してしまう可能性がある。このような問題は散見され、これによって開発全体の遅れを余儀なくされている。
【０００７】
もう１つの方法としては、ソフトウェアツールを、Ｃ言語ソース・ファイルとしてスケルトンＡＰＩサンクのセットを作るために使用し、後にこれを手作業で修正するようにしてきた。この手法は、このツールが全ての手作業による編集の破壊を繰り返しているという点から、実用的なものとは言えない。
Yi−hsiu Wei 他の「多相RPCシステム用スタブ・ジェネレータ」Journal of Parallel and Distributed Computing, Vol. 11, No.3 (1991年3月1日), 188-197頁には、２つの異なるプラットフォーム間の遠隔手続呼出し用のデータ変換スタブを構成するために、異なる目的にテンプレートを使用することを教示している。
【課題を解決するための手段】
【０００８】
本発明によるユーティリティー・プログラムは、あるプラットフォーム用に書込まれたＡＰＩｓを翻訳するためのコード・モジュールを作成し、それを自動的に更新するので、このプログラムは、異なるプラットフォームにおいて適切に実行されることになる。このユーティリティーは、ＡＰＩｓによって遂行される機能に基づき、オペレーティング・システム又は他のソフトウエア環境の新開発反復に対し実行され、翻訳モジュール用ソース・コードを作成するためにテンプレートのセットを使用する。特殊な翻訳要件は、専用の翻訳コードを含む例外テンプレートによって処理される。他の種類のテンプレートは、原ＡＰＩｓのパラメータ又は引数から、異なるプラットフォームのそれらへの、タイプの変換を遂行する。
【発明の効果】
【０００９】
この方法における自動的なコード生成は、翻訳モジュールが、新オペレーティング・システム又は環境の対してなされた変更と同期化するようにした自動化された方法を提供することによって、開発反復を一段と迅速化することができる。コード・ジェネレータは、全翻訳モジュールが、最新の更新レベルにあることを確実にし、相性の悪いモジュールによって引起されるシステム破壊を防止する。また、それは、先行して行われる手作業による生成方法に起因する個々のコード・モジュール内のエラーも飛躍的に低減し、更に、違う人間が異なるモジュールを別々に作成することから起こるモジュール間のエラーをも排除する。
他の特徴、利点、及び本発明の範囲に属する変更、付加については、以下の記載により当業者に対し明らかにされる。
【発明を実施するための最良の形態】
【００１０】
図１により、本発明を実施するに相応しいコンピュータの環境に関する簡単な全体的説明を行う。ハードウェア及びソフトウエア環境が、最初に述べられ、その後に、あるプラットフォーム用に書込まれたＡＰＩｓを翻訳するためのコード・モジュールを作成し、更に、それを自動的に更新することによって、それらが異なるプラットフォーム上で適切に実行されるようにするツールを備える本発明の詳細な説明を行う。以下、本発明は、パーソナル・コンピュータ（ＰＣ）によって実行される、プログラム・モジュールのようなコンピュータ実行命令の一般的文脈において説明されるが、他の環境とすることも可能である。プログラム・モジュールは、特定のタスクを遂行する、つまり特定の抽象データのタイプを作成する、ルーチン、プログラム、目的、構成要素、データの各構造等を含む。本発明が、手持型の装置、多重プロセッサ、マイクロプロセッサをベースとしたプログラム可能な大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ等を含む他のコンピュータシステムの機器構成によって実践できることは、当業者に十分理解されるであろう。また、本発明は、分散されたコンピュータ環境においても実践でき、そこにおいて、タスクは、通信ネットワークを通じて連結された遠隔中央演算処理装置により遂行される。分散されたコンピュータ環境において、プログラム・モジュールは、局所及び遠隔の両方のメモリ記憶装置内に設けることができる。
【００１１】
図１は、本発明を実施するための例示的システムを示す。それは、処理ユニット２１、システムメモリ２２、及びシステムメモリ及び他のシステム構成部品を処理ユニットに連結するシステムバス２３を備えた、既存のパーソナル・コンピュータ２０の形態での汎用コンピュータ装置を使用している。システムバス２３は、メモリバス又はメモリコントローラ、周辺バス、及び局所バスを含む様々なタイプの内の何れでも良く、様々なバス構造の何れでも使用できる。システムメモリ２２は、読取り専用メモリ（ＲＯＭ）２４及びランダムアクセス・メモリ（ＲＡＭ）２５を備えている。ＲＯＭ２４に記憶された基本入出力システム（ＢＩＯＳ）２６は、パーソナル・コンピュータの構成部品間で情報を伝送する基本ルーチンを含んでいる。また、ＢＩＯＳ２４は、システムの起動ルーチンを含んでいる。パーソナル・コンピュータ２０は、更に、ハードディスク（図示せず）からの読出し、またそこへの書込みを行うハードディスク・ドライブ２７、取外し可能な磁気ディスク２９からの読出し、またそこへの書込みを行う磁気ディスク・ドライブ２８、及びＣＤ−ＲＯＭ又は他の光媒体のような取外し可能な光ディスク３１からの読出し、またそこへの書込みを行う光ディスク・ドライブ３０を備えている。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８、及び光ディスク・ドライブ３０は、各々、ハードディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３、及び光ディスク・ドライブ・インターフェース３４によって、システムバス２３に接続される。これらドライブ及びそれらの関連するコンピュータ読出し可能媒体は、パーソナル・コンピュータ２０用の、コンピュータ読出し命令、データ構造、プログラム・モジュール、及び他のデータの不揮発性記憶装置を備えている。
ここで説明される例示的環境は、ハードディスク、取外し可能な磁気ディスク２９、及び取外し可能な光ディスク３１を使用しているが、コンピュータによりアクセス可能なデータを記憶できる他タイプのコンピュータ読出し可能媒体が、この例示的オペレーティング環境において同様に使用できることは、当業者に十分理解されるであろう。このような媒体としては、磁気カセット、フラッシュメモリカード、デジタル多目的ディスク、ベルヌーイ・カートリッジ、ＰＡＭｓ、ＰＯＭｓ等を含むことができる。
【００１２】
プログラム・モジュールは、該ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、及びＲＡＭ２５に記憶されることができる。プログラム・モジュールは、オペレーティング・システム３５、１つ以上のアプリケーション・プログラム３６、他のプログラム・モジュール３７、及びプログラムデータ３８を含んでいる。使用者は、キーボード４０や指示装置４２のような入力装置を介して、コマンド及び情報をパーソナル・コンピュータ２０に入力できる。その他の入力装置（図示せず）としては、マイクロフォン、ジョイステック、ゲームパッド、パラボラアンテナ、走査器等を含むことができる。これら及びその他の入力装置は、しばしば、システムバス２３に連結されたシリアルポート・インターフェース４６を介して、処理ユニット２１に接続されるが、それらは、パラレルポート、ゲームポート、又はユニバーサル・シリアルポート（ＵＳＰ）のような、図１に示されていない他のインターフェースを介して接続されることが可能である。また、モニタ４７又は他の表示装置を、ビデオアダプタ４８のようなインターフェースを介して、システムバス２３に接続される。この表示装置に加え、パーソナル・コンピュータは、通常、スピーカやプリンタのような他の周辺出力装置（図示せず）を備える。
【００１３】
パーソナル・コンピュータ２０は、遠隔コンピュータのような１つ以上の遠隔コンピュータへの論理的接続を使用したネットワーク化環境において使用することができる。遠隔コンピュータ４９は、もう１つのパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア（ｐｅｅｒ）装置、又は他の一般的ネットワーク・ノードとすることができる。図１には記憶装置５０のみが示されているが、この遠隔コンピュータは、通常、パーソナル・コンピュータ２０に関する上記した構成部品の多く又は全てを備えている。図１に書かれた論理的接続は、ローカル・エリア・ネットワーク（ＬＡＮ）５１及び広域ネットワーク（ＷＡＮ）５２を含んでいる。このようなネットワーク環境は、事務所、企業の広範囲なコンピュータ・ネットワーク、イントラネット、インターネットにおいて一般的なものである。
【００１４】
ＬＡＮネットワーク環境に設置する場合、ＰＣ２０は、ネットワーク・インターフェース又はアダプタ５３を介してローカル・ネットワーク５１に接続される。インターネットのようなＷＡＮネットワーク環境において使用する場合、ＰＣ２０は、通常、ネットワーク５２を通じての通信を確立するためのモデム５４又は他の手段を備えている。モデム５４は、ＰＣ２０に内蔵又は外付けすることができ、シリアルポートを介して、システムバス２３に接続される。ネットワーク環境において、２０又はその１部内に存在するように書かれたプログラム・モジュールは、遠隔記憶装置５０内に記憶することができる。当然の事であるが、示されたネットワーク接続は、例示的なものであり、コンピュータ間の通信リンクを確立する他の手段と置換えることが可能である。
【００１５】
あるプラットフォーム用のアプリケーション・プログラム２１０を、異なるプラットフォームを意味する中央演算処理装置２２０において実行するためのソフトウエア環境を示す。破線２０１に囲まれた要素は、図１の中央演算処理装置２１のような、Ｉｎｔｅｌ社の「Ｘ８６」系、例えばＩｎｔｅｌ  ８０３８６、８０４８６、又はペンティアム  マイクロプロセッサで構成した第１プラットフォームにおいて実行されるよう設計された要素である。他の要素は、中央演算処理装置２１として使用されるＤｉｇｉｔａｌ  Ｅｑｕｉｐｍｅｎｔ社の「Ａｌｐｈａ」又はＩＢＭ社の「Ｐｏｗｅｒ  ＰＣ」マイクロプロセッサのような第２プラットフォームにおいて実行される。この説明においては、第１及び第２プラットフォームを、それぞれ、「Ｘ８６」及び「固有プラットフォーム」と呼ぶ。
例示目的のため、Ｍｉｃｒｏｓｏｆｔ  ＮＴオペレーティング・システムの固有プラットフォーム２３０版が、Ｆｉｇ．１のＯＳ  ３５として使用される。
【００１６】
既存のエミュレータ・プログラム２４０は、図１及び２の３６のようなＸ８６プラットフォーム・アプリケーション・プログラムに関する、命令、データ、及びインターフェース（ＡＰＩｓ）を、Ｘ８６プラットフォームのこれらから、固有プラットフォームにおける等価のオペレーションに翻訳する。アプリケーション・プログラムのＡＰＩｓは、実際のところ、図２にほんの１部が示された、ＡＰＩモジュール２５１−２５３のセット２５０に対する呼出しである。ＡＰＩモジュールは、普通、２５４のようなダイナミック・リンク・ライブラリにグループ化されている。先に述べたように、ＯＳ２３０は、ＤＬＬの４０という数よりも多い数百のＡＰＩｓを持っており、集合的には「Ｗｉｎ３２」として知られているこのセットは、開発作業過程でほとんど毎日、新しい「構成（ｂｕｉｌｄ）」に再編成される。アプリケーション２１０が、ＡＰＩ２５１のような、Ｘ８６プラットフォーム用に書込まれたＡＰＩを呼出す場合、エミュレータ２４０内の既存のＡＰＩ翻訳層２４１は、適切なＡＰＩモジュール２５１を検索し、関連する翻訳コード・モジュール、つまり「サンク」２６１を呼出し、どのようなＡＰＩ配列及びデータでも、固有プラットフォームに対し正しいフォーマットに変換するとともに、ＡＰＩが原Ｘ８６プラットフォームにおいて実行していたものをエミュレートする機能を果す。サンク２６０のセットは、Ｘ８６のＡＰＩ２５１−２５２の各々に対する個別のモジュール２６１−２６２を含んでいる。固有プラットフォーム用に書込まれた２５３のようなＡＰＩｓは、ＯＳ２３０から呼出され、サンクを必要としない場合には、直接的に実行される。
【００１７】
図３は、本発明による翻訳ユーティリティーを、その入出力とともに示した、上位層のブロック図３００である。図２に示された要素のいくらかは、コンパイルされたオブジェクト・コードの形式においては図２のものと一致する要素であるが、図３においてはソース・コードとして存在していることを示すため、図３とは異なる番号を付している。
【００１８】
そのソース・コード形式において、図２の各ＤＬＬ２５４は、図２におけるＡＰＩ２５０用のＣのような言語で書かれた命令を各々含むファイル３１１の集合３１０である。各ファイルは、１つ以上の機能３１２を表現し、ＡＰＩｓ２５１−２５２の内の１つによって実行される。［＠＠  Ｉｎｖｅｎｔｏｒ  ｎｏｔｅ  １］（ある専門用語：ダイナミック・リンク・ライブラリは、３つのソース・ファイル、つまり、Ｃソース・ファイル、Ｃヘッダ・ファイル、及びＤＥＦファイル、から生成される。コンパイラは、これらを、ＤＬＬコード・ファイル及びインポート．ＬＩＢファイルの２つのオブジェクト・ファイルに変換する。）
【００１９】
モジュール定義ファイル（．ＤＥＦ）ファイル３２２は、ＡＰＩｓとしてＤＬＬ３２０からエクスポートさせるという機能のリストを特定する。この．ＤＥＦファイルは、インポート・ライブラリ（．ＬＩＢ）ファイル３２１にコンパイルされている。例えば、．ＤＥＦファイルにおける入力ＦＯＯ＝ＢＡＲ＠４が、ＦＯＯとして内部的に知られている機能を、ＢＡＲとしてＤＬＬからエクスポートするようにリンカー（ｌｉｎｋｅｒ）に命令する場合のように、ＤＬＬからエクスポートされたＡＰＩの名前は、ソース・ファイル３１１における機能の名前と異なる可能性があるため、．ＬＩＢファイルは非常に重要である。サンク・ジェネレータ３３０は、．ＬＩＢファイル３２１を使用し、内部的機能の名前をエクスポートされたＡＰＩの名前と関連付けを行う。Ｃ言語ファイルは、データのタイプ及び外部の変動しやすい名前のような、外部インターフェースとしてのコード・ファイル３１１を特定するヘッダ（．Ｈ）ファイル３１３と関連付けされている。具体的には、ヘッダ・ファイルは、コード・ファイル３１１における機能３１２のタイプに関する情報３１５を含んでいる。
【００２０】
例えば、．Ｈヘッダ・ファイルは、以下のようなタイプの定義を含むことができる。
Typedef  struct  tagFoo  （
int  member1；
int  member2；
）*PEOO    
【００２１】
そして、機能宣言：
int  AnApi    （PFOO  argl,  char  *）；
ジェネレータ330は、全APIsに関するこの情報を記憶する。上記例に関する入力は、
TYPENAME    struct  tagFoo
MEMBER  LIST
MEMBER  NAME    member1
MEMBER  TYPE          int
MEMBER  OFFSET        0
MEMBER  NAME    member2
MEMBER  TYPE          int
MEMBER  OFFSET        4
TYPENAME    Foo
INDIRECTION    1
BASETYPE      struct  tagFoo
APINAME      AnApi
RETURN  TYPE      int
ARG  NAME          argl
ARG  TYPE          PFOO
ARG  NAME          ＜noname＞
ARG  TYPE            char  *
最後に、既存の定義（．ＤＥＦ）ファイルは、内部的ＡＰＩの名前を、異なる名前としてＤＬＬ３２０からエクスポートするように、ＯＳ２３０における既存のリンカー（図示せず）に命令を出す。
【００２２】
翻訳ジェネレータ３３０は、ファイル３１１、３１３、及び３２１からの情報を使用し、Ｃ言語のソース・コード・ファイル３４０を作り、このファイルは、図２における翻訳コード・モジュール２６０にコンパイルされる。本発明は、この目的のために、新規なテンプレート・ファイル３５０のセットを備える。テンプレート（．ＴＰＬ）ファイルは、翻訳コード・モジュール（「サンク」）を生成する方法に関する記述である。それらは、ＡＰＩ機能及びそれらの引数全体にわたって反復し、特定のＡＰＩｓから生じる特殊ケースを処理するために、手作業により生成されたＣコードを少し含んでいる。
【００２３】
各テンプレートは、以下のような構文を持っている。
[Type_of_Template]
TemplateName=Name_of_Template
CgenBegin=
<このテンプレートが拡張された際生成されるコード>
CgenEnd= 
【００２４】
反復機能（ＩＦｕｎｃ）テンプレート３５１は、ＡＰＩ機能全体を反復する。ジェネレータ３３０は、ＡＰＩにおける各拡張機能に対して、これらの内の１つを拡張する。ＩＦｕｎｃテンプレート３５１は、ＡＰＩｓに対するデフォルト拡張である。以下の例のテンプレートは、スケルトン・サンク３４０を生成する。
[Ifunc]
TemplateName=HostFuncs
CgenBegin=
Void
wh@ ApiName  (PULONG BaseArgs, ULONG RetVal)
(
@ApiFnRet  *pRetVal = (@ApiFnRet  *)  RetVal
@Types  (Locals)
@Types  (Body)
@IfApiRet  (*pRetVal = )   @ApinName  (@IfArgs  (@ArgList
( *( (@ArgType
* )  (@ArgAddr (BaseArgs) ) )  @ArgMore ( , ) ) ) ) ;
@Types  (Return)
)
CgenEnd =
【００２５】
ジェネレータ３３０は、以下のような、特定のＡＰＩ３１０に対するファイル３１３及び３２１から収集したデータからの、テンプレート３５１において「＠」が接頭に付けられたキーワードの各々を拡張する。
@ApiName      APIの内部の名前
@ApiFnRet          APIの復帰タイプ
@Types(X)          形式「X」のテンプレートの拡張タイプ
@IfApiRet(X)        APIの復帰タイプが非ボイドの場合、「X」を拡張する
@IfArg(X)            APIが引数を有する場合、「X」を拡張する
@ArgList(X)          全引数の反復し、各引数に対する「X」を拡張する
@ArgType            引数のタイプ
@ArgAddr(X)        「X」に関する引数のアドレス
@ArgMore(X)        現在の引数に後続する更なる引数が存在する場合に拡張する
【００２６】
例えば、プロトタイプの「HWND  Fine  WindowA（LASTR  lpClass,  LASTER  lpWindow）」は、
WhFindWindowA  (PULONG pBaseArgs, ULONG RetVal)
(
HWND  *pRetVal = (HWND * )   RetVal;
*pRetVal = FindWindowA (  * (LASTR  *)  (pBaseArgs + 0) ,  *
(LPSTR * )  (pBaseArgs + 1)  ) ;
)
に対して拡張する。
【００２７】
例外機能（ＥＦｕｎｃ）テンプレート３５２は、特定のＡＰＩを認識し、そのＡＰＩに対するデフォルトＩｆｕｎｃテンプレート３５１を無効にする。以下のテンプレート３５２の例は、
「SetErrorMode」と名づけられた特定のＡＰＩに対する固定コードを作る。[Efunc]TemplateName = SetErrorMode
CgenBegin =
Void
Wh@ApiName (PULONG BaseArgs,  ULONG RetVal)
(
@ApiFnRet  *PretVal = (@ApiFnRet  *)  RetVal ;
*pRetVal = SetErrorMode  (  * (UINT  *)  (pBaseArgs ) ?
SEM_NOALIGNMENTFAULTTEXCEPT )
* pRetVal,  &  = −NOALIGNMENTFAULTTEXCEPT  ;
）
CgenEnd  ＝ 
ＥＦｕｎｃテンプレートは、ＡＰＩに対する特注書込みコードのための機能を備えており、その上、ＡＰＩ変更に対してのローバスト性を抑制している。勿論、そのようなＡＰＩに対するコードは、単に、そのＥｆｕｎｃテンプレートを書換えるだけで、いつでも書換えることができる。
【００２８】
タイプ（Ｔｙｐｅｓ）テンプレート３５３は、特定されたタイプの名前に適合する、各パラメータつまり引数に対するサンク３４０を作り出す。タイプ・テンプレートは、新しいＡＰＩｓに自動的にそれらを適用するジェネレータ３３０において力を発揮する。以下の例を考察されたい。
【００２９】
[Types]
TemplateName = Locals
TypeName = LPSTR
IndLevel = 0 
CgenBegin =
@ArgLocal = * ( ( @ArgType * )  (pBaseArgs + @ArgOff ) ) ;
CgenEnd =
【００３０】
TemplateName = Body
TypeName = LPSTR
IndLevel = 0 
CgenBegin =
VALIDATE_LPSTR  ( @ArgNameLocal ) ;
CgenEnd =
【００３１】
これら２つのテンプレートによって、Ｃ言語のＬＰＳＴＲデータタイプであるＡＰＩ３１１は、デフォルトＩＦｕｎｃテンプレートに対するＩＦｕｎｃコードに加え、特殊目的タイプのコードを自動的に受入れる。例えば、上述した「FindWindowA」のＡＰＩは、ここで、
（
ＨＷＮＤ  *pRetVal = (HWND  *)  ReVal ;
LPSTR lpClass = * ( (LASTR  *)  (pBaseArgs + 0 ) ;
LPSTR lpWindow = * ( (LASTR  *)  (pBaseArgs + 1 ) ;
VALIDATE_LPSTR  (lpClass) ;
VALIDATE_LPSTR  (lpWindow) ;    
*pRetVal = FindWindowA  (lpClass , pWindow ) ;
)
に拡張する。
【００３２】
コード・テンプレート３５４は、マクロのように機能する。これは、他の多くのテンプレートと共通にすることが可能なコードを含んでおり、これらのテンプレートにおける名前によって参照される。例えば、以下の行
*pRetVal = SetErrorMode  ( ( * (UINT  *)  pBaseArgs )  ?
が、異なるテンプレート３５１、３５２、又は３５３において何度の生じる場合には、その行は、「ｓｅｒｒｍ」というような名前のコード・テンプレートに置換えることができる。次に、上記例のように参照されたテンプレートは、その行を、マクロの名前、例えば、「［＠ｓｅｒｒｍ］」によって、単に置換える。そして、既存のＣマクロ機能は、その名前をコードに置換えるが、勿論、Ｃマクロは、この例よりもずっと複雑である。
上記テンプレートは、Ｃ言語で書かれたのもとして示されたが、それらは、言語が何であるかに無関係である。テンプレート３５０は、Ｃ＋＋、アセンブリ言語、或いは他の望ましい形式のコードを生成できる。
【００３３】
図４は、図３の翻訳コード・ジェネレータ３３０によって実行されるステップ４００を記載している。ジェネレータは、ＡＰＩの再生を必要とするオペレーティング・システム２３０又は他のエンティティの全集合体に対し、４０１において作動される。その終末４０２において、ＡＰＩ翻訳モジュールのソース・コード・ファイル３４０の全セットは、同一層において同期化されており、エミュレータ２４０のＡＰＩ翻訳部（「サンク」層）を共に形成する、図２のオブジェクト・コード・モジュール２６０のセットに、既存の形態でコンパイルされることが可能である。
【００３４】
ブロック４１０は、ＯＳ２３０に属する全てのＤＬＬｓ２５４を走査し、再生を必要とするＡＰＩｓ（図２における２６１、２６２、−−−）のセットを確認する。これらのＡＰＩの名前は、先に説明したように、各ＤＬＬのエクスポート・テーブル３１４及びインポート．ＬＩＢファイル３２１内に存在する。（技術的な挿話として、原タイプのエクスポートの源は、インポート．ＬＩＢである。しかし、それらの多くは、名前の付けられていない序数、又は名前を付け直されたＣ機能である可能性がある。タイプに関する情報を得るため、ジェネレータ３３０は、各ＡＰＩを実行する原機能の名前を再構築しなくてはならない。従って、このジェネレータは、時には、エクスポートの名前を機能の名前に戻すようにマップ化しなくてはならない。）次に、ステップ４０３は、処理するために、順次、セットの中から最新のＡＰＩを選定する。
【００３５】
ステップ４２０では、例外テンプレート名のリストにおける既存のテーブル調査機能によって、例外テンプレート３５２を手に入れるように、最新のＡＰＩを確認する。このようなテンプレートが存在する場合には、ステップ４２１で、関連するＥＦｕｎｋテンプレートにアクセスし、ステップ４２２で、そのソース・コードを、そのＡＰＩに対するサンク・ファイル３４０に置く。
最新のＡＰＩが、正常なＡＰＩである場合には、ステップ４３０で、そのエクスポートされた機能全ての名前を抽出するために、そのヘッダ・ファイル３１３のエクスポート・テーブル３１３を読取る。上述したように、ステップは、これらの機能に対するＥＦｕｎｃテンプレートを拡張する。ステップ４３１で、最新のＡＰＩのエクスポートされた機能が全て抽出されると、出口４３２は、次のステップに進む。
【００３６】
ステップ４４０で、最新のＡＰＩのパラメータ（引数）全体を通して反復され、最新のパラメータとしての１つが順次選定される。ステップ４４１で、このパラメータのタイプに対するタイプ・テンプレートが存在すると、次に、ステップ４４２で、このテンプレートのソース・コードが、モジュール３４０に置かれるため、ＡＰＩは、その引数のタイプを正しく処理することになる。大半のタイプ・テンプレートは、あるパラメータを異なる値に置換える。しかし、タイプ・テンプレートは、パラメータの範囲を有効化するような、他の機能を実行することができる。全てのタイプ・テンプレートが処理された時、制御は出口４４３を通過する。
【００３７】
ステップ４５０で、図３のコード・テンプレート３５４が処理される。コード・テンプレートの名前が、テンプレート処理ステップ４２２、４３２．又は４４２において、（マクロの名前として）現れる際は、常に、破線４５１が、ステップ４５０を呼出し、特定の名前を付けられたコード・テンプレートが拡張されると共に、このコードを、呼出しているテンプレートに戻す。
ステップ４５０は、実際には、サンクのソース・コード・ファイル３４０が、オブジェクト・コード・モジュール２６０に一般的な形でコンパイルされる後に生じる可能性がある。
【００３８】
上記説明は例示を意図したもので、限定的なものではないことを理解すべきである。本発明は、複数のプラットフォームから、ただ１つのインターフェースが相反する場合のインターフェース実行させるために使用することができる。更に、適合するテンプレートは、多くの異なる形態で、例えば、望ましいテンプレートを直接的に確認するインターフェースにおけるフィールドを持つことによって、行うことが可能である。他の多くの実施形態が存在することは、上記説明を検討すれば、当業者にとって明らかなことであろう。従って、本発明の範囲は、請求の範囲を参照するとともに、その請求範囲に許された均等範囲を考慮することによって決定されるべきである。
【図面の簡単な説明】
【００３９】
【図１】図１は、本発明を実施することが可能なコンピュータシステムのブロック図である。
【図２】図２は、本発明がユーティリティーを見出す、複数プラットフォームのエミュレーション環境における上位層のブロック図である。
【図３】図３は、本発明による翻訳ユーティリティーを、その入出力とともに示す上位層のブロック図である。
【図４】図４は、図３のトランスレータのオペレーションを示す流れ図である。
【図１】
2005100437.tif 000003
【図２】
2005100437.tif 000004
【図３】
2005100437.tif 000005
【図４】
2005100437.tif 000006