(57)【特許請求の範囲】
【請求項１】
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを、前記移植元ＯＳと異なる移植先ＯＳ上で動作させるラッパープログラムであって、
前記ラッパープログラムは、前記移植元ＡＰＩのエラー条件情報と、前記移植元ＡＰＩが当該エラー条件情報に該当した場合に前記移植元ＡＰＩの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース（以下、ＤＢ）を参照可能であり、
前記ラッパープログラムは、
前記アプリケーションプログラムから前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩが前記移植元エラー条件ＤＢの前記エラー条件情報に該当するか否かを判定し、該当する場合に前記移植元ＯＳに対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、
該当しない場合に前記移植元ＡＰＩに対応する前記移植先ＯＳの移植先ＡＰＩを呼び出すＡＰＩ変換工程とを、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。
【請求項２】
請求項１において、
前記ラッパープログラムは、前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、
前記移植元エラー条件ＤＢの前記エラー条件情報は、前記ステータス値に基づくエラー条件情報であり、
前記エラー判定工程は、前記ラッパー管理情報を参照して前記移植元ＡＰＩに関連するステータス値を取得し、前記移植元エラー条件ＤＢを参照して当該取得したステータス値に基づいて前記移植元ＡＰＩが前記エラー条件情報に該当するか否かを判定するラッパープログラム。
【請求項３】
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを、前記移植元ＯＳと異なる移植先ＯＳ上で動作させるラッパープログラムであって、
前記ラッパープログラムは、
前記アプリケーションプログラムからステータス値を参照する前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩに対応する移植先ＡＰＩを呼び出すことなく、前記移植先ＯＳが管理情報として更新する前記ステータス値を含むラッパー管理情報を参照し、前記移植元ＡＰＩが参照する前記ステータス値を取得し、前記アプリケーションプログラムに出力する参照ＡＰＩ処理工程を、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。
【請求項４】
プロセッサと、
メモリと、を有し、
前記メモリは、
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを動作させるＯＳであって、前記移植元ＯＳと異なる移植先ＯＳと、
前記移植元ＡＰＩのエラー条件情報と、前記移植元ＡＰＩが当該エラー条件情報に該当した場合に前記移植元ＡＰＩの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース（以下、ＤＢ）と、
前記アプリケーションプログラムから前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩが前記移植元エラー条件ＤＢの前記エラー条件情報に該当するか否かを判定し、該当する場合に前記移植元ＯＳに対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元ＡＰＩに対応する前記移植先ＯＳの移植先ＡＰＩを呼び出すＡＰＩ変換工程とを前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。
【請求項５】
プロセッサと、
メモリと、を有し、
前記メモリは、
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを動作させるＯＳであって、前記移植元ＯＳと異なる移植先ＯＳと、
前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報と、
前記アプリケーションプログラムから前記ステータス値を参照する前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩに対応する移植先ＡＰＩを呼び出すことなく、前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報を参照し、前記移植元ＡＰＩが参照する前記ステータス値を取得し、前記アプリケーションプログラムに出力する参照ＡＰＩ処理工程を前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。
【請求項６】
請求項３において、
前記ラッパー管理情報は、前記移植元ＯＳの管理情報と同じフォーマットで構築され、
前記参照ＡＰＩ処理工程は、前記移植元ＡＰＩが参照する前記移植元のＯＳと同じフォーマットの前記ステータス値を取得するラッパープログラム。
【請求項７】
請求項３において、
前記ラッパー管理情報のステータス値は、前記移植元ＯＳのステータス値の規約に合わせて修正された値であり、
前記参照ＡＰＩ処理工程は、前記移植元ＯＳのステータス値の規約に合ったステータス値を取得し前記アプリケーションプログラムに出力するラッパープログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ラッパープログラム及び集積回路装置に関する。
【背景技術】
【０００２】
従来から、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ、以下ＯＳ）やミドルウェア等のプラットフォーム上で稼働するアプリケーションプログラム（以下、アプリケーション）を開発するため、命令や関数、規約等からなるアプリケーション・プログラム・インターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ、以下ＡＰＩ）が提供されている。アプリケーションの開発者は、プログラム上での所望の機能に対応するＡＰＩを呼び出すことにより、アプリケーションに当該機能を搭載することができる。
【０００３】
あるプラットフォーム用に開発されたアプリケーションは、別のプラットフォーム上で動作できない。ただし、次の２つのいずれかの方法によって、あるプラットフォーム用に開発されたアプリケーションが、別のプラットフォームで動作可能となる。第１の方法は、アプリケーションで呼び出すＡＰＩを、移植する先のＯＳのＡＰＩに書き換える方法である。第２の方法は、アプリケーションと移植先ＯＳの間に、移植元ＡＰＩを移植先のＡＰＩに変換するラッパープログラムを設け、当該ラッパープログラムを経由して移植先のＡＰＩを呼び出す方法である。
【０００４】
第１の方法の場合、アプリケーションから直接、移植先のＯＳのＡＰＩを呼び出すため、オーバーヘッドが少なく、使用するメモリ容量も抑えられる。ただし、その反面、既に移植元ＯＳで動作実績のあるアプリケーションに対して修正を行うため、不具合が混入してしまう可能性があり、アプリケーションの検証が新たに必要になる。
【０００５】
一方、第２の方法の場合、移植元のＯＳのＡＰＩを移植先のＯＳのＡＰＩに変換するラッパー関数を用意するため、アプリケーションを修正する必要がない。ただし、その半面、アプリケーション実行時のオーバーヘッドが大きくなり消費するメモリ容量は第１の方法より大きくなる。しかしながら、動作実績のある信頼性が高いアプリケーションに変更を加える必要がないため、不具合が発生した時の問題箇所の特定が容易である。また、各ＡＰＩのラッパープログラムを用意すればよいため、アプリケーション内のＡＰＩを全て書き換える1つ目の方法よりも、工数が削減され効率的な移植が可能となる。このため、第２の方法がより用いられる（例えば、特許文献１、非特許文献１）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−２４６６９０号公報
【非特許文献】
【０００７】
【非特許文献１】パーソナルメディア株式会社「I-right/TK」「平成２３年１月３１日検索」、インターネット＜URL：http://www.t-engine4u.com/products/iright_tk.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、移植元ＯＳと移植先ＯＳ間には、各ＡＰＩの引数や戻り値のインターフェースの相違に加え、それぞれのＯＳの有するエラー値やステータス値（ＯＳモード、タスクの状態情報、メモリサイズ等）に相違がある。そのため、ラッパープログラム内で、移植元のＯＳのＡＰＩを移植先のＯＳのＡＰＩに変換しただけでは、移植先ＯＳのＡＰＩからアプリケーションに出力されるエラー値やステータス情報については同一にすることはできない。このような場合、ラッパープログラムからアプリケーションに想定しない値が出力され、アプリケーションが誤動作するという問題があった。
【０００９】
これを解決するためには、移植先と移植元、双方のＯＳの仕様を熟知したプログラマーがラッパープログラムを生成し、当該ラッパープログラム内でアプリケーションへのエラー値やステータス値に関する出力値をも移植元ＯＳの規約に合わせる必要がある。しかし、エラー値やステータス情報等に関するアプリケーションへの出力値を元ＯＳの規約に合わせるための変換をもラッパープログラムで行うこととすると、ラッパープログラムでの変換処理、移植先のＯＳのＡＰＩの呼び出し、および呼び出されたＡＰＩでの変換処理結果に基づく処理が発生するのでオーバーヘッドが大きくなり効率が悪い。
【００１０】
そこで、本発明は、移植元のＯＳの規約に合わせた出力値を効率的にアプリケーションプログラムに出力するラッパープログラム及び集積回路装置を提供することにある。
【課題を解決するための手段】
【００１１】
第１の側面は、移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを、前記移植元ＯＳと異なる移植先ＯＳ上で動作させるラッパープログラムであって、
前記ラッパープログラムは、前記移植元ＡＰＩのエラー条件情報と、前記移植元ＡＰＩが当該エラー条件情報に該当した場合に前記移植元ＡＰＩの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース（以下、ＤＢ）を参照可能であり、
前記ラッパープログラムは、
前記アプリケーションプログラムから前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩが前記移植元エラー条件ＤＢの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、
該当しない場合に前記移植元ＡＰＩに対応する前記移植先ＯＳの移植先ＡＰＩを呼び出すＡＰＩ変換工程とを、コンピューターに実行させる。
【発明の効果】
【００１２】
第１の側面によれば、移植元のＯＳの規約に合わせた出力値を効率的にアプリケーションプログラムに出力する。
【図面の簡単な説明】
【００１３】
【図１】本実施の形態例における集積回路装置の一例を表す図である。
【図２】異なるＯＳ間でのアプリケーションの移植方法を説明する図である。
【図３】ラッパープログラムの基本動作を表す図である。
【図４】従来のラッパープログラムと移植先ＯＳの処理を説明するフローチャート図である。
【図５】管理情報の一例を表す図である。
【図６】図４のフローチャート図のエラー判定処理Ｓ１２を表すフローチャート図である。
【図７】アプリケーションの処理の一例を表すフローチャート図である。
【図８】第１の実施の形態例におけるラッパープログラムと移植先ＯＳの処理の流れを説明するフローチャート図である。
【図９】第２の実施の形態例におけるラッパープログラムと移植先ＯＳの処理の流れを説明するフローチャート図である。
【図１０】ラッパープログラムの一例を示す図である。
【図１１】第３の実施の形態例におけるラッパープログラムと移植先ＯＳの処理の流れを説明するフローチャート図である。
【図１２】ラッパープログラム用の管理情報が移植先ＯＳによって生成、更新される例を表すフローチャート図である。
【図１３】参照用ＡＰＩに対応するラッパープログラムの具体例を表す図である。
【図１４】メモリプールの管理対象のメモリ領域を表す図である。
【図１５】参照ＡＰＩ関数を呼び出すアプリケーションの処理の一例を表すフローチャート図である。
【図１６】第４の実施の形態例におけるラッパープログラムと移植先ＯＳの処理の流れを説明するフローチャート図である。
【図１７】移植先ＯＳによってラッパープログラム用の管理情報が生成、更新される例を表すフローチャート図である。
【発明を実施するための形態】
【００１４】
以下、図面にしたがって本発明の実施の形態について説明する。ただし、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。
【００１５】
図１は、本実施の形態例における集積回路装置１０の一例を表す図である。同図において、集積回路装置１０は、プロセッサ１１とＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２とプログラムメモリ１３とを有する。また、プログラムメモリ１３は、オペレーティングシステム（以下、移植先ＯＳ）３０、アプリケーションプログラム（以下、アプリケーション）３１、ラッパープログラム３２、移植先ＯＳのエラー条件データベース（以下、ＤＢ）３３、移植元ＯＳのエラー条件ＤＢ５３を有する。集積回路装置１０は、移植先ＯＳ３０によって制御される。
【００１６】
図１のアプリケーション３１は、移植元ＯＳが備えるアプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有し、移植元ＯＳにおいて動作検証済みのアプリケーションである。ラッパープログラム３２は、当該アプリケーション３１を、移植先ＯＳ３０で動作可能にするためのプログラムである。プログラムメモリ１３が有するラッパープログラム３２、移植元ＯＳのエラー条件ＤＢ３３、及び、ＲＡＭ１２が有する移植先ＯＳの管理情報２１、ラッパープログラム用の管理情報２２の詳細については、後述する。
【００１７】
図２は、異なるＯＳ間におけるアプリケーション３１の２つの移植方法を説明する図である。なお、同図の移植元ＯＳ５０及び移植先ＯＳ３０とは、Ｔ−ＫｅｒｎｅｌやＩＴＲＯＮ（Ｉｎｄｕｓｔｒｉａｌ ＴＲＯＮ）等の組み込み向けのリアルタイムＯＳであってもよいし、ＬｉｎｕｘやＷｉｎｄｏｗｓ（登録商標）等の汎用ＯＳであってもよい。
【００１８】
図２（Ａ）に示される第１の移植方法は、アプリケーション３１が有する移植元ＯＳ５０のＡＰＩを、移植先ＯＳ３０のＡＰＩに置き換えてプログラムし直す方法である。この方法では、移植元ＯＳ５０で検証済みのアプリケーション３１に変更が加えられることにより、新たに不具合が作りこまれる可能性を有する。
【００１９】
そして、図２（Ｂ）に示される第２の移植方法は、移植先ＯＳ３０上でラッパープログラム３２を介してアプリケーション３１を動作させる方法である。この方法では、アプリケーション３１から移植元ＯＳ５０のＡＰＩが呼び出された時、ラッパープログラム３２の有するＡＰＩと同名の関数を介して、当該ＡＰＩに対応する移植先ＯＳ３０のＡＰＩが呼び出され処理される。これにより、アプリケーション３１自体に変更を加えることなく移植先ＯＳ３０上で動作可能になり、移植や検証に要する工数が抑えられると共に、動作時に不具合が発生した場合の箇所の特定が容易になる。
【００２０】
このため、図２（Ｂ）に示される第２の移植方法が用いられることが多い。本実施の形態例におけるラッパープログラム３２は、図２（Ｂ）に示されるラッパープログラム３２に関する。しかし、ラッパープログラム３２は、後述する課題を有する。課題を説明する前に、まず、前提となるラッパープログラム３２の基本動作について説明する。
【００２１】
図３は、ラッパープログラム３２の基本動作を説明する図である。この例において、アプリケーション３１は、移植元ＯＳ５０のＡＰＩである関数ｔｅｒ＿ｔｓｋを呼び出すコードを有する。関数は、当該関数の処理で使用される引数ｐａｒ１と、その処理結果が出力される戻り値（例えば、ｅｒｃｄ）を有し、引数の数や、戻り値の有無は関数によって異なる。同図の関数ｔｅｒ＿ｔｓｋは、引数ｐａｒ１（例えば、ｔｓｋｉｄ）で指定されたタスクを終了させる関数であり、プログラムのコード上で「戻り値＝ｔｅｒ_ｔｓｋ（引数）；」のように記述される。同図の例において、引数ｐａｒ１には、終了対象のタスクを示す正の識別値を有するｔｓｋｉｄという変数が指定される。そして、戻り値にはｅｒｃｄという変数が指定され、例えば、変数ｅｒｃｄにマイナスの値が出力された場合、この関数でエラーが発生したことを表す。
【００２２】
移植元のＯＳ５０でアプリケーション３１が動作する場合、図３の左部のように、アプリケーション３１から関数ｔｅｒ＿ｔｓｋが呼び出されると、移植元ＯＳ５０のライブラリから関数ｔｅｒ＿ｔｓｋが呼び出され処理が行われる（ａ１）。そして、その処理結果が戻り値ｅｒｃｄとして、アプリケーション３１に出力される（ａ２）。
【００２３】
一方、移植先ＯＳ３０上でアプリケーション３１が動作する場合、図３の右部のように、ラッパープログラム３２を介して関数の処理が行われる。ラッパープログラム３２は、移植元ＯＳ５０のＡＰＩと同名の関数ｔｅｒ＿ｔｓｋを有する。そして、ラッパープログラム３２のｔｅｒ＿ｔｓｋ関数内で、移植元ＯＳ５０のＡＰＩ関数ｔｅｒ＿ｔｓｋに対応する移植先ＯＳのＡＰＩ関数ｔｅｒ＿ｔｓｋＸと「ｒｅｔｕｒｎ ｅｒｃｄＸ；」を呼び出す。これにより、ラッパープログラム３２を介して（ｂ１）関数ｔｅｒ＿ｔｓｋＸが呼び出され（ｂ２）、移植先ＯＳ３０によって関数ｔｅｒ＿ｔｓｋＸの処理が行われる。そして、その処理結果として出力された戻り値ｅｒｃｄＸが（ｂ３）、アプリケーション３１に出力される（ｂ４）。
【００２４】
ただし、移植元ＯＳ５０のＡＰＩと、移植先ＯＳ３０のＡＰＩとではインターフェースが異なる場合がある。この例では、移植元ＯＳ５０の関数ｔｅｒ＿ｔｓｋは引数が１つ（ｐａｒ１）であるのに対し、移植先ＯＳの関数ｔｅｒ＿ｔｓｋＸは２つ（ｐａｒ２、ｐａｒ３）である。例えば、関数ｔｅｒ＿ｔｓｋＸの１番目の引数ｐａｒ２には、移植元ＯＳ５０の関数ｔｅｒ＿ｔｓｋと同じ終了対象のタスクが指定され、２番目の引数ｐａｒ３にはタスクの強制終了の有無が指定される。このように、ＯＳによってＡＰＩのインターフェースが異なる場合、ラッパープログラム３２は、移植元ＯＳ５０のＡＰＩの処理内容と実質的に同じになるように、移植先ＯＳ３０のＡＰＩを呼び出す。この例では、関数ｔｅｒ＿ｔｓｋＸの２番目の引数ｐａｒ３に、強制終了無を示す「０」が指定される。
【００２５】
また、移植元ＯＳ５０のＡＰＩと、移植先ＯＳ３０のＡＰＩとでは、インターフェースに加えて、戻り値として出力されるエラー値についても、規約が相違する場合がある。例えば、移植元ＯＳ５０のＡＰＩ関数ｔｅｒ＿ｔｓｋでは、エラーが発生した場合、戻り値ｅｒｃｄとして「−１〜−１０」のいずれかのエラー値が出力されるのに対し（図３のａ２）、移植先ＯＳ３０のＡＰＩ関数ｔｅｒ＿ｔｓｋＸでは、エラーが発生した場合、戻り値ｅｒｃｄＸとして「−１１〜−２０」のいずれかのエラー値が出力される（図３のｂ３、ｂ４）。
【００２６】
これによると、アプリケーション３１が移植元ＯＳ５０上で動作する場合、エラー発生時に、当該移植元ＯＳ５０のエラー値の規約に基づいて、−１〜−１０のいずれかのエラー値が出力される。それに対して、アプリケーション３１が移植先ＯＳ３０上で動作する場合、エラーが発生時に、当該移植先ＯＳ３０のエラー値の規約に基づいて、−１１〜−２０のいずれかのエラー値が出力される。このように、ＯＳのエラー値の規約が相違する場合、アプリケーション３１が移植元ＯＳ５０、移植先ＯＳ３０のいずれのＯＳで動作するかによって、ＡＰＩからアプリケーション３１に出力される戻り値が異なってしまうことがある。
【００２７】
そして、アプリケーション３１は、ＡＰＩの戻り値に基づいて後続の処理を制御することが多い。また、アプリケーション３１は、移植元ＯＳ５０のエラー値の規約に基づいてプログラムミングされている。そのため、アプリケーション３１が移植先ＯＳ３０上で動作しＡＰＩから当該移植先ＯＳ３０の規約に基づいたエラー値が出力される場合、アプリケーション３１の処理が意図したとおりに制御されず適切な処理が行われない。このように、ラッパープログラム３２は、アプリケーション３１が移植先ＯＳ３０上で動作する場合についても、移植元ＯＳ５０と同じ規約に基づく戻り値を出力させたいという課題を有する。
【００２８】
［第１の実施の形態例］
ここで、第１の実施の形態例のラッパープログラム３２の処理を説明する前に、従来のラッパープログラム３２及び移植先ＯＳ５０のより詳細な処理の流れについて、フローチャート図に基づいて説明する。
【００２９】
図４は、従来のラッパープログラム３２と移植先ＯＳ３０の詳細な処理の流れを説明するフローチャート図である。同図において、点線で囲む処理（Ｓ１０、Ｓ１１）は従来のラッパープログラム、その他の処理（Ｓ１２〜Ｓ１４）は移植先ＯＳ３０の処理を表す。図３で前述したとおり、アプリケーション３１から移植元ＯＳ５０のＡＰＩが呼び出されると（Ｓ１０）、ラッパープログラム３２の有する同名の関数を介して、移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩが呼び出される（Ｓ１１）。
【００３０】
続いて、移植先ＯＳ３０は、呼び出された移植先ＯＳ３０のＡＰＩの処理に当たり、移植先ＯＳのエラー条件ＤＢ３３や管理情報２１を参照して、当該ＡＰＩが処理可能か否かの判定を行う（Ｓ１２）。ここでは、ＡＰＩ関数の引数の形式やその値の範囲、ＯＳの状態等に基づいて、当該ＡＰＩが処理可能であるか否かが判定される。ここで、工程Ｓ１２のエラー判定処理について説明する前に、当該エラー判定処理で参照される移植先ＯＳのエラー条件ＤＢ３３、及び、管理情報２１について説明する。
【００３１】
移植先ＯＳのエラー条件ＤＢ３３とは、移植先ＯＳ３０の各ＡＰＩのエラー条件情報と、当該ＡＰＩがエラー条件に該当した場合のエラー値を有するＤＢであり、例えば、関数マクロ等で記述される。移植先ＯＳのエラー条件ＤＢ３３は、例えば、ＡＰＩ関数ｔｅｒ＿ｔｓｋＸについて、正の値が指定されるべき引数ｔｓｋｉｄにマイナス値が指定された場合に所定のエラー値（本実施の形態例では、例えば−１１）を、引数の数が不足している場合に所定のエラー値（本実施の形態例では、例えば−１２）を出力する等の情報を有する。
【００３２】
そして、移植先ＯＳの管理情報２１とは、ＯＳ上の各タスクの動作状態やＩＤ情報、メモリプールのサイズ情報、モード情報等のＯＳの状態を表すステータス値を有する情報である。各ステータス値は、主にＡＰＩの処理時に更新され、常に最新の状態に更新される。また、前述した移植先ＯＳのエラー条件ＤＢ３３は、ステータス値に基づくエラー条件情報も有する。例えば、関数ｔｅｒ＿ｔｓｋＸに関して、引数ｔｓｋｉｄによって指定された終了対象タスクの動作状態を示すステータス値が非動作状態を示す場合に、所定のエラー値（本実施の形態例では、例えば−１３）を出力する等の情報である。
【００３３】
図５は、管理情報の一例を表す図である。同図の（Ａ）に示されるのは移植先ＯＳの管理情報２１であり、（Ｂ）に示されるのは移植元ＯＳの管理情報５２である。同図の（Ａ）のように、移植先ＯＳの管理情報２１は、例えば、ＯＳＩＤ情報ｉｄや各タスクの動作状態ｔｓ、メモリプールのサイズ情報ｍｚ、ｆｚ、モード情報ｍｄ等を表すステータス値を有する。同図（Ｂ）の移植元ＯＳの管理情報５２については、第３、４の実施の形態例において後述する。
【００３４】
図６は、図４の工程Ｓ１２のエラー判定処理を表すフローチャート図である。具体的に、移植先ＯＳ３０は、図５のようなＯＳの管理情報２１を参照して、移植先ＯＳ３０のＡＰＩに関連するステータス値を取得する（Ｓ１６）。移植先ＯＳ３０は、例えば、関数ｔｅｒ＿ｔｓｋＸの場合、移植先ＯＳ３０は、図５の移植先ＯＳの管理情報２１を参照して、引数ｔｓｋｉｄに指定された終了対象のタスクの動作状態を示すステータス値ｔｓを取得する。続いて、移植先ＯＳ３０は、取得したステータス値に基づいて移植先ＯＳのエラー条件ＤＢ３３を参照し、ＡＰＩがエラー条件に該当するか否かを判定する。なお、移植先ＯＳ３０は、当該ＡＰＩに関連するステータス値がある場合にのみ、管理情報２１を参照すればよい。このように、移植先ＯＳ３０は、当該ＯＳの管理情報２１と、エラー条件ＤＢ３３とを参照することにより、当該移植先ＯＳ３０のＡＰＩが処理可能か否かを判定する。
【００３５】
図４のフローチャート図に戻り、エラー判定の結果、エラー条件に該当する場合（Ｓ１３のＹＥＳ）、移植先ＯＳ３０は、エラー条件ＤＢ３３に基づいて、エラー条件に対応するエラー値を戻り値としてラッパープログラム３２に出力する。一方、エラー条件に該当しない場合（Ｓ１３のＮＯ）、移植先ＯＳ３０は、当該ＡＰＩの処理を行い、その処理結果を戻り値として、ラッパープログラム３２に出力する（Ｓ１４）。そして、戻り値がラッパープログラム３２を介してアプリケーション３１に出力される。このようにして、従来のラッパープログラム３２は、移植元ＯＳ５０のＡＰＩを呼び出すコードを有するアプリケーション３１の移植先ＯＳ３０上での動作を可能にする。
【００３６】
しかしながら、図３で前述したとおり、移植元ＯＳ５０と移植先ＯＳ３０とでは、ＡＰＩの処理結果として出力されるエラー値の規約が異なることがある。つまり、同じエラー条件に該当する場合であっても、移植元ＯＳ５０のＡＰＩと、対応する移植先ＯＳ３０のＡＰＩとでは、出力するエラー値が異なることがある。これにより、アプリケーション３１が移植先ＯＳ３０上で動作する場合、アプリケーション３１の処理が不定になるが、その例をフローチャート図に基づいて説明する。
【００３７】
図７は、アプリケーション３１の処理の一例を表すフローチャート図である。アプリケーション３１が、例えば、移植元ＯＳ５０の関数ｔｅｒ＿ｔｓｋを呼び出すと（Ｓ１）、ラッパープログラム３２を介して移植先ＯＳの関数ｔｅｒ＿ｔｓｋＸが移植先ＯＳ３０で処理され（ｂ１〜ｂ３）、その処理結果が戻り値としてアプリケーション３１に出力される（Ｓ２、ｂ４）。続いて、アプリケーション３１は、その戻り値が所定のエラー値であるか否かを判定する（Ｓ３）。
【００３８】
この例において、工程Ｓ３において、引数に不正な値が指定された場合のエラー値が出力された場合に（Ｓ３のＹＥＳ）、エラー処理（Ｓ４）に遷移するものとする。移植元ＯＳ５０では、関数ｔｅｒ＿ｔｓｋに引数に不正な値が指定された場合、当該移植元ＯＳ５０の規約に基づいてエラー値−１が出力される。そのため、この例において、工程Ｓ３では戻り値が−１であるか否かが判定される。
【００３９】
しかしながら、移植先ＯＳ３０では、関数ｔｅｒ＿ｔｓｋＸについて引数に不正値が指定された場合、当該移植先ＯＳ３０の規約に基づいて−１１が出力される。そのため、アプリケーション３１が移植先ＯＳ３０上で動作する場合、引数に不正な値が指定されたにもかかわらずエラー値が−１とは異なるため、エラー処理（Ｓ４）に遷移しない。このように、アプリケーション３１が移植先ＯＳ３０上で動作する場合、ＯＳによるエラー値の規約の相違によって移植元ＯＳ５０上で動作する場合と処理が異なってしまう。
【００４０】
そこで、第１の実施の形態例におけるラッパープログラム３２は、アプリケーション３１から移植元ＯＳ５０のＡＰＩが呼び出された時に、移植元ＯＳのエラー条件ＤＢ５３を参照し、移植元ＡＰＩが移植元エラー条件ＤＢ５３のエラー条件情報に該当するか否かを判定し、該当する場合に対応するエラー情報をアプリケーション３１に出力する。また、エラー条件情報に該当しない場合、ラッパープログラム３２は、当該移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す。
【００４１】
図８は、第１の実施の形態例におけるラッパープログラム３２と移植先ＯＳ３０の処理の流れを説明するフローチャート図である。図８は、従来のラッパープログラムの処理を表す図４に対応する。図８において、点線で囲む処理（Ｓ２０〜Ｓ２４）はラッパープログラム３２、その他の処理（Ｓ２５〜Ｓ２８）は移植先ＯＳ３０の処理を表す。本実施の形態例におけるラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３を有し、移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す前に、移植元ＯＳ５０のＡＰＩについてエラー条件ＤＢ５３を参照してエラー判定を行う。そのため、ラッパープログラム３２は、エラー条件に該当する場合、移植先ＯＳ３０のＡＰＩの呼び出しを不要にして処理を高速にすると共に、アプリケーションへの移植元ＯＳ５０の規約に基づくエラー値の出力を可能にする。以下、その点について具体的に説明する。
【００４２】
移植元ＯＳのエラー条件ＤＢ５３とは、移植元ＯＳ５０の各ＡＰＩのエラー条件情報と、当該ＡＰＩがエラー条件に該当した場合のエラー値を有するＤＢである。移植元ＯＳのエラー条件ＤＢ５３は、例えば、関数ｔｅｒ＿ｔｓｋについて、正の値が指定されるべき引数ｔｓｋｉｄにマイナス値が指定された場合に所定のエラー値（本実施の形態例では、例えば−１）を、引数の数が不足している場合に所定のエラー値（本実施の形態例では、例えば−２）を、引数ｔｓｋｉｄに指定された終了対象のタスクの動作状態を示すステータス値が非動作状態を示す場合に所定のエラー値（本実施の形態例では、例えば−３）を出力する等の情報を有する。
【００４３】
一方、前述したとおり、移植先ＯＳのエラー条件ＤＢ３３は、関数ｔｅｒ＿ｔｓｋＸについて、例えば、引数ｔｓｋｉｄにマイナス値が指定された場合にエラー値−１１を、引数の数が不足している場合にエラー値−１２を、引数ｔｓｋｉｄが非動作状態を示す場合にエラー値−１３を出力する等の情報を有する。つまり、ＯＳによってエラー値の規約が異なる。
【００４４】
図８のフローチャート図において、アプリケーション３１から移植元ＯＳ５０のＡＰＩが呼び出されると（Ｓ２０、図３のｂ１）、本実施の形態例のラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３を参照して、呼び出された移植元ＯＳ５０のＡＰＩが移植元ＯＳのエラー条件３４に該当するか否か判定する（Ｓ２１）。
【００４５】
エラー条件に該当する場合（Ｓ２２のＹＥＳ）、ラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３に基づいたエラー値を戻り値としてアプリケーション３１に出力する。このため、アプリケーション３１には、移植元ＯＳ５０上で動作する場合と同じ規約に基づくエラー値が戻り値として出力される（Ｓ２３、図３のｂ４）。また、この場合、ラッパープログラム３２は、移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出さない。これにより、アプリケーション３１は、エラー条件に該当する場合、移植先ＯＳ３０のＡＰＩの呼び出しを不要にして処理を高速にすると共に、アプリケーションへの移植元ＯＳ５０の規約に基づくエラー値の出力を可能にする。
【００４６】
一方、エラー条件に該当しない場合（Ｓ２２のＮＯ）、ラッパープログラム３２は、当該ＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す（Ｓ２４、図３のｂ２）。移植先ＯＳのＡＰＩが呼び出された後の処理は（Ｓ１２〜Ｓ１５）、図４のフローチャート図と同じである。
【００４７】
図８のフローチャート図の処理を、図３に例示した関数ｔｅｒ＿ｔｓｋに基づいてより具体的に説明する。この場合、アプリケーション３１が呼び出す移植元ＯＳの関数ｔｅｒ＿ｔｓｋの引数ｔｓｋｉｄには、不正な値が指定されているものとする。
【００４８】
アプリケーション３１から関数ｔｅｒ＿ｔｓｋが呼び出されると（図８のＳ２０、図３のｂ１）、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３を参照して関数ｔｅｒ＿ｔｓｋのエラー判定を行う（Ｓ２１）。この場合、引数ｔｓｋｉｄに不正な値が指定された場合のエラー条件に該当するため（Ｓ２２のＹＥＳ）、ラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３に基づくエラー値−１をアプリケーション３１に出力する（Ｓ２３、ｂ４）。この戻り値−１は、移植元ＯＳのエラー条件ＤＢ５３に基づいていることにより、アプリケーション３１が移植元ＯＳ５０上で動作する場合と同じ値となる。これにより、アプリケーション３１は、移植先ＯＳ３０上で動作する場合であっても、移植元ＯＳ５０と同じ戻り値に基づいて判定処理を行うことができる。
【００４９】
このように、本実施の形態例のラッパープログラム３２は、アプリケーション３１から呼び出された移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す前に、移植元ＯＳのエラー条件ＤＢ５３を参照して移植元ＯＳ５０のＡＰＩのエラー判定を行う。これにより、ラッパープログラム３２は、移植元ＯＳのＡＰＩが、移植元ＯＳのエラー条件ＤＢ５３のエラー条件に該当する場合、移植元ＯＳ５０と同じ規約に基づく戻り値をアプリケーション３１に出力することができる。また、ラッパープログラム３２は、エラー条件に該当する場合、対応する移植先ＯＳ３０のＡＰＩを呼び出す前にエラー判定を行うことにより、処理を高速にすることができる。
【００５０】
このように、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳ５０と移植先ＯＳ３０のエラー情報の規約が異なる場合であっても移植元ＯＳ５０と同じ規約に基づくエラー情報を、効率的にアプリケーション３１に出力することができる。従って、移植元ＯＳ５０のエラー情報の規約に基づいてプログラミングされているアプリケーション３１に対して、移植先ＯＳ３０の規約に基づくエラー情報用の判定処理等が加えられる必要がない。また、ラッパープログラムが、移植元ＯＳのエラー条件ＤＢ５３のエラー条件に基づいてエラー判定を行うので、ラッパープログラム内に移植元ＯＳのエラー情報に関する規約を移植先ＯＳの規約に変換する仕組みを設ける必要もない。これにより、移植元ＯＳ５０で検証済みのアプリケーション３１を変更せずに移植先ＯＳ３０上で動作させることができるため、移植工数が削減される。
【００５１】
［第２の実施の形態例］
第１の実施の形態例では、ラッパープログラム３２が、移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す前に、移植元ＯＳのエラー条件ＤＢ５３を参照して移植元ＯＳ５０のＡＰＩのエラー判定を行う例を示した。第２の実施の形態例のラッパープログラム３２は、図９に示すように、さらに移植先ＯＳの管理情報２１を参照して移植元ＯＳ５０のＡＰＩのエラー判定を行う。これにより、ラッパープログラム３２は、動作環境であるＯＳ３０の状態に基づいたＡＰＩのエラー判定も行うことができる。
【００５２】
図９は、第２の実施の形態例におけるラッパープログラム３２と移植先ＯＳ３０の処理の流れを説明するフローチャート図である。図８と同様に、点線で囲む処理（Ｓ３０〜Ｓ３４）はラッパープログラム３２、その他の処理（Ｓ１２〜Ｓ１５）は移植先ＯＳ３０の処理を表す。
【００５３】
アプリケーション３１から移植元ＯＳ５０のＡＰＩが呼び出されると（Ｓ３０）、本実施の形態例のラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３に加えて移植先ＯＳの管理情報２１をも参照して、当該ＡＰＩが移植元ＯＳのエラー条件３４に該当するか否かを判定する（Ｓ３１）。エラー判定処理の流れは、図６のフローチャート図と同様である。ただし、本実施の形態例におけるラッパープログラム３２は、移植先ＯＳの管理情報２１と移植元ＯＳのエラー情報ＤＢ３４に基づいて次のようにエラー判定を行う。
【００５４】
まず、本実施の形態例におけるラッパープログラム３２は、移植先ＯＳの管理情報２１を参照して、呼び出された移植元ＯＳのＡＰＩに関連するステータス値を取得する。ラッパープログラム３２は、図５（Ａ）に示した移植先ＯＳの管理情報２１を参照して、ＡＰＩに関連する例えば、タスクの動作状態ｔｓやＯＳのモード情報ｍｄ等のステータス値を取得する。続いて、ラッパープログラム３２は、取得したステータス値に基づいて移植元ＯＳのエラー条件ＤＢ５３を参照し、ＡＰＩがエラー条件に該当するか否かを判定する。エラー判定後の処理（Ｓ３３、Ｓ３４、Ｓ１２〜Ｓ１５）は、第１の実施の形態例と同様である。
【００５５】
これにより、ラッパープログラム３２は、動作環境のＯＳ３０の状態に基づいたステータス値に基づいて、移植元ＯＳ５０のエラー値の規約に基づくエラー値をアプリケーション３１に出力することができる。続いて、図９のフローチャート図の処理を、ＡＰＩの具体例に基づいてより詳細に説明する。
【００５６】
図１０は、ラッパープログラム３２の一例を表す図である。同図の例において、アプリケーション３１−１は、移植元ＯＳ５０のＡＰＩである関数ｓｌｐ＿ｔｓｋを呼び出すコードを有する。関数ｓｌｐ＿ｔｓｋは、例えば、自タスク（ＡＰＩを発行したタスク）を待ち状態（スリープ状態：ｓｌｐ）に移行する関数であり、プログラムのコード上で「戻り値＝ｓｌｐ_ｔｓｋ（ｖｏｉｄ…引数なし）；」のように記述される。関数ｓｌｐ＿ｔｓｋは、ＯＳがディスパッチ禁止（タスクの切り替え禁止）モードの時に処理された場合にエラーとなる。また、移植元ＯＳ５０の関数ｓｌｐ_ｔｓｋに対応するラッパープログラム３２−１は、移植先ＯＳ３０のＡＰＩ関数ｓｌｐ_ｔｓｋＸを呼び出す。
【００５７】
図９に示される通り、アプリケーション３１から移植元ＯＳ５０の関数ｓｌｐ＿ｔｓｋが呼び出されると（図９のＳ３０、図１０のｃ１）、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３と移植先ＯＳの管理情報２１とを参照して関数ｓｌｐ＿ｔｓｋのエラー判定を行う（Ｓ３１）。この例において、この時、アプリケーション３１が動作する移植先ＯＳ３０はディスパッチ禁止モードであるものとする。
【００５８】
続いて、ラッパープログラム３２は、移植先ＯＳの管理情報２１を参照して、関数ｓｌｐ＿ｔｓｋに関連するステータス値である自タスクの識別値とＯＳのモード情報を取得する。この場合、ラッパープログラム３２は、移植先ＯＳの管理情報２１を参照して、ディスパッチ禁止モードを示すＯＳのモード情報を取得する。ディスパッチ禁止モードはエラー条件に該当するため（Ｓ３２のＹＥＳ）、ラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３に基づいて、当該エラー条件に対応する所定のエラー値をアプリケーション３１に出力する（図９のＳ３３、図１０のｃ２）。エラー値は、移植元ＯＳのエラー条件ＤＢ５３に基づいているため、アプリケーション３１が移植元ＯＳ５０上で動作する場合と同じである。これにより、アプリケーション３１は、移植先ＯＳ３０上で動作する場合であっても、移植元ＯＳ５０と同じ戻り値に基づいて判定処理を行うことができる。
【００５９】
このように、本実施の形態例のラッパープログラム３２は、アプリケーション３１から呼び出された移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す前に、移植先ＯＳの管理情報２１を参照して取得したステータス値に基づいて移植元ＯＳのエラー条件ＤＢ５３を参照し、動作環境であるＯＳ３０の状態に基づいた移植元ＯＳ５０のＡＰＩのエラー判定を行う。そして、ラッパープログラム３２は、エラー条件に該当する場合、移植元ＯＳのエラー条件ＤＢ５３の当該エラー条件に対応するエラー値をアプリケーション３１に出力する。
【００６０】
これにより、ラッパープログラム３２は、呼び出された移植元ＯＳ５０のＡＰＩについて、第１の実施の形態例における形式的なエラー判定に加え、動作環境である移植先ＯＳ３０の状態に基づいたエラー判定をも可能にしながら、移植元ＯＳ５０と同じ規約に基づいた戻り値をアプリケーション３１に出力することができる。
【００６１】
以上のように、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳ５０と移植先ＯＳ３０のエラー情報の規約が異なる場合であっても、移植元ＯＳ５０と同じ規約に基づくエラー情報を効率的にアプリケーション３１に出力することができる。これにより、移植元ＯＳ５０で検証済みのアプリケーション３１を変更せずに移植先ＯＳ３０上で動作させることができるため、移植工数が削減される。
【００６２】
［第３の実施の形態例］
第２の実施の形態例では、ラッパープログラム３２が、移植元ＯＳのエラー条件ＤＢ５３と移植先ＯＳの管理情報２１を参照して移植元ＯＳ５０のＡＰＩのエラー判定を行う例を示した。これに対して、第３の実施の形態例におけるラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３と共に、移植元ＯＳのステータス値の規約に合わせて、移植先ＯＳの管理情報２１に基づいて生成、更新したラッパープログラム用の管理情報２２を参照して、移植元ＯＳ５０のＡＰＩのエラー判定を行う。これにより、ラッパープログラム３２は、移植元ＯＳ５０と移植先ＯＳ３０とでステータス値の規約が相違する場合であっても、ＯＳの状態に基づいたＡＰＩのエラー判定を行うことができる。
【００６３】
前述した図５では、（Ａ）の移植先ＯＳの管理情報２１と、（Ｂ）の移植元ＯＳの管理情報５２とを表しているが、ＯＳによって各ステータス値の意味合い（規約）は相違することがある。例えば、図５の管理情報の動作状態ｔｓを例示して説明する。
【００６４】
例えば、図５（Ｂ）に示した移植元ＯＳの管理情報５２では、タスクの動作状態ｔｓを示すステータス値として、次の４つのいずれかの値を有するものとする。「停止状態＝０／動作状態＝１／動作可能状態＝２／待ち状態＝３」。それに対して、図５（Ａ）に示した移植先ＯＳの管理情報２１では、タスクの動作状態ｔｓを示す同じステータス値として、次の５つのいずれかのステータス値を有するものとする。「停止状態＝１／動作状態＝０／動作可能状態＝２／待ち状態＝３／強制待ち状態＝４」。このように、移植先ＯＳ３０と移植元ＯＳ５０とで、「停止状態」及び「動作状態」を示すステータス値が相違していると共に、移植先ＯＳの管理情報２１は、動作状態ｔｓとして移植元ＯＳ５０にない値（強制待ち状態＝４）を有する。
【００６５】
このように、移植先ＯＳ３０と移植元ＯＳ５０とでステータス値の規約が異なる場合、移植先ＯＳの管理情報２１は、移植先ＯＳ３０のステータス値の規約に基づくのに対し、移植元ＯＳのエラー条件ＤＢ５３は移植元ＯＳ５０のステータス値の規約に基づく。そのため、ラッパープログラム３２は、移植先ＯＳの管理情報２１を参照して取得したステータス値に基づいて、移植元ＯＳのエラー条件ＤＢ５３のエラー条件に該当するか否かを判定することができない。具体的に、処理対象のタスクが停止状態のときエラー条件に該当する場合、移植先ＯＳの管理情報２１によるとタスクの状態を表すステータス値が「停止状態＝１」のときにエラー条件に該当する。しかし、移植元ＯＳのエラー条件ＤＢ５３において、タスクの状態を表すステータス値が「１」の場合は動作状態を示し、エラー条件に該当しない。
【００６６】
そこで、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳの管理情報５２のステータス値の規約に合わせて修正した、移植先ＯＳの管理情報２１の各ステータス値を有するラッパープログラム用の管理情報２２を生成して、上記の課題を解消する。具体的に、ラッパープログラム３２は、上記の例において、移植元ＯＳ５０の規約に合わせて、移植先ＯＳ３０の動作状態を表すステータス値が「停止状態＝１」の場合は「０」に、「動作状態＝０」の場合は「１」に修正したラッパープログラム用の管理情報２２を生成する。また、ラッパープログラム３２は、移植元ＯＳ５０が有しないステータス値については、最も意味合いの近い値に修正する。この例において、ラッパープログラム３２は、移植元ＯＳ５０が有しない移植先ＯＳ３０のステータス値「強制待ち状態＝４」を広義の「待ち状態」と仮定し、移植元ＯＳ５０のステータス値「待ち状態＝３」に修正する。
【００６７】
図１１は、第３の実施の形態例におけるラッパープログラム３２と移植先ＯＳ３０の処理の流れを説明するフローチャート図である。同図において、点線で囲む処理（Ｓ４０〜Ｓ４５）はラッパープログラム３２、その他の処理（Ｓ１２〜Ｓ１５）は移植先ＯＳの処理を表す。
【００６８】
アプリケーション３１から移植元ＯＳ５０のＡＰＩが呼び出されると（Ｓ４０）、本実施の形態例のラッパープログラム３２は、上述したように、移植元ＯＳの管理情報５２のステータス値の規約に合わせて修正した移植先ＯＳの管理情報２１のステータス値を有するラッパープログラム用の管理情報２２を生成する（Ｓ４１）。また、既に、ラッパープログラム３２がラッパープログラム用の管理情報２２を有する場合、ラッパープログラム３２は、移植先ＯＳの管理情報２１の各ステータス値に基づいて、当該ラッパープログラム用の管理情報２２を更新する（Ｓ４１）。
【００６９】
そして、ラッパープログラム３２は、移植元ＯＳ５０のＡＰＩに関連するステータス値をラッパープログラム用の管理情報２２を参照して取得し、当該ステータス値に基づいて移植元ＯＳエラー条件ＤＢ５３を参照してＡＰＩがエラー条件に該当するか否かを判定する。エラー判定の後の処理（Ｓ４４、Ｓ４５、Ｓ１２〜Ｓ１５）は、第１の実施の形態例と同様である。
【００７０】
続いて、図１１のフローチャート図の処理を、図１０の関数ｓｔａ＿ｔｓｋの具体例に基づいて説明する。図１０の例において、アプリケーション３１−１は、移植元ＯＳ５０のＡＰＩである関数ｓｔａ＿ｔｓｋを呼び出すコードを有する。関数ｓｔａ＿ｔｓｋは、例えば、自タスク以外のタスクを動作状態に移行させる関数であり、プログラムのコード上で「戻り値＝ｓｔａ_ｔｓｋ（引数）；」のように記述される。ただし、関数ｓｔａ＿ｔｓｋは、引数に指定した対象のタスクが停止状態以外の場合にエラーとなる。また、移植元ＯＳ５０の関数ｓｔａ_ｔｓｋに対応するラッパープログラム３２−２は、移植先ＯＳ３０のＡＰＩ関数ｓｔａ_ｔｓｋＸを呼び出す。
【００７１】
アプリケーション３１から移植元ＯＳ５０の関数ｓｔａ＿ｔｓｋが呼び出されると（図１１のＳ４０、図１０のｄ１）、本実施の形態例におけるラッパープログラム３２は、ラッパープログラム用の管理情報２２の生成または更新処理を行う（Ｓ４１）。なお、この例において、この時、関数ｓｔａ＿ｔｓｋの引数ｔｓｋｉｄに指定された対象タスクは、既に動作状態であるものとする。
【００７２】
続いて、ラッパープログラム３２は、ラッパープログラム用の管理情報２２を参照して、引数ｔｓｋｉｄに指定した対象タスクの動作状態を示すステータス値（動作状態＝１）を取得する。このステータス値は、移植元ＯＳ５０の規約に基づいているため、移植元ＯＳのエラー条件ＤＢ５３において、処理対象のタスクが既に動作状態である旨のエラー条件に該当すると判定され（Ｓ４３のＹＥＳ）、対応する所定のエラー値がアプリケーション３１に出力される（Ｓ４４、図１０のｄ２）。また、このエラー値は、アプリケーション３１が移植元ＯＳ５０上で動作する場合と同じ規約に基づくエラー値である。
【００７３】
このように、本実施の形態例のラッパープログラム３２は、アプリケーション３１から呼び出された移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩを呼び出す前に、移植元ＯＳの管理情報５２におけるステータス値の規約に合わせて修正した移植先ＯＳの管理情報２１におけるステータス値を有するラッパープログラム用の管理情報２２を生成する。そして、ラッパープログラム３２は、当該ラッパープログラム用の管理情報２２を参照して取得したステータス値に基づいて、移植元ＯＳのエラー条件ＤＢ５３を参照してエラー判定を行う。そして、ラッパープログラム３２は、エラー条件に該当する場合、移植元ＯＳのエラー条件ＤＢ５３の当該エラー条件に対応するエラー値をアプリケーション３１に出力する。
【００７４】
これにより、ラッパープログラム３２は、移植先ＯＳ３０と移植元ＯＳ５０とで戻り値に加えてステータス値の規約が異なる場合であっても、移植元ＯＳ５０と同じ規約に基づくエラー情報を効率的にアプリケーション３１に出力することができる。これにより、移植元ＯＳ５０で検証済みのアプリケーション３１を変更せずに移植先ＯＳ３０上で動作させることができるため、移植工数が削減される。
【００７５】
なお、上記の例では、ラッパープログラム３２によって、ラッパープログラム用の管理情報２２を生成または更新される例について説明した。しかしながら、ラッパープログラム用の管理情報２２は、移植先ＯＳ３０によって生成、更新されてもよい。
【００７６】
図１２は、移植先ＯＳによってラッパープログラム用の管理情報２２が生成、更新される例を表すフローチャート図である。同図において、ラッパープログラム３２は、ラッパープログラム用の管理情報２２の生成、更新処理を行わない。この場合、ラッパープログラム用の管理情報２２の生成、更新処理は、エラー条件に該当せず（Ｓ５２のＮＯ、Ｓ１３のＮＯ）移植元ＯＳ５０のＡＰＩに対応する移植先ＯＳ３０のＡＰＩの処理が行われた後に（Ｓ１４）、移植先ＯＳ３０によって行われる（Ｓ５５）。
【００７７】
というのも、ステータス値は、主にＡＰＩの処理後に更新される。そのため、ＡＰＩの処理後、移植先ＯＳ３０においてラッパープログラム用の管理情報２２の生成または更新処理が行われることによって、当該管理情報２２のステータス値が常に最新の状態に更新される。
【００７８】
これにより、ラッパープログラム３２は、移植元ＯＳ５０のＡＰＩのエラー判定前に（Ｓ５１）、ラッパープログラム用の管理情報２２の生成、更新処理を行わないことにより、オーバーヘッドを抑えることができる。また、エラー条件に該当して移植先ＯＳのＡＰＩが呼び出されない場合（Ｓ５２のＹＥＳ、Ｓ１３のＹＥＳ）、ラッパープログラム用の管理情報２２の生成、更新処理が発生しないことにより、当該処理の回数が最小限に抑えられる。
【００７９】
［第４の実施の形態例］
第１から第３の実施の形態例では、アプリケーション３１からＯＳのタスクに対して処理を行うＡＰＩを呼び出す例について述べた。それに対して、第４の実施の形態例では、アプリケーション３１から、ステータス値を参照するＡＰＩ（以下、参照ＡＰＩ）を呼び出す場合について述べる。前述したとおり、ステータス値の規約はＯＳによって異なることがある。本実施の形態例におけるラッパープログラム３２は、参照ＡＰＩが呼び出された時に、効率的に、移植元ＯＳ５０と同じ規約に基づくステータス値を出力する。
【００８０】
図１３は、参照ＡＰＩを有するアプリケーション３１−２の一例を表す図である。同図の例において、アプリケーション３１−２は、移植元ＯＳ５０のＡＰＩである関数ｒｅｆ＿ｍｐｌを呼び出すコードを有する。関数ｒｅｆ＿ｍｐｌは、例えば、メモリプール（ｍｐｌ）に係るステータス値を参照する（ｒｅｆｅｒｅｎｃｅ）参照ＡＰＩであり、プログラムのコード上で「戻り値＝ｒｅｆ_ｍｐｌ（引数１、引数２）；」のように記述される。
【００８１】
関数ｒｅｆ＿ｍｐｌでは、メモリプールのメモリ領域の全体メモリサイズｍｚ、空きメモリサイズｆｚを示すステータス値が参照される。引数１（この例では、ｍｐｌｉｄ）には対象のメモリプールの識別値（例えば、正の識別値）が、引数２（この例では、＆ｐｋ_ｒｍｐｌ）には当該ＡＰＩによって参照されるステータス値を格納するメモリＭＣが指定される。同図のように、メモリＭＣは、全体メモリサイズｍｚ、空きメモリサイズｆｚを示すステータス値を格納する。関数が処理されると、処理結果を示す値が戻り値（この例では、ｅｒｃｄ）に出力されると共に、引数２＆ｐｋ_ｒｍｐｌで示されるメモリＭＣに、ステータス値である全体メモリサイズｍｚ、空きメモリサイズｆｚが格納される。
【００８２】
図１４は、メモリプールの管理対象のメモリ領域ｍｐを表す図である。メモリプールとは、ＯＳのメモリ管理機能であり、アプリケーション３１から指定されたサイズのメモリ領域の確保や、確保したメモリのメモリブロック単位の管理を行う。同図において、メモリ領域ｍｐは、管理領域メモリｃｍと５つのメモリブロックｍ１〜ｍ５を有する。図１３の関数ｒｅｆ＿ｍｐｌで参照される空きメモリサイズｆｚとは、メモリブロックｍ１〜ｍ５のうち未使用メモリブロックｍ２の総サイズを示す。
【００８３】
一方、全体メモリサイズｍｚは、移植元ＯＳ５０と移植先ＯＳ３０とでその意味合い（規約）が異なる。例えば、この例において、移植元ＯＳ５０における全体メモリサイズｍｚは管理領域メモリｃｍを含まない０ｘ５０であるのに対し、移植先ＯＳ３０における全体メモリサイズｍｚは管理領域メモリｃｍを含む０ｘ５８であるとする。
【００８４】
アプリケーション３１は、参照用ＡＰＩによって取得したステータス値に基づいて、後続の処理を制御するが、上記のようにＯＳによってステータス値の規約が相違する場合、アプリケーション３１の処理が不定となってしまう。その例をフローチャートに基づいて説明する。
【００８５】
図１５は、参照ＡＰＩを呼び出すアプリケーション３１の処理の一例を表すフローチャート図である。このアプリケーション３１が、例えば、移植元ＯＳ５０の参照ＡＰＩ関数ｒｅｆ＿ｍｐｌを呼び出すと（Ｓ５）、ラッパープログラム３２を介して対応する移植先ＯＳの関数によって取得された全体メモリサイズｍｚが取得される（Ｓ６）。次に、取得された全体メモリサイズｍｚが所定値を超えるか否かが判定される（Ｓ７）。この例において、工程Ｓ７における所定値は、移植元ＯＳ５０のステータス値の規約に基づいて、管理領域メモリｃｍを含まない全体メモリサイズｍｚを前提として設定されている。
【００８６】
しかしながら、移植先ＯＳ３０における全体メモリサイズｍｚは管理領域メモリｃｍを含む。そのため、アプリケーション３１が移植先ＯＳ３０上で動作する場合、工程Ｓ７において、管理領域メモリｃｍを含まない全体メモリサイズｍｚを前提とする所定値が、管理領域メモリｃｍを含む全体メモリサイズｍｚと比較されることになってしまう。これにより、移植元ＯＳ５０の規約に基づく全体メモリサイズｓｚであれば所定値以上にならず（Ｓ７のＮＯ）処理２に遷移する（Ｓ９）にもかかわらず、移植先ＯＳ３０の規約に基づく全体メモリサイズｍｚであるため所定値に達し（Ｓ７のＹＥＳ）、処理１（Ｓ８）に遷移することがある。
【００８７】
このように、アプリケーション３１が移植先ＯＳ３０上で動作する場合、ＯＳによるステータス値の規約の相違によって、移植先ＯＳ５０上で動作する場合と処理が異なってしまう。
【００８８】
そこで、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳ５０のステータス値の規約に合わせて修正した移植先ＯＳ３０のステータス値を有するラッパープログラム用の管理情報２２を参照して参照ＡＰＩに係るステータス値を収集する。これにより、ラッパープログラム３２は、移植元ＯＳ５０の規約に基づいたステータス値をアプリケーション３１に出力することができる。
【００８９】
図１６は、第４の実施の形態例におけるラッパープログラム３２と移植先ＯＳ３０の処理の流れを説明するフローチャート図である。同図の処理は全てラッパープログラム３２の処理である。
【００９０】
アプリケーション３１から移植元ＯＳ５０の参照ＡＰＩが呼び出されると（Ｓ６０）、本実施の形態例のラッパープログラム３２は、第３の実施の形態例と同様に、移植元ＯＳの管理情報のステータス値の規約に合わせて修正した移植先ＯＳの管理情報２１の各ステータス値を有するラッパープログラム用の管理情報２２を生成、更新する（Ｓ６１）。続いて、ラッパープログラム３２は、移植元ＯＳのＡＰＩに関連するステータス値をラッパープログラム用の管理情報２２を参照して取得し、当該ステータス値に基づいて移植元ＯＳエラー条件ＤＢ５３を参照してＡＰＩがエラー条件に該当するか否かを判定する（Ｓ６２）。
【００９１】
エラー条件に該当する場合（Ｓ６３のＹＥＳ）、第１の実施の形態例と同様にして、ラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３に基づくエラー値を戻り値としてアプリケーション３１に出力する。一方、エラー条件に該当しない場合（Ｓ６３のＮＯ）、ラッパープログラム３２は、ラッパープログラム用の管理情報２２を参照して移植元ＯＳ５０の参照ＡＰＩに係る参照情報を収集し（Ｓ６５）、アプリケーション３１に引き渡す（Ｓ６６）。
【００９２】
このように、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳ５０のＡＰＩの参照対象のステータス値を、移植先ＯＳ３０のＡＰＩを呼び出すことなくアプリケーション３１に出力することができる。
【００９３】
図１６のフローチャート図の処理を、図１３の関数ｒｅｆ＿ｍｐｌの具体例に基づいて説明する。アプリケーション３１から関数ｒｅｆ＿ｍｐｌが呼び出されると（Ｓ６０）、本実施の形態例におけるラッパープログラム３２は、ラッパープログラム用の管理情報２２を生成、更新する（Ｓ６１）。例えば、ラッパープログラム３２は、メモリプールの全体メモリサイズｍｚを、移植元ＯＳ５０の全体メモリサイズｍｚの規約に合わせて「移植先ＯＳの全体メモリサイズｍｚ−移植先ＯＳの管理領域メモリサイズｃｍ」のように修正したラッパープログラム用の管理情報２２を生成する。
【００９４】
続いて、ラッパープログラム３２は、移植元ＯＳのエラー条件ＤＢ５３及びラッパープログラム用の管理情報２２を参照して関数ｒｅｆ＿ｍｐｌのエラー判定を行う（Ｓ６２）。エラー条件に該当する場合（Ｓ６３のＹＥＳ）、第１の実施の形態例と同様に、移植元ＯＳのエラー条件ＤＢ５３に基づいて、移植元ＯＳ５０と同じ規約の戻り値がアプリケーション３１に出力される（Ｓ６４）。一方、エラー条件に該当しない場合（Ｓ６３のＮＯ）、ラッパープログラム３２は、ラッパープログラム用の管理情報２２を参照して、メモリプールの全体メモリサイズｍｚ及び空きメモリサイズｆｚを収集する（Ｓ６５）。ラッパープログラム用の管理情報２２における全体メモリサイズｍｚは管理領域サイズｃｍを含まないため、移植元ＯＳ５０と同じ規約に基づいた全体メモリサイズｍｚがアプリケーション３１に引き渡される（Ｓ６６）。
【００９５】
このように、本実施の形態例のラッパープログラム３２は、移植元ＯＳ５０の管理情報におけるステータス値の規約に合わせて修正した移植先ＯＳの管理情報２１におけるステータス値を有するラッパープログラム用の管理情報２２を生成する。そして、ラッパープログラム３２は、当該ラッパープログラム用の管理情報２２を参照して、アプリケーション３１から呼び出された移植元ＯＳの参照ＡＰＩに係るステータス値を収集する。
【００９６】
これにより、ラッパープログラム３２は、移植元ＯＳ５０と移植先ＯＳ３０とでステータス値の規約が異なる場合であっても、移植元ＯＳ５０と同じ規約に基づいたステータス値を収集し、アプリケーション３１に出力することができる。また、ラッパープログラム３２は、呼び出された参照ＡＰＩに係るステータス値を、移植先ＯＳ３０のＡＰＩを呼び出すことなくラッパープログラム用の管理情報２２を参照することによって収集可能にするため、処理を高速にすることができる。
【００９７】
なお、上記の例では、管理情報におけるステータス値の規約がＯＳによって異なる場合を例示したが、管理情報のフォーマット（管理情報におけるステータス値の配置順序やサイズ）が異なる場合にも有効である。前述した図５のとおり、同図の（Ａ）に示される移植先ＯＳの管理情報２１と、（Ｂ）に示される移植元ＯＳの管理情報５２とでは、管理情報の有するステータス値、及び、当該ステータス値の配置順序が相違している。これは、例えば、ラッパープログラム３２が管理情報をメモリに一括して取得し、当該取得したメモリから各ステータス値を参照する場合、次のような課題を有する。
【００９８】
この場合、アプリケーション３１は、例えば、参照ＡＰＩによって管理情報を１つのメモリに取得する。そして、アプリケーション３１は、移植元ＯＳ５０の管理情報の各ステータス値の配置順序やサイズに従って取得したメモリから、各ステータス値を参照する。しかしながら、移植先ＯＳ３０と移植元ＯＳ５０とで管理情報のフォーマットが異なるため、アプリケーション３１は、移植先ＯＳ５０のフォーマットに従って、メモリから各ステータス値を参照することができない。
【００９９】
そこで、ラッパープログラム３２は、移植元ＯＳ５０と同じフォーマットでラッパープログラム用の管理情報２２を構築する。これにより、アプリケーション３１は、参照ＡＰＩによって取得されたメモリ内の各ステータス値を、移植元ＯＳ５０と同じフォーマットに従って参照することができる。
【０１００】
以上のように、本実施の形態例におけるラッパープログラム３２は、移植元ＯＳ５０と移植先ＯＳ３０の管理情報の規約（各ステータス値の意味合い、及び、管理情報のフォーマット等）が相違する場合であっても、移植元ＯＳ５０と同じ規約に基づく参照値（出力値）をアプリケーション３１に引き渡すことができる。これにより、移植元ＯＳ５０で検証済みのアプリケーション３１を変更せずに移植先ＯＳ３０上で動作させることができるため、移植工数が削減される。
【０１０１】
また、第３の実施の形態例と同様、ラッパープログラム用の管理情報２２は、アプリケーション３１が動作する移植先ＯＳ３０によって生成、更新されてもよい。
【０１０２】
図１７は、移植先ＯＳ３０によってラッパープログラム用の管理情報２２が生成、更新される例を表すフローチャート図である。同図において、ラッパープログラム３２は、ラッパープログラム用の管理情報２２の生成、更新処理を行わない。この場合、ラッパープログラム用の管理情報２２の生成、更新処理は、ＡＰＩが処理される度に（Ｓ７６）、移植先ＯＳ３０によって行われる（Ｓ７７）。なお、管理情報の各ステータス値は、参照ＡＰＩの処理では更新されない。そのため、移植先ＯＳ３０は、非参照系のＡＰＩについてのみ、その処理後に（Ｓ７６）、ラッパープログラム用の管理情報２２を生成または更新する（Ｓ７７）。
【０１０３】
これにより、ラッパープログラム３２は、ラッパープログラム用の管理情報２２を生成、更新処理を行わないため、オーバーヘッドを抑えることができる。また、移植元ＯＳ５０の参照ＡＰＩが呼び出される度にラッパープログラム用の管理情報２２の生成、更新処理が発生しないことにより、当該処理の回数が最小限に抑えられる。
【０１０４】
以上の実施の形態をまとめると、次の付記のとおりである。
【０１０５】
（付記１）
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを、前記移植元ＯＳと異なる移植先ＯＳ上で動作させるラッパープログラムであって、
前記ラッパープログラムは、前記移植元ＡＰＩのエラー条件情報と、前記移植元ＡＰＩが当該エラー条件情報に該当した場合に前記移植元ＡＰＩの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース（以下、ＤＢ）を参照可能であり、
前記ラッパープログラムは、
前記アプリケーションプログラムから前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩが前記移植元エラー条件ＤＢの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、
該当しない場合に前記移植元ＡＰＩに対応する前記移植先ＯＳの移植先ＡＰＩを呼び出すＡＰＩ変換工程とを、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。
【０１０６】
（付記２）
付記１において、
前記ラッパープログラムは、前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、
前記移植元エラー条件ＤＢの前記エラー条件情報は、前記ステータス値に基づくエラー条件情報であり、
前記エラー判定工程は、前記ラッパー管理情報を参照して前記移植元ＡＰＩに関連するステータス値を取得し、前記移植元エラー条件ＤＢを参照して当該取得したステータス値に基づいて前記移植元ＡＰＩが前記エラー条件情報に該当するか否かを判定するラッパープログラム。
【０１０７】
（付記３）
付記２において、
前記ラッパー管理情報を前記エラー判定工程の前に生成または更新するラッパープログラム。
【０１０８】
（付記４）
付記２において、
前記ラッパー管理情報は、前記移植先ＡＰＩが実行された後に前記移植先ＯＳによって生成または更新されるラッパープログラム。
【０１０９】
（付記５）
付記２乃至４のいずれかにおいて、
前記ラッパー管理情報のステータス値は、前記移植元ＯＳのステータス値の規約に合わせて修正された値であり、
前記エラー判定工程は、前記移植元ＯＳのステータス値の規約に合ったステータス値に基づいて前記移植元ＡＰＩが前記エラー条件情報に該当するか否かを判定するラッパープログラム。
【０１１０】
（付記６）
付記２乃至５のいずれかにおいて、
前記アプリケーションプログラムから前記ステータス値を参照する前記移植元ＡＰＩが呼び出された時に、前記ラッパー管理情報から前記移植元ＡＰＩが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照ＡＰＩ処理工程を、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。
【０１１１】
（付記７）
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを、前記移植元ＯＳと異なる移植先ＯＳ上で動作させるラッパープログラムであって、
前記ラッパープログラムは、前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、
前記ラッパープログラムは、
前記アプリケーションプログラムから前記ステータス値を参照する前記移植元ＡＰＩが呼び出された時に、前記ラッパー管理情報から前記移植元ＡＰＩが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照ＡＰＩ処理工程を、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。
【０１１２】
（付記８）
付記７において、
前記ラッパー管理情報を前記参照ＡＰＩ処理工程の前に生成または更新するラッパープログラム。
【０１１３】
（付記９）
付記７において、
前記ラッパー管理情報は、前記移植先ＯＳの移植先ＡＰＩが実行された後に前記移植先ＯＳによって生成または更新されるラッパープログラム。
【０１１４】
（付記１０）
付記７乃至９のいずれかにおいて、
前記ラッパー管理情報は、前記移植元ＯＳの管理情報と同じフォーマットで構築され、
前記参照ＡＰＩ処理工程は、前記移植元ＡＰＩが参照する前記移植元のＯＳと同じフォーマットの前記ステータス値を取得するラッパープログラム。
【０１１５】
（付記１１）
付記７乃至１０のいずれかにおいて、
前記ラッパー管理情報のステータス値は、前記移植元ＯＳのステータス値の規約に合わせて修正された値であり、
前記参照ＡＰＩ処理工程は、前記移植元ＯＳのステータス値の規約に合ったステータス値を取得し前記アプリケーションプログラムに出力するラッパープログラム。
【０１１６】
（付記１２）
プロセッサと、
メモリと、を有し、
前記メモリは、
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを動作させるＯＳであって、前記移植元ＯＳと異なる移植先ＯＳと、
前記移植元ＡＰＩのエラー条件情報と、前記移植元ＡＰＩが当該エラー条件情報に該当した場合に前記移植元ＡＰＩの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース（以下、ＤＢ）と、
前記アプリケーションプログラムから前記移植元ＡＰＩが呼び出された時に、前記移植元ＡＰＩが前記移植元エラー条件ＤＢの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元ＡＰＩに対応する前記移植先ＯＳの移植先ＡＰＩを呼び出すＡＰＩ変換工程とを前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。
【０１１７】
（付記１３）
付記１２において、
前記メモリは、前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報を有し、
前記移植元エラー条件ＤＢの前記エラー条件情報は、前記ステータス値に基づくエラー条件情報であり、
前記エラー判定工程は、前記ラッパー管理情報を参照して前記移植元ＡＰＩに関連するステータス値を取得し、前記移植元エラー条件ＤＢを参照して当該取得したステータス値に基づいて前記移植元ＡＰＩが前記エラー条件情報に該当するか否かを判定する集積回路装置。
【０１１８】
（付記１４）
プロセッサと、
メモリと、を有し、
前記メモリは、
移植元オペレーティングシステム（以下、ＯＳ）の移植元アプリケーション・プログラム・インターフェース（以下、ＡＰＩ）を呼び出すコードを有するアプリケーションプログラムを動作させるＯＳであって、前記移植元ＯＳと異なる移植先ＯＳと、
前記移植先ＯＳが管理情報として更新するステータス値を含むラッパー管理情報と、
前記アプリケーションプログラムから前記ステータス値を参照する前記移植元ＡＰＩが呼び出された時に、前記ラッパー管理情報から前記移植元ＡＰＩが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照ＡＰＩ処理工程を前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。
【符号の説明】
【０１１９】
１１：プロセッサ、１２：ＲＡＭ、２１：移植先ＯＳの管理情報、２２：ラッパープログラム用の管理情報、１３：プログラムメモリ、３０：オペレーティングシステム（移植先ＯＳ）、３１：アプリケーションプログラム、３２：ラッパープログラム、３３：移植先ＯＳのエラー条件ＤＢ、５３：移植元ＯＳのエラー条件ＤＢ、１０：集積回路装置
【図１】
0005716469.tif 000002
【図２】
0005716469.tif 000003
【図３】
0005716469.tif 000004
【図４】
0005716469.tif 000005
【図５】
0005716469.tif 000006
【図６】
0005716469.tif 000007
【図７】
0005716469.tif 000008
【図８】
0005716469.tif 000009
【図９】
0005716469.tif 000010
【図１０】
0005716469.tif 000011
【図１１】
0005716469.tif 000012
【図１２】
0005716469.tif 000013
【図１３】
0005716469.tif 000014
【図１４】
0005716469.tif 000015
【図１５】
0005716469.tif 000016
【図１６】
0005716469.tif 000017
【図１７】
0005716469.tif 000018