移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを、前記移植元OSと異なる移植先OS上で動作させるラッパープログラムであって、前記ラッパープログラムは、前記移植元APIのエラー条件情報と、前記移植元APIが当該エラー条件情報に該当した場合に前記移植元APIの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース以下、DBを参照可能であり、前記ラッパープログラムは、前記アプリケーションプログラムから前記移植元APIが呼び出された時に、前記移植元APIが前記移植元エラー条件DBの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元APIに対応する前記移植先OSの移植先APIを呼び出すAPI変換工程とを、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。請求項1において、前記ラッパープログラムは、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、前記移植元エラー条件DBの前記エラー条件情報は、前記ステータス値に基づくエラー条件情報であり、前記エラー判定工程は、前記ラッパー管理情報を参照して前記移植元APIに関連するステータス値を取得し、前記移植元エラー条件DBを参照して当該取得したステータス値に基づいて前記移植元APIが前記エラー条件情報に該当するか否かを判定するラッパープログラム。移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを、前記移植元OSと異なる移植先OS上で動作させるラッパープログラムであって、前記ラッパープログラムは、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、前記ラッパープログラムは、前記アプリケーションプログラムから前記ステータス値を参照する前記移植元APIが呼び出された時に、前記ラッパー管理情報から前記移植元APIが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照API処理工程を、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。プロセッサと、メモリと、を有し、前記メモリは、移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを動作させるOSであって、前記移植元OSと異なる移植先OSと、前記移植元APIのエラー条件情報と、前記移植元APIが当該エラー条件情報に該当した場合に前記移植元APIの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース以下、DBと、前記アプリケーションプログラムから前記移植元APIが呼び出された時に、前記移植元APIが前記移植元エラー条件DBの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元APIに対応する前記移植先OSの移植先APIを呼び出すAPI変換工程とを前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。プロセッサと、メモリと、を有し、前記メモリは、移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを動作させるOSであって、前記移植元OSと異なる移植先OSと、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報と、前記アプリケーションプログラムから前記ステータス値を参照する前記移植元APIが呼び出された時に、前記ラッパー管理情報から前記移植元APIが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照API処理工程を前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。しかし、移植元OSと移植先OS間には、各APIの引数や戻り値のインターフェースの相違に加え、それぞれのOSの有するエラー値やステータス値OSモード、タスクの状態情報、メモリサイズ等に相違がある。そのため、ラッパープログラム内で、移植元のOSのAPIを移植先のOSのAPIに変換しただけでは、移植先OSのAPIからアプリケーションに出力されるエラー値やステータス情報については同一にすることはできない。このような場合、ラッパープログラムからアプリケーションに想定しない値が出力され、アプリケーションが誤動作するという問題があった。これを解決するためには、移植先と移植元、双方のOSの仕様を熟知したプログラマーがラッパープログラムを生成し、当該ラッパープログラム内でアプリケーションへのエラー値やステータス値に関する出力値をも移植元OSの規約に合わせる必要がある。しかし、エラー値やステータス情報等に関するアプリケーションへの出力値を元OSの規約に合わせるための変換をもラッパープログラムで行うこととすると、ラッパープログラムでの変換処理、移植先のOSのAPIの呼び出し、および呼び出されたAPIでの変換処理結果に基づく処理が発生するのでオーバーヘッドが大きくなり効率が悪い。そこで、本発明は、移植元のOSの規約に合わせた出力値を効率的にアプリケーションプログラムに出力するラッパープログラム及び集積回路装置を提供することにある。第1の側面は、移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを、前記移植元OSと異なる移植先OS上で動作させるラッパープログラムであって、前記ラッパープログラムは、前記移植元APIのエラー条件情報と、前記移植元APIが当該エラー条件情報に該当した場合に前記移植元APIの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース以下、DBを参照可能であり、前記ラッパープログラムは、前記アプリケーションプログラムから前記移植元APIが呼び出された時に、前記移植元APIが前記移植元エラー条件DBの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元APIに対応する前記移植先OSの移植先APIを呼び出すAPI変換工程とを、コンピューターに実行させる。第1の側面によれば、移植元のOSの規約に合わせた出力値を効率的にアプリケーションプログラムに出力する。以下、図面にしたがって本発明の実施の形態について説明する。ただし、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。図1は、本実施の形態例における集積回路装置10の一例を表す図である。同図において、集積回路装置10は、プロセッサ11とRAMRandomAccessMemory12とプログラムメモリ13とを有する。また、プログラムメモリ13は、オペレーティングシステム以下、移植先OS30、アプリケーションプログラム以下、アプリケーション31、ラッパープログラム32、移植先OSのエラー条件データベース以下、DB33、移植元OSのエラー条件DB53を有する。集積回路装置10は、移植先OS30によって制御される。図1のアプリケーション31は、移植元OSが備えるアプリケーションプログラムインターフェース以下、APIを呼び出すコードを有し、移植元OSにおいて動作検証済みのアプリケーションである。ラッパープログラム32は、当該アプリケーション31を、移植先OS30で動作可能にするためのプログラムである。プログラムメモリ13が有するラッパープログラム32、移植元OSのエラー条件DB33、及び、RAM12が有する移植先OSの管理情報21、ラッパープログラム用の管理情報22の詳細については、後述する。図2は、異なるOS間におけるアプリケーション31の2つの移植方法を説明する図である。なお、同図の移植元OS50及び移植先OS30とは、T-KernelやITRONIndustrialTRON等の組み込み向けのリアルタイムOSであってもよいし、LinuxやWindows登録商標等の汎用OSであってもよい。図2Aに示される第1の移植方法は、アプリケーション31が有する移植元OS50のAPIを、移植先OS30のAPIに置き換えてプログラムし直す方法である。この方法では、移植元OS50で検証済みのアプリケーション31に変更が加えられることにより、新たに不具合が作りこまれる可能性を有する。そして、図2Bに示される第2の移植方法は、移植先OS30上でラッパープログラム32を介してアプリケーション31を動作させる方法である。この方法では、アプリケーション31から移植元OS50のAPIが呼び出された時、ラッパープログラム32の有するAPIと同名の関数を介して、当該APIに対応する移植先OS30のAPIが呼び出され処理される。これにより、アプリケーション31自体に変更を加えることなく移植先OS30上で動作可能になり、移植や検証に要する工数が抑えられると共に、動作時に不具合が発生した場合の箇所の特定が容易になる。このため、図2Bに示される第2の移植方法が用いられることが多い。本実施の形態例におけるラッパープログラム32は、図2Bに示されるラッパープログラム32に関する。しかし、ラッパープログラム32は、後述する課題を有する。課題を説明する前に、まず、前提となるラッパープログラム32の基本動作について説明する。図3は、ラッパープログラム32の基本動作を説明する図である。この例において、アプリケーション31は、移植元OS50のAPIである関数ter_tskを呼び出すコードを有する。関数は、当該関数の処理で使用される引数par1と、その処理結果が出力される戻り値例えば、ercdを有し、引数の数や、戻り値の有無は関数によって異なる。同図の関数ter_tskは、引数par1例えば、tskidで指定されたタスクを終了させる関数であり、プログラムのコード上で戻り値=tertsk引数;のように記述される。同図の例において、引数par1には、終了対象のタスクを示す正の識別値を有するtskidという変数が指定される。そして、戻り値にはercdという変数が指定され、例えば、変数ercdにマイナスの値が出力された場合、この関数でエラーが発生したことを表す。移植元のOS50でアプリケーション31が動作する場合、図3の左部のように、アプリケーション31から関数ter_tskが呼び出されると、移植元OS50のライブラリから関数ter_tskが呼び出され処理が行われるa1。そして、その処理結果が戻り値ercdとして、アプリケーション31に出力されるa2。一方、移植先OS30上でアプリケーション31が動作する場合、図3の右部のように、ラッパープログラム32を介して関数の処理が行われる。ラッパープログラム32は、移植元OS50のAPIと同名の関数ter_tskを有する。そして、ラッパープログラム32のter_tsk関数内で、移植元OS50のAPI関数ter_tskに対応する移植先OSのAPI関数ter_tskXとreturnercdX;を呼び出す。これにより、ラッパープログラム32を介してb1関数ter_tskXが呼び出されb2、移植先OS30によって関数ter_tskXの処理が行われる。そして、その処理結果として出力された戻り値ercdXがb3、アプリケーション31に出力されるb4。ただし、移植元OS50のAPIと、移植先OS30のAPIとではインターフェースが異なる場合がある。この例では、移植元OS50の関数ter_tskは引数が1つpar1であるのに対し、移植先OSの関数ter_tskXは2つpar2、par3である。例えば、関数ter_tskXの1番目の引数par2には、移植元OS50の関数ter_tskと同じ終了対象のタスクが指定され、2番目の引数par3にはタスクの強制終了の有無が指定される。このように、OSによってAPIのインターフェースが異なる場合、ラッパープログラム32は、移植元OS50のAPIの処理内容と実質的に同じになるように、移植先OS30のAPIを呼び出す。この例では、関数ter_tskXの2番目の引数par3に、強制終了無を示す0が指定される。また、移植元OS50のAPIと、移植先OS30のAPIとでは、インターフェースに加えて、戻り値として出力されるエラー値についても、規約が相違する場合がある。例えば、移植元OS50のAPI関数ter_tskでは、エラーが発生した場合、戻り値ercdとして-1~-10のいずれかのエラー値が出力されるのに対し図3のa2、移植先OS30のAPI関数ter_tskXでは、エラーが発生した場合、戻り値ercdXとして-11~-20のいずれかのエラー値が出力される図3のb3、b4。これによると、アプリケーション31が移植元OS50上で動作する場合、エラー発生時に、当該移植元OS50のエラー値の規約に基づいて、-1~-10のいずれかのエラー値が出力される。それに対して、アプリケーション31が移植先OS30上で動作する場合、エラーが発生時に、当該移植先OS30のエラー値の規約に基づいて、-11~-20のいずれかのエラー値が出力される。このように、OSのエラー値の規約が相違する場合、アプリケーション31が移植元OS50、移植先OS30のいずれのOSで動作するかによって、APIからアプリケーション31に出力される戻り値が異なってしまうことがある。そして、アプリケーション31は、APIの戻り値に基づいて後続の処理を制御することが多い。また、アプリケーション31は、移植元OS50のエラー値の規約に基づいてプログラムミングされている。そのため、アプリケーション31が移植先OS30上で動作しAPIから当該移植先OS30の規約に基づいたエラー値が出力される場合、アプリケーション31の処理が意図したとおりに制御されず適切な処理が行われない。このように、ラッパープログラム32は、アプリケーション31が移植先OS30上で動作する場合についても、移植元OS50と同じ規約に基づく戻り値を出力させたいという課題を有する。[第1の実施の形態例]ここで、第1の実施の形態例のラッパープログラム32の処理を説明する前に、従来のラッパープログラム32及び移植先OS50のより詳細な処理の流れについて、フローチャート図に基づいて説明する。図4は、従来のラッパープログラム32と移植先OS30の詳細な処理の流れを説明するフローチャート図である。同図において、点線で囲む処理S10、S11は従来のラッパープログラム、その他の処理S12~S14は移植先OS30の処理を表す。図3で前述したとおり、アプリケーション31から移植元OS50のAPIが呼び出されるとS10、ラッパープログラム32の有する同名の関数を介して、移植元OS50のAPIに対応する移植先OS30のAPIが呼び出されるS11。続いて、移植先OS30は、呼び出された移植先OS30のAPIの処理に当たり、移植先OSのエラー条件DB33や管理情報21を参照して、当該APIが処理可能か否かの判定を行うS12。ここでは、API関数の引数の形式やその値の範囲、OSの状態等に基づいて、当該APIが処理可能であるか否かが判定される。ここで、工程S12のエラー判定処理について説明する前に、当該エラー判定処理で参照される移植先OSのエラー条件DB33、及び、管理情報21について説明する。移植先OSのエラー条件DB33とは、移植先OS30の各APIのエラー条件情報と、当該APIがエラー条件に該当した場合のエラー値を有するDBであり、例えば、関数マクロ等で記述される。移植先OSのエラー条件DB33は、例えば、API関数ter_tskXについて、正の値が指定されるべき引数tskidにマイナス値が指定された場合に所定のエラー値本実施の形態例では、例えば-11を、引数の数が不足している場合に所定のエラー値本実施の形態例では、例えば-12を出力する等の情報を有する。そして、移植先OSの管理情報21とは、OS上の各タスクの動作状態やID情報、メモリプールのサイズ情報、モード情報等のOSの状態を表すステータス値を有する情報である。各ステータス値は、主にAPIの処理時に更新され、常に最新の状態に更新される。また、前述した移植先OSのエラー条件DB33は、ステータス値に基づくエラー条件情報も有する。例えば、関数ter_tskXに関して、引数tskidによって指定された終了対象タスクの動作状態を示すステータス値が非動作状態を示す場合に、所定のエラー値本実施の形態例では、例えば-13を出力する等の情報である。図5は、管理情報の一例を表す図である。同図のAに示されるのは移植先OSの管理情報21であり、Bに示されるのは移植元OSの管理情報52である。同図のAのように、移植先OSの管理情報21は、例えば、OSID情報idや各タスクの動作状態ts、メモリプールのサイズ情報mz、fz、モード情報md等を表すステータス値を有する。同図Bの移植元OSの管理情報52については、第3、4の実施の形態例において後述する。図6は、図4の工程S12のエラー判定処理を表すフローチャート図である。具体的に、移植先OS30は、図5のようなOSの管理情報21を参照して、移植先OS30のAPIに関連するステータス値を取得するS16。移植先OS30は、例えば、関数ter_tskXの場合、移植先OS30は、図5の移植先OSの管理情報21を参照して、引数tskidに指定された終了対象のタスクの動作状態を示すステータス値tsを取得する。続いて、移植先OS30は、取得したステータス値に基づいて移植先OSのエラー条件DB33を参照し、APIがエラー条件に該当するか否かを判定する。なお、移植先OS30は、当該APIに関連するステータス値がある場合にのみ、管理情報21を参照すればよい。このように、移植先OS30は、当該OSの管理情報21と、エラー条件DB33とを参照することにより、当該移植先OS30のAPIが処理可能か否かを判定する。図4のフローチャート図に戻り、エラー判定の結果、エラー条件に該当する場合S13のYES、移植先OS30は、エラー条件DB33に基づいて、エラー条件に対応するエラー値を戻り値としてラッパープログラム32に出力する。一方、エラー条件に該当しない場合S13のNO、移植先OS30は、当該APIの処理を行い、その処理結果を戻り値として、ラッパープログラム32に出力するS14。そして、戻り値がラッパープログラム32を介してアプリケーション31に出力される。このようにして、従来のラッパープログラム32は、移植元OS50のAPIを呼び出すコードを有するアプリケーション31の移植先OS30上での動作を可能にする。しかしながら、図3で前述したとおり、移植元OS50と移植先OS30とでは、APIの処理結果として出力されるエラー値の規約が異なることがある。つまり、同じエラー条件に該当する場合であっても、移植元OS50のAPIと、対応する移植先OS30のAPIとでは、出力するエラー値が異なることがある。これにより、アプリケーション31が移植先OS30上で動作する場合、アプリケーション31の処理が不定になるが、その例をフローチャート図に基づいて説明する。図7は、アプリケーション31の処理の一例を表すフローチャート図である。アプリケーション31が、例えば、移植元OS50の関数ter_tskを呼び出すとS1、ラッパープログラム32を介して移植先OSの関数ter_tskXが移植先OS30で処理されb1~b3、その処理結果が戻り値としてアプリケーション31に出力されるS2、b4。続いて、アプリケーション31は、その戻り値が所定のエラー値であるか否かを判定するS3。この例において、工程S3において、引数に不正な値が指定された場合のエラー値が出力された場合にS3のYES、エラー処理S4に遷移するものとする。移植元OS50では、関数ter_tskに引数に不正な値が指定された場合、当該移植元OS50の規約に基づいてエラー値-1が出力される。そのため、この例において、工程S3では戻り値が-1であるか否かが判定される。しかしながら、移植先OS30では、関数ter_tskXについて引数に不正値が指定された場合、当該移植先OS30の規約に基づいて-11が出力される。そのため、アプリケーション31が移植先OS30上で動作する場合、引数に不正な値が指定されたにもかかわらずエラー値が-1とは異なるため、エラー処理S4に遷移しない。このように、アプリケーション31が移植先OS30上で動作する場合、OSによるエラー値の規約の相違によって移植元OS50上で動作する場合と処理が異なってしまう。そこで、第1の実施の形態例におけるラッパープログラム32は、アプリケーション31から移植元OS50のAPIが呼び出された時に、移植元OSのエラー条件DB53を参照し、移植元APIが移植元エラー条件DB53のエラー条件情報に該当するか否かを判定し、該当する場合に対応するエラー情報をアプリケーション31に出力する。また、エラー条件情報に該当しない場合、ラッパープログラム32は、当該移植元OS50のAPIに対応する移植先OS30のAPIを呼び出す。図8は、第1の実施の形態例におけるラッパープログラム32と移植先OS30の処理の流れを説明するフローチャート図である。図8は、従来のラッパープログラムの処理を表す図4に対応する。図8において、点線で囲む処理S20~S24はラッパープログラム32、その他の処理S25~S28は移植先OS30の処理を表す。本実施の形態例におけるラッパープログラム32は、移植元OSのエラー条件DB53を有し、移植元OS50のAPIに対応する移植先OS30のAPIを呼び出す前に、移植元OS50のAPIについてエラー条件DB53を参照してエラー判定を行う。そのため、ラッパープログラム32は、エラー条件に該当する場合、移植先OS30のAPIの呼び出しを不要にして処理を高速にすると共に、アプリケーションへの移植元OS50の規約に基づくエラー値の出力を可能にする。以下、その点について具体的に説明する。移植元OSのエラー条件DB53とは、移植元OS50の各APIのエラー条件情報と、当該APIがエラー条件に該当した場合のエラー値を有するDBである。移植元OSのエラー条件DB53は、例えば、関数ter_tskについて、正の値が指定されるべき引数tskidにマイナス値が指定された場合に所定のエラー値本実施の形態例では、例えば-1を、引数の数が不足している場合に所定のエラー値本実施の形態例では、例えば-2を、引数tskidに指定された終了対象のタスクの動作状態を示すステータス値が非動作状態を示す場合に所定のエラー値本実施の形態例では、例えば-3を出力する等の情報を有する。一方、前述したとおり、移植先OSのエラー条件DB33は、関数ter_tskXについて、例えば、引数tskidにマイナス値が指定された場合にエラー値-11を、引数の数が不足している場合にエラー値-12を、引数tskidが非動作状態を示す場合にエラー値-13を出力する等の情報を有する。つまり、OSによってエラー値の規約が異なる。図8のフローチャート図において、アプリケーション31から移植元OS50のAPIが呼び出されるとS20、図3のb1、本実施の形態例のラッパープログラム32は、移植元OSのエラー条件DB53を参照して、呼び出された移植元OS50のAPIが移植元OSのエラー条件34に該当するか否か判定するS21。エラー条件に該当する場合S22のYES、ラッパープログラム32は、移植元OSのエラー条件DB53に基づいたエラー値を戻り値としてアプリケーション31に出力する。このため、アプリケーション31には、移植元OS50上で動作する場合と同じ規約に基づくエラー値が戻り値として出力されるS23、図3のb4。また、この場合、ラッパープログラム32は、移植元OS50のAPIに対応する移植先OS30のAPIを呼び出さない。これにより、アプリケーション31は、エラー条件に該当する場合、移植先OS30のAPIの呼び出しを不要にして処理を高速にすると共に、アプリケーションへの移植元OS50の規約に基づくエラー値の出力を可能にする。一方、エラー条件に該当しない場合S22のNO、ラッパープログラム32は、当該APIに対応する移植先OS30のAPIを呼び出すS24、図3のb2。移植先OSのAPIが呼び出された後の処理はS12~S15、図4のフローチャート図と同じである。図8のフローチャート図の処理を、図3に例示した関数ter_tskに基づいてより具体的に説明する。この場合、アプリケーション31が呼び出す移植元OSの関数ter_tskの引数tskidには、不正な値が指定されているものとする。アプリケーション31から関数ter_tskが呼び出されると図8のS20、図3のb1、本実施の形態例におけるラッパープログラム32は、移植元OSのエラー条件DB53を参照して関数ter_tskのエラー判定を行うS21。この場合、引数tskidに不正な値が指定された場合のエラー条件に該当するためS22のYES、ラッパープログラム32は、移植元OSのエラー条件DB53に基づくエラー値-1をアプリケーション31に出力するS23、b4。この戻り値-1は、移植元OSのエラー条件DB53に基づいていることにより、アプリケーション31が移植元OS50上で動作する場合と同じ値となる。これにより、アプリケーション31は、移植先OS30上で動作する場合であっても、移植元OS50と同じ戻り値に基づいて判定処理を行うことができる。このように、本実施の形態例のラッパープログラム32は、アプリケーション31から呼び出された移植元OS50のAPIに対応する移植先OS30のAPIを呼び出す前に、移植元OSのエラー条件DB53を参照して移植元OS50のAPIのエラー判定を行う。これにより、ラッパープログラム32は、移植元OSのAPIが、移植元OSのエラー条件DB53のエラー条件に該当する場合、移植元OS50と同じ規約に基づく戻り値をアプリケーション31に出力することができる。また、ラッパープログラム32は、エラー条件に該当する場合、対応する移植先OS30のAPIを呼び出す前にエラー判定を行うことにより、処理を高速にすることができる。このように、本実施の形態例におけるラッパープログラム32は、移植元OS50と移植先OS30のエラー情報の規約が異なる場合であっても移植元OS50と同じ規約に基づくエラー情報を、効率的にアプリケーション31に出力することができる。従って、移植元OS50のエラー情報の規約に基づいてプログラミングされているアプリケーション31に対して、移植先OS30の規約に基づくエラー情報用の判定処理等が加えられる必要がない。また、ラッパープログラムが、移植元OSのエラー条件DB53のエラー条件に基づいてエラー判定を行うので、ラッパープログラム内に移植元OSのエラー情報に関する規約を移植先OSの規約に変換する仕組みを設ける必要もない。これにより、移植元OS50で検証済みのアプリケーション31を変更せずに移植先OS30上で動作させることができるため、移植工数が削減される。[第2の実施の形態例]第1の実施の形態例では、ラッパープログラム32が、移植元OS50のAPIに対応する移植先OS30のAPIを呼び出す前に、移植元OSのエラー条件DB53を参照して移植元OS50のAPIのエラー判定を行う例を示した。第2の実施の形態例のラッパープログラム32は、図9に示すように、さらに移植先OSの管理情報21を参照して移植元OS50のAPIのエラー判定を行う。これにより、ラッパープログラム32は、動作環境であるOS30の状態に基づいたAPIのエラー判定も行うことができる。図9は、第2の実施の形態例におけるラッパープログラム32と移植先OS30の処理の流れを説明するフローチャート図である。図8と同様に、点線で囲む処理S30~S34はラッパープログラム32、その他の処理S12~S15は移植先OS30の処理を表す。アプリケーション31から移植元OS50のAPIが呼び出されるとS30、本実施の形態例のラッパープログラム32は、移植元OSのエラー条件DB53に加えて移植先OSの管理情報21をも参照して、当該APIが移植元OSのエラー条件34に該当するか否かを判定するS31。エラー判定処理の流れは、図6のフローチャート図と同様である。ただし、本実施の形態例におけるラッパープログラム32は、移植先OSの管理情報21と移植元OSのエラー情報DB34に基づいて次のようにエラー判定を行う。まず、本実施の形態例におけるラッパープログラム32は、移植先OSの管理情報21を参照して、呼び出された移植元OSのAPIに関連するステータス値を取得する。ラッパープログラム32は、図5Aに示した移植先OSの管理情報21を参照して、APIに関連する例えば、タスクの動作状態tsやOSのモード情報md等のステータス値を取得する。続いて、ラッパープログラム32は、取得したステータス値に基づいて移植元OSのエラー条件DB53を参照し、APIがエラー条件に該当するか否かを判定する。エラー判定後の処理S33、S34、S12~S15は、第1の実施の形態例と同様である。これにより、ラッパープログラム32は、動作環境のOS30の状態に基づいたステータス値に基づいて、移植元OS50のエラー値の規約に基づくエラー値をアプリケーション31に出力することができる。続いて、図9のフローチャート図の処理を、APIの具体例に基づいてより詳細に説明する。図10は、ラッパープログラム32の一例を表す図である。同図の例において、アプリケーション31-1は、移植元OS50のAPIである関数slp_tskを呼び出すコードを有する。関数slp_tskは、例えば、自タスクAPIを発行したタスクを待ち状態スリープ状態:slpに移行する関数であり、プログラムのコード上で戻り値=slptskvoid...引数なし;のように記述される。関数slp_tskは、OSがディスパッチ禁止タスクの切り替え禁止モードの時に処理された場合にエラーとなる。また、移植元OS50の関数slptskに対応するラッパープログラム32-1は、移植先OS30のAPI関数slptskXを呼び出す。図9に示される通り、アプリケーション31から移植元OS50の関数slp_tskが呼び出されると図9のS30、図10のc1、本実施の形態例におけるラッパープログラム32は、移植元OSのエラー条件DB53と移植先OSの管理情報21とを参照して関数slp_tskのエラー判定を行うS31。この例において、この時、アプリケーション31が動作する移植先OS30はディスパッチ禁止モードであるものとする。続いて、ラッパープログラム32は、移植先OSの管理情報21を参照して、関数slp_tskに関連するステータス値である自タスクの識別値とOSのモード情報を取得する。この場合、ラッパープログラム32は、移植先OSの管理情報21を参照して、ディスパッチ禁止モードを示すOSのモード情報を取得する。ディスパッチ禁止モードはエラー条件に該当するためS32のYES、ラッパープログラム32は、移植元OSのエラー条件DB53に基づいて、当該エラー条件に対応する所定のエラー値をアプリケーション31に出力する図9のS33、図10のc2。エラー値は、移植元OSのエラー条件DB53に基づいているため、アプリケーション31が移植元OS50上で動作する場合と同じである。これにより、アプリケーション31は、移植先OS30上で動作する場合であっても、移植元OS50と同じ戻り値に基づいて判定処理を行うことができる。このように、本実施の形態例のラッパープログラム32は、アプリケーション31から呼び出された移植元OS50のAPIに対応する移植先OS30のAPIを呼び出す前に、移植先OSの管理情報21を参照して取得したステータス値に基づいて移植元OSのエラー条件DB53を参照し、動作環境であるOS30の状態に基づいた移植元OS50のAPIのエラー判定を行う。そして、ラッパープログラム32は、エラー条件に該当する場合、移植元OSのエラー条件DB53の当該エラー条件に対応するエラー値をアプリケーション31に出力する。これにより、ラッパープログラム32は、呼び出された移植元OS50のAPIについて、第1の実施の形態例における形式的なエラー判定に加え、動作環境である移植先OS30の状態に基づいたエラー判定をも可能にしながら、移植元OS50と同じ規約に基づいた戻り値をアプリケーション31に出力することができる。以上のように、本実施の形態例におけるラッパープログラム32は、移植元OS50と移植先OS30のエラー情報の規約が異なる場合であっても、移植元OS50と同じ規約に基づくエラー情報を効率的にアプリケーション31に出力することができる。これにより、移植元OS50で検証済みのアプリケーション31を変更せずに移植先OS30上で動作させることができるため、移植工数が削減される。[第3の実施の形態例]第2の実施の形態例では、ラッパープログラム32が、移植元OSのエラー条件DB53と移植先OSの管理情報21を参照して移植元OS50のAPIのエラー判定を行う例を示した。これに対して、第3の実施の形態例におけるラッパープログラム32は、移植元OSのエラー条件DB53と共に、移植元OSのステータス値の規約に合わせて、移植先OSの管理情報21に基づいて生成、更新したラッパープログラム用の管理情報22を参照して、移植元OS50のAPIのエラー判定を行う。これにより、ラッパープログラム32は、移植元OS50と移植先OS30とでステータス値の規約が相違する場合であっても、OSの状態に基づいたAPIのエラー判定を行うことができる。前述した図5では、Aの移植先OSの管理情報21と、Bの移植元OSの管理情報52とを表しているが、OSによって各ステータス値の意味合い規約は相違することがある。例えば、図5の管理情報の動作状態tsを例示して説明する。例えば、図5Bに示した移植元OSの管理情報52では、タスクの動作状態tsを示すステータス値として、次の4つのいずれかの値を有するものとする。停止状態=0/動作状態=1/動作可能状態=2/待ち状態=3。それに対して、図5Aに示した移植先OSの管理情報21では、タスクの動作状態tsを示す同じステータス値として、次の5つのいずれかのステータス値を有するものとする。停止状態=1/動作状態=0/動作可能状態=2/待ち状態=3/強制待ち状態=4。このように、移植先OS30と移植元OS50とで、停止状態及び動作状態を示すステータス値が相違していると共に、移植先OSの管理情報21は、動作状態tsとして移植元OS50にない値強制待ち状態=4を有する。このように、移植先OS30と移植元OS50とでステータス値の規約が異なる場合、移植先OSの管理情報21は、移植先OS30のステータス値の規約に基づくのに対し、移植元OSのエラー条件DB53は移植元OS50のステータス値の規約に基づく。そのため、ラッパープログラム32は、移植先OSの管理情報21を参照して取得したステータス値に基づいて、移植元OSのエラー条件DB53のエラー条件に該当するか否かを判定することができない。具体的に、処理対象のタスクが停止状態のときエラー条件に該当する場合、移植先OSの管理情報21によるとタスクの状態を表すステータス値が停止状態=1のときにエラー条件に該当する。しかし、移植元OSのエラー条件DB53において、タスクの状態を表すステータス値が1の場合は動作状態を示し、エラー条件に該当しない。そこで、本実施の形態例におけるラッパープログラム32は、移植元OSの管理情報52のステータス値の規約に合わせて修正した、移植先OSの管理情報21の各ステータス値を有するラッパープログラム用の管理情報22を生成して、上記の課題を解消する。具体的に、ラッパープログラム32は、上記の例において、移植元OS50の規約に合わせて、移植先OS30の動作状態を表すステータス値が停止状態=1の場合は0に、動作状態=0の場合は1に修正したラッパープログラム用の管理情報22を生成する。また、ラッパープログラム32は、移植元OS50が有しないステータス値については、最も意味合いの近い値に修正する。この例において、ラッパープログラム32は、移植元OS50が有しない移植先OS30のステータス値強制待ち状態=4を広義の待ち状態と仮定し、移植元OS50のステータス値待ち状態=3に修正する。図11は、第3の実施の形態例におけるラッパープログラム32と移植先OS30の処理の流れを説明するフローチャート図である。同図において、点線で囲む処理S40~S45はラッパープログラム32、その他の処理S12~S15は移植先OSの処理を表す。アプリケーション31から移植元OS50のAPIが呼び出されるとS40、本実施の形態例のラッパープログラム32は、上述したように、移植元OSの管理情報52のステータス値の規約に合わせて修正した移植先OSの管理情報21のステータス値を有するラッパープログラム用の管理情報22を生成するS41。また、既に、ラッパープログラム32がラッパープログラム用の管理情報22を有する場合、ラッパープログラム32は、移植先OSの管理情報21の各ステータス値に基づいて、当該ラッパープログラム用の管理情報22を更新するS41。そして、ラッパープログラム32は、移植元OS50のAPIに関連するステータス値をラッパープログラム用の管理情報22を参照して取得し、当該ステータス値に基づいて移植元OSエラー条件DB53を参照してAPIがエラー条件に該当するか否かを判定する。エラー判定の後の処理S44、S45、S12~S15は、第1の実施の形態例と同様である。続いて、図11のフローチャート図の処理を、図10の関数sta_tskの具体例に基づいて説明する。図10の例において、アプリケーション31-1は、移植元OS50のAPIである関数sta_tskを呼び出すコードを有する。関数sta_tskは、例えば、自タスク以外のタスクを動作状態に移行させる関数であり、プログラムのコード上で戻り値=statsk引数;のように記述される。ただし、関数sta_tskは、引数に指定した対象のタスクが停止状態以外の場合にエラーとなる。また、移植元OS50の関数statskに対応するラッパープログラム32-2は、移植先OS30のAPI関数statskXを呼び出す。アプリケーション31から移植元OS50の関数sta_tskが呼び出されると図11のS40、図10のd1、本実施の形態例におけるラッパープログラム32は、ラッパープログラム用の管理情報22の生成または更新処理を行うS41。なお、この例において、この時、関数sta_tskの引数tskidに指定された対象タスクは、既に動作状態であるものとする。続いて、ラッパープログラム32は、ラッパープログラム用の管理情報22を参照して、引数tskidに指定した対象タスクの動作状態を示すステータス値動作状態=1を取得する。このステータス値は、移植元OS50の規約に基づいているため、移植元OSのエラー条件DB53において、処理対象のタスクが既に動作状態である旨のエラー条件に該当すると判定されS43のYES、対応する所定のエラー値がアプリケーション31に出力されるS44、図10のd2。また、このエラー値は、アプリケーション31が移植元OS50上で動作する場合と同じ規約に基づくエラー値である。このように、本実施の形態例のラッパープログラム32は、アプリケーション31から呼び出された移植元OS50のAPIに対応する移植先OS30のAPIを呼び出す前に、移植元OSの管理情報52におけるステータス値の規約に合わせて修正した移植先OSの管理情報21におけるステータス値を有するラッパープログラム用の管理情報22を生成する。そして、ラッパープログラム32は、当該ラッパープログラム用の管理情報22を参照して取得したステータス値に基づいて、移植元OSのエラー条件DB53を参照してエラー判定を行う。そして、ラッパープログラム32は、エラー条件に該当する場合、移植元OSのエラー条件DB53の当該エラー条件に対応するエラー値をアプリケーション31に出力する。これにより、ラッパープログラム32は、移植先OS30と移植元OS50とで戻り値に加えてステータス値の規約が異なる場合であっても、移植元OS50と同じ規約に基づくエラー情報を効率的にアプリケーション31に出力することができる。これにより、移植元OS50で検証済みのアプリケーション31を変更せずに移植先OS30上で動作させることができるため、移植工数が削減される。なお、上記の例では、ラッパープログラム32によって、ラッパープログラム用の管理情報22を生成または更新される例について説明した。しかしながら、ラッパープログラム用の管理情報22は、移植先OS30によって生成、更新されてもよい。図12は、移植先OSによってラッパープログラム用の管理情報22が生成、更新される例を表すフローチャート図である。同図において、ラッパープログラム32は、ラッパープログラム用の管理情報22の生成、更新処理を行わない。この場合、ラッパープログラム用の管理情報22の生成、更新処理は、エラー条件に該当せずS52のNO、S13のNO移植元OS50のAPIに対応する移植先OS30のAPIの処理が行われた後にS14、移植先OS30によって行われるS55。というのも、ステータス値は、主にAPIの処理後に更新される。そのため、APIの処理後、移植先OS30においてラッパープログラム用の管理情報22の生成または更新処理が行われることによって、当該管理情報22のステータス値が常に最新の状態に更新される。これにより、ラッパープログラム32は、移植元OS50のAPIのエラー判定前にS51、ラッパープログラム用の管理情報22の生成、更新処理を行わないことにより、オーバーヘッドを抑えることができる。また、エラー条件に該当して移植先OSのAPIが呼び出されない場合S52のYES、S13のYES、ラッパープログラム用の管理情報22の生成、更新処理が発生しないことにより、当該処理の回数が最小限に抑えられる。[第4の実施の形態例]第1から第3の実施の形態例では、アプリケーション31からOSのタスクに対して処理を行うAPIを呼び出す例について述べた。それに対して、第4の実施の形態例では、アプリケーション31から、ステータス値を参照するAPI以下、参照APIを呼び出す場合について述べる。前述したとおり、ステータス値の規約はOSによって異なることがある。本実施の形態例におけるラッパープログラム32は、参照APIが呼び出された時に、効率的に、移植元OS50と同じ規約に基づくステータス値を出力する。図13は、参照APIを有するアプリケーション31-2の一例を表す図である。同図の例において、アプリケーション31-2は、移植元OS50のAPIである関数ref_mplを呼び出すコードを有する。関数ref_mplは、例えば、メモリプールmplに係るステータス値を参照するreference参照APIであり、プログラムのコード上で戻り値=refmpl引数1、引数2;のように記述される。関数ref_mplでは、メモリプールのメモリ領域の全体メモリサイズmz、空きメモリサイズfzを示すステータス値が参照される。引数1この例では、mplidには対象のメモリプールの識別値例えば、正の識別値が、引数2この例では、pkrmplには当該APIによって参照されるステータス値を格納するメモリMCが指定される。同図のように、メモリMCは、全体メモリサイズmz、空きメモリサイズfzを示すステータス値を格納する。関数が処理されると、処理結果を示す値が戻り値この例では、ercdに出力されると共に、引数2pkrmplで示されるメモリMCに、ステータス値である全体メモリサイズmz、空きメモリサイズfzが格納される。図14は、メモリプールの管理対象のメモリ領域mpを表す図である。メモリプールとは、OSのメモリ管理機能であり、アプリケーション31から指定されたサイズのメモリ領域の確保や、確保したメモリのメモリブロック単位の管理を行う。同図において、メモリ領域mpは、管理領域メモリcmと5つのメモリブロックm1~m5を有する。図13の関数ref_mplで参照される空きメモリサイズfzとは、メモリブロックm1~m5のうち未使用メモリブロックm2の総サイズを示す。一方、全体メモリサイズmzは、移植元OS50と移植先OS30とでその意味合い規約が異なる。例えば、この例において、移植元OS50における全体メモリサイズmzは管理領域メモリcmを含まない0x50であるのに対し、移植先OS30における全体メモリサイズmzは管理領域メモリcmを含む0x58であるとする。アプリケーション31は、参照用APIによって取得したステータス値に基づいて、後続の処理を制御するが、上記のようにOSによってステータス値の規約が相違する場合、アプリケーション31の処理が不定となってしまう。その例をフローチャートに基づいて説明する。図15は、参照APIを呼び出すアプリケーション31の処理の一例を表すフローチャート図である。このアプリケーション31が、例えば、移植元OS50の参照API関数ref_mplを呼び出すとS5、ラッパープログラム32を介して対応する移植先OSの関数によって取得された全体メモリサイズmzが取得されるS6。次に、取得された全体メモリサイズmzが所定値を超えるか否かが判定されるS7。この例において、工程S7における所定値は、移植元OS50のステータス値の規約に基づいて、管理領域メモリcmを含まない全体メモリサイズmzを前提として設定されている。しかしながら、移植先OS30における全体メモリサイズmzは管理領域メモリcmを含む。そのため、アプリケーション31が移植先OS30上で動作する場合、工程S7において、管理領域メモリcmを含まない全体メモリサイズmzを前提とする所定値が、管理領域メモリcmを含む全体メモリサイズmzと比較されることになってしまう。これにより、移植元OS50の規約に基づく全体メモリサイズszであれば所定値以上にならずS7のNO処理2に遷移するS9にもかかわらず、移植先OS30の規約に基づく全体メモリサイズmzであるため所定値に達しS7のYES、処理1S8に遷移することがある。このように、アプリケーション31が移植先OS30上で動作する場合、OSによるステータス値の規約の相違によって、移植先OS50上で動作する場合と処理が異なってしまう。そこで、本実施の形態例におけるラッパープログラム32は、移植元OS50のステータス値の規約に合わせて修正した移植先OS30のステータス値を有するラッパープログラム用の管理情報22を参照して参照APIに係るステータス値を収集する。これにより、ラッパープログラム32は、移植元OS50の規約に基づいたステータス値をアプリケーション31に出力することができる。図16は、第4の実施の形態例におけるラッパープログラム32と移植先OS30の処理の流れを説明するフローチャート図である。同図の処理は全てラッパープログラム32の処理である。アプリケーション31から移植元OS50の参照APIが呼び出されるとS60、本実施の形態例のラッパープログラム32は、第3の実施の形態例と同様に、移植元OSの管理情報のステータス値の規約に合わせて修正した移植先OSの管理情報21の各ステータス値を有するラッパープログラム用の管理情報22を生成、更新するS61。続いて、ラッパープログラム32は、移植元OSのAPIに関連するステータス値をラッパープログラム用の管理情報22を参照して取得し、当該ステータス値に基づいて移植元OSエラー条件DB53を参照してAPIがエラー条件に該当するか否かを判定するS62。エラー条件に該当する場合S63のYES、第1の実施の形態例と同様にして、ラッパープログラム32は、移植元OSのエラー条件DB53に基づくエラー値を戻り値としてアプリケーション31に出力する。一方、エラー条件に該当しない場合S63のNO、ラッパープログラム32は、ラッパープログラム用の管理情報22を参照して移植元OS50の参照APIに係る参照情報を収集しS65、アプリケーション31に引き渡すS66。このように、本実施の形態例におけるラッパープログラム32は、移植元OS50のAPIの参照対象のステータス値を、移植先OS30のAPIを呼び出すことなくアプリケーション31に出力することができる。図16のフローチャート図の処理を、図13の関数ref_mplの具体例に基づいて説明する。アプリケーション31から関数ref_mplが呼び出されるとS60、本実施の形態例におけるラッパープログラム32は、ラッパープログラム用の管理情報22を生成、更新するS61。例えば、ラッパープログラム32は、メモリプールの全体メモリサイズmzを、移植元OS50の全体メモリサイズmzの規約に合わせて移植先OSの全体メモリサイズmz-移植先OSの管理領域メモリサイズcmのように修正したラッパープログラム用の管理情報22を生成する。続いて、ラッパープログラム32は、移植元OSのエラー条件DB53及びラッパープログラム用の管理情報22を参照して関数ref_mplのエラー判定を行うS62。エラー条件に該当する場合S63のYES、第1の実施の形態例と同様に、移植元OSのエラー条件DB53に基づいて、移植元OS50と同じ規約の戻り値がアプリケーション31に出力されるS64。一方、エラー条件に該当しない場合S63のNO、ラッパープログラム32は、ラッパープログラム用の管理情報22を参照して、メモリプールの全体メモリサイズmz及び空きメモリサイズfzを収集するS65。ラッパープログラム用の管理情報22における全体メモリサイズmzは管理領域サイズcmを含まないため、移植元OS50と同じ規約に基づいた全体メモリサイズmzがアプリケーション31に引き渡されるS66。このように、本実施の形態例のラッパープログラム32は、移植元OS50の管理情報におけるステータス値の規約に合わせて修正した移植先OSの管理情報21におけるステータス値を有するラッパープログラム用の管理情報22を生成する。そして、ラッパープログラム32は、当該ラッパープログラム用の管理情報22を参照して、アプリケーション31から呼び出された移植元OSの参照APIに係るステータス値を収集する。これにより、ラッパープログラム32は、移植元OS50と移植先OS30とでステータス値の規約が異なる場合であっても、移植元OS50と同じ規約に基づいたステータス値を収集し、アプリケーション31に出力することができる。また、ラッパープログラム32は、呼び出された参照APIに係るステータス値を、移植先OS30のAPIを呼び出すことなくラッパープログラム用の管理情報22を参照することによって収集可能にするため、処理を高速にすることができる。なお、上記の例では、管理情報におけるステータス値の規約がOSによって異なる場合を例示したが、管理情報のフォーマット管理情報におけるステータス値の配置順序やサイズが異なる場合にも有効である。前述した図5のとおり、同図のAに示される移植先OSの管理情報21と、Bに示される移植元OSの管理情報52とでは、管理情報の有するステータス値、及び、当該ステータス値の配置順序が相違している。これは、例えば、ラッパープログラム32が管理情報をメモリに一括して取得し、当該取得したメモリから各ステータス値を参照する場合、次のような課題を有する。この場合、アプリケーション31は、例えば、参照APIによって管理情報を1つのメモリに取得する。そして、アプリケーション31は、移植元OS50の管理情報の各ステータス値の配置順序やサイズに従って取得したメモリから、各ステータス値を参照する。しかしながら、移植先OS30と移植元OS50とで管理情報のフォーマットが異なるため、アプリケーション31は、移植先OS50のフォーマットに従って、メモリから各ステータス値を参照することができない。そこで、ラッパープログラム32は、移植元OS50と同じフォーマットでラッパープログラム用の管理情報22を構築する。これにより、アプリケーション31は、参照APIによって取得されたメモリ内の各ステータス値を、移植元OS50と同じフォーマットに従って参照することができる。以上のように、本実施の形態例におけるラッパープログラム32は、移植元OS50と移植先OS30の管理情報の規約各ステータス値の意味合い、及び、管理情報のフォーマット等が相違する場合であっても、移植元OS50と同じ規約に基づく参照値出力値をアプリケーション31に引き渡すことができる。これにより、移植元OS50で検証済みのアプリケーション31を変更せずに移植先OS30上で動作させることができるため、移植工数が削減される。また、第3の実施の形態例と同様、ラッパープログラム用の管理情報22は、アプリケーション31が動作する移植先OS30によって生成、更新されてもよい。図17は、移植先OS30によってラッパープログラム用の管理情報22が生成、更新される例を表すフローチャート図である。同図において、ラッパープログラム32は、ラッパープログラム用の管理情報22の生成、更新処理を行わない。この場合、ラッパープログラム用の管理情報22の生成、更新処理は、APIが処理される度にS76、移植先OS30によって行われるS77。なお、管理情報の各ステータス値は、参照APIの処理では更新されない。そのため、移植先OS30は、非参照系のAPIについてのみ、その処理後にS76、ラッパープログラム用の管理情報22を生成または更新するS77。これにより、ラッパープログラム32は、ラッパープログラム用の管理情報22を生成、更新処理を行わないため、オーバーヘッドを抑えることができる。また、移植元OS50の参照APIが呼び出される度にラッパープログラム用の管理情報22の生成、更新処理が発生しないことにより、当該処理の回数が最小限に抑えられる。以上の実施の形態をまとめると、次の付記のとおりである。付記1移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを、前記移植元OSと異なる移植先OS上で動作させるラッパープログラムであって、前記ラッパープログラムは、前記移植元APIのエラー条件情報と、前記移植元APIが当該エラー条件情報に該当した場合に前記移植元APIの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース以下、DBを参照可能であり、前記ラッパープログラムは、前記アプリケーションプログラムから前記移植元APIが呼び出された時に、前記移植元APIが前記移植元エラー条件DBの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元APIに対応する前記移植先OSの移植先APIを呼び出すAPI変換工程とを、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。付記2付記1において、前記ラッパープログラムは、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、前記移植元エラー条件DBの前記エラー条件情報は、前記ステータス値に基づくエラー条件情報であり、前記エラー判定工程は、前記ラッパー管理情報を参照して前記移植元APIに関連するステータス値を取得し、前記移植元エラー条件DBを参照して当該取得したステータス値に基づいて前記移植元APIが前記エラー条件情報に該当するか否かを判定するラッパープログラム。付記3付記2において、前記ラッパー管理情報を前記エラー判定工程の前に生成または更新するラッパープログラム。付記4付記2において、前記ラッパー管理情報は、前記移植先APIが実行された後に前記移植先OSによって生成または更新されるラッパープログラム。付記5付記2乃至4のいずれかにおいて、前記ラッパー管理情報のステータス値は、前記移植元OSのステータス値の規約に合わせて修正された値であり、前記エラー判定工程は、前記移植元OSのステータス値の規約に合ったステータス値に基づいて前記移植元APIが前記エラー条件情報に該当するか否かを判定するラッパープログラム。付記6付記2乃至5のいずれかにおいて、前記アプリケーションプログラムから前記ステータス値を参照する前記移植元APIが呼び出された時に、前記ラッパー管理情報から前記移植元APIが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照API処理工程を、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。付記7移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを、前記移植元OSと異なる移植先OS上で動作させるラッパープログラムであって、前記ラッパープログラムは、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報を参照可能であって、前記ラッパープログラムは、前記アプリケーションプログラムから前記ステータス値を参照する前記移植元APIが呼び出された時に、前記ラッパー管理情報から前記移植元APIが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照API処理工程を、コンピューターに実行させるコンピューター読み取り可能なラッパープログラム。付記8付記7において、前記ラッパー管理情報を前記参照API処理工程の前に生成または更新するラッパープログラム。付記9付記7において、前記ラッパー管理情報は、前記移植先OSの移植先APIが実行された後に前記移植先OSによって生成または更新されるラッパープログラム。付記10付記7乃至9のいずれかにおいて、前記ラッパー管理情報は、前記移植元OSの管理情報と同じフォーマットで構築され、前記参照API処理工程は、前記移植元APIが参照する前記移植元のOSと同じフォーマットの前記ステータス値を取得するラッパープログラム。付記11付記7乃至10のいずれかにおいて、前記ラッパー管理情報のステータス値は、前記移植元OSのステータス値の規約に合わせて修正された値であり、前記参照API処理工程は、前記移植元OSのステータス値の規約に合ったステータス値を取得し前記アプリケーションプログラムに出力するラッパープログラム。付記12プロセッサと、メモリと、を有し、前記メモリは、移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを動作させるOSであって、前記移植元OSと異なる移植先OSと、前記移植元APIのエラー条件情報と、前記移植元APIが当該エラー条件情報に該当した場合に前記移植元APIの呼び出し元に出力するエラー情報とを有する移植元エラー条件データベース以下、DBと、前記アプリケーションプログラムから前記移植元APIが呼び出された時に、前記移植元APIが前記移植元エラー条件DBの前記エラー条件情報に該当するか否かを判定し、該当する場合に対応する前記エラー情報を前記アプリケーションプログラムに出力するエラー判定工程と、該当しない場合に前記移植元APIに対応する前記移植先OSの移植先APIを呼び出すAPI変換工程とを前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。付記13付記12において、前記メモリは、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報を有し、前記移植元エラー条件DBの前記エラー条件情報は、前記ステータス値に基づくエラー条件情報であり、前記エラー判定工程は、前記ラッパー管理情報を参照して前記移植元APIに関連するステータス値を取得し、前記移植元エラー条件DBを参照して当該取得したステータス値に基づいて前記移植元APIが前記エラー条件情報に該当するか否かを判定する集積回路装置。付記14プロセッサと、メモリと、を有し、前記メモリは、移植元オペレーティングシステム以下、OSの移植元アプリケーションプログラムインターフェース以下、APIを呼び出すコードを有するアプリケーションプログラムを動作させるOSであって、前記移植元OSと異なる移植先OSと、前記移植先OSが管理情報として更新するステータス値を含むラッパー管理情報と、前記アプリケーションプログラムから前記ステータス値を参照する前記移植元APIが呼び出された時に、前記ラッパー管理情報から前記移植元APIが参照する前記ステータス値を取得し前記アプリケーションプログラムに出力する参照API処理工程を前記プロセッサに実行させるラッパープログラムと、を有する集積回路装置。