(57)【特許請求の範囲】
【請求項１】
プロセッサとメモリを有するコンピュータ上に導入されたオペレーティングシステムに適合しないアプリケーションにパッチを当てるための前記コンピュータにより実行される方法であって、
前記方法は、
（ａ）前記アプリケーションを起動するステップであって、前記アプリケーションは、関連するアドレス空間を前記メモリ内に有し、かつ、前記アプリケーションを実行するために前記関連するアドレス空間にロードされたダイナミックリンクライブラリを有し、前記ダイナミックリンクライブラリは、関数を有するとともに前記関数への関数ポインタを含む関連インポートテーブルを有する、ステップと、
（ｂ）前記オペレーティングシステムと適合しないアプリケーションを識別する情報の中に前記アプリケーションに関する情報が含まれているかどうかの決定に基づいて、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップと、
（ｃ）前記アプリケーションが前記オペレーティングシステムに適合しない場合に、前記アプリケーションの前記関連するアドレス空間に、シムダイナミックリンクライブラリおよびフックダイナミックリンクライブラリを挿入するステップであって、前記フックダイナミックリンクライブラリは、前記シムダイナミックリンクライブラリからロードされるように構成されており、アプリケーション中でパッチを当てる必要のある関数のリストと、この関数のリストに含まれる関数にパッチを当てるための情報とを含み、前記シムダイナミックリンクライブラリは、前記関数のリストに含まれる関数にパッチを当てるのに必要なプログラムコードを含んでおり、前記シムダイナミックリンクライブラリを使用して、
（ｉ）前記フックダイナミックリンクライブラリの関数のリストに基づいて、前記適合しないアプリケーション中のどの関数にパッチを当てる必要があるかを決定し、
（ｉｉ）前記フックダイナミックライブラリに含まれる前記情報に基づいて、前記プログラムコードで前記決定された関数にパッチを当てるステップと、
（ｄ）前記パッチ後のアプリケーションを実行するステップと
を備えることを特徴とする方法。
【請求項２】
請求項１に記載の方法であって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップが、
（ａ）前記起動したアプリケーションの複数の識別属性のうち少なくとも１つの識別属性が、不適合アプリケーションの複数の識別属性のうち少なくとも１つの識別属性と一致するかどうかを判定するステップと、
（ｂ）少なくとも１つの前記識別属性が一致する場合には、前記起動したアプリケーションは適合しないと判定し、そうでない場合には、前記起動したアプリケーションは適合すると判定するステップと
を備えることを特徴とする方法。
【請求項３】
請求項２に記載の方法であって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップが、
不適合アプリケーションの識別属性を記憶するステップと、
前記起動したアプリケーションの複数の識別属性のうち少なくとも１つの識別属性が、不適合アプリケーションの前記記憶された識別属性のうち少なくとも１つの識別属性と一致するかどうかを判定するために、前記記憶された識別属性の少なくとも１つを取り出すステップと
をさらに備えることを特徴とする方法。
【請求項４】
請求項３に記載の方法であって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップが、
前記起動したアプリケーションの追加の識別属性を、不適合アプリケーションの前記記憶された識別属性と比較するステップと、
前記識別属性が一致する場合には、前記アプリケーションは適合しないと判定するステップと
をさらに備えることを特徴とする方法。
【請求項５】
請求項４に記載の方法であって、前記プログラムコードは、前記リスト中の前記関数をパッチするためのスタブ関数群を含むことを特徴とする方法。
【請求項６】
請求項５に記載の方法であって、前記関数にパッチを当てるステップでは、前記コンピュータは、前記決定された関数を前記スタブ関数に置き換えるように構成されていることを特徴とする方法。
【請求項７】
オペレーティングシステムに適合しないアプリケーションにパッチを当てるためのプロセッサとメモリを含むコンピュータシステムにより実行されて方法を行うコンピュータ実行可能命令を格納したコンピュータ可読記録媒体であって、前記命令は、以下のステップをプロセッサに実行させるものであり、
（ａ）前記アプリケーションを起動するステップであって、前記アプリケーションは、関連するアドレス空間を前記メモリ内に有し、かつ、前記アプリケーションを実行するために前記関連するアドレス空間にロードされたダイナミックリンクライブラリを有し、前記ダイナミックリンクライブラリは、関数を有するとともに前記関数への関数ポインタを含む関連インポートテーブルを有する、ステップと、
（ｂ）前記オペレーティングシステムと適合しないアプリケーションを識別する情報の中に前記アプリケーションに関する情報が含まれているかどうかの決定に基づいて、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップと、
（ｃ）前記アプリケーションが前記オペレーティングシステムに適合しない場合に、前記アプリケーションのアドレス空間にシムダイナミックリンクライブラリおよびフックダイナミックリンクライブラリを挿入するステップであって、前記フックダイナミックリンクライブラリは、前記シムダイナミックライブラリからロードされるように構成されており、前記適合しないアプリケーション中でパッチを当てる必要のある関数のリストと、この関数のリストに含まれる関数にパッチを当てるための情報とを含み、前記シムダイナミックリンクライブラリは、前記関数のリストに含まれる関数でパッチを当てるのに必要なプログラムコードを含んでおり、前記シムダイナミックリンクライブラリを使用して、
（ｉ）前記フックダイナミックリンクライブラリの関数のリストに基づいて、前記適合しないアプリケーション中のどの関数にパッチを当てる必要があるかを決定し、
（ｉｉ）前記フックダイナミックライブラリに含まれる前記情報に基づいて、前記プログラムコードで前記決定された関数にパッチを当てるステップと、
（ｄ）前記パッチ後のアプリケーションを実行するステップと
を含むことを特徴とするコンピュータ可読記録媒体。
【請求項８】
請求項７に記載のコンピュータ可読記録媒体であって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップが、
（ａ）前記起動したアプリケーションの複数の識別属性のうち少なくとも１つの識別属性が、不適合アプリケーションの複数の識別属性のうち少なくとも１つの識別属性と一致するかどうかを判定するステップと、
（ｂ）少なくとも１つの前記識別属性が一致する場合には、前記起動したアプリケーションは適合しないと判定し、そうでない場合には、前記起動したアプリケーションは適合すると判定するステップと
を備えることを特徴とするコンピュータ可読記録媒体。
【請求項９】
請求項８に記載のコンピュータ可読記録媒体であって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップが、
不適合アプリケーションの識別属性を記憶するステップと、
前記起動したアプリケーションの複数の識別属性のうち少なくとも１つの識別属性が、不適合アプリケーションの前記記憶された識別属性のうち少なくとも１つの識別属性と一致するかどうかを判定するために、前記記憶された識別属性の少なくとも１つを取り出すステップと
をさらに備えることを特徴とするコンピュータ可読記録媒体。
【請求項１０】
請求項９に記載のコンピュータ可読記録媒体であって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定するステップが、
（ａ）前記起動したアプリケーションの追加の識別属性を、不適合アプリケーションの前記記憶された識別属性と比較するステップと、
（ｂ）前記識別属性が一致する場合には、前記アプリケーションは適合しないと判定するステップと
をさらに備えることを特徴とするコンピュータ可読記録媒体。
【請求項１１】
請求項１０に記載のコンピュータ可読記録媒体であって、前記プログラムコードは、前記リスト中の前記関数をパッチするためのスタブ関数群を含むことを特徴とするコンピュータ可読記録媒体。
【請求項１２】
請求項１１に記載のコンピュータ可読記録媒体であって、前記関数にパッチを当てるステップでは、前記コンピュータは、前記決定された関数を前記スタブ関数に置き換えるように構成されていることを特徴とするコンピュータ可読記録媒体。
【請求項１３】
メモリとプロセッサとを有するコンピュータシステムに導入されたオペレーティングシステムに適合しないアプリケーションにパッチを当てるためのコンピュータシステムであって、
（ａ）前記アプリケーションを起動する処理であって、前記アプリケーションは、関連するアドレス空間を前記メモリ内に有し、かつ、前記アプリケーションを実行するために前記関連するアドレス空間にロードされたダイナミックリンクライブラリを有し、前記ダイナミックリンクライブラリは、関数を有するとともに前記関数への関数ポインタを含む関連インポートテーブルを有する、処理と、
（ｂ）前記オペレーティングシステムと適合しないアプリケーションを識別する情報の中に前記アプリケーションに関する情報が含まれているかどうかの決定に基づいて、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定する処理と、
（ｃ）前記アプリケーションが前記オペレーティングシステムに適合しない場合に、前記アプリケーションのアドレス空間にシムダイナミックリンクライブラリおよびフックダイナミックリンクライブラリを挿入する処理であって、前記フックダイナミックリンクライブラリは、前記シムダイナミックライブラリからロードされるように構成されており、前記適合しないアプリケーション中でパッチを当てる必要のある関数のリストと、この関数のリストに含まれる関数にパッチを当てるための情報とを含み、前記シムダイナミックリンクライブラリは、前記関数のリストに含まれる関数でパッチを当てるのに必要なプログラムコードを含んでおり、前記シムダイナミックリンクライブラリを使用して、
（ｉ）前記フックダイナミックリンクライブラリの関数のリストに基づいて、前記適合しないアプリケーション中のどの関数にパッチを当てる必要があるかを決定し、
（ｉｉ）前記フックダイナミックライブラリに含まれる前記情報に基づいて、前記プログラムコードで前記決定された関数にパッチを当てる処理と、
（ｄ）前記パッチ後のアプリケーションを実行する処理と
を実行するように構成されていることを特徴とするコンピュータシステム。
【請求項１４】
請求項１３に記載のコンピュータシステムであって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定する処理では、
（ａ）前記起動したアプリケーションの複数の識別属性のうち少なくとも１つの識別属性が、不適合アプリケーションの複数の識別属性のうち少なくとも１つの識別属性と一致するかどうかを判定する処理と、
（ｂ）少なくとも１つの前記識別属性が一致する場合には、前記起動したアプリケーションは適合しないと判定し、そうでない場合には、前記起動したアプリケーションは適合すると判定する処理と
を実行するように構成されていることを特徴とするコンピュータシステム。
【請求項１５】
請求項１４に記載のコンピュータシステムであって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定する処理では、
不適合アプリケーションの識別属性を記憶する処理と、
前記起動したアプリケーションの複数の識別属性のうち少なくとも１つの識別属性が、不適合アプリケーションの前記記憶された識別属性のうち少なくとも１つの識別属性と一致するかどうかを判定するために、前記記憶された識別属性の少なくとも１つを取り出す処理と
をさらに実行するように構成されていることを特徴とするコンピュータシステム。
【請求項１６】
請求項１５に記載のコンピュータシステムであって、前記アプリケーションが前記オペレーティングシステムに適合するか否かを判定する処理では、
前記起動したアプリケーションの追加の識別属性を、不適合アプリケーションの前記記憶された識別属性と比較する処理と、
前記識別属性が一致する場合には、前記アプリケーションは適合しないと判定する処理と
をさらに実行するように構成されていることを特徴とするコンピュータシステム。
【請求項１７】
請求項１６に記載のコンピュータシステムであって、前記プログラムコードは、前記リスト中の前記関数をパッチするためのスタブ関数群を含むことを特徴とするコンピュータシステム。
【請求項１８】
請求項１７に記載のコンピュータシステムであって、前記関数にパッチを当てる処理では、前記コンピュータシステムは、前記決定された関数を前記スタブ関数に置き換えるように構成されていることを特徴とするコンピュータシステム。
【発明の詳細な説明】
【０００１】
（他の出願との関連）
本出願は、１９９９年９月１日出願の米国仮出願第６０／１５００７７号の利益を主張する。
【０００２】
（発明の分野）
本発明はソフトウェアに関し、より詳細には、オペレーティングシステムに適合しないソフトウェアアプリケーションを適合させることに関する。
【０００３】
（発明の背景）
めまぐるしく動いている今日のソフトウェア分野では、アプリケーションの多くは、アプリケーションの開発時に使用されるオペレーティングシステム用に特化してプログラムされる。通常はオペレーティングシステム開発者からアプリケーション開発者にプログラミング仕様が提供されるが、これらの手順および規則が守られないこともある。その結果、多くのアプリケーションが、新たにリリースされたオペレーティングシステムのもとで正しく機能しなくなる場合がある。これは、プログラミング仕様に従わないことや、オペレーティングシステムがどのように動作するかを憶測することなど、様々な多くの要因から生じる可能性がある。例えば、あるタイプのファイルが常にコンピュータ中の特定位置に記憶されているとアプリケーション開発者が信じていることがあり、このプログラマは、プログラミング仕様の指示どおりにオペレーティングシステム中の関数にそのファイルの位置を要求するのではなく、アプリケーションコードにファイル位置のパスを具体的に入力することになる。さらに、プログラマは、オペレーティングシステムの関数内でエラーが発生した場合にその関数がある種の値だけしか返さないということに依拠する場合もある。例えば、オペレーティングシステムの以前のバージョンではエラーを示すのに１つの負の値が返されていた場合、プログラマは、将来も１つの負の値だけが返されるであろうと憶測することがある。しかし、オペレーティングシステムの変更により、エラーに基づいて他の値が返されるように関数が修正されているかもしれず、したがってプログラムは、このオペレーティングシステムのもとで、すべての状況では正しく機能しなくなる可能性がある。
【０００４】
他の例では、プログラムがエラーを含んでいても、あるバージョンのオペレーティングシステムのもとでは正しく動作するように見えることがある。これは、古いバージョンのオペレーティングシステムがアプリケーションに含まれるエラーを検出しないとき、またはエラーを有効としないときに起こる可能性がある。しかし、新たにリリースされたオペレーティングシステムは、以前はチェックされていなかったこれらの条件をチェックするかもしれず、それにより、アプリケーションは新バージョンのオペレーティングシステムに適合しなくなる。
【０００５】
適合しないアプリケーションをさらに作り出すということは、オペレーティングシステムの普及が高まるにつれて不適合アプリケーションの問題もまた増大するということである。例えば、あるオペレーティングシステムがそのリリース中に普及すると、そのオペレーティングシステム用に特化して何千ものアプリケーションが書かれることになる。アプリケーションが多数あり、かつアプリケーション開発者のグループが多様であることにより、オペレーティングシステムの新バージョンがリリースされたときに多くのプログラムが正しく機能しなくなる可能性がある。
【０００６】
現在機能しているアプリケーションが新しいオペレーティングシステムに適合しない場合、これらのアプリケーションのユーザは、新しいオペレーティングシステムに切り替えたくないと思うことがある。この問題を解決しようとするために、アプリケーション開発者は自分たちのアプリケーション自体を修正することが必要であり、あるいはオペレーティングシステム開発者は、既知の問題のアプリケーションの多くを修正するためにオペレーティングシステムの新バージョンに一体化されたパッチを含め、新しいオペレーティングシステムのもとでもアプリケーションが正しく機能するようにしてきた。
【０００７】
しかし、オペレーティングシステムパッチ手法は多くの問題を生じる。第１に、パッチは、オペレーティングシステムに多量のデータを追加することがあり、したがってオペレーティングシステムの空間要件が大きく増大する恐れがある。第２に、新しいオペレーティングシステムに適合するアプリケーションが多いにもかかわらず、すべてのアプリケーションがこの追加パッチ層を通して動作することが必要とされる。これにより、プログラムの実行が遅くなる可能性がある。第３に、修正が必要かもしれないプログラムの数が多いため、オペレーティングシステムのプログラミングコードが非常に乱雑になる場合がある。この乱雑なコードは、オペレーティングシステム開発者がオペレーティングシステムに変更や改良を加えることをより困難にする。最後に、新しいオペレーティングシステムが最初にリリースされるときに、正しく機能しないであろうアプリケーションを開発者がすべて知ることは不可能である。したがって、それらのプログラムが正しく機能できるようにするために、オペレーティングシステムに後続のパッチを作成しなければならない。これにより、すでに複雑なオペレーティングシステムにもう一つの層が加わり、オペレーティングシステムの動作効率が低下する。
【０００８】
（発明の概要）
本発明は、アプリケーションが動作するコンピュータのオペレーティングシステムに普通なら適合しないはずのアプリケーションにパッチを当てるためのシステムおよび方法を提供することを対象とする。本発明によれば、適合しないアプリケーションのアドレス空間にダイナミックリンクライブラリ（ＤＬＬ）が挿入される。ＤＬＬは、適合しないアプリケーション中でパッチを当てる必要のある関数を決定し、これらの関数にパッチを当てる。
【０００９】
ＤＬＬは、オペレーティングシステムに適合しないと識別されたアプリケーションだけについてオペレーティングシステムによってロードされることを理解されたい。したがって、オペレーティングシステムに適合するアプリケーションは、実行時に追加のオペレーティングシステムレベルを通る必要はなく、これによりシステムリソースが温存される。
【００１０】
本発明の一実施形態は次のようにして機能する。最初に、ユーザがアプリケーションを起動する。第２に、アプリケーションがオペレーティングシステムに適合するまたは適合しないと識別される。アプリケーションが適合しないかどうかを判定するために、アプリケーションからの識別情報が、現在適合しないことがわかっているアプリケーションのリストを含むデータベースと照らしてチェックされる。アプリケーションの名前がデータベース中にある場合は、アプリケーションのこの特定バージョンが適合するかどうかを調べるために属性のセットがチェックされる。チェックされた属性すべてがデータベース中に見られるものと一致する場合、このアプリケーションは現オペレーティングシステムに適合しないと判定される。
【００１１】
アプリケーションの名前がデータベース中に見られない場合は、アプリケーションは現オペレーティングシステムに適合すると判定される。アプリケーションが適合すると判定された場合、アプリケーションは通常どおり実行される。アプリケーションが適合しないと判定された場合、オペレーティングシステムは、アプリケーションとオペレーティングシステムとの間でシム（詰め木）として働くＤＬＬを、アプリケーションのアドレス空間にロードする。Ｓｈｉｍ  ＤＬＬ（シムＤＬＬ）は、Ｈｏｏｋ  ＤＬＬ（フックＤＬＬ）と呼ぶ別個のＤＬＬに含まれるパッチを当てるのに必要なプログラムコードを含む。Ｈｏｏｋ  ＤＬＬは、適合しないアプリケーションにパッチを当てるのに必要な実際のプログラムコードを含む。
【００１２】
Ｈｏｏｋ  ＤＬＬがロードされた後で、Ｓｈｉｍ  ＤＬＬは、Ｈｏｏｋ  ＤＬＬの内容を解析して、アプリケーション中のどの関数にパッチを当てる必要があるかを決定する。本発明の一実施形態では、Ｈｏｏｋ  ＤＬＬはまた、適合しない関数が位置するモジュールの名前、適合しない関数の名前、問題を修正するために呼び出すべきスタブ関数、およびパッチを当てる必要のあるアプリケーションのＤＬＬのリストも含むことができる。次いでＳｈｉｍ  ＤＬＬは、Ｈｏｏｋ  ＤＬＬに含まれる情報を用いて、適合しないアプリケーションのプログラムコードにパッチを当てる。
【００１３】
適合しないアプリケーションによってＳｈｉｍ  ＤＬＬおよびＨｏｏｋ  ＤＬＬがロードされた後、アプリケーションに必要な残りのＤＬＬがロードされる。ロードされる各ＤＬＬは、そのＤＬＬに含まれる関数および関数ポインタのリストを維持するインポートテーブルを有する。Ｓｈｉｍ  ＤＬＬは、ＤＬＬ中の適合しない関数ポインタを、Ｈｏｏｋ  ＤＬＬに含まれる更新済み関数ポインタで置換する。
【００１４】
本発明の他の態様によれば、実行時にロードされるときＤＬＬにパッチを当てるのに加えて、アプリケーションが実行されている間に動的にロードされるＤＬＬにパッチを当てるための方法およびシステムも提供される。動的にロードされるＤＬＬの内にある不適合性を訂正するために、オペレーティングシステムはデフォルトで、アプリケーションがＤＬＬに動的にリンクしてそのＤＬＬからＡＰＩを呼び出すために使用する少数のシステムＡＰＩにパッチを当てる。
【００１５】
前述の概要から当業者なら理解するであろうが、本発明は、適合しないアプリケーションにパッチを当てる効率的な方法を提供する。
【００１６】
本発明の前述の態様および付随する多くの利点は、添付の図面と共に以下の詳細な説明を参照することによってよりよく理解されたとき、より容易に認識されるであろう。
【００１７】
（好ましい実施形態の詳細な説明）
本発明は、適合しないアプリケーションにパッチを当てるためのコンピュータ方法およびシステムを対象とする。より具体的には、本発明は、アプリケーションを実行するコンピュータ上で稼動するオペレーティングシステムのもとで実行されたときに普通なら適切に機能しないはずのアプリケーションにパッチを当てる際に使用するのに理想的に適している。簡単に述べると、本発明は、アプリケーションがオペレーティングシステムに適合するまたは適合しないと識別し、アプリケーションが適合しないと判定された場合は、適合しないアプリケーションにパッチを当てるＳｈｉｍ  ＤＬＬをアプリケーションのアドレス空間に挿入する。
【００１８】
図１および以下の考察は、本発明を実施できる適したコンピューティング環境の簡単かつ一般的な記述を提供するものである。本発明は、パーソナルコンピュータに関連するオペレーティングシステム上で実行されるアプリケーションプログラムの一般的なコンテキストで述べるが、本発明は他のプログラムモジュールと共に実施することもできることを当業者なら理解するであろう。一般にプログラムモジュールは、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な民生電子機器、ミニコンピュータ、メインフレームコンピュータなどを含めた、他のコンピュータシステム構成で実施することもできることを当業者なら理解するであろう。本発明はまた、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが行われる分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールがローカルとリモートの両方の記憶デバイス中に位置することができる。
【００１９】
図１を参照すると、本発明を実施するための例示的なシステムは従来型のパーソナルコンピュータ２０を含み、このパーソナルコンピュータ２０は、プロセッシングユニット２１と、システムメモリ２２と、システムメモリをプロセッシングユニット２１に結合するシステムバス２３とを備える。システムメモリ２２は、読出し専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。ＲＯＭ２４には、起動時などにパーソナルコンピュータ２０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）２６が記憶されている。パーソナルコンピュータ２０はさらに、ハードディスクドライブ２７と、例えば取外し可能ディスク２９に対して読取りまたは書込みを行うための磁気ディスクドライブ２８と、例えばＣＤ−ＲＯＭディスク３１を読み取ったり他の光学媒体に対して読取りまたは書込みを行ったりするための光学ディスクドライブ３０とを備える。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光学ディスクドライブ３０は、それぞれハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光学ドライブインタフェース３４によってシステムバス２３に接続される。ドライブおよびそれらに関連するコンピュータ可読媒体は、パーソナルコンピュータ２０のための不揮発性記憶域を提供する。以上のコンピュータ可読媒体についての記述ではハードディスク、取外し可能磁気ディスク、およびＣＤ−ＲＯＭディスクに言及しているが、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイ（Ｂｅｒｎｏｕｌｌｉ）カートリッジ、ＺＩＰディスクなど、コンピュータによって読取り可能な他のタイプの媒体もまた、この例示的な動作環境で使用できることを当業者は理解されたい。
【００２０】
ドライブおよびＲＡＭ２５には、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、その他のプログラムモジュール３７、およびプログラムデータ３８を含めた、いくつかのプログラムモジュールを記憶することができる。ユーザは、キーボード４０やマウス４２などの入力デバイスを介してパーソナルコンピュータ２０にコマンドおよび情報を入力することができる。その他の入力装置（図示せず）には、マイクロホン、タッチパッド、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナなどを含めることができる。これらおよび他の入力デバイスは、システムバスに結合されたシリアルポートインタフェース４６を介してプロセッシングユニット２１に接続されることが多いが、ゲームポートやユニバーサルシリアルバス（ＵＳＢ）など、他のインタフェースによって接続することもできる。モニタ４７または他のタイプの表示装置もまた、ビデオアダプタ４８などのインタフェースを介してシステムバス２３に接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカやプリンタなど他の周辺出力デバイス（図示せず）も備える。
【００２１】
パーソナルコンピュータ２０は、リモートコンピュータ４９など、１つまたは複数のリモートコンピュータへの論理接続を用いてネットワーク化された環境で動作することもできる。リモートコンピュータ４９は、サーバ、ルータ、ピアデバイス、またはその他の一般的なネットワークノードとすることができ、図１にはメモリ記憶デバイス５０しか示していないが通常は、パーソナルコンピュータ２０に関して述べた要素の多くまたはすべてを備える。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１およびワイドエリアネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでよくみられる。
【００２２】
ＬＡＮネットワーキング環境で使用されるときは、パーソナルコンピュータ２０は、ネットワークインタフェース５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーキング環境で使用されるときは、パーソナルコンピュータ２０は通常、インターネットなどのＷＡＮ５２を介して通信を確立するためのモデム５４またはその他の手段を備える。モデム５４は、内蔵でも外付けでもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続される。ネットワーク化された環境では、パーソナルコンピュータ２０に関して示すプログラムモジュールまたはその一部をリモートメモリ記憶デバイスに記憶することもできる。図示のネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を用いることもできることを理解されたい。
【００２３】
本発明は、図２〜６を参照することによって最もよく記述され、これらの図は本発明の一実施形態を示している。図２〜４には、オペレーティングシステムに対するアプリケーションの適合性を判定して、適合しないアプリケーションにパッチを当てるためにアプリケーションのアドレス空間にＳｈｉｍ  ＤＬＬを挿入するための論理を示す。図５および６には、Ｈｏｏｋ  ＤＬＬと、本発明の一実施形態により適合しないアプリケーションにどのようにパッチを当てるかに関する例を示す。
【００２４】
図２は、本発明の概観を示すフローチャートである。ブロック６２はアプリケーションの起動を示す。決定ブロック６４で、アプリケーションがオペレーティングシステムに適合するかどうかが判定される。本発明の一実施形態では、この判定はオペレーティングシステムが行う。アプリケーションは様々なレベルでオペレーティングシステムに適合する可能性があることを、当業者なら理解するであろう。例えば、適合しないアプリケーションのせいでオペレーティングシステムがコンピュータを停止することもあり、また、適合しないアプリケーションは、起こりそうにない指定のイベントが発生するまでは不適合性を含まないかのように動作することもある。したがって、適合しないアプリケーションとは、あるオペレーティングシステムのもとで正しく機能しないと識別されるアプリケーションであると定義する。当業者には理解されるであろうが、この定義に従えば、多くのアプリケーションが適合しないと識別される可能性がある。本発明の一実施形態では、アプリケーションは、アプリケーションがそのプログラムコードの実行を開始する前に、適合しないアプリケーションであると識別される。アプリケーションが適合するとオペレーティングシステムが判定した場合は、ブロック６６で示すように、アプリケーションは通常どおり実行される。そうではなくアプリケーションが適合しないと判定した場合は、オペレーティングシステムは、ブロック６８で示すように、アプリケーションにパッチを当てるのに使用されるＳｈｉｍ  ＤＬＬをアプリケーションのアドレス空間にロードする。次いで、アプリケーションは終了まで実行される。
【００２５】
図３に、図２の決定ブロック６４によって行われる機能をより詳細に示す。より具体的には、図３は、アプリケーションを実行することになるコンピュータのオペレーティングシステムにアプリケーションが適合するかどうかを判定するための、本発明の一実施形態を示すフローチャートである。最初にブロック８２で、起動されたアプリケーションの識別属性（名前など）の少なくとも１つが、オペレーティングシステムによってチェックされる。チェックできる他の識別属性には、ヘッダのバージョン数、アプリケーションのバージョン数、社名、アプリケーションのチェックサム、アプリケーションのリリース日、アプリケーションのサイズ、アプリケーションの始めの６バイト、またはアプリケーションを識別する助けとして使用できるその他の属性が含まれるが、これらに限定しない。当業者には理解されるであろうが、アプリケーションを一意的に識別するものならどんな属性を選択してもよい。
【００２６】
次にブロック８４で、オペレーティングシステムが、起動されたアプリケーションの属性を、適合しないと判定されているアプリケーションの属性と比較する。本発明の一実施形態では、適合しないアプリケーションの属性のいくつかが、データベース、具体的にはＷｉｎｄｏｗｓ（登録商標）レジストリに記憶されている。属性は異なる多くの位置に記憶してもよいことは、当業者には理解されるであろう。例えば属性は、ユーザのパーソナルコンピュータのハードディスクドライブに記憶してもよい。別法として属性は、ウェブサーバやリモートホストなどのリモート位置に記憶してもよい。リモートに記憶する場合、識別属性は、インターネットを介してユーザのコンピュータにダウンロードすることができ、あるいはリモートホストから直接読み取ることさえもできる。さらに、識別属性は、光学ディスクまたは磁気ディスクに記憶してもよく、あるいは前述のようにリモートホストのウェブサーバに記憶してもよい。本発明の一実施形態では、データベースは、オペレーティングシステムに適合しないことが現在わかっているアプリケーションの名前を他の識別情報と共に含む。ｒｅｇｅｄｉｔ．ｅｘｅやｒｅｇｅｄｉｔ３２．ｅｘｅを含め、レジストリデータベースを編集するのに使用できるツールが多くあることは、当業者には理解されるであろう。これらのツールまたは同様のツールを使用して、ユーザは、適合しないアプリケーションの識別属性をレジストリに入力することができる。
【００２７】
起動されたアプリケーションの識別属性が、識別済みの不適合アプリケーションの属性と等しい場合、起動されたアプリケーションは現オペレーティングシステムに適合しないと判定される。前述のように本発明の一実施形態では、比較される第１の識別属性は、起動されたアプリケーションの名前である。アプリケーションの名前がデータベースに含まれる名前のどれとも一致しない場合、アプリケーションは現オペレーティングシステムに適合すると判定される。起動されたアプリケーションの名前がデータベースに含まれる名前と一致する場合は、アプリケーションがオペレーティングシステムに適合しないかどうかを判定するために追加の識別属性がチェックされる。アプリケーションは様々な多くの方式で識別することができ、比較される識別属性のセットには前述のように様々な多くの識別パラメータを含めることができることは、当業者には理解されるであろう。場合によっては、適合しないアプリケーションを一意的に識別するのに識別属性は１つで十分なこともある。
【００２８】
本発明の実際の一実施形態では、識別属性はデータベース内のバイナリデータで表される。最初の数バイトは、後続の識別属性のサイズを示す。識別属性はＡＳＣＩＩフォーマットまたはその他のコンピュータ可読フォーマットで記憶することができることを理解されたい。
【００２９】
属性がチェックされ（ブロック８２）比較された（ブロック８４）後で、起動されたアプリケーションの属性がデータベースに含まれる属性と一致するかどうかを判定するためのテストが行われる（決定ブロック８６）。ブロック８８で示すように、比較された属性が一致する場合は、アプリケーションはオペレーティングシステムに適合しないと判定される。ブロック９０で示すように、属性が一致しない場合は、アプリケーションはオペレーティングシステムに適合すると判定される。アプリケーションが適合すると判定された場合、アプリケーションは通常どおり実行される。そうではなくアプリケーションが適合しない場合は、図２に示し上に述べたように、オペレーティングシステムは、適合しないアプリケーションにパッチを当てるためにアプリケーションのアドレス空間にＳｈｉｍ  ＤＬＬをロードする。図４に、Ｓｈｉｍ  ＤＬＬをロードするプロセスをより詳細に示す。
【００３０】
図４は、Ｓｈｉｍ  ＤＬＬを使用して適合しないアプリケーションにパッチを当てるための、本発明の一実施形態によって採用される論理を示す流れ図である。ブロック１００で、オペレーティングシステムは、アプリケーションのアドレス空間にＳｈｉｍ  ＤＬＬをロードする。これは、アプリケーションがオペレーティングシステムに適合しないと判定された後で行われる（図３参照）。Ｓｈｉｍ  ＤＬＬは、アプリケーションとオペレーティングシステムとの間の層を形成し、アプリケーションのＤＬＬインポートテーブルにパッチを当てるのに必要な機能を提供する。本発明の一実施形態では、Ｓｈｉｍ  ＤＬＬは、Ｈｏｏｋ  ＤＬＬと呼ぶ別個のＤＬＬに含まれるパッチを当てるのに必要なプログラムコードを含む。Ｓｈｉｍ  ＤＬＬはアプリケーションのためのパッチをＳｈｉｍ  ＤＬＬ自体の中に含むこともできることは、当業者には理解されるであろう。Ｓｈｉｍ  ＤＬＬは、適合しないアプリケーションにパッチを当てるための関数（プログラムコード）だけでなく、適合しないアプリケーション中のどの関数にパッチを当てる必要があるかをＨｏｏｋ  ＤＬＬに基づいて決定するプログラムコードも含む。
【００３１】
Ｓｈｉｍ  ＤＬＬがアプリケーションのアドレス空間にロードされた後、ブロック１０２で、Ｓｈｉｍ  ＤＬＬは、適合しないアプリケーションのための実際のパッチを含むＨｏｏｋ  ＤＬＬをロードする。Ｓｈｉｍ  ＤＬＬがロードされると、オペレーティングシステムはＳｈｉｍ  ＤＬＬ内にある初期化ルーチンを呼び出すが、これにより、アプリケーションにパッチを当てるのに使用されるスタブ関数を含むＨｏｏｋ  ＤＬＬの名前が提供される。本発明の実際の一実施形態では、Ｈｏｏｋ  ＤＬＬは、Ｈｏｏｋ  ＤＬＬが最初に作成されたときにオペレーティングシステムに適合しないことがわかっていたアプリケーションのためのすべてのパッチを含む。パッチは１つのＤＬＬに含まれる必要はなく、別々のＤＬＬに含まれるものとすることもできることは、当業者には理解されるであろう。例えば、適合しない各アプリケーションにつき別個のＨｏｏｋ  ＤＬＬを作成してもよい。さらに、製品の製造元に基づいて別々のＨｏｏｋ  ＤＬＬを作成してもよい。
【００３２】
Ｈｏｏｋ  ＤＬＬをロードした後、Ｓｈｉｍ  ＤＬＬは、適合しないアプリケーション中のどの関数にパッチを当てる必要があるかを決定する。本発明の実際の一実施形態では、Ｓｈｉｍ  ＤＬＬは、アプリケーションにパッチを当てるのに必要な情報を含む構造体の配列（図５参照）を生み出す。当業者には理解されるであろうが、様々な多くのデータ構造体を使用して、パッチを当てる必要のある関数についての情報を記憶することができる。例えば、連係リストのデータ構造体を使用してもよい。本発明の一実施形態では、Ｓｈｉｍ  ＤＬＬはＧｅｔＨｏｏｋＡＰＩと呼ばれる関数を含み、この関数は、Ｈｏｏｋ  ＤＬＬに含まれる構造体で構造体の配列を埋めるものである。ＧｅｔＨｏｏｋＡＰＩはまた、Ｈｏｏｋ  ＤＬＬからロードされた構造体の数も返す。Ｈｏｏｋ  ＤＬＬは、アプリケーション中でパッチを当てる必要のある関数のリストを含む。Ｈｏｏｋ  ＤＬＬ中のこのリストはまた、適合しない関数が位置するモジュールの名前、適合しない関数の名前、問題を修正するために呼び出すべきスタブ関数、およびパッチを当てる必要のあるアプリケーションＤＬＬのリストも含む。次いで、Ｓｈｉｍ  ＤＬＬはこの情報を用いて、適合しないアプリケーションにパッチを当てる。
【００３３】
図４のブロック１０４に示すように、Ｈｏｏｋ  ＤＬＬ中で指定されたＡＰＩが、パッチを当てたスタブ関数で置換される（図６Ａ〜Ｃ参照）。Ｈｏｏｋ  ＤＬＬ中で指定されたＡＰＩにパッチが当てられた後は、ブロック１０６で示すように、アプリケーションは通常どおり実行される。
【００３４】
アプリケーションはまた、最初に実行時にロードされなかったＤＬＬ中にある適合しない関数を呼び出すこともある。本発明の実際の一実施形態では、適合しないアプリケーションが動的にＤＬＬをロードするために出した要求をインターセプトするフックが、オペレーティングシステム中に提供される。より具体的には、ブロック１０８で示すように、動的にロードされるモジュールがあればそれがロードされるときにパッチを当てるようにオペレーティングシステムを設計することができる。動的にロードされるＤＬＬの内にある不適合性を正すために、Ｓｈｉｍ  ＤＬＬは、アプリケーションプログラマが動的にＤＬＬをリンクするのに利用するシステムＡＰＩにパッチを当てる。これらの関数は、Ｗｉｎｄｏｗｓ（登録商標）内ではＣａｌｌＰｒｏｃＡｄｄｒｅｓｓおよびＬａｄＬｉｂｒａｒｙと呼ばれる。例えば、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムで、アプリケーションがＣａｌｌＰｒｏｃＡｄｒｅｓｓ（”ｆａ”）を呼び出したときであって（”ｆａ”）はパッチを当てる必要のある適合しない関数であるとき、パッチを当てられたＧｅｔＰｒｏｃＡｄｄｒｅｓｓが、その関数ポインタを、アプリケーションに返す前にＨｏｏｋ  ＤＬＬからのパッチ済み関数で置換する。これは、すべてのプロセスが実行前に確実に修正されるようにするのに役立ち、したがってシステム間がよりよく噛み合うようになる。当業者には理解されるであろうが、他のオペレーティングシステムでは、同じ目的のために異なる関数が使用される場合もあるが、これらも同様の方式でパッチを当てることができる。
【００３５】
当業者その他には理解されるであろうが、本発明のいくつかの実施形態では、動的にロードされるＤＬＬにパッチを当てることが必要でない場合もある。より具体的には、適合しないアプリケーションの実行中にＤＬＬが動的にロードされない場合、オペレーティングシステム中にフックを提供する必要はない。この結果、ブロック１０８に示し上に述べた機能もまた、除くことができる。同様に本発明の他の実施形態では、適合しない関数はすべて、実行時の前にではなく、実行時に呼び出されたときにパッチを当てることもできる。この場合、ブロック１００、１０２、および１０４に示す機能のいくつかまたは全部を除くことができる。
【００３６】
図５は、擬似コードによるＨｏｏｋ  ＤＬＬの図である。インジケータ１２０は、適合しないアプリケーションに含まれる関数の不適合性を正すスタブ関数群を示す。本発明の実際の一実施形態では、Ｈｏｏｋ  ＤＬＬは、適合しないと判定されているすべてのアプリケーション関数のためのスタブ関数を含む。スタブ関数は、適合しない関数にパッチを当てるのに必要なコードを含む。通常、スタブ関数は、適合しない関数への関数呼出しの周りを取り巻く前処理（ｐｒｅｐｒｏｃｅｓｓｉｎｇ）コードおよび後処理（ｐｏｓｔ  ｐｒｏｃｅｓｓｉｎｇ）コードを含む。ただし、スタブ関数は適合しない関数を呼び出さないことさえもある。例えば、適合しないアプリケーションが、オペレーティングシステムのもとで正しく機能するために単にアプリケーションの前バージョンを返すように要求するだけである場合、スタブ関数はこの値をアプリケーションに返すだけとなる可能性が高い。本発明の実際の一実施形態では、スタブ関数とＳｔｒｕｃｔｕｒｅ  Ｈｏｏｋ  ＡＰＩの間には、インジケータ１２２で示すように一対一の関係がある。
【００３７】
インジケータ１２２は、本発明の実際の一実施形態によって採用されるＨｏｏｋ構造体を示している。図５を参照するとわかるように、Ｈｏｏｋ構造体は、モジュール名（ｍｏｄｕｌｅ  ｎａｍｅ）と、関数名（ｆｕｎｃｔｉｏｎ  ｎａｍｅ）と、スタブ関数（ｓｔｕｂ  ｆｕｎｃｔｉｏｎ）と、パッチを当てるべきＤＬＬのリスト、または関連するアプリケーションに伴うすべてのＤＬＬにパッチを当てることを示すＮＵＬＬなどのインジケータとを含む。Ｈｏｏｋ  ＤＬＬは、アプリケーション中の適合しない関数それぞれにつき１つのＳｔｒｕｃｔｕｒｅ  Ｈｏｏｋ  ＡＰＩを含む。ただし、当業者には理解されるであろうが、単一の構造体を使用して、別々の構造体に含まれる情報を含めることもできる。さらに、異なる３つ以上の構造体が単一のスタブ関数を呼び出すこともできる。モジュール名は、適合しないプログラムのモジュールを示す。関数名は、アプリケーション中の適合しないと判定された関数を示す。Ｓｔｕｂ  ｆｕｎｃｔｉｏｎ（ｆ）は、適合しない関数の代わりに呼び出されることになる、Ｈｏｏｋ  ＤＬＬに含まれる関連する関数を示す。ＤＬＬのリストは、アプリケーションを適合させるためにパッチを当てる必要のある、適合しないアプリケーションのＤＬＬをすべて含む。ＮＵＬＬは、すべてのアプリケーションＤＬＬにパッチを当てる必要があることを示すために提供される。
【００３８】
図６Ａ〜Ｃは、本発明の実際の一実施形態で、ＤＬＬに含まれる適合しない関数をどのようにＨｏｏｋ  ＤＬＬ内にある適合スタブ関数で置換するかを示す一連の図である。図６Ａおよび６Ｂには、アプリケーションに関連する２つのＤＬＬと、適合しないアプリケーションにパッチを当てるために使用される１つのＨｏｏｋ  ＤＬＬとを示す。ロードされた各ＤＬＬには、インポートテーブルが関連付けられている。図６Ａ〜Ｃに示すインポートテーブル１４０、１４２、および１４４は、ＤＬＬに含まれる関数および関数ポインタのリストを含む。インポートテーブルはまた、ＤＬＬ１のインポートテーブル１４０で示すように、別個のＤＬＬにある他の関数への参照またはポインタを含む場合もある。一般にＳｈｉｍ  ＤＬＬは、適合しない関数を含むＤＬＬに関連するインポートテーブル内の、適合しない位置にパッチを当てる。アプリケーションの関連ＤＬＬがロードされているとき、Ｓｈｉｍ  ＤＬＬは、インポートテーブルに含まれるすべての情報を列挙する。次いでＳｈｉｍ  ＤＬＬは、適合しないエントリがあるかどうかインポートテーブルを検索する。
【００３９】
図６Ａに示すＤＬＬ１のインポートテーブル１４０は、ＤＬＬ２に含まれる関数への参照を含む。このエントリは、インポートテーブルのこの位置にロードされる関数がＤＬＬ２のインポートテーブル１４２中にあり、ｆＡと呼ばれることを示している。アプリケーションが適合するときは、インポートテーブル１４０中のｆＡ参照は、ＤＬＬ２内にある関数の実際の位置で置換される。この例では、アプリケーションが適合する場合、ＤＬＬ１中のｆＡはＤＬＬ２に含まれるｆＡ（０ｘ０００５）で置換されることになる。オペレーティングシステムは、ＤＬＬ１中のｆＡおよびＤＬＬ２の参照を、ＤＬＬ２中にみられるｆＡの実際の値で置換する。しかし、適合しないアプリケーションにおいては、適合しないと判定された関数があれば、その関数はＨｏｏｋ  ＤＬＬに含まれる値で置換されることになる。Ｈｏｏｋ  ＤＬＬのインポートテーブル１４４は、関数が適合しないせいで、ｆＡが、ＤＬＬ２に含まれる値ではなく、ＤＬＬ２に含まれる０ｘ０００５と比較して実際には値０ｘ０００１を有することを示している。したがって、識別されたいずれかのＤＬＬ中にｆＡへの参照があれば、インポートテーブル中のｆＡの値はＨｏｏｋ  ＤＬＬに含まれる値で置換される必要がある。
【００４０】
図６Ｂには、ＤＬＬ２のインポートテーブル１４２に含まれるｆＡを、Ｈｏｏｋ  ＤＬＬに含まれる訂正済みアドレスで置換することが示されている。図６Ｂを参照するとわかるように、関数ｆＡの適合バージョンは０ｘ０００１である。この値がＤＬＬ２のインポートテーブル１４２に挿入され、それによって前の値０×０００５が置換される。ＤＬＬ２内にｆＡへの参照が他にもあれば、それらもまたこの関数のパッチ済みバージョンで置換される。
【００４１】
図６Ｃには、ＤＬＬ１のインポートテーブル１４０に含まれるｆＡへの参照を、ＤＬＬ２のインポートテーブル１４２に含まれる訂正済みのｆＡの値で置換することが示されている。ＤＬＬ１のインポートテーブル１４０を参照すると、参照が０ｘ０００１で置換されたことがわかる。この例のこの時点で、適合しない関数へのすべての参照が、Ｈｏｏｋ  ＤＬＬに含まれる訂正済みの関数位置で置換されている。
【００４２】
適合しないと識別された各関数につき、Ｓｈｉｍ  ＤＬＬは、識別されたＤＬＬを検索するか、Ｓｔｒｕｃｔｕｒｅ  Ｈｏｏｋ  ＡＰＩ中でＮＵＬＬが識別される場合はアプリケーションのＤＬＬをすべて検索し、適合しない関数へのすべての参照をＨｏｏｋ  ＤＬＬに含まれる値で置換する。これらの参照にパッチが当てられた後で、アプリケーションが実行される。ただしアプリケーションは、適合しない関数を呼び出す代わりに、適合するスタブ関数を呼び出す。
【００４３】
本発明の好ましい実施形態について図示および記述したが、本発明の趣旨および範囲を逸脱することなく様々な変更を加えることができることを理解されたい。
【図面の簡単な説明】
【図１】  本発明のための例示的な動作環境を提供するのに適したコンピュータのブロック図である。
【図２】  本発明を示す概略流れ図である。
【図３】  アプリケーションがオペレーティングシステムに適合するまたは適合しないことをどのように判定するかを示す流れ図である。
【図４】  ＤＬＬを使用して適合しないアプリケーションにどのようにパッチを当てるかについての論理を示す流れ図である。
【図５】  擬似コードによるＨｏｏｋ  ＤＬＬの図である。
【図６Ａ】  インポートテーブルと、総称関数名を実際の関数へのポインタで置換することを示す図である。
【図６Ｂ】  インポートテーブルと、適合しない関数ポインタをＨｏｏｋ  ＤＬＬ内に含まれる関数ポインタの値で置換することを示す図である。
【図６Ｃ】  インポートテーブルと、適合しない関数名をＨｏｏｋ  ＤＬＬから供給される訂正済み関数ポインタで置換することを示す図である。
【図１】
0004878715.tif 000002
【図２】
0004878715.tif 000003
【図３】
0004878715.tif 000004
【図４】
0004878715.tif 000005
【図５】
0004878715.tif 000006
【図６Ａ】
0004878715.tif 000007
【図６Ｂ】
0004878715.tif 000008
【図６Ｃ】
0004878715.tif 000009