JP2013214247A - 情報処理装置、制御方法、およびプログラム - Google Patents

Abstract

【課題】 システム環境に適したインストーラを使用しインストールを行う情報処理装置を提供する。
【解決手段】 アプリケーションがインストールされていなかった場合は、第１のインストーラを使用しアプリケーションのインストールを行い、修正モジュールをインストールすることでインストールされているアプリケーションのバージョンが変化する場合は、第２のインストーラを使用し修正モジュールのインストールを行うよう制御する。
【選択図】 図５

Description

本発明は、インストーラを使用しアプリケーションをインストールする情報処理装置、制御方法、およびプログラムに関する。

アプリケーションの高機能化に伴い、ソフトウェアを使用するために必要なシステム環境（システム環境とは、オペレーティングシステム（ＯＳ）のファイル、レジストリ、サービス、設定の状況、およびアプリケーションのイストール状況を指す）の変更も年々増大してきた。このため、情報処理装置にインストールするソフトウェアのモジュール数が増加し、更に、モジュールを動作させるために必要なレジストリへの記述、ＯＳのセキュリティ設定の変更など、システム環境に対応して変更するための項目は枚挙にいとまがない。

結果、アプリケーションのバージョンアップを行うためのサービスパックインストーラ、およびＯＳのアーキテクチャごとに３２ｂｉｔインストーラと６４ｂｉｔインストーラを用意するという形でインストーラの種類が増加した。インストーラが増加したことで、ユーザはインストールしたいアプリケーションに対応するインストーラを選択する必要があった。例えば、３２ｂｉｔメジャーバージョン、３２ｂｉｔサービスパックの２種類のインストーラがインストールメディア内に記憶されている場合、ユーザは自分のシステム環境に適したインストーラを自ら選択しなければならない。

このような問題を鑑み、情報処理装置にインストールメディアを挿入した際、ＯＳの自動実行機能により、ユーザにインストーラを選択させることなくインストーラの処理を実行する技術が生まれた。例えば、メジャーバージョンのインストーラとサービスパックのインストーラを記憶したインストールメディアを情報処理装置に挿入した場合、自動実行機能によってメジャーバージョンインストーラが起動するソフトウェアがある。

また、アプリケーションの自動インストールに関する技術として特許文献１が挙げられる。特許文献１では、情報処理装置にインストールされているアプリケーションのバージョンを管理、抽出を行う管理装置が、情報処理装置にインストール可能なアプリケーションをインストールする技術が開示されている。この技術も、自動実行機能の一種である。

特開２００１−２３６２１１

従来の自動実行機能には、インストーラを実行する情報処理装置のシステム環境に応じ、適切なインストーラを使用しアプリケーションをインストールするというような機能がない。結果、情報処理装置のシステム環境に適したインストーラを使用しアプリケーションをインストールできるとは限らない。

本発明は、上記課題を鑑み、システム環境に適したインストーラを使用しインストールを行う情報処理装置を提供することを１つの目的とする。

本発明の一実施形に係る情報処理装置は、複数のソフト部品から構成されたアプリケーションをインストールする第１のインストーラと、前記アプリケーションを構成するソフト部品を変更するために修正モジュールをインストールする第２のインストーラとを記憶する記憶手段と、前記アプリケーションがインストールされていなかった場合は、記憶された前記第１のインストーラを使用しアプリケーションのインストールを行い、前記修正モジュールをインストールすることでインストールされている前記アプリケーションが変化する場合は、記憶された前記第２のインストーラを使用し修正モジュールのインストールを行うよう制御することを特徴とする。

本発明によれば、システム環境に適したインストーラを使用しインストールを行う情報処理装置を提供することができる。

情報処理装置のハードウェア構成を示す図である。 ソフトウェアの構成を説明するソフトウェア構成図である。 レジストリ情報、および、インストーラ情報を示す図である。 インストーラ管理画面のユーザインタフェースのＵＩを示す図である。 インストーラによるインストール処理のフローチャートである。 インストーラによるアプリケーションの管理処理のフローチャートである。 インストーラにより出力されるログデータを示す図である。

始めに、インストーラを使用しアプリケーションをインストールする情報処理装置、制御方法、およびプログラムにおける課題についてより詳細に述べる。

１つ目は、情報処理装置にインストール済みのアプリケーションに対しユーザがサービスパックを適用しようとした場合、自動実行機能によりメジャーバージョンインストーラが起動され、アプリケーションを修復、または、削除するための管理画面が表示されることで発生する問題を解決する。その問題とは、アプリケーションにサービスパックを適用したいユーザは、その管理画面を閉じる指示を行い、その後、インストールメディアからサービスパックインストーラを選択し起動しなければならないため、操作が手間であるという問題である。この問題は、メジャーバージョンインストーラからサービスパックインストーラを起動するために必要な幾つかのロジックが従来技術には存在しないため発生する。

２つ目は、ＯＳのアーキテクチャの差異により適正なインストーラが起動できない問題を解決する。ここで、Ｗｉｎｄｏｗｓ（登録商標）を例にこの問題が抱える一側面を説明する。６４ｂｉｔ環境で自動実行機能により３２ｂｉｔインストーラが起動すると、６４ｂｉｔのインストーラを使用する旨をエラーで表示することがある。そのため、このようなエラーが表示された場合、ユーザは手動で６４ｂｉｔのインストーラを起動する必要がある。

また、ＯＳのアーキテクチャが３２ｂｉｔ、６４ｂｉｔのどちらでも動作するＷＯＷ６４インストーラが存在するが、このインストーラでは次の様な問題を解決できていない。ＷＯＷ６４インストーラは３２ｂｉｔプロセスとして起動しエミュレーションを行うため、エミュレーション用のソフトウェアを使用する。エミュレーション用のソフトウェアは６４ｂｉｔでは使用されないため、ＷＯＷ６４インストーラは６４ｂｉｔインストーラにパフォーマンスで劣る。

また、ＷＯＷ６４インストーラがインストール処理中に使用する６４ｂｉｔアプリケーションとの互換性が悪く、６４ｂｉｔのＤＬＬをロード出来ない問題もある。更に、ＷＯＷ６４インストーラは３２ｂｉｔ、６４ｂｉｔがそれぞれのインストーラに比べレジストリ操作やフォルダ操作が複雑になるため、インストーラを作成する開発者の開発工数が増すという懸念もある。以上の様な理由から、エミュレーションを行うインストーラよりもＯＳのアーキテクチャに最適なインストーラが起動する方が好ましいが、ユーザの操作に手間がかかる。

以上が本発明の更なる課題であり、本発明が提供する情報処理装置によって、これらの課題の内少なくとも１つを解決することが可能となる。

次に、本願発明を説明する上で使用する用語について説明する。

６４ｂｉｔ環境は、３２ｂｉｔ環境と比較し、一度の処理においてメモリに展開できるデータ量が多く、かつ１クロックの処理量が多いアーキテクチャであり、データ処理速度が３２ｂｉｔ環境よりも速いアーキテクチャである。換言すれば、６４ｂｉｔ環境と３２ｂｉｔ環境はデータ処理のロジックが異なるアーキテクチャである。３２ｂｉｔ環境が第１のアーキテクチャ、６４ｂｉｔ環境が第２のアーキテクチャに相当する。

アプリケーションは、特定の処理の開始を指示させるためのユーザインターフェースを所望の結果を得たいユーザに対して提供する他、ユーザインターフェースを介して入力された設定に基づき特定の処理の実行を実現するためのソフトウェアである。アプリケーションはコンポーネントで構成されており、各コンポーネントにはユーザインターフェースを提供する役割、または特定の処理を実行する役割、と言った役割が与えられている。コンポーネントはその役割を達成するためのソフトウェア部品である。なお、各コンポーネントはモジュールと呼ばれるソフトウェア部品の集合体であり、一般的に、アプリケーションはモジュール単位でしばしば不具合が発生する。その不具合を解消するために配布されるのが、不具合を解消するモジュール群を内包するサービスパックである。コンポーネント、およびモジュールは、規模は違えど、アプリケーションを構成する部品であることは共通であるため、本願発明では両方を含めてソフト部品と称する。ソフト部品と称する場合、アプリケーションを構成するソフトウェアを指すことになる。

また、アプリケーションはＯＳ上で実行されるものであり、ＯＳ上にインストールされることで実行可能となる。また、アプリケーションはＯＳに依存するソフトウェアであり、ＯＳの差異、または同じＯＳであってもアーキテクチャの差異を考慮し、夫々のシステム環境に適したソフトウェア構成を持つ必要がある。システム環境に適したソフトウェア構成を持たないアプリケーションが情報処理装置にインストールされた場合、アプリケーションの本来の機能を十分に発揮できなくなる他、場合によっては情報処理装置の動作にも影響を与えかねない。

インストーラは、ＯＳを備えた情報処理装置に対してアプリケーションをインストール、またはアンインストールする他、インストールされたアプリケーションを修復するための補助ソフトウェアである。ユーザは、インストーラを使用することで容易にアプリケーションのインストールを達成することが可能になる。インストーラは、夫々のシステム環境に適したソフトウェア構成を持つ複数のアプリケーション毎に用意されているものとする。各インストーラは、アプリケーションの機能を十分に発揮させるために最適なインストール処理を実現する。

以下、本発明の実施の形態を図面に基づいて説明する。

図１は、本発明の一実施形態において適用されるシステム環境のハードウェア構成を示す図であり、具体的には、情報処理装置１００のハードウェア構成を示す図である。図１において、情報処理装置１００はユーザが使用するコンピュータである。なお、情報処理装置１００には、所定のオペレーティングシステム（ＯＳ）がインストールされ、かつ特定の機能処理を実行する各種のアプリケーションもインストールされている。

また、情報処理装置１００はユーザ操作入力を受信する入力デバイスであるキーボード１０５とポインティングデバイス１０６が設けられている。さらに、情報処理装置１００は、ユーザに視覚的な出力情報フィードバックを与える表示部１０２を備える。

さらに、本実施形態における各種プログラムや実行情報を保管する記憶デバイスＲＡＭ
１０３、ＲＯＭ １０４、ＨＤＤ１０７が設けられる。また、ＣＤ／ＤＶＤ１１０に記録されたデータを読み取るためのＣＤ−ＲＯＭ／ＤＶＤ−ＲＯＭドライブ１０８も設ける。

ＲＡＭ１０３は、ＣＰＵ１０１によりＯＳや本発明を実現するための制御プログラムを含むその他の制御プログラムがロードされ実行される。また、制御プログラムを実行するために用いられる各種作業領域、一時待避領域として機能する。ＲＯＭ１０４は、ＣＰＵ１０１の各種制御を実行する各種制御プログラムを記憶している。さらに、外部機器との通信を行うインターフェイスデバイスＩ／Ｏ１０９を備え、プログラム実行を行うＣＰＵ１０１を備える。なお、周辺機器との接続形態は有線／無線を問わない。

図２は、情報処理装置１００のソフトウェアの構成を説明するソフトウェア構成図の一例を示す図である。

３２ｂｉｔメジャーバージョンインストーラ２００は、アプリケーションのインストールを実行する上で必要となるユーザインタフェースを提供する。また、３２ｂｉｔメジャーバージョンインストーラ２００は、提供したユーザインターフェースを介して受け付けたユーザからの要求に従いアプリケーションのインストールに必要な処理を行う。また、３２ｂｉｔメジャーバージョンインストーラ２００は、ＨＤＤ１０７により実現される記憶部２０７、またはＣＤ／ＤＶＤ１１０に記憶されたプログラムを、ＣＰＵ１０１により実行されることで実現される。なお、各インストーラはＲＡＭ１０３に記憶された後ＣＰＵ１０１により実行され、実行情報、および一時データはＲＡＭ１０３に記憶される。即ち、図２のソフトウェア構成を実現したＣＰＵ１０１は、各種ソフトウェアが提供する処理が実行されるように制御する。

また、６４ｂｉｔメジャーバージョンインストーラ２１０、３２ｂｉｔサービスパックインストーラ２２０、６４ ｂｉｔサービスパックインストーラ２３０は、３２ｂｉｔメジャーバージョンインストーラ２００と同等の機能を担う。記憶部２０７、またはＣＤ／ＤＶＤ１１０には、６４ｂｉｔメジャーバージョンインストーラ２１０、３２ｂｉｔサービスパックインストーラ２２０、６４ ｂｉｔサービスパックインストーラ２３０、３２ｂｉｔメジャーバージョンインストーラ２００の計４つのインストーラが記憶されている。３２ｂｉｔメジャーバージョンインストーラ２００は第１のインストーラに相当する。３２ｂｉｔサービスパックインストーラ２２０は第２のインストーラに相当する。６４ｂｉｔメジャーバージョンインストーラ２１０は、第３のインストーラ、または第２のインストーラに相当する。６４ ｂｉｔサービスパックインストーラ２３０は第４のインストーラに相当する。

なお、インストール処理に関するログデータを出力するログ出力機能に関しては、３２ｂｉｔメジャーバージョンインストーラ２００に限り、それ以外の各インストーラ―とは異なるログ出力機能を有している。詳細は後述するが、３２ｂｉｔメジャーバージョンインストーラ２００と、それ以外の各インストーラ―が出力するログデータには差異がある。各インストーラは３２ｂｉｔメジャーバージョンインストーラ２００と同様に実現される。

また、各インストーラは異なるシステム環境毎に用意されたインストーラであるため、各インストーラによりインストールされるコンポーネント、および／またはモジュールはインストーラ毎に異なる。例えば、３２ｂｉｔメジャーバージョンインストーラ２００は、システムやプログラム等の仕様に大幅に修正があったバージョン、または新規アプリケーションをインストール可能である。３２ｂｉｔサービスパックインストーラ２２０は、メジャーバージョンのアプリケーションに対して、小幅な修正をするための修正モジュールを適用し、バージョンアップインストールすることが可能である。

換言すれば、メジャーバージョンインストーラは、ユーザに対し新たな効果を提供するためのアプリケーションであって、特定の処理を実行するためのコンポーネントを備えたメジャーバージョンのアプリケーションをインストールするためのインストーラである。一方、サービスパックインストーラは、その特定の処理を実行するコンポーネントを構成するモジュールを追加・修正するためのモジュールを、インストールされたアプリケーションのコンポーネントに対し適用するためのインストーラである。サービスパックインストーラは、インストールされたアプリケーションを構成するモジュールを変更するための修正モジュールを提供するためのインストーラである。

また、６４ｂｉｔに関する各インストーラは、６４ｂｉｔ環境に適応されたメジャーバージョンのアプリケーション、および修正プログラムを情報処理装置１００にインストールさせるインストーラである。

３２ｂｉｔメジャーバージョンインストーラ２００を構成するコンポーネントを２０１〜２０３で示す。３２ｂｉｔメジャーバージョンインストーラ２００におけるインストーラ実行部２０１は、３２ｂｉｔ用のアプリケーションのインストール、アンインストール、修復インストール、ログデータの出力、アプリケーションの設定構築機能を有する。また、インストーラ実行部２０１は、環境解析部２０３で解析された情報を基に異なるインストーラを起動させる。そして、別のプロセス上で起動するインストーラがインストール処理を継続して行う。

インストーラＵＩ部２０２は、３２ｂｉｔメジャーバージョンのアプリケーションをインストールさせるためのユーザインタフェースの構築、およびユーザからの各種入力操作の受け付けを処理する。

環境解析部２０３は、情報処理装置１００の環境情報の取得、および解析を行う。環境情報とは、例えば、ＯＳのアーキテクチャ情報、ＯＳのバージョン情報、レジストリ情報、環境変数、インストールされているソフトウェア情報、アプリケーションの各種設定等である。なお、必ずしも全ての情報が環境情報として取り扱われるわけではない。各インストーラは環境解析部２０３を介して後述する判断処理を行うわけだが、環境解析部２０３は取得した環境情報を取得し、解析した結果をインストーラに送信する構成としている。しかし、取得した環境情報をそのままインストーラに送信する構成でも良い。本実施例では、取得した環境情報を送信すると表現された場合、両方の構成を含むものとする。

６４ｂｉｔメジャーバージョンインストーラ２１０を構成するコンポーネントを２１１〜２１３で示す。各コンポーネント２１１〜２１３は、３２ｂｉｔの各コンポーネント２０１〜２０３の６４ｂｉｔ環境に対応している。インストーラ実行部２１１はインストーラ実行部２０１、インストーラＵＩ部２１２はインストーラＵＩ部２０２、環境解析部２１３は環境解析部２０３と対応している。３２ｂｉｔサービスパックインストーラ２２０を構成するコンポーネントを２２１〜２２３で示す。

インストーラ実行部２２１は、３２ｂｉｔサービスパックインストーラ２２０において、アプリケーションのインストールやログデータの出力、アプリケーションの設定構築機能を担う。また、環境解析部２０３で解析した情報を基にインストール処理を変更する。

インストーラＵＩ部２２２は、３２ｂｉｔサービスパックインストーラ２２０において、ユーザインタフェースの構築やユーザからの各種入力操作の受け付けを処理する。

環境解析部２２３は、３２ｂｉｔサービスパックインストーラ２２０で情報処理装置１００の環境情報を解析する機能を担う。

６４ｂｉｔサービスパックインストーラ２３０を構成するコンポーネントを２３１〜２３３で示す。各コンポーネント２３１〜２３３は、３２ｂｉｔの各コンポーネント２２１〜２２３の６４ｂｉｔ用として対応している。インストーラ実行部２３１はインストーラ実行部２２１、インストーラＵＩ部２３２はインストーラＵＩ部２２２、環境解析部２３３は環境解析部２２３と対応している。

アプリケーション２４０は、上述したアプリケーションと同等のソフトウェアである。

図３は、情報処理装置１００のレジストリ情報３００、および、各種インストーラ２００、２１０、２２０、２３０のインストーラ情報３１０の一例を示す。レジストリ情報３００は、情報処理装置１００のレジストリ情報一覧を示し、情報処理装置１００にインストールされているアプリケーション２４０の情報を保持する。例えば、レジストリ情報３００は、バージョン情報３０１、ＰｒｏｄｕｃｔＣｏｄｅ３０２、ＵｐｇｒａｄｅＣｏｄｅ、ＧＵＩＤ、インストールパス等を保持する。

バージョン情報３０１は、情報処理装置１００にインストールされているアプリケーション２４０のバージョンを示す。例えば、バージョン情報３０１の値が「３．０．０」であれば、メジャーバージョンが「３」、マイナーバージョン「０」、リビジョン（適用されたサービスパックのバージョン）「０」のアプリケーション２４０がインストールされていることになる。リビジョン「０」の場合、サービスパックはインストールされていないと判断できる。

ＰｒｏｄｕｃｔＣｏｄｅ３０２は、アプリケーション２４０に対して一意なコードで、レジストリ情報３００にアプリケーション２４０のＰｒｏｄｕｃｔＣｏｄｅ３０２が存在すれば、アプリケーション２４０がインストールされているということになる。

インストーラ情報３１０は、各種インストーラ２００、２１０、２２０、２３０のインストール処理に必要な情報を保持する。前記インストーラ情報３１０は、設定ファイル、または、各インストーラ内部に保持している情報である。インストーラ情報３１０は、各種インストーラ２００、２１０、２２０、２３０のバージョン情報３１１、ＰｒｏｄｕｃｔＣｏｄｅ３１２、ＵｐｇｒａｄｅＣｏｄｅ、ＧＵＩＤ等を保持する。

バージョン情報３１１は、インストーラがインストール可能なアプリケーションのバージョンを示す。例えば、バージョン情報３０１の値が「３．０．１」であれば、メジャーバージョンが「３」、マイナーバージョン「０」、リビジョン（サービスパックのバージョン）「１」のアプリケーション２４０に対応するインストーラとなる。リビジョン「１」の場合、サービスパックのバージョン「１」がインストールされていると判断できる。ＰｒｏｄｕｃｔＣｏｄｅ３１２は、アプリケーション２４０に対して一意なコードで、各インストーラによって、レジストリ情報３００のＰｒｏｄｕｃｔＣｏｄｅ３０２にＰｒｏｄｕｃｔＣｏｄｅ３１２が書き込まれる。一般的に製品のメジャーバージョン、マイナーバージョンが同じ場合、ＰｒｏｄｕｃｔＣｏｄｅ３０２は同じコードを使用する。即ち、サービスパックをインストールした場合は、レジストリ情報３００に書き込まれるＰｒｏｄｕｃｔＣｏｄｅ３０２の値は変化しない。

図３を例にまとめると、レジストリ情報３００を有する情報処理装置１００はメジャーバージョンであるバージョン３．０のアプリケーションがインストールされており、バージョン情報３１１を有するインストーラはサービスパックであると言える。レジストリ情報３００、および、インストーラ情報３１０の情報は、インストーラ２００、２２０が実行するインストール処理時に利用される。また、レジストリ情報３００、インストーラ情報３１０の記載表現は、この記載に限ったものではない、また、記述される情報もこれに限ったものではない。

図４は、アプリケーションを操作するためのインストーラ管理画面のユーザインタフェースを示す。

図４の画面は、情報処理装置１００のＯＳにおけるインストーラの仕様で表示される画面である。また、図４の画面は、従来のインストーラにより表示されるインストーラ管理画面でもあり、実施例１における３２ｂｉｔメジャーバージョンインストーラ２００、および６４ｂｉｔメジャーバージョンインストーラ２１０により表示されるインストーラ管理画面でもある。アプリケーションがインストール済みの環境では、アプリケーションをインストールするためのインストーラを起動すると表示される。一般的に、インストール済みのアプリケーションにサービスパックを適用する場合、サービスパック用のインストーラを起動する必要がある。しかし、ＯＳの自動実行機能によってメジャーバージョン用のインストーラが起動すると、図４のような管理画面が起動してしまうため、ユーザは手動で画面を閉じる指示を行い、サービスパック用のインストーラを起動しなければならない。このような手順になるのは、情報処理装置１００にメディアが挿入された際、ＯＳの自動実行機能がメディア内に含まれているソフトウェアを一つしか起動できないからである。

実施例１では、３２ｂｉｔメジャーバージョンインストーラ２００、または、６４ｂｉｔメジャーバージョンインストーラ２１０でインストール可能なアプリケーション２４０が情報処理装置１００にインストール済みである場合に、メジャーバージョンのアプリケーションに対応したインストーラを起動することによって図４が表示される。

インストーラ管理画面ウインドウ４００は、インストーラＵＩ部２０２のユーザインタフェースを示している。修復処理ラジオボタン４０１は、情報処理装置１００にインストールされているアプリケーション２４０の修復を行う際に選択するラジオボタンを示す。例えば、３２ｂｉｔメジャーバージョンインストーラ２００により管理画面が表示され、修復を行う選択がされた場合は、３２ｂｉｔメジャーバージョンインストーラ２００によりアプリケーションのインストールが行われる。即ち、メジャーバージョンのアプリケーションの動作が芳しくないような場合に、再インストールを行う目的として使用される。削除処理ラジオボタン４０２は、情報処理装置１００にインストールされているアプリケーション２４０の削除（アンインストール）を行う際に選択するラジオボタンを示す。

開始ボタン４０３は、ボタンが押下されたことによって、修復処理ラジオボタン４０１、または、削除処理ラジオボタン４０２のいずれかで選択された処理を開始する。処理終了後、インストーラ管理画面ウインドウ４００を閉じる。キャンセルボタン４０４は、ボタンが押下されたことによって、インストーラ管理画面ウインドウ４００を閉じる。

図５は、３２ｂｉｔメジャーバージョンインストーラ２００、６４ｂｉｔメジャーバージョンインストーラ２１０、３２ｂｉｔサービスパックインストーラ２２０、または６４ｂｉｔサービスパックインストーラ２３０により実行されるインストール処理のフローチャートを示している。本フローチャートが開始されるトリガーは、インストーラ実行部２０１がメジャーバージョンインストーラ２００の実行を示す操作を受け付けた際、または、ＯＳの自動実行機能によって３２ｂｉｔメジャーバージョンインストーラ２００が起動した際に開始される。起動とは、インストーラがインストール処理を開始したことを指し、起動と同時にＲＡＭ１０３にインストーラのプログラムをロードしてインストール処理を実行する。

実施例１では、３２ｂｉｔメジャーバージョン、３２ｂｉｔサービスパック、６４ｂｉｔメジャーバージョン、６４ｂｉｔサービスパックのインストーラが一つのメディア（例えば、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の記憶媒体）に記憶されているものとする。しかし、インストーラが所定のフォルダに配置されていれば、メディアから実行される処理に限ったものとしない。何れの場合にせよ、インストーラ２００、２１０、２２０、２３０はＲＡＭ１０３に一度記憶され、ＣＰＵ１０１により実行される。インストーラ２００、２１０、２２０、２３０は、インストーラ起動と同時にログデータを生成し、インストール処理と並行してインストーラ終了時までに発生する現象を把握するためのログデータを出力する。ログデータの出力処理については後述する。

また、図５に示された実線の区切りは、処理の主体が異なることを意味している。具体的には、左から、３２ｂｉｔメジャーバージョン、３２ｂｉｔサービスパック、６４ｂｉｔメジャーバージョン、６４ｂｉｔサービスパックのインストーラにより実行される処理である。

ステップ５００において、インストーラ実行部２０１は、環境解析部２０３を介し、情報処理装置に備えられたＯＳが３２ｂｉｔ、または、６４ｂｉｔのいずれのアーキテクチャで構成されているかを判断する。環境解析部２０３はＯＳが提供しているＡＰＩを利用しアーキテクチャに関する情報を取得し、インストーラ実行部２０１は取得された情報を基にＯＳが３２ｂｉｔであるか６４ｂｉｔであるかの判断を行う。なお、環境解析部２０３はＯＳの環境変数を参照する形態であっても良いため、アーキテクチャに関する情報の取得に限定はない。インストーラ実行部２０１は、何れかの方法でＯＳを構成しているアーキテクチャに関する情報を取得する。ＯＳが３２ｂｉｔ環境だった場合、ステップ５０１へ処理が遷移する。一方、ＯＳが６４ｂｉｔ環境だった場合、ステップ５０９へ処理が遷移する。

ステップ５０１において、インストーラ実行部２０１は、環境解析部２０３を介しレジストリ情報を取得する。そして、インストーラ実行部２０１は、レジストリ情報３００とインストーラ情報３１０を基に、起動したインストーラに対応するメジャーバージョンのアプリケーションが情報処理装置１００にインストール済みか否かを判断する。判断ロジックを具体的に説明する。インストーラ実行部２０１は、インストーラ情報３１０が保持するＰｒｏｄｕｃｔＣｏｄｅ３１２がレジストリ情報３００に保持されているかを解析する。レジストリ情報３００のＰｒｏｄｕｃｔＣｏｄｅ３０２にＰｒｏｄｕｃｔＣｏｄｅ３１２と一致するコードが含まれていた場合、メジャーバージョンのアプリケーションがインストール済みであると判断する。一方、レジストリ情報３００のＰｒｏｄｕｃｔＣｏｄｅ３０２にＰｒｏｄｕｃｔＣｏｄｅ３１２と一致するコードが含まれてなかった場合、メジャーバージョンがインストール済みでないと判断され、ステップ５０２へ処理が遷移する。

インストーラ実行部２０１がメジャーバージョンのアプリケーションがインストール済みと判断した場合、次に、ＰｒｏｄｕｃｔＶｅｒｓｉｏｎのバージョン情報３０１と、ＩｎｓｔａｌｌｅｒＶｅｒｓｉｏｎのバージョン情報３１１のメジャーバージョンが一致するか否かを判断する。なぜなら、例えば、バージョン情報３０１が「３．０．０」、バージョン情報３１１が「４．０．１」である場合、メディア等に記憶されたアプリケーションの最新のコンポーネントをインストールする必要があるからである。一致していれば、既に最新のアプリケーションがインストールされているのでステップ５０３へ処理が遷移する。一方、一致していなければ、アプリケーションはインストールされているが最新の機能は利用できない状態なので、Ｓ５０２へ処理が遷移する。ステップ５０２において、インストーラ実行部２０１は、３２ｂｉｔメジャーバージョンのアプリケーションのインストール処理を行う。このステップが実行されることで、アプリケーション２４０は３２ｂｉｔメジャーバージョンのアプリケーションとなる。

ステップ５０３において、インストーラ実行部２０１は、３２ｂｉｔサービスパックインストーラ２２０が存在するか否かを判断する。３２ｂｉｔサービスパックインストーラ２２０が所定の位置に存在する場合、ステップ５０４へ処理が遷移する。所定の位置に存在とは、例えば、３２ｂｉｔサービスパックインストーラ２２０がインストールメディア内に存在しＲＡＭ１０３にインストーラがロードされた状態、または、インストールメディアの中身をＯＳのフォルダにコピーし、そのフォルダ内のインストーラがロードされた状態を指す。一方、３２ｂｉｔサービスパックインストーラ２２０が所定の位置に存在しない場合、ステップ５０５へ処理が遷移する。

ステップ５０４において、インストーラ実行部２０１は、環境解析部２０３を介し、サービスパック対応済みアプリケーションがインストール済みであるか否かを判断する。換言すれば、インストーラ実行部２０１は、修正モジュールをインストールすることで、インストールされているアプリケーション２４０のバージョンに変化が発生する否かを判断する。この判断ロジックは、次の２ステップで構成される。

インストーラ実行部２０１は、３２ｂｉｔサービスパックインストーラ２２０が保持するインストーラ情報３１０のＰｒｏｄｕｃｔＣｏｄｅ３１２がレジストリ情報３００のＰｒｏｄｕｃｔＣｏｄｅ３０２に存在するか否かを判断する。次に、インストーラ実行部２０１は、レジストリ情報３００が保持するバージョン情報３０１と３２ｂｉｔサービスパックインストーラ２２０が保持するインストーラ情報３１０のバージョン情報３１１の値を比較する。例えば、３２ｂｉｔサービスパックインストーラ２２０が保持するＰｒｏｄｕｃｔＣｏｄｅ３１２がレジストリ情報３００のＰｒｏｄｕｃｔＣｏｄｅ３０２に存在すれば、インストーラ実行部２０１は、少なくともメジャーバージョンのアプリケーションがインストールされていると判断する。また、バージョン情報３０１が「３．０．０」、バージョン情報３１１が「３．０．１」である場合、バージョン情報３０１のリビジョンがバージョン情報３１１より大きいため、インストーラ実行部２０１はサービスパックがインストールされていないと判断する。無論、バージョン情報３０１のリビジョンがバージョン情報３１１より小さい場合であっても良く、その場合も、インストーラ実行部２０１はサービスパックがインストールされていないと判断する。なお、アプリケーション２４０に対し、アプリケーションの構成を変更するためのモジュールが適用されているか否かの判断はバージョン情報を基に判断する形態に限られない。例えば、レジストリ情報３００にサービスパックがインストールされているか否かを示す情報が記載された場合は、バージョン情報を比較することなく、サービスパックをインストールするか否かの判断はできる。この判断ロジックであったとしても、結果としてアプリケーション２４０のバージョンは、サービスパックのインストーラによる修正モジュールの適用前と比較し変化する。

レジストリ情報３００にインストーラ情報３１０のＰｒｏｄｕｃｔＣｏｄｅ３１２が存在し、かつ、バージョン情報３０１とバージョン情報３１１が一致する場合、サービスパック対応済みアプリケーションがインストール済みであると判断され、ステップ５０３へ処理が遷移する。一方、レジストリ情報３００にインストーラ情報３１０のＰｒｏｄｕｃｔＣｏｄｅ３１２が存在し、かつ、バージョン情報３０１とバージョン情報３１１が同一でない場合、サービスパック対応済みアプリケーションがインストール済みでないと判断され、３２ｂｉｔサービスパックインストーラ２２０を起動するように制御する。この際、３２ｂｉｔメジャーバージョンインストーラ２００は、３２ｂｉｔサービスパックインストーラ２２０のインストール処理が終了するまで一時的にインストール処理を停止する。そして、起動されたインストーラの処理が終了すると、３２ｂｉｔメジャーバージョンインストーラ２００の処理が再開する。このように、３２ｂｉｔメジャーバージョンインストーラ２００に限らず、インストール処理中のインストーラが他のインストーラを起動する際は、各インストーラはそれぞれ異なるプロセスで起動され、呼び出しもとのインストーラはインストール処理を一時停止する。そして、呼び出しもとのインストーラは、起動されたインストーラからインストール処理の終了を示す終了コードを取得したことに応じて、インストール処理を再開する。

ステップ５０５において、インストーラ実行部２０１は、今回の３２ｂｉｔインストーラの起動に伴い、ステップ５０２にてアプリケーション２４０のインストール処理を行ったか否かを判断する。ステップ５０２の処理を行った場合、アプリケーション２４０のインストール処理を行ったと判断し、ステップ５０７へ処理が遷移する。一方、ステップ５０２の処理を行わなかった場合、アプリケーション２４０のインストール処理を行わなかったと判断し、ステップ５０６へ処理が遷移する。

ステップ５０６において、インストーラ実行部２０１は、アプリケーション２４０を修復、または、削除するためのインストーラ管理画面を起動する。ステップ５０７において、インストーラ実行部２０１は、インストール処理の終了コードがエラーであるか否かを判断する。インストール処理の終了コードがエラーである場合、ステップ５０８へ処理が遷移する。一方、インストール処理の終了コードがエラーでない場合、３２ｂｉｔメジャーバージョンインストーラ２００のインストール処理を終了し、本フローチャートの処理を終了する。終了コードは、３２ｂｉｔメジャーバージョンインストーラ２００、６４ｂｉｔメジャーバージョンインストーラ２１０、３２ｂｉｔサービスパックインストーラ２２０から受け取ることが出来、受け取った終了コードを基にＳ５０７の判断を行う。なお、実施例１では、６４ｂｉｔサービスパックインストーラ２２０の終了コードは６４ｂｉｔメジャーバージョンインストーラ２１０に回収されるため、６４ｂｉｔサービスパックインストーラ２２０からエラーコードを受け取ることはない。また、３２ｂｉｔメジャーバージョンインストーラ２００のエラーコードは、インストーラ実行部２０１自身が発行するエラーコードである。

ステップ５０８において、インストーラ実行部２０１は、終了コードを基にインストールの後処理を行う。インストールの後処理とは、メッセージウインドウを表示してエラー概要を表示する他、ＯＳの再起動を促す旨を表示する。即ち、各インストーラによりエラーが発生した場合であっても、インストールの後処理は呼び出し元のインストーラである３２ｂｉｔメジャーバージョンインストーラ２００により行われる。本フローチャートでは、メッセージウインドウを３２ｂｉｔメジャーバージョンインストーラ２００のみが表示する形になっているが、他のインストーラを単体で起動した場合も考慮し、メッセージウインドウを表示する仕組み自体は全てのインストーラが保持しているものとする。ではなぜ実施例１において、各インストーラがメッセージウインドウを表示せず、３２ｂｉｔメジャーバージョンインストーラ２００が代理でメッセージウインドウを表示するのかについての詳細な理由は後述する。なお、この理由を簡略的に述べると、３２ｂｉｔメジャーバージョンインストーラ２００が各インストーラのログデータを含めたログ出力処理を行うことに起因する。

ステップ５０９において、インストーラ実行部２０１は、６４ｂｉｔメジャーバージョンインストーラ２１０が存在するか否かを判断する。６４ｂｉｔメジャーバージョンインストーラ２１０が存在する場合、６４ｂｉｔメジャーバージョンインストーラ２１０が起動される。この判断処理は、Ｓ５０３の判断処理における３２ｂｉｔサービスパックインストーラ２２０を６４ｂｉｔメジャーバージョンインストーラ２１０に置き換えたものであるため詳細は省く。この際、３２ｂｉｔメジャーバージョンインストーラ２００は６４ｂｉｔメジャーバージョンインストーラ２１０のインストール処理が終了するまで一時的にインストール処理を停止する。そして、６４ｂｉｔメジャーバージョンインストーラ２１０の処理が終了すると、３２ｂｉｔメジャーバージョンインストーラ２００の処理が再開する。一方、６４ｂｉｔメジャーバージョンインストーラ２１０が存在しない場合、ステップ５０７へ処理が遷移する。６４ｂｉｔメジャーバージョンインストーラ２１０のインストール処理が開始されるトリガーは、インストーラ実行部２０１が６４ｂｉｔメジャーバージョンインストーラ２１０の実行を示す処理を、３２ｂｉｔメジャーバージョンインストーラ２００のインストーラ実行部２０１から受け付けたことによって開始される。

ステップ５４０において、インストーラ実行部２１１は、環境解析部２１３を介し、レジストリ情報３００とインストーラ情報３１０を基に６４ｂｉｔメジャーバージョンインストーラ２１０がメジャーバージョンのアプリケーションがインストール済みか否かを判断する。この判断ロジックは、Ｓ５０１における３２ｂｉｔメジャーバージョンのアプリケーションがインストール済みか否かの判断と同等である。具体的には、３２ｂｉｔメジャーバージョンのアプリケーションを、６４ｂｉｔメジャーバージョンのアプリケーションに置き換えて判断する形態である。以上からＳ５４０の詳細な説明は省略する。そして、メジャーバージョンのアプリケーションがインストール済みであると判断された場合、ステップ５４２へ処理が遷移する。一方、メジャーバージョンがインストール済みでないと判断された場合、ステップ５４１へ処理が遷移する。

ステップ５４１において、インストーラ実行部２１１は、アプリケーション２４０の６４ｂｉｔメジャーバージョンのアプリケーションのインストール処理を行う。このステップが実行されることで、アプリケーション２４０は６４ｂｉｔメジャーバージョンのアプリケーションとなる。

ステップ５４２において、インストーラ実行部２１１は、６４ｂｉｔサービスパックインストーラ２３０が存在するか否かを判断する。この判断ロジックは、Ｓ５０３における３２ｂｉｔサービスパックのインストーラが存在するか否かの判断と同等である。具体的には、３２ｂｉｔサービスパックのインストーラを、６４ｂｉｔサービスパックのインストーラに置き換えて判断する形態である。以上からＳ５４２の詳細な説明は省略する。そして、６４ｂｉｔサービスパックインストーラ２３０が所定の位置に存在すると判断された場合、ステップ５４３へ処理が遷移する。一方、６４ｂｉｔサービスパックインストーラ２３０が所定の位置に存在しないと判断された場合、ステップ５４４へ処理が遷移する。

ステップ５４３において、インストーラ実行部２１１は、環境解析部２１３を介し、レジストリ情報３００とインストーラ情報３１０を基にサービスパック対応済みアプリケーションがインストール済みか否かを判断する。この判断ロジックは、Ｓ５０４における３２ｂｉｔサービスパック対応済みアプリケーションがインストールされているか否かの判断と同等である。具体的には、３２ｂｉｔサービスパック対応済みアプリケーションを、６４ｂｉｔサービスパック対応済みアプリケーションに置き換えて判断する形態である。以上からＳ５４３の詳細な説明は省略する。

サービスパック対応済みアプリケーションがインストール済みであると判断された場合、ステップ５４４へ処理が遷移する。一方、サービスパック対応済みアプリケーションがインストール済みでないと判断された場合、６４ｂｉｔサービスパックインストーラ２３０を起動するように制御する。

この際、６４ｂｉｔメジャーバージョンインストーラ２１０は、６４ｂｉｔサービスパックインストーラ２３０のインストール処理が終了するまで一時的にインストール処理を停止する。そして、６４ｂｉｔサービスパックインストーラ２３０の処理が終了すると、６４ｂｉｔメジャーバージョンインストーラ２１０のインストール処理が再開する。

ステップ５４４において、インストーラ実行部２１１は、今回の６４ｂｉｔインストーラの起動に伴い、ステップ５４１にてアプリケーション２４０のインストール処理を行った否かを判断する。ステップ５４１の処理を行った場合、アプリケーション２４０のインストール処理を行ったと判断し、ステップ５４６へ処理が遷移する。一方、ステップ５４１の処理を行わなかった場合、アプリケーション２４０のインストール処理を行わなかったと判断し、ステップ５４５へ処理が遷移する。

ステップ５４５において、インストーラ実行部２１１は、アプリケーション２４０を修復、または、削除するためのインストーラ管理画面を表示する。

ステップ５４６において、インストーラ実行部２１１は、６４ｂｉｔメジャーバージョンインストーラ２１０、および６４ｂｉｔサービスパックインストーラ２３０から送信される終了コードの送信制御を行う。６４ｂｉｔサービスパックインストーラ２３０から終了コードを受け取っている場合、６４ｂｉｔサービスパックインストーラ２３０の終了コードを引き継ぎ、６４ｂｉｔメジャーバージョンインストーラ２１０でインストール処理を行った場合は、終了コードを生成する。そして、インストーラ実行部２１１は、引き継いだ終了コード、または生成した終了コードを３２ｂｉｔメジャーバージョンインストーラ２００へ送信する。このように、終了コードは呼び出し元のインストーラに送信されるわけだが、６４ｂｉｔメジャーバージョンインストーラ２１０も呼び出されたインストーラであるため、更に呼び出しの大元である３２ｂｉｔメジャーバージョンインストーラ２００に送信される。本願発明がこのような構成であるのは、後述するログ出力処理に関係する。

３２ｂｉｔサービスパックインストーラ２２０のインストール処理は、インストーラ実行部２２１が３２ｂｉｔサービスパックインストーラ２２０の実行を示す処理を、３２ｂｉｔメジャーバージョンインストーラ２００のインストーラ実行部２０１から受け付けたことによって開始される。

ステップ５２０において、インストーラ実行部２２１は、アプリケーション２４０の３２ｂｉｔサービスパックのインストール処理を行う。３２ｂｉｔサービスパックのインストール処理後、３２ｂｉｔサービスパックインストーラ２２０のインストール処理を終了し、３２ｂｉｔサービスパックインストーラ２２０の終了コードを３２ｂｉｔメジャーバージョンインストーラ２００に送信する。このステップが実行されることで、アプリケーション２４０は３２ｂｉｔサービスパック対応済みのアプリケーションとなる。

６４ｂｉｔサービスパックインストーラ２３０のインストール処理は、インストーラ実行部２３１が６４ｂｉｔサービスパックインストーラ２３０の実行を示す処理を、６４ｂｉｔメジャーバージョンインストーラ２１０のインストーラ実行部２１１から受け付けたことによって開始される。

ステップ５６０において、インストーラ実行部２３１は、アプリケーション２４０の６４ｂｉｔサービスパックのインストール処理を行う。６４ｂｉｔサービスパックのインストール処理後、６４ｂｉｔサービスパックインストーラ２３０のインストール処理を終了し、６４ｂｉｔサービスパックインストーラ２３０の終了コードを６４ｂｉｔメジャーバージョンインストーラ２１０に送信する。このステップが実行されることで、アプリケーション２４０は６４ｂｉｔサービスパック対応済みのアプリケーションとなる。

なお、別インストーラを呼び出す呼び出し元のインストーラは、必ずしも図５の通りでなくても良い。例えば、システム環境に応じてインストーラの切り替える処理を行えれば図５で示したインストーラ以外の別のインストーラが呼び出しても良い。また、システム環境判別専用のアプリケーションを別途設け、そのアプリケーションが各インストーラを呼び出しても良い。以上のように、自動でシステム環境に最適なインストーラによりインストールを行うとともに、ユーザの操作負担を軽減させることができる。

図６は、３２ｂｉｔメジャーバージョンインストーラ２００、または、６４ｂｉｔメジャーバージョンインストーラ２１０により実行される、アプリケーション２４０の修復、または、削除のフローチャートを示している。本フローチャートが開始されるトリガーは、インストーラＵＩ部２０２、２１２がインストーラ管理画面ウインドウ４００を表示する処理を受け付けたことにより開始される。

ステップ６００において、インストーラＵＩ部２０２、または２１２は、開始ボタン４０３、または、キャンセルボタン４０４のどちらが押下されたかを判断する。インストーラＵＩ部２０２、２１２は開始ボタン４０３が押下されたことを示す処理を受け付けた場合、開始ボタン４０３が押下されたと判断し、ステップ６０１へ処理が遷移する。一方、インストーラＵＩ部２０２、２１２は、キャンセルボタン４０４が押下されたことを示す処理を受け付けた場合、キャンセルボタン４０４が押下されたと判断し、本フローチャートの処理を終了する。

ステップ６０１において、インストーラＵＩ部２０２、２１２は、修復処理ラジオボタン４０１、または、削除処理ラジオボタン４０２のどちらが選択されているかを判断する。修復処理ラジオボタン４０１が選択されている場合、アプリケーション２４０を修復すると判断し、ステップ６０２へ処理が遷移する。一方、削除処理ラジオボタン４０２が選択されている場合、アプリケーション２４０を削除すると判断し、ステップ６０３へ処理が遷移する。

ステップ６０２において、インストーラ実行部２０１、２１１はアプリケーション２４０の修復を行う。アプリケーション２４０の修復後、本フローチャートの処理を終了する。ステップ６０３において、インストーラ実行部２０１、２１１はアプリケーション２４０の削除を行う。アプリケーション２４０の削除後、本フローチャートの処理を終了する。

図７は、３２ｂｉｔメジャーバージョンインストーラ２００、６４ ｂｉｔメジャーバージョンインストーラ２１０が出力するログデータの一例を示している。ログデータは、インストーラ実行部２０１、２１１によって、インストーラ起動から終了までのインストーラ処理の詳細をファイル形式に出力する。本実施例では二つのインストーラが出力するログデータで説明を行うが、ログデータは各インストーラにより、夫々のインストール処理における詳細なログデータが出力される。

３２ｂｉｔインストーラログデータ７００は、３２ｂｉｔメジャーバージョンインストーラ２００のインストール処理の詳細なログを保持する。また、３２ｂｉｔインストーラログデータ７００には、３２ｂｉｔメジャーバージョンインストーラ２００以外のインストーラであって、呼び出されたことで実際に起動されたインストーラのログデータも保持される。

例えば、６４ｂｉｔサービスパックインストーラ２３０によりインストール処理が行われた場合は、３２ｂｉｔメジャーバージョンインストーラ２００、６４ｂｉｔメジャーバージョンインストーラ２１０、および６４ｂｉｔサービスパックインストーラ２３０のログデータが、３２ｂｉｔインストーラログデータ７００に含まれることになる。しかしながら、３２ｂｉｔメジャーバージョンインストーラ２００によるインストール処理以外のログデータは、呼び出し先のインストーラから送信された終了コードを基に作成されているため、どのようなファイル（例えば、コンポーネント）をコピーしたのか等の詳細な情報は含まれていない。よって、３２ｂｉｔインストーラログデータ７００を見たユーザは、どのようなインストーラが起動され、どのインストーラによりインストール処理が行われ、そしてそのインストーラによるインストール処理がどうなったのか、と言った全体の流れを把握できる。このログデータが第１のログデータに相当する。

６４ｂｉｔインストーラログデータ７１０は、６４ｂｉｔインストーラのインストール処理の詳細なログを保持する。６４ｂｉｔインストーラログデータ７１０には、６４ｂｉｔメジャーバージョンインストーラ２１０によるインストール処理のみが保持されている。そのため、６４ｂｉｔメジャーバージョンインストーラ２１０によるインストール処理に関するログデータは詳細に保持されている。例えば、どのようなファイルをコピーしたのか等の詳細な情報が含まれている。よって、６４ｂｉｔインストーラログデータ７１０を見たユーザは、どのようなファイルが情報処理装置１００にインストールされたかを明確に把握することができる。このログデータが第２のログデータに相当する。

３２ｂｉｔメジャーバージョンインストーラ２００のインストーラ実行部２０１は、インストーラの起動と同時に３２ｂｉｔインストーラログデータ７００の出力を開始する。

次にインストーラ実行部２０１によってインストーラの切り替え処理が行われ、別のインストーラが呼び出され（ステップ５０９）、６４ｂｉｔメジャーバージョンインストーラ２１０が起動する。そして、インストーラ実行部２１１は、６４ｂｉｔインストーラログデータ７１０の出力を開始する。無論、インストーラ実行部２１１によりインストール処理が行われるので、どのようなファイルをコピーしたのか等の詳細な情報は出力される。インストーラの切り替え処理が行われたタイミングで３２ｂｉｔメジャーバージョンインストーラ２００の処理が一時停止するため、３２ｂｉｔインストーラログデータ７００の出力も一時停止する。

インストーラの切り替え処理で起動した６４ｂｉｔメジャーバージョンインストーラ２１０のインストール処理中にインストールエラーが発生すると、エラーログ７１１が出力され、６４ｂｉｔメジャーバージョンインストーラ２１０の処理が終了する。この際、６４ｂｉｔメジャーバージョンインストーラ２１０の終了コード７１２がログデータとして出力される。この際の終了コードはエラーを示している。

６４ｂｉｔメジャーバージョンインストーラ２１０の処理が終了すると、３２ｂｉｔメジャーバージョンインストーラ２００のインストール処理、および、ログの出力処理が再開する。３２ｂｉｔメジャーバージョンインストーラ２００のインストーラ実行部２０１は、６４ｂｉｔメジャーバージョンインストーラ２１０の終了コード７１２を受け取り、６４ｂｉｔメジャーバージョンインストーラ２１０のインストール結果を３２ｂｉｔインストーラログデータ７００にログ７０２として出力する。このように、終了コードはあくまでどのように終了したかを示すものに過ぎず、どのようなインストール処理が行われたかを示す詳細な情報ではない。インストーラ実行部２０１は、受け取った終了コードを基にインストールの後処理等を行う（ステップ５０７、５０８）。

なぜ、３２ｂｉｔメジャーバージョンインストーラ２００が、他のインストーラに代わりインストールの後処理を行うかの理由をここで説明する。上述したように、３２ｂｉｔインストーラログデータ７００は、全体の流れを把握できるように出力されたログであり、インストーラ開発者はそのログを見ることでインストール処理の概要を把握できる。そのため、インストーラ開発者は、問題となるインストーラを容易に特定できるようになる。このログデータを出力するには一度３２ｂｉｔメジャーバージョンインストーラ２００にログデータを集約させないといけないわけだが、インストールの後処理を行うために、もう一度別のインストーラを呼び出すことはパフォーマンス劣化を招きナンセンスである。そして、終了コードさえあれば、最初に別のインストーラを呼び出したインストーラであって、かつ各インストーラのインストール処理に関するログデータを集約して出力するインストーラである３２ｂｉｔメジャーバージョンインストーラでもインストールの後処理を実行できるので、３２ｂｉｔメジャーバージョンインストーラ２００によりインストールの後処理が行われる。後処理が実行された後、３２ｂｉｔメジャーバージョンインストーラ２１０の処理が終了し、エラーで終了したこと示すログ７０３が出力される。

最後に、図７に示すように異なる２種類のログデータを出力する理由を説明する。インストーラ開発者は、インストール処理で問題が起きた際、ログデータを基にどのようにインストール処理が行われたかを把握する必要がある。インストーラの切り替えを行った３２ｂｉｔメジャーバージョンインストーラ２００が出力した３２ｂｉｔインストーラログデータ７００により、インストーラ開発者はどのインストーラでインストール処理が失敗したかを容易に把握できる。例えば、６４ｂｉｔメジャーバージョンインストーラ２１０によるインストール処理が失敗したことを、インストーラ開発者は把握できる。そして、アプリケーションのインストール処理を行った６４ｂｉｔメジャーバージョンインストーラ２１０が出力した６４ｂｉｔインストーラログデータ７１０により、何がどこにインストールされたのか等のインストール処理の詳細を把握し、どこに原因があったのかを把握することが出来る。

各インストーラが自身のログデータしか出力しない形態であった場合、インストーラ開発者はどのインストーラにエラーがあるかを把握するのに時間がかかる。そのため、本願発明の様に複数のインストーラが自動的に切り替わるような発明の場合、ログデータは一カ所に集約し、問題のあったインストーラを特定しやすくする方が良い。しかし、全てのログデータを３２ｂｉｔメジャーバージョンインストーラ２００が出力する形態にした場合、非常に長いログデータになってしまい、インストール開発者はエラーの原因を把握するのに時間がかかる。本願発明の情報処理装置、制御方法、およびプログラムによれば、これらの問題は解決する。また、本願発明により、本願発明の最適なログ出力処理に併せ、インストールの後処理に関しても最適な後処理が行われる。

以上、実施例１において、システム環境に適したインストーラを使用しインストールを行う情報処理装置について説明をした。

［その他の実施例］
実施例１では、３２ｂｉｔ、６４ｂｉｔを基に説明を行ったが、このアーキテクチャに限定される話しではない。ＯＳのデータ処理におけるアーキテクチャの構成の差異により、インストーラを少なくとも２つ以上用意しなくてはならない状況であれば、本願発明は適用可能である。

実施例１では、ＣＤ／ＤＶＤ１１０には、計４つのインストーラが記憶されていたが、必ずしも４つである必要はない。例えば、ＣＤ／ＤＶＤ１１０には、３２ｂｉｔサービスパックインストーラ２２０、３２ｂｉｔメジャーバージョンインストーラ２００の計２つのインストーラが記憶されている形態であっても良い。また、ＣＤ／ＤＶＤ１１０には、６４ｂｉｔメジャーバージョンインストーラ２１０、３２ｂｉｔメジャーバージョンインストーラ２００の計２つのインストーラが記憶されている形態であっても良い。このような形態の場合は、図５の処理で実行される処理は、記憶されているインストーラのみの処理となる。また、メジャーバージョンインストーラと、サービスパックインストーラとを一体化させ、一体化させた３２ｂｉｔ、および６４ｂｉｔインストーラであっても、本願発明は適用可能である。また、４つ以上のインストーラであっても良い。

また、情報処理装置に備えられたオペレーティングシステムの自動実行機能によりインストーラから別のインストーラを起動する場合、実施例１では別のインストーラを利用しインストールすることをユーザに問い合わせることなくインストールする形態であった。しかしながら、その別のインストーラを利用しインストールする際にユーザに問い合わせる形態であっても良い。例えば、３２ｂｉｔメジャーバージョンインストーラ２００から３２ｂｉｔサービスパックインストーラ２２０を起動する場合に、「３２ｂｉｔサービスパックインストーラ２２０でインストールを実行しますが良いですか？」のように問い合わせる形態が考えられる。ここで、ユーザにより許可された場合は、３２ｂｉｔサービスパックインストーラ２２０でインストールを行い、許可されなかった場合は、インストールを行うことなく終了する。無論、６４ｂｉｔのインストーラに対してもこの構成は適用可能である。

Claims (14)

1. 複数のソフト部品から構成されたアプリケーションをインストールする第１のインストーラと、前記アプリケーションを構成するソフト部品を変更するために修正モジュールをインストールする第２のインストーラとを記憶する記憶手段と、
   前記アプリケーションがインストールされていなかった場合は、記憶された前記第１のインストーラを使用しアプリケーションのインストールを行い、
   前記修正モジュールをインストールすることでインストールされている前記アプリケーションが変化する場合は、記憶された前記第２のインストーラを使用し修正モジュールのインストールを行うよう制御する制御手段と、を有する情報処理装置。
2. 前記制御手段は、記憶された前記第２のインストーラを使用し修正モジュールのインストールを行う場合、前記アプリケーションを操作するための管理画面を表示することなく、前記修正モジュールのインストールを行うよう制御することを特徴とする請求項１に記載の情報処理装置。
3. 前記制御手段は、情報処理装置に備えられたオペレーティングシステムの自動実行機能により前記第１のインストーラを起動した際に、記憶された前記第２のインストーラを使用し修正モジュールのインストールを行う場合、起動された前記第１のインストーラから前記第２のインストーラを起動するよう制御することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記制御手段は、既に前記アプリケーションと前記修正モジュールの両方がインストールされている場合は、両方のインストールを行うことなく、前記アプリケーションを操作するための管理画面を表示するよう制御することを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
5. 前記制御手段は、前記情報処理装置のオペレーティングシステムにより管理されているレジストリ情報を取得し、
   前記第１のインストーラに保持されているインストーラ情報に含まれるコードと一致するコードが、取得された前記レジストリ情報に含まれていない場合は、記憶された前記第１のインストーラを使用しアプリケーションのインストールを行い、
   前記インストーラ情報に含まれるリビジョンと一致するリビジョンが、取得された前記レジストリ情報に含まれていない場合は、記憶された前記第２のインストーラを使用し修正モジュールのインストールを行うよう制御することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
6. 前記第１のインストーラ、および第２のインストーラは第１のアーキテクチャに対応するインストーラであり、
   前記記憶手段は、第２のアーキテクチャに対応する前記アプリケーションをインストールするための第３のインストーラを更に記憶し、
   前記制御手段は、情報処理装置のシステム環境が第２のアーキテクチャに対応する環境であった場合、前記第３のインストーラを起動するよう制御することを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
7. 前記記憶手段は、第２のアーキテクチャに対応する前記アプリケーションを構成するモジュールを変更するために修正モジュールをインストールする第４のインストーラを更に記憶し、
   前記制御手段は、前記第３のインストーラを起動した際に、前記アプリケーションがインストールされていなかった場合は、記憶された前記第３のインストーラを使用しアプリケーションのインストールを行い、
   前記修正モジュールをインストールすることでインストールされている前記第２のアーキテクチャに対応する前記アプリケーショに変化が発生する場合は、記憶された前記第４のインストーラを使用し修正モジュールのインストールを行うよう制御する請求項６に記載の情報処理装置。
8. 前記第１のアーキテクチャに対応するシステム環境は３２ｂｉｔ環境であり、前記第２のアーキテクチャに対応するシステム環境は６４ｂｉｔ環境であることを特徴とする請求項６または７に記載の情報処理装置。
9. 前記制御手段は、前記第１のインストーラを使用したことに応じて第１のログデータを出力するよう制御し、前記第１のインストーラから別のインストーラを起動したことに応じて第２のログデータを出力するよう制御し、前記第１のログデータは前記第１のインストーラ、および前記別のインストーラのインストールに関するログを含み、前記第２のログデータは前記第１のインストーラのインストールに関するログは含まず、前記別のインストーラのインストールに関するログを含むことを特徴とする請求項１乃至８の何れか１項に記載の情報処理装置。
10. 前記制御手段は、前記第１のインストーラから別のインストーラを起動した際に、前記別のインストーラによるインストールにエラーが発生した場合、前記別のインストーラを使用せず、前記第１のインストーラを使用してインストールの後処理を行うことを特徴とする請求項１乃至９の何れか１項に記載の情報処理装置。
11. 第１のアーキテクチャに対応するアプリケーションをインストールするための第１のインストーラと、第２のアーキテクチャに対応する前記アプリケーションをインストールするための第２のインストーラとを記憶する記憶手段と、
    情報処理装置のシステム環境が前記第１のアーキテクチャに対応する場合は、記憶された前記第１のインストーラを使用しアプリケーションのインストールを行い、
    情報処理装置のシステム環境が前記第２のアーキテクチャに対応する場合は、記憶された前記第２のインストーラによりアプリケーションのインストールを行うよう制御する制御手段と、を有する情報処理装置。
12. 複数のソフト部品から構成されたアプリケーションをインストールする第１のインストーラと、前記アプリケーションを構成するソフト部品を変更するために修正モジュールをインストールする第２のインストーラとを記憶し、
    前記アプリケーションがインストールされていなかった場合は、記憶された前記第１のインストーラを使用しアプリケーションのインストールを行い、
    前記修正モジュールをインストールすることでインストールされている前記アプリケーションが変化する場合は、記憶された前記第２のインストーラを使用し修正モジュールのインストールを行うよう制御することを特徴とする制御方法。
13. 第１のアーキテクチャに対応するアプリケーションをインストールするための第１のインストーラと、第２のアーキテクチャに対応する前記アプリケーションをインストールするための第２のインストーラとを記憶し、
    情報処理装置のシステム環境が前記第１のアーキテクチャに対応する場合は、記憶された前記第１のインストーラを使用しアプリケーションのインストールを行い、
    情報処理装置のシステム環境が前記第２のアーキテクチャに対応する場合は、記憶された前記第２のインストーラによりアプリケーションのインストールを行うよう制御することを特徴とする制御方法。
14. 請求項１２、または１３に記載の制御方法を情報処理装置に実行させるためのプログラム。

Images