(57)【特許請求の範囲】
【請求項１】
プラットフォームされたデジタル・コンピュータにおいて、上記デジタル・コンピュータは確認手段（３３０）、選定手段（３３０）、テンプレートを記憶した記憶手段および情報処理手段を有し、
第１プラットフォーム用に書き込まれたコードを含み、１つ以上の機能を実行するインターフェース・モジュール(２５１、２５２)を上記確認手段により確認するステップ（４１０）、
上記インターフェース・モジュールを表すソース・コード・ファイルを上記選定手段により選定するステップ(４０３)、
上記インターフェース・モジュールの機能を実行する第２プラットフォームにおいて実行可能なコードを含み、上記選定手段により選定されたソース・コード・ファイルに対応する翻訳モジュール（２６０、３４０）を上記情報処理手段により生成するステップ（４２０−４５１）、及び多くのインターフェース及び翻訳モジュールに対し、上記ステップを繰り返すステップを含む方法であって、上記翻訳モジュールを生成するステップは、
上記インターフェース・モジュールから、上記インターフェース・モジュールによって実行される１つ以上の機能を表すデータを抽出するステップ（４３０）、
上記インターフェース・モジュール機能を、少なくとも１部が上記第２プラットフォーム用に書込まれた一般化されたプログラム・コードを含む、上記記憶手段に記憶されたテンプレートのグループ（３５０）に照合するとともに、上記グループから、少なくとも１つの適合するテンプレート（３５１）を選定するステップ（４３０）、及び
上記選定されたテンプレートに関し、上記テンプレートにおける上記一般化されたプログラム・コードを、上記翻訳モジュールにおける上記インターフェース・モジュールの機能を実行する専用化されたプログラム・コードに変換するステップ（４３１）を含み、
上記翻訳はＡＰＩ呼び出しの変換であることを特徴とする方法。
【請求項２】
上記専用化されたプログラム・コードは、上記第２プラットフォーム用のソース・コードであることを特徴とする請求項１に記載の方法。
【請求項３】
上記第１プラットフォームは、第２プラットフォームにおけるエミュレータ（２４０）の下で実行することを特徴とする請求項１に記載の方法。
【請求項４】
上記プログラムは、第２プラットフォームにおいて実行する場合には、上記インターフェース・モジュールの代わりとして、翻訳モジュールを呼出すことを特徴とする請求項３に記載の方法。
【請求項５】
上記照合及び変換ステップは、各インターフェース・モジュールにおける複数の機能を反復することを特徴とする請求項１に記載の方法。
【請求項６】
請求項１の方法を実行するためのプログラム命令（３７）及びデータ（３８）を記録したコンピュータ読取可能な記録媒体（２７、２９、３１、５１、５２）。
【請求項７】
コンピュータシステムにおいて、第１のプラットフォームにおいて実行されるインターフェース・モジュールのセット（２５１、２５２）を、上記インターフェース・モジュールの機能の１つに対応して実行する、但し、第２プラットフォームにおいて実行する翻訳モジュールのセット（２６０、３４０）に変換するためのテンプレートのセット（３５０）を有するとともに、上記インターフェース・モジュールは、上記インターフェース・モジュールによってエクスポートされた機能の名前を含む、関連付けられたヘッダ・ファイル（３１４）を有し、上記コンピュータシステムは、上記テンプレートを記憶した記憶手段およびジェネレータ手段（３３０）とを有し、
上記テンプレートは、第２プラットフォームにおいて機能を実行するための一般化されたコードを含み、更に
上記ジェネレータ手段は、上記ヘッダ・ファイルにエクスポートされた機能の名前に従って、特定の上記インターフェースのファイルを、少なくとも１つの上記テンプレートに照合し、適合した１つ又は複数の、上記記憶手段に記憶されたテンプレートを拡張し、上記第２プラットフォームにおいて上記インターフェース・モジュールの機能を実行するための翻訳モジュールにソース・コードを作成し、上記翻訳はＡＰＩ呼び出しの変換であることを特徴とするコンピュータシステム。
【請求項８】
上記ヘッダ・ファイルの各々は、上記インターフェース・モジュールの１つによって実行される機能のリスト（３１４）を含んでいることを特徴とする請求項７に記載のシステム。
【請求項９】
上記ジェネレータ手段は、上記ヘッダ・ファイル内の機能のリスト全体を反復し、上記適合したテンプレート内に専用化されたコードとして上記機能の各々を拡張するようにしたことを特徴とする請求項７に記載のシステム。
【請求項１０】
上記ヘッダ・ファイルは、上記インターフェース・モジュールによって受け渡されたパラメータを特定することを特徴とする請求項７に記載のシステム。
【請求項１１】
上記テンプレートの１部は、上記パラメータを異なる形式に変換するタイプ・テンプレートであることを特徴とする請求項１０に記載のシステム。
【請求項１２】
上記ジェネレータ手段は、複数のパラメータ全体を反復し、上記パラメータの各々に対し、異なる可能性のある上記タイプ・テンプレートの１つを選択することを特徴とする請求項１１に記載のシステム。
【請求項１３】
記憶手段、選定手段および情報処理手段を有し、適切にプログラムされたデジタル・コンピュータ（２０）に、
第１プラットフォーム用に書込まれたコードを含み、１つ以上の機能を実行するインターフェース・モジュール（２５１、２５２）を確認するステップ、
上記記憶手段に記憶された、インターフェース・モジュールを表すソース・コード・ファイルを上記選定手段により選定するステップ（４０３）、
上記インターフェース・モジュールの機能を実行する第２プラットフォームにおいて実行可能なコードを含む翻訳モジュールであって、上記選定手段により選定されたソース・コードに対応する翻訳モジュール（２６０、３４０）を上記情報処理手段により生成するステップ（４２０−４５１）、及び
多くのインターフェース及び翻訳モジュールに対し、上記ステップを繰り返すステップを
実行させるためのプログラム命令（３７）を記録したコンピュータ読取可能な記録媒体（２７、２９、３１、５１、５２）であって、上記翻訳モジュールを生成するステップは、
上記インターフェース・モジュールから、上記インターフェース・モジュールによって実行される１つ以上の機能を表すデータを抽出するステップ（４３０）、
上記記憶手段に記憶されているテンプレートのグループであって、上記インターフェース・モジュール機能を、少なくとも１部が上記第２プラットフォーム用に書込まれた一般化されたプログラム・コードを含むテンプレートのグループ（３５０）に照合するとともに、上記グループから、少なくとも１つの適合するテンプレート（３５１）を選定するステップ（４３０）、及び
上記選定されたテンプレートに関し、上記テンプレートにおける上記一般化されたプログラム・コードを、上記翻訳モジュールにおける上記インターフェース・モジュールの機能を実行する専用化されたプログラム・コードに変換するステップ（４３１）を含み、
上記翻訳はＡＰＩ呼び出しの変換であることを特徴とする媒体。
【請求項１４】
上記媒体は、磁気的（２７、２９）、又は光学的（３１）記録媒体であることを特徴とする請求項１３に記載のコンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の分野】
本発明は、電子データ処理に係り、より具体的には、あるプラットフォーム用に書込まれたアプリケーション・プログラムを、異なるプラットフォームでも実行できるようにするエミュレータとともに使用され、アプリケーション・プログラム・インターフェース（APLs）を、あるプラットフォームから他のプラットフォームに翻訳する翻訳コード・モジュールのセットを生成するためのソフトウェアツールに関する。
【０００２】
【発明の背景】
今日、アプリケーション・プログラムは、それらが実行されるコンピュータシステムのハードウェアに対し、直接的にインターフェースされることはほとんどない。その代わり、アプリケーション・プログラム・インターフェース（APIs）が、ハードウェアを制御するコード・モジュール、又は  まだ下位層に置かれたプログラムされたインターフェースを呼出す。大半のAPIコード・モジュールは、オペレーティング・システム（OS）内に在り、その他のものは、基本入出力システム（BIOS）、或いは他の場所に存在する。API機能を果たすコード・モジュールは、通常、数十、数百に近いAPI機能を実行するためのルーチンを各々含む自立構造をした複数のダイナミック・・ライブラリ（DLL）ファイル内に存在する。
【０００３】
あるコンピュータの中央演算処理装置用に書込まれたアプリケーション・プログラムを実行するには、オペレーティング・システム、つまり、もう１つのプラットフォームである他のプラットフォームは、エミュレータ、シミュレータ、インタープリタ、又はトランスレータのような、色々知られているプログラムを必要とし、このプログラムによって、命令、データ・フォーマット、アプリケーション・プログラム・インターフェース（APIs）、及び  アプリケーションの他の特性を、その原プラットフォームのものから、該エミュレータが実行される固有プラットフォームの特性に変換する。原プラットフォームが交換される時にも、元から在るアプリケーションは、新しいプラットフォームにおいても実行され続けなくてはならない。プログラムが、抽象的なプラットフォームに書込まれている場合には、この抽象的なプラットフォームを扱う各々の固有プラットフォームにエミュレータを書込むたけで、同じアプリケーションを多くの異なるプラットフォームにおいて実行させることが可能である。
【０００４】
エミュレータのサブシステムは、一般的に、2つの構成要素を有する。エミュレータ自身は、そのアプリケーションからの原中央演算処理装置への命令を、新しいプラットフォームの中央演算処理装置に相応しい複数の又は複数グループの命令に変換する。API翻訳層は、固有プラットフォーム用に書込まれたAPIsに対する呼出しにエミュートされている原プラットフォームからのAPI呼出しを「サンク(thunk)」する。つまり、API翻訳層は、エミュレートされたプラットフォーム用に書込まれたアプリケーションによって作られたAPI呼出しを遮り、それらの引数を、原プラットフォームの呼出し変換から、固有プラットフォームの呼出し変換へと変換することによって、API機能を実行するに相応しい固有プラットフォーム・モジュールを呼出す。
【０００５】
従来の手法では、新しいAPI及び修正されたAPI用の手書きサンク・コードが使用されている。しかし、APIセットは、オペレーティング・システムの進歩とともに、日々変化する可能性がある。また、APIの数も、非常に多くなる可能性がある。例えば、マイクロソフト・ウインドウズ  NTのオペレーティング・システムは、42の異なるDLLモジュールにおいて3500を越すAPIを含んでいる。従って、手作業による個々のAPI翻訳コードの作成は、益々非現実的なものとなっている。益々短くなる商品サイクルは、この問題を倍化している。
【０００６】
いくらかのインターフェース・モジュール、つまりサンクは、個々のAPIの各々に対し手書きによる記述によって生成されてきた。しかし、これらは、複数のAPI自身から分離した状態に維持されなくてはならず、コスト的に余分な努力が必要とされる。また、インターフェース・モジュールは、「同期化」の問題に苦しんでおり、１つ以上のモジュールが、ある開発反復から次のものへの更新を、うっかりして忘れた場合には、それらのダウン層コードは、APIを翻訳し損なう可能性があり、つまりシステムを破壊してしまう可能性がある。このような問題は散見され、これによって開発全体の遅れを余儀なくされている。
【０００７】
もう１つの方法としては、ソフトウェアツールを、C言語ソース・ファイルとしてスケルトンAPIサンクのセットを作るために使用し、後にこれを手作業で修正するようにしてきた。この手法は、このツールが全ての手作業による編集の破壊を繰り返しているという点から、実用的なものとは言えない。
Yi−hsiu  Wei  他の「多相RPCシステム用スタブ・ジェネレータ」Journal of Parallel and Distributed Computing, Vol. 11, No.3 (1991年3月1日), 188-197頁には、２つの異なるプラットフォーム間の遠隔手続呼出し用のデータ変換スタブを構成するために、異なる目的にテンプレートを使用することを教示している。
【０００８】
【発明の概要】
本発明によるユーティリティー・プログラムは、あるプラットフォーム用に書込まれたAPIsを翻訳するためのコード・モジュールを作成し、それを自動的に更新するので、このプログラムは、異なるプラットフォームにおいて適切に実行されることになる。このユーティリティーは、APIsによって遂行される機能に基づき、オペレーティング・システム又は他のソフトウエア環境の新開発反復に対し実行され、翻訳モジュール用ソース・コードを作成するためにテンプレートのセットを使用する。特殊な翻訳要件は、専用の翻訳コードを含む例外テンプレートによって処理される。他の種類のテンプレートは、原APIsのパラメータ又は引数から、異なるプラットフォームのそれらへの、タイプの変換を遂行する。
【０００９】
この方法における自動的なコード生成は、翻訳モジュールが、新オペレーティング・システム又は環境の対してなされた変更と同期化するようにした自動化された方法を提供することによって、開発反復を一段と迅速化することができる。コード・ジェネレータは、全翻訳モジュールが、最新の更新レベルにあることを確実にし、相性の悪いモジュールによって引起されるシステム破壊を防止する。また、それは、先行して行われる手作業による生成方法に起因する個々のコード・モジュール内のエラーも飛躍的に低減し、更に、違う人間が異なるモジュールを別々に作成することから起こるモジュール間のエラーをも排除する。
他の特徴、利点、及び  本発明の範囲に属する変更、付加については、以下の記載により当業者に対し明らかにされる。
【００１０】
【詳細な説明】
図1により、本発明を実施するに相応しいコンピュータの環境に関する簡単な全体的説明を行う。ハードウェア及びソフトウエア環境が、最初に述べられ、その後に、あるプラットフォーム用に書込まれたAPIsを翻訳するためのコード・モジュールを作成し、更に、それを自動的に更新することによって、それらが異なるプラットフォーム上で適切に実行されるようにするツールを備える本発明の詳細な説明を行う。以下、本発明は、パーソナル・コンピュータ（PC）によって実行される、プログラム・モジュールのようなコンピュータ実行命令の一般的文脈において説明されるが、他の環境とすることも可能である。プログラム・モジュールは、特定のタスクを遂行する、つまり  特定の抽象データのタイプを作成する、ルーチン、プログラム、目的、構成要素、データの各構造  等を含む。本発明が、手持型の装置、多重プロセッサ、マイクロプロセッサをベースとしたプログラム可能な大衆消費電子製品、ネットワークPC、ミニコンピュータ、メインフレーム・コンピュータ  等を含む他のコンピュータシステムの機器構成によって実践できることは、当業者に十分理解されるであろう。また、本発明は、分散されたコンピュータ環境においても実践でき、そこにおいて、タスクは、通信ネットワークを通じて連結された遠隔中央演算処理装置により遂行される。分散されたコンピュータ環境において、プログラム・モジュールは、局所及び遠隔の両方のメモリ記憶装置内に設けることができる。
【００１１】
図1は、本発明を実施するための例示的システムを示す。それは、処理ユニット21、システムメモリ22、及び  システムメモリ及び他のシステム構成部品を処理ユニットに連結するシステムバス23を備えた、既存のパーソナル・コンピュータ20の形態での汎用コンピュータ装置を使用している。システムバス23は、メモリバス又はメモリコントローラ、周辺バス、及び  局所バスを含む様々なタイプの内の何れでも良く、様々なバス構造の何れでも使用できる。システムメモリ22は、読取り専用メモリ（ROM）24及びランダムアクセス・メモリ（RAM）25を備えている。ROM24に記憶された基本入出力システム（BIOS）26は、パーソナル・コンピュータの構成部品間で情報を伝送する基本ルーチンを含んでいる。また、BIOS24は、システムの起動ルーチンを含んでいる。パーソナル・コンピュータ20は、更に、ハードディスク（図示せず）からの読出し、またそこへの書込みを行うハードディスク・ドライブ27、取外し可能な磁気ディスク29からの読出し、またそこへの書込みを行う磁気ディスク・ドライブ28、及び  CD-ROM又は他の光媒体のような取外し可能な光ディスク31からの読出し、またそこへの書込みを行う光ディスク・ドライブ30を備えている。ハードディスク・ドライブ27、磁気ディスク・ドライブ28、及び  光ディスク・ドライブ30は、各々、ハードディスク・ドライブ・インターフェース32、磁気ディスク・ドライブ・インターフェース33、及び  光ディスク・ドライブ・インターフェース34によって、システムバス23に接続される。これらドライブ及びそれらの関連するコンピュータ読出し可能媒体は、パーソナル・コンピュータ20用の、コンピュータ読出し命令、データ構造、プログラム・モジュール、及び  他のデータの不揮発性記憶装置を備えている。ここで説明される例示的環境は、ハードディスク、取外し可能な磁気ディスク29、及び  取外し可能な光ディスク31を使用しているが、コンピュータによりアクセス可能なデータを記憶できる他タイプのコンピュータ読出し可能媒体が、この例示的オペレーティング環境において同様に使用できることは、当業者に十分理解されるであろう。このような媒体としては、磁気カセット、フラッシュメモリカード、デジタル多目的ディスク、ベルヌーイ・カートリッジ、PAMs、POMs  等を含むことができる。
【００１２】
プログラム・モジュールは、該ハードディスク、磁気ディスク29、光ディスク31、ROM24、及び  RAM25に記憶されることができる。プログラム・モジュールは、オペレーティング・システム35、１つ以上のアプリケーション・プログラム36、他のプログラム・モジュール37、及びプログラムデータ38を含んでいる。使用者は、キーボード40や指示装置42のような入力装置を介して、コマンド及び情報をパーソナル・コンピュータ20に入力できる。その他の入力装置（図示せず）としては、マイクロフォン、ジョイステック、ゲームパッド、パラボラアンテナ、走査器  等を含むことができる。これら及びその他の入力装置は、しばしば、システムバス23に連結されたシリアルポート・インターフェース46を介して、処理ユニット21に接続されるが、それらは、パラレルポート、ゲームポート、又は  ユニバーサル・シリアルポート（USP）のような、図1に示されていない他のインターフェースを介して接続されることが可能である。また、モニタ47又は他の表示装置を、ビデオアダプタ48のようなインターフェースを介して、システムバス23に接続される。この表示装置に加え、パーソナル・コンピュータは、通常、スピーカやプリンタのような他の周辺出力装置（図示せず）を備える。
【００１３】
パーソナル・コンピュータ20は、遠隔コンピュータのような1つ以上の遠隔コンピュータへの論理的接続を使用したネットワーク化環境において使用することができる。遠隔コンピュータ49は、もう１つのパーソナル・コンピュータ、サーバ、ルータ、ネットワークPC、ピア(peer)装置、又は  他の一般的ネットワーク・ノードとすることができる。図1には記憶装置50のみが示されているが、この遠隔コンピュータは、通常、パーソナル・コンピュータ20に関する上記した構成部品の多く又は全てを備えている。図1に書かれた論理的接続は、ローカル・エリア・ネットワーク（LAN）51及び広域ネットワーク（WAN）52を含んでいる。このようなネットワーク環境は、事務所、企業の広範囲なコンピュータ・ネットワーク、イントラネット、インターネットにおいて一般的なものである。
【００１４】
LANネットワーク環境に設置する場合、PC20は、ネットワーク・インターフェース又はアダプタ53を介してローカル・ネットワーク51に接続される。インターネットのようなWANネットワーク環境において使用する場合、PC20は、通常、ネットワーク52を通じての通信を確立するためのモデム54又は他の手段を備えている。モデム54は、PC20に内蔵又は外付けすることができ、シリアルポートを介して、システムバス23に接続される。ネットワーク環境において、20又はその1部内に存在するように書かれたプログラム・モジュールは、遠隔記憶装置50内に記憶することができる。当然の事であるが、示されたネットワーク接続は、例示的なものであり、コンピュータ間の通信リンクを確立する他の手段と置換えることが可能である。
【００１５】
あるプラットフォーム用のアプリケーション・プログラム210を、異なるプラットフォームを意味する中央演算処理装置220において実行するためのソフトウエア環境を示す。破線201に囲まれた要素は、図1の中央演算処理装置21のような、Intel社の「X86」系、例えばIntel 80386、80486、又は  ペンティアム マイクロプロセッサで構成した第1プラットフォームにおいて実行されるよう設計された要素である。他の要素は、中央演算処理装置21として使用されるDigital Equipment 社の「Alpha」又は  IBM社の「Power PC」マイクロプロセッサのような第2プラットフォームにおいて実行される。この説明においては、第1及び第2プラットフォームを、それぞれ、「X86」及び「固有プラットフォーム」と呼ぶ。例示目的のため、Microsoft NTオペレーティング・システムの固有プラットフォーム230版が、Fig.1のOS 35として使用される。
【００１６】
既存のエミュレータ・プログラム240は、図1及び2の36のようなX86プラットフォーム・アプリケーション・プログラムに関する、命令、データ、及び  インターフェース（APIs）を、X86プラットフォームのこれらから、固有プラットフォームにおける等価のオペレーションに翻訳する。アプリケーション・プログラムのAPIsは、実際のところ、図2にほんの1部が示された、APIモジュール251−253のセット250に対する呼出しである。APIモジュールは、普通、254のようなダイナミック・リンク・ライブラリにグループ化されている。先に述べたように、OS230は、DLLの40という数よりも多い数百のAPIsを持っており、集合的には「Win32」として知られているこのセットは、開発作業過程でほとんど毎日、新しい「構成(build)」に再編成される。アプリケーション210が、API251のような、X86プラットフォーム用に書込まれたAPIを呼出す場合、エミュレータ240内の既存のAPI翻訳層241は、適切なAPIモジュール251を検索し、関連する翻訳コード・モジュール、つまり「サンク」261を呼出し、どのようなAPI配列及びデータでも、固有プラットフォームに対し正しいフォーマットに変換するとともに、APIが原X86プラットフォームにおいて実行していたものをエミュレートする機能を果す。サンク260のセットは、X86のAPI251−252の各々に対する個別のモジュール261−262を含んでいる。固有プラットフォーム用に書込まれた253のようなAPIsは、OS230から呼出され、サンクを必要としない場合には、直接的に実行される。
【００１７】
図3は、本発明による翻訳ユーティリティーを、その入出力とともに示した、上位層のブロック図300である。図2に示された要素のいくらかは、コンパイルされたオブジェクト・コードの形式においては図2のものと一致する要素であるが、図3においてはソース・コードとして存在していることを示すため、図3とは異なる番号を付している。
【００１８】
そのソース・コード形式において、図2の各DLL254は、図2におけるAPI250用のCのような言語で書かれた命令を各々含むファイル311の集合310である。各ファイルは、1つ以上の機能312を表現し、APIs251−252の内の1つによって実行される。[＠＠ Inventor note 1]  (ある専門用語：ダイナミック・リンク・ライブラリは、３つのソース・ファイル、つまり、Cソース・ファイル、Cヘッダ・ファイル、及び  DEFファイル、から生成される。コンパイラは、これらを、DLLコード・ファイル及びインポート.LIBファイルの２つのオブジェクト・ファイルに変換する。)
【００１９】
モジュール定義ファイル（.DEF）ファイル322は、APIsとしてDLL320からエクスポートさせるという機能のリストを特定する。この.DEFファイルは、インポート・ライブラリ（.LIB）ファイル321にコンパイルされている。例えば、.DEFファイルにおける入力FOO＝BAR＠4が、FOOとして内部的に知られている機能を、BARとしてDLLからエクスポートするようにリンカー(linker)に命令する場合のように、DLLからエクスポートされたAPIの名前は、ソース・ファイル311における機能の名前と異なる可能性があるため、.LIBファイルは非常に重要である。サンク・ジェネレータ330は、.LIBファイル321を使用し、内部的機能の名前をエクスポートされたAPIの名前と関連付けを行う。C言語ファイルは、データのタイプ及び外部の変動しやすい名前のような、外部インターフェースとしてのコード・ファイル311を特定するヘッダ（.H）ファイル313と関連付けされている。具体的には、ヘッダ・ファイルは、コード・ファイル311における機能312のタイプに関する情報315を含んでいる。
【００２０】
例えば、.Hヘッダ・ファイルは、以下のようなタイプの定義を含むことができる。
0003641430.tif 000002
【００２１】
そして、機能宣言：
0003641430.tif 000003
ジェネレータ330は、全APIsに関するこの情報を記憶する。上記例に関する入力は、
0003641430.tif 000004
最後に、既存の定義（.DEF）ファイルは、内部的APIの名前を、異なる名前としてDLL320からエクスポートするように、OS230における既存のリンカー（図示せず）に命令を出す。
【００２２】
翻訳ジェネレータ330は、ファイル311、313、及び321からの情報を使用し、C言語のソース・コード・ファイル340を作り、このファイルは、図2における翻訳コード・モジュール260にコンパイルされる。本発明は、この目的のために、新規なテンプレート・ファイル350のセットを備える。テンプレート（.TPL）ファイルは、翻訳コード・モジュール(「サンク」)を生成する方法に関する記述である。それらは、API機能及びそれらの引数全体にわたって反復し、特定のAPIsから生じる特殊ケースを処理するために、手作業により生成されたCコードを少し含んでいる。
【００２３】
各テンプレートは、以下のような構文を持っている。
0003641430.tif 000005
【００２４】
反復機能（IFunc）テンプレート351は、API機能全体を反復する。ジェネレータ330は、APIにおける各拡張機能に対して、これらの内の１つを拡張する。IFuncテンプレート351は、APIsに対するデフォルト拡張である。以下の例のテンプレートは、スケルトン・サンク340を生成する。
0003641430.tif 000006
【００２５】
ジェネレータ330は、以下のような、特定のAPI310に対するファイル313及び321から収集したデータからの、テンプレート351において「@」が接頭に付けられたキーワードの各々を拡張する。
0003641430.tif 000007
【００２６】
例えば、プロトタイプの「HWND  Fine  WindowA（LASTR  lpClass,  LASTER  lpWindow）」は、
0003641430.tif 000008
に対して拡張する。
【００２７】
例外機能（EFunc）テンプレート352は、特定のAPIを認識し、そのAPIに対するデフォルトIfuncテンプレート351を無効にする。以下のテンプレート352の例は、「SetErrorMode」と名づけられた特定のAPIに対する固定コードを作る。[Efunc]
0003641430.tif 000009
EFuncテンプレートは、APIに対する特注書込みコードのための機能を備えており、その上、API変更に対してのローバスト性を抑制している。勿論、そのようなAPIに対するコードは、単に、そのEfuncテンプレートを書換えるだけで、いつでも書換えることができる。
【００２８】
タイプ（Types）テンプレート353は、特定されたタイプの名前に適合する、各パラメータつまり引数に対するサンク340を作り出す。タイプ・テンプレートは、新しいAPIsに自動的にそれらを適用するジェネレータ330において力を発揮する。以下の例を考察されたい。
【００２９】
0003641430.tif 000010
【００３０】
0003641430.tif 000011
【００３１】
これら2つのテンプレートによって、C言語のLPSTRデータタイプであるAPI311は、デフォルトIFuncテンプレートに対するIFuncコードに加え、特殊目的タイプのコードを自動的に受入れる。例えば、上述した「FindWindowA」のAPIは、ここで、
0003641430.tif 000012
に拡張する。
【００３２】
コード・テンプレート354は、マクロのように機能する。これは、他の多くのテンプレートと共通にすることが可能なコードを含んでおり、これらのテンプレートにおける名前によって参照される。例えば、以下の行
0003641430.tif 000013
が、異なるテンプレート351、352、又は353において何度の生じる場合には、その行は、「serrm」というような名前のコード・テンプレートに置換えることができる。次に、上記例のように参照されたテンプレートは、その行を、マクロの名前、例えば、「[@serrm]」によって、単に置換える。そして、既存のCマクロ機能は、その名前をコードに置換えるが、勿論、Cマクロは、この例よりもずっと複雑である。
上記テンプレートは、C言語で書かれたのもとして示されたが、それらは、言語が何であるかに無関係である。テンプレート350は、C＋＋、アセンブリ言語、或いは他の望ましい形式のコードを生成できる。
【００３３】
図4は、図3の翻訳コード・ジェネレータ330によって実行されるステップ400を記載している。ジェネレータは、APIの再生を必要とするオペレーティング・システム230又は他のエンティティの全集合体に対し、401において作動される。その終末402において、API翻訳モジュールのソース・コード・ファイル340の全セットは、同一層において同期化されており、エミュレータ240のAPI翻訳部（「サンク」層）を共に形成する、図2のオブジェクト・コード・モジュール260のセットに、既存の形態でコンパイルされることが可能である。
【００３４】
ブロック410は、OS230に属する全てのDLLs254を走査し、再生を必要とするAPIs（図2における261、262、−−−）のセットを確認する。これらのAPIの名前は、先に説明したように、各DLLのエクスポート・テーブル314及びインポート.LIBファイル321内に存在する。（技術的な挿話として、原タイプのエクスポートの源は、インポート.LIBである。しかし、それらの多くは、名前の付けられていない序数、又は名前を付け直されたC機能である可能性がある。タイプに関する情報を得るため、ジェネレータ330は、各APIを実行する原機能の名前を再構築しなくてはならない。従って、このジェネレータは、時には、エクスポートの名前を機能の名前に戻すようにマップ化しなくてはならない。）次に、ステップ403は、処理するために、順次、セットの中から最新のAPIを選定する。
【００３５】
ステップ420では、例外テンプレート名のリストにおける既存のテーブル調査機能によって、例外テンプレート352を手に入れるように、最新のAPIを確認する。このようなテンプレートが存在する場合には、ステップ421で、関連するEFunkテンプレートにアクセスし、ステップ422で、そのソース・コードを、そのAPIに対するサンク・ファイル340に置く。
最新のAPIが、正常なAPIである場合には、ステップ430で、そのエクスポートされた機能全ての名前を抽出するために、そのヘッダ・ファイル313のエクスポート・テーブル313を読取る。上述したように、ステップは、これらの機能に対するEFuncテンプレートを拡張する。ステップ431で、最新のAPIのエクスポートされた機能が全て抽出されると、出口432は、次のステップに進む。
【００３６】
ステップ440で、最新のAPIのパラメータ（引数）全体を通して反復され、最新のパラメータとしての１つが順次選定される。ステップ441で、このパラメータのタイプに対するタイプ・テンプレートが存在すると、次に、ステップ442で、このテンプレートのソース・コードが、モジュール340に置かれるため、APIは、その引数のタイプを正しく処理することになる。大半のタイプ・テンプレートは、あるパラメータを異なる値に置換える。しかし、タイプ・テンプレートは、パラメータの範囲を有効化するような、他の機能を実行することができる。全てのタイプ・テンプレートが処理された時、制御は出口443を通過する。
【００３７】
ステップ450で、図3のコード・テンプレート354が処理される。コード・テンプレートの名前が、テンプレート処理ステップ422、432．又は442において、（マクロの名前として）現れる際は、常に、破線451が、ステップ450を呼出し、特定の名前を付けられたコード・テンプレートが拡張されると共に、このコードを、呼出しているテンプレートに戻す。
ステップ450は、実際には、サンクのソース・コード・ファイル340が、オブジェクト・コード・モジュール260に一般的な形でコンパイルされる後に生じる可能性がある。
【００３８】
上記説明は例示を意図したもので、限定的なものではないことを理解すべきである。本発明は、複数のプラットフォームから、ただ１つのインターフェースが相反する場合のインターフェース実行させるために使用することができる。更に、適合するテンプレートは、多くの異なる形態で、例えば、望ましいテンプレートを直接的に確認するインターフェースにおけるフィールドを持つことによって、行うことが可能である。他の多くの実施形態が存在することは、上記説明を検討すれば、当業者にとって明らかなことであろう。従って、本発明の範囲は、請求の範囲を参照するとともに、その請求範囲に許された均等範囲を考慮することによって決定されるべきである。
【図面の簡単な説明】
【図１】  図１は、本発明を実施することが可能なコンピュータシステムのブロック図である。
【図２】  図2は、本発明がユーティリティーを見出す、複数プラットフォームのエミュレーション環境における上位層のブロック図である。
【図３】  図3は、本発明による翻訳ユーティリティーを、その入出力とともに示す上位層のブロック図である。
【図４】  図４は、図3のトランスレータのオペレーションを示す流れ図である。
【図１】
0003641430.tif 000014
【図２】
0003641430.tif 000015
【図３】
0003641430.tif 000016
【図４】
0003641430.tif 000017