JP2004533054A - オペレーティングシステム抽象化／保護レイヤ - Google Patents

Abstract

本発明は、クライアントコンピュータのオペレーティングシステムを変更することなくアプリケーションソフトウェア環境を作成するためのシステムを提供する。このシステムは、オペレーティングシステム抽象化／保護レイヤから成り、抽象化／保護レイヤは実行されているソフトウェアアプリケーションとオペレーティングシステムとの間に配置される。これにより、アプリケーションを実行できる仮想環境が提供され、アプリケーションレベル間の相互作用が実質的に除去される。好ましくは、オペレーティングシステムに対する直接的な変更を、実行されているアプリケーションのコンテキスト内で選択的に行い、抽象化／保護レイヤが管理設定に従って仮想環境を動的に変更する。また、一部の実施形態では、システムが共有システムリソースの使用状況を継続的に監視し、システムコンポーネントに対する変更を適用および除去するサービスとして機能する。このため、本発明は「オペレーティングシステムガード」を定義するものである。これらのコンポーネントには、ＤＬＬおよびその他の共有ライブラリコードで必要とされるセマンティクス、システムデバイスドライバ、フォント、レジストリ、その他の構成項目、ファイル、環境変数が含まれる。
【選択図】図１

Description

【技術分野】
【０００１】
本出願は米国特許出願第０９／４５６，１８１号の一部継続出願であり、その全体が十分に記載されているものとし、引用参考文献としてここに包含される。
【０００２】
本発明は、コンピュータソフトウェア、より詳細にはオペレーティングシステムソフトウェアに関する。
【背景技術】
【０００３】
多くの環境において、特にアプリケーションがネットワークを介して配布されるような環境において最も重要な機能は、複雑なインストール作業なしにアプリケーションをすぐに実行できることである。一般に、一部の従来システムでは、あたかもプログラムがインストールされているかのようにクライアントシステムを変更したり、あるいはソフトウェア自体を実際にインストールした後でこれらの変更を取り消して元の構成を復元する際に、大変手間がかかった。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このような作業を行う場合、次のような多くの問題が生じる。すなわち、アプリケーションと現在のコンピュータ構成との間に矛盾、不一致があること、同じまたは異なるアプリケーションのインスタンスが複数存在すること、取り消し処理が複雑であるため、アプリケーションに対して厳密な処理を施して、アプリケーションに対するすべての変更の原因を明らかにする必要があること、複数のアプリケーションで共有ファイルと共有システムコンポーネントが使用されているため、取り消し処理とインストール処理が複雑になるといった問題である。
【課題を解決するための手段】
【０００５】
本発明は、クライアントコンピュータのオペレーティングシステムを変更することなくアプリケーションソフトウェア環境を作成するためのシステムを提供する。このシステムは、オペレーティングシステム抽象化／保護レイヤから成り、抽象化／保護レイヤは実行されているソフトウェアアプリケーションとオペレーティングシステムとの間に配置される。これにより、アプリケーションを実行できる仮想環境が提供され、アプリケーションレベル間の相互作用が実質的に除去される。好ましくは、オペレーティングシステムに対する直接的な変更を、実行されているアプリケーションのコンテキスト内で選択的に行い、抽象化／保護レイヤが管理設定に従って仮想環境を動的に変更する。また、幾つかの実施形態では、システムが共有システムリソースの使用状況を継続的に監視し、システムコンポーネントに対する変更を適用および除去するサービスとして機能する。
【０００６】
したがって、たとえばＷｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステム内の実施形態では、Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙに対する操作はすべてＷｉｎ３２ ＡＰＩによって行われ、好ましくはシステムが関数をフックするための手段を提供する。これにより、関数が呼び出されるたびに別の関数またはアプリケーションがその呼び出しを中断する。最も好ましくは、サーバーから実行されているアプリケーションによる要求であれ、アクティブに管理されている構成キーに対してアプリケーションが出した要求であれ、要求に応えるためにシステムが適切なＡＰＩ関数それぞれをフックする。
【０００７】
本発明の別の好ましい実施形態では、追加機能が提供される。たとえば、オペレーティングシステム抽象化／保護レイヤが、実行されているアプリケーションインスタンスの数を認識することで、１つのアプリケーションの複数インスタンスの統合を管理する。このような実施形態では、実行されているアプリケーションインスタンスが１つのみではない場合、起動時とシャットダウン時の変更を避けることが最も好ましい。この実施形態では、種々異なるユーザーのために多重のアプリケーションインスタンスを実行できる、マルチユーザーオペレーティングシステムをサポートすることも可能である。
【０００８】
このため、オペレーティングシステム抽象化／保護レイヤが、インストールを実行しないでもインストール環境であるように現れる環境をアプリケーションに提供する。これにより、アプリケーションの実行時にすべての設定が仮想環境にもたらされる「擬似インストール」が作成される。また、アプリケーションがインストールされている場合は、実行時にアプリケーションの動作を動的に変更する。好ましい実施形態は、クライアントコンピュータ上の情報によってアプリケーション動作が干渉障害を受けたり、変更されることを防止するための手段を提供し、最も好ましくは、管理設定に従って仮想環境を動的に変更するための手段を提供する。上記のように、一部の実施形態では、同じクライアントコンピュータ上で単一ソフトウェアアプリケーションの複数のインスタンスを実行することができる（本来そのように作成されていない場合でも）。このような実施形態では、単一アプリケーションの前記の複数のインスタンスのうちの少なくとも２つが１つ以上の仮想設定を共有するような、共有・制御されたコンテキストが提供される。
【発明を実施するための最良の形態】
【０００９】
図１は、本発明、オペレーティングシステム、およびソフトウェアアプリケーションの相対的関係を示すブロック略図である。本発明の好ましい実施形態は、オペレーティングシステム抽象化／保護レイヤ（１００）を提供する。これを「オペレーティングシステムガード」と呼ぶ。内部的には、多数のオペレーティングシステム（１０）が、実行時にアプリケーションが互いに影響し合うことを防止する障害ドメインを備える。しかし、共有されているシステムリソースとその他の多くのオペレーティングシステム機能によって、この保護ドメインが危険にさらされる。オペレーティングシステム抽象化／保護レイヤ（１００）は、アプリケーションレベル間のほとんどの相互作用をなくすために、プログラム制御された障壁をアプリケーション（５０）間に追加する。アプリケーション（５０）とオペレーティングシステム（１０）との間に配置されたアプリケーション抽象化／保護レイヤ（１００）が、オペレーティングシステム（１０）に対する直接的な変更か、実行されているアプリケーションのコンテキスト内に変更を含めるかを選択的に許可する。一例としてＷｉｎｄｏｗｓ（登録商標）ベースのシステムでは通常、Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙに対する操作はすべてＷｉｎ３２ ＡＰＩによって実行される。後述するように、ＱｕｅｒｙＲｅｇＥｘやＧｅｔＰｒｏｆｉｌｅＳｔｒｉｎｇなどのシステム関数が呼び出されるたびに別の関数またはアプリケーションがこの呼び出しを中断するように、これらのシステム関数をフックすることができる。アクティブに管理されているアプリケーションによる要求であれ、アクティブに管理されている構成項目に対してアプリケーションが出した要求であれ、要求に応えるために本発明のオペレーティングシステムガード（１００）が適切なＡＰＩ関数それぞれをフックする。この方法では、これを実行するように明示的に構成されていない場合、本発明によって、エンドユーザーシステムを実際に変更することなくアプリケーション環境を作成することができる。また、実行時にアプリケーションによって実行された変更を存続させたり除去することも容易である。
【００１０】
ここで使用している「オペレーティングシステムガード」という用語は、ターゲットコンピュータまたはクライアントコンピュータ上の、実行されているアプリケーションとオペレーティングシステムとの間に配置され、アプリケーションを実行できる仮想環境を提供するレイヤを意味する。この仮想環境にはいくつかの目的がある。第１の目的は、実行されているアプリケーションによってクライアントコンピュータが変更されることを防止することである。アプリケーションがクライアントコンピュータの基本オペレーティングシステム設定の変更を試みると、この設定は保護され、仮想環境でのみ変更が「行われる」。たとえば、アプリケーションがＭＳＶＣＲＴ．ＤＬＬなどの共有オブジェクトのバージョンを変更しようとすると、この変更がアプリケーションだけにとどめられ、クライアントコンピュータに常駐するコードは影響を受けない。
【００１１】
第２の目的は、インストールを実行しないでもインストール環境であるようにみえる環境（すなわち「擬似インストール」または「インストールのような」環境）を、実行されているアプリケーションに提供することである。アプリケーションの実行時、またはアプリケーションが特定の設定を必要としているちょうどのタイミングですべての設定が仮想環境にもたらされる。たとえば、Ａｄｏｂｅ Ｐｈｏｔｏｓｈｏｐ（Ｒ）などのコンピュータプログラムが、一連のＷｉｎｄｏｗｓ（登録商標） ＲｅｇｉｓｔｒｙエントリがＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ￥Ｓｏｆｔｗａｒｅ￥Ａｄｏｂｅにあると想定している場合に、Ｐｈｏｔｏｓｈｏｐがインストールされていないためクライアントコンピュータ上のＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ￥Ｓｏｆｔｗａｒｅ￥Ａｄｏｂｅにこれらのエントリが存在しなければ、本発明のこの態様に従うシステムは、あたかもクライアントコンピュータ上に常駐するかのように、これらのレジストリエントリをＰｈｏｔｏｓｈｏｐプログラミングコードに対して「示す」。
【００１２】
次に、本発明は、クライアント／ユーザーマシン上に存在する可能性がある情報によってアプリケーションの動作が干渉または変更されることを防止する。たとえば、ユーザーがＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ￥Ｓｏｆｔｗａｒｅ￥Ａｄｏｂｅの下にＰｈｏｔｏｓｈｏｐの古いバージョン用のレジストリエントリが既に存在している状態で、新しいバージョンを稼動したい場合、これらのエントリを新しいアプリケーションから隠して競合を防ぐことができる。
【００１３】
最後に、本発明は、アプリケーションが現在書き込まれているため存在しない可能性があるアプリケーション動作をアンロックする。このアンロックが可能なのは、管理設定に従って仮想環境を動的に変更できるからである。たとえば、企業向けソフトウェアアプリケーションの典型的な例では、クライアントアプリケーションは、ユーザーがレジストリ内の設定から接続する必要があるデータベースのアドレスについての設定を読み取ることを期待することがある。このレジストリキーはＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥに格納されることが多いため、この設定はクライアントコンピュータ全体に適用される。ユーザーが複数のデータベースに接続するには、クライアントを再インストールするか、またはこのレジストリキーの変更方法を知ってアプリケーションを実行するたびにレジストリキーを変更しなければならない。しかし、本発明を実現する場合、アプリケーションの２つのインスタンスを同じクライアントコンピュータ上で実行し、それぞれのインスタンスを異なるデータベースに接続できるようになる。
【００１４】
コンテキスト
この機能があるため、システム内のプライベートコンテキストで各アプリケーションを実行することができる。アプリケーションに対してシステムがどのように見えるか、およびその挙動特性についてプライベートビューが与えられる。本発明は、その固有の性質によってこれを実現する。図２では、２つの個別アプリケーション（５２と５４）または同じアプリケーション（図１の５０）の２つのインスタンスにプライベートコンテキストを提供することができる。このプライベートコンテキストでは、これらのアプリケーションまたはインスタンスが、システムサービス、構成、およびデータの個別コピーまたは異なるコピーを持つようにみえる。好ましい実施態様では、これがシステムの既定動作である。
【００１５】
この着想を拡張することで、本発明のオペレーティングシステムガード（１００）は、複数のアプリケーション（５２と５４）が一部またはすべての仮想設定を共有できるような、共有・制御されたコンテキストを提供することもできる。このことは、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅなどのアプリケーションスイートや、別のアプリケーションが存在すると動作が異なってくるアプリケーションにとって重要である。たとえば、メールマージや文書作成機能を実行するためのエンジンとしてＭｉｃｒｏｓｏｆｔ Ｗｏｒｄが多くのアプリケーションで使用されている。このようなアプリケーションはＷｏｒｄのインストールまたは有無に関する情報を知り、Ｗｏｒｄの機能を利用できなければならない。好ましい実施形態では、同じアプリケーションの２つのインスタンスが既定で単一のコンテキストを共有し、一方、２つの別個のアプリケーションがプライベートコンテキストを維持する。図３に示したように、２つのアプリケーション（５２と５４）を実行可能であり、オペレーティングシステムガード（１００）が、利用可能なシステムリソースの共有ビューを提供する。
【００１６】
設計
図４に示したように、オペレーティングシステムガードは次のサブシステムから構成される。すなわち、コア（１０２）、構成マネージャ（１０４）、ファイルマネージャ（１０６）、共有オブジェクトマネージャ（１０８）、デバイスマネージャ（１１０）、フォントマネージャ（１１２）、プロセスマネージャ（１２０）、プロセス環境マネージャ（１１４）、ローダー（１１６）、およびリカバリマネージャ（１１８）から構成される。コア（１０２）、プロセスマネージャ（１２０）、およびローダー（１１６）を除くすべてのサブシステムは、以下で詳述する仮想化システムの要素である。コア（１０２）は主として、アプリケーションと、構成ファイルで定義されるアプリケーションのコンテキストを管理する。
【００１７】
オペレーティングシステムガードのプロセスマネージャ（１２０）によって、当該のプロセスまたはスレッドイベントをコア（１０２）に通知できるようになる。また、プロセスマネージャ（１２０）は、プロセス空間の管理とスレッド処理のために、オペレーティングシステムに依存する実現化に対して抽象化レイヤを提供する。プロセスをまとめてアプリケーションバンドルにすることができる。アプリケーションバンドルとは、すべてが互いに仮想リソースを共有するプロセスのグループである。たとえば、Ｍｉｃｒｏｓｏｆｔ ＷｏｒｄとＭｉｃｒｏｓｏｆｔ Ｅｘｅｃｌがアプリケーション一式として協働するために、仮想レジストリと仮想ファイルシステムを共有する場合がある。プロセスマネージャ（１２０）は、これらのアプリケーションバンドルを「アプリケーション」とみなす。プロセスマネージャ（１２０）がアプリケーションの解放を指示されるまで、アプリケーションに関する情報が存在する。別のプロセスをアプリケーションバンドルにロードする必要がある場合、アプリケーションが解放されていない限りロードが可能である。
【００１８】
本発明のローダーサブシステム（１１６）を使用すれば、実行されているシステムに仮想環境を転送したり、システムから仮想環境を転送することができる。ローダー（１１６）。仮想化サブシステムそれぞれは、ローダー（１１６）に対して構成をシリアル化し、リバースプロセスを通じて構成を取得することができる。さらに、ローダー（１１６）は段階的ロード／アンロードを実行し、個々の段階の結果を組み合わせて単一の環境記述にすることができる。
【００１９】
レジストリと構成
アプリケーションを正しく動作させるには、様々な量の構成情報が必要である。アプリケーションが構成を読み取ることができる構成レコードの数は、ゼロから数千の範囲におよぶ。Ｗｉｎｄｏｗｓ（登録商標）では、構成情報が一般に格納される場所が２つある。すなわち、Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙとシステムレベル初期化ファイル（ｗｉｎ．ｉｎｉおよびｓｙｓｔｅｍ．ｉｎｉ）である。さらに、￥ＷＩＮＤＯＷＳ（登録商標）￥ＳＹＳＴＥＭディレクトリは、アプリケーションがアプリケーション固有の構成または初期化ファイルをよく書き込む場所である。また、アプリケーションは、ローカルアプリケーションディレクトリ内の構成ファイルまたはデータファイルを使用して、追加情報を格納する。この情報が独自仕様の形式であるため扱いにくいことが多い。Ｗｉｎｄｏｗｓ（登録商標）以外のプラットフォームにはＲｅｇｉｓｔｒｙに相当するものはないが、構成情報がよく格納されるディレクトリが存在する。Ｘ Ｗｉｎｄｏｗｓ（登録商標）には、ａｐｐ−ｄｅｆａｕｌｔｓディレクトリがある。ＭａｃｉｎｔｏｓｈにはＳｙｓｔｅｍ Ｆｏｌｄｅｒがあり、その他のオペレーティングシステムには対応する要素が存在する。また図２に示したように、ほとんどのＵＮＩＸ（登録商標）システムでは、個々のアプリケーション（５２と５４）それぞれがその構成（１５２と１５４）をローカルに格納することがほとんどである。
【００２０】
本発明の一実施態様には、仮想Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙコンポーネントが含まれる。このコンポーネントは全機能レジストリをアプリケーションに提供するが、基本システムレジストリに対する変更は防止する。アプリケーションがアクセスすることを期待するキーはすべて存在するが、これらのキーは仮想レジストリにのみ存在することができる。この方法では、本発明のオペレーティングシステムガード（１００）とＷｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙが、レジストリにアクセスするための２段階プロセスを形成する。アプリケーションがキーへのアクセスを必要とする場合、アプリケーションはＲｅｇｉｓｔｒｙに問い合わせる。オペレーティングシステムガードは、キーおよびキーの値（値を知っている場合）で応答する。そうでない場合、オペレーティングシステムガードは要求をＷｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙまで通過させることを許可する。値の変更が試みられた場合、オペレーティングシステムガードは、それ自身に対する変更のみ許可する。次回アプリケーションがキーにアクセスするとき、そのキーはオペレーティングシステムガード内に存在し、要求は実際のＲｅｇｉｓｔｒｙまで流れ込まず、変更されない。
【００２１】
オペレーティングシステムガードが使用するキーは、３つの個別セクションで指定される。これらのオペレーティングシステムガードキーはこれらのセクションで、既存キーの変更、キーの存在の削除、またはレジストリへの新しいキーの追加のためのコマンドとして指定される。このようにして、仮想レジストリは、全くシステムの意図通りに出現することができる。このことは、キーの有無がキーの実際の値と同じ程度に重要になることができるため、重要である。
【００２２】
好ましい実施態様では、オペレーティングシステムガードはまず、アプリケーションに対する基本レジストリエントリを含むデータファイルをロードする。次に、ユーザーの基本設定を含む第２のデータファイルがロードされる。最後に、オペレーティングシステムガードは、ユーザーが上書きを禁止されているポリシー項目を含む一連のキーを任意にロードできる。この３つのファイルは順にロードされ、各ファイル内に重複する項目がある場合、前のファイル内の項目が上書きされる。ユーザーが初めてアプリケーションを実行するとき、ユーザー固有の情報が存在せず、アプリケーション既定情報のみ存在するため、第２のデータファイルは存在しない。しかし、各セッションの後、オペレーティングシステムガードはユーザーの変更内容を保存し、将来のセッションで使用するために第２のデータファイルを生成する。
【００２３】
構成ファイルを２つの方法で変更できる。第１の方法では、構成ファイルをアプリケーションによって直接編集できる。この方法では、後述するオペレーティングシステムガードのファイルサブシステムがファイルへの変更を扱う。好ましい実施形態である第２の方法では、アプリケーションがＷｉｎｄｏｗｓ（登録商標） ＡＰＩ関数ＧｅｔＰｒｏｆｉｌｅＳｔｒｉｎｇやＷｒｉｔｅＰｒｏｆｉｌｅＳｔｒｉｎｇなどを呼び出して、これらのファイルを変更することができる。この方法では、本発明のオペレーティングシステムガードが上述のとおりこれらの呼び出しを横取りし、内部からこれらの呼び出しを実行する。
【００２４】
共有オブジェクト
オペレーティングシステムおよび実行されているアプリケーションで使用される多くのコンポーネントは、複数のアプリケーションまたはインスタンスで共有される。一般に、これは優れた方法である。この方法では、ディスク容量を節約でき、同じファイルを数多くコピーする必要がない。また、頻繁に使用されるコードのライブラリをオペレーティングシステムベンダーとサードパーティが作成・配布できるようになる。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームでは、ＤＬＬ（ダイナミックリンクライブラリ）がアプリケーション内や複数のアプリケーション間で共有されることが多い。その他のプラットフォームでも、問題は同じである。Ｍａｃｉｎｔｏｓｈでは、ＩＮＩＴおよびその他のシステムコンポーネントがアプリケーション用にロードされる。これらのコンポーネントには複数のバージョンが存在し、一度に使用されるのがそれらのうちの１つのみである場合がある。ＵＮＩＸ（登録商標）システムでは、ロード時間の短縮やディスク容量の節約などの理由で動的共有オブジェクト（たとえば”．ｓｏ”ライブラリファイル）がアプリケーションで使用される。多くのプログラムでは既定の”ｌｉｂｃ．ｓｏ”が使用されるが、このライブラリファイルはｌｉｂｃ．ｓｏ．３など一部のバージョンへのシンボリックリンクであることが多い。実際には、この機能が大きな混乱を招いてきた。これらの共有コンポーネントは改訂されることが多く、同じコンポーネントの複数のバージョンがインストールされる。アプリケーション作成者は、作成したソフトウェアが共有コンポーネントの１つまたは一部のバージョンとのみ動作できることを知っている。このため実際には、アプリケーションは希望のバージョンをインストールして、その他のバージョンを上書きすることが一般的である。その結果、同じシステム上で実行されている別のアプリケーションが動作できなくなる可能性がある。
【００２５】
Ｗｉｎｄｏｗｓ（登録商標） ９８とＷｉｎｄｏｗｓ（登録商標） ２０００においてＭｉｃｒｏｓｏｆｔが開発したＷｉｎｄｏｗｓ（登録商標） Ｐｒｏｔｅｃｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＷＰＦＳ）により、システム管理者はアプリケーションのベースディレクトリにＸＸＸＸＬＯＣＡＬ（ＸＸＸＸは拡張子のない実行可能ファイル名）と呼ばれるファイルを作成できる。これにより、Ｗｉｎｄｏｗｓ（登録商標） ＬｏａｄｅｒがＬｏａｄＬｉｂｒａｒｙの実行中にパス参照を解決する方法を変更する。ただし、問題を完全に解決するにはこれでは不十分である。不十分である第１の理由は、ＸＸＸＸファイルのセットアップの成否がシステム管理者の知識に左右されるからである。システム管理者の知識は、人によって大きな差がある。第２の理由は、コンポーネントのバージョンを元に戻してからローカルディレクトリにインストールし、次に”．ＬＯＣＡＬ”ファイルを作成しなければならないからである。これは、ＷＩＮＤＯＷＳ（登録商標）￥ＳＹＳＴＥＭに配置された最も基本的なコンポーネントを除いては、簡単なプロセスではない。さらに、この解決法では、必要とされる機能すべてに対処できるわけではない。ＬｏａｄＬｉｂｒａｒｙの実行中、Ｗｉｎｄｏｗｓ（登録商標）は、コンポーネントが明示的または非明示的なＬｏａｄＬｉｂｒａｒｙのどちらの結果として解決されたか、また、有名な（または周知の）ＤＬＬであることを示すＲｅｇｉｓｔｒｙ Ｋｅｙが存在するかどうかに応じて、異なるパス解決セマンティクスを使用する。このケースでは、ＬｏａｄＬｉｂｒａｒｙ呼び出しは常にＷＩＮＤＯＷＳ（登録商標）￥ＳＹＳＴＥＭディレクトリに解決される。
【００２６】
ＤＬＬおよびその他の共有コンポーネントは、実行されているアプリケーションが参照していない場合はコンポーネントが変更されないことを保証するために、参照カウントセマンティクスも保持する。実際には、オペレーティングシステムベンダーのアプリケーションとオペレーティングシステム自体のみ、この規約に従うことができる。
【００２７】
原則として、常に共有オブジェクトが正しいコンポーネントに帰着するよう解決されることが望ましい。この機能を実現するには、アプリケーションがともに動作できるコンポーネントのバージョンまたはバージョンの範囲を知る必要がある。次に、アプリケーションの実行時に、本発明はコンポーネントが正しく解決されることを保証することが望ましい。本発明では、機能能力があれば、必要な場合はＷＰＦＳまたはその他のオペレーティングシステムを自動的に使用することも許容される。この場合、必要なコンポーネントを検出してローカルファイルシステムに配置する必要がある。この処理は、インストールの単なる監視よりも複雑である。なぜならば、必要なコンポーネントが既にインストールされている場合、インストールプログラムはコンポーネントをインストールしないことが多いからである。
【００２８】
名前付きオブジェクトが正しくロードされることも保証する方法を識別する必要性がある。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームでは、ＭＳＶＣＲＴ．ＤＬＬがこの問題の大きな原因である。このオブジェクトの複数のバージョンが維持されている場合、上述のＲｅｇｉｓｔｒｙキーを動的に変更して、ＬｏａｄＬｉｂｒａｒｙ関数で正しいコンポーネントバージョンを解決することができる。正しいコンポーネントのロードを保証するもう１つの妥当な方法は、有効な検索パスを使用するようにプロセス環境を動的に編集することである。この検索パスによって、システムワイドコンポーネントの前にローカルコンポーネントが必ず解決される。正しい共有オブジェクトを解決する別の方法は、シンボリックリンクを使用することである。共有コンポーネントに対してシンボリックリンクを作成すれば、実行時にコンピュータのファイルシステムによって共有コンポーネントを必要なコンポーネントに帰着するよう解決することができる。最後の方法として、共有オブジェクトのファイルからの情報に対する実際のオープン／読み取り／クローズ要求を本発明によって中断し、ローカルシステム上または本発明のサブシステム内に存在する可能性があるファイルの正しいバージョンに向けて動的に応答することができる。
【００２９】
いくつかの特別な形態が存在する。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームでは、実行中の複数またはすべてのプロセス間でグローバルに共有するように、ＯＬＥ、ＯＤＢＣ、ＭＤＡＣ、およびその他のベンダー固有の多数のコンポーネントが書き込まれている。ＯＬＥの場合は、個別プロセス間でデータおよびメモリー空間でさえも共有される。これらのコンポーネントの多くと同様に、ＯＬＥはＯＬＥ自身の複数のコピーが一度に実行されることを防止する。またＯＬＥには、特定のアプリケーションについて特定バージョンのロードを必要とするバグと機能が多く存在する。本発明では、アプリケーションが必要とされるＯＬＥのバージョンをどれでもロードすることができ、同じバージョンのＯＬＥを使用する別のコンポーネントとセマンティクスを共有することも可能である。
【００３０】
一般に、明確に構成されていない場合は、競合防止のために共有オブジェクトをプライベートにロードする必要がある。コンポーネントをプライベートにロードするための方法は、コンポーネントの完全なアンロードや別のソフトウェアアプリケーション（オペレーティングシステムガードによってアクティブに管理されているかどうかにかかわらず）に対する正しいコンポーネントのロードを妨げてはならない。さらに、システムがクラッシュした場合、基本オペレーティングシステムが上書きまたは変更されていないクリーンな状態に回復する必要がある。
【００３１】
ファイル
多くのアプリケーションは、設定エントリまたはその他のアプリケーションデータを格納するためにアプリケーション内でデータファイルを使用する。本発明は、上記の仮想レジストリに酷似した仮想ファイルシステムを提供する。アプリケーションが起動する前に、本発明はファイルシステム変更内容のリストをロードすることができる。変更内容には、ファイルを隠すこと、仮想環境にファイルを追加すること、仮想環境内の別のファイルへファイルをリダイレクトすることなどが含まれる。アプリケーションがファイルにアクセスしたりファイルを変更した場合は必ずオペレーティングシステムガードが、そのファイルをリダイレクトする必要があるかどうかをチェックし、リダイレクトする必要がある場合、好ましい実施形態では、その要求をオペレーティングシステムガード構成で指定された場所にリダイレクトする。
【００３２】
ユーザーのローカルドライブに書き込むためにアプリケーションが新規ファイルの作成または既存ファイルのオープンを試みた場合、オペレーティングシステムガードは、リダイレクトされた場所でそのファイルが実際に作成または変更されることを保証しなければならない。後でアプリケーションが再ロードされる場合、このファイルマッピングをオペレーティングシステムガードの仮想環境に再ロードする必要がある。ユーザーのローカルドライブ上に常駐する既存ファイルの変更要求があった場合、オペレーティングシステムガードはそのファイルをリダイレクションポイントにコピーしてから、要求を継続しなければならない。ファイルパスの安全なマッピングを保証するために、リダイレクトされたファイルは元のファイルと同じ名前であってはならない。好ましい実施形態では、システムのセキュリティとアプリケーションの互換性を最大限確保するために、ＩＮＩファイルをこのように扱う。
【００３３】
本発明は、ネットワークを介して配布されるアプリケーションに対して特に有用である。このような実現化では、ソフトウェアアプリケーションが複数種類のデータから構成されることを理解することが重要であり、ソフトウェアアプリケーションで使用されるファイルの大部分を個別の論理ドライブに格納することが最も望ましい。ファイルベースとレジストリベースの両構成は、ユーザー固有であってもシステムワイドであってもよい。使用されるアプリケーション配布システムは、各ファイルがこれらの種類のいずれであるかをマークする必要がある。この情報は、オペレーティングシステムガードシステムが適切に動作するために役立つ。
【００３４】
デバイスドライバ
多くのアプリケーションは、ハードウェアサポートまたはオペレーティングシステムとの低レベルの直接的相互作用など一部の機能を実現化するために、デバイスドライバまたはその他のオペレーティングシステムレベルソフトウェアを使用する。本発明では、オペレーティングシステムガードが、これらのコンポーネントをアプリケーションの仮想環境に対して動的に、そして、なるべくプライベートに追加および削除する機能を提供する。
【００３５】
多くのデバイスドライバは、動的にロード可能であるように構築される。可能であればすべてのデバイスドライバを動的にロードすることが、好ましい実施形態である。起動時にデバイスドライバを静的にロードする必要がある場合、アプリケーションを実行する前にユーザーはこの知識を得ていなければならない。システムを再起動した場合、アプリケーションを前回停止したところから継続することが望ましい。しかし、デバイスドライバのほとんどは動的にアンロードすることができない。ドライバを動的にアンロードしないことが望ましいが、これが実現できない場合は、次回の再起動時に削除するようにドライバがマークされる。ユーザーにこのことを通知することが望ましい。次回の再起動の前のアプリケーション実行が２度目である場合、システムはドライバが存在することを認識し、２度目のインストールを試みずに、終了を待ってから次回の再起動時に削除可能なコンポーネントを認識することが望ましい。
【００３６】
本発明を正しく機能させるには、各デバイスドライバクラスについて基本的な類似点と相違点を特徴づけることが大切である。常駐するシステムハードウェア用のデバイスドライバをロード・アンロードすることは望ましくない。プログラミングの容易さという点ではこれは好ましい実施形態ではないが、本発明の範囲を逸脱するものではなく、特別な理由で必要とされることがある。たとえば、本発明を使用して配布・実行されるアプリケーションの使用許諾を制限する場合である。
【００３７】
Ｍｉｃｒｏｓｏｆｔ以外のプラットフォームでは、デバイスドライバの扱いが異なることが多い。Ｍａｃｉｎｔｏｓｈシステムは静的ドライバと動的ドライバの双方をサポートするが、両ドライバはすべて同じ方法でインストール・削除される。Ｍａｃｉｎｔｏｓｈシステムフォルダにリンクすることにより、必要なサポートが提供される。ＵＮＩＸ（登録商標）システムではほとんどの場合、デバイスドライバを使用するために、実行中のＵＮＩＸ（登録商標）カーネルを変更した後で再起動しなければならない。このプロセスは非常に複雑な場合がある。好ましい実施形態では、このプロセスが自動化される（アプリケーション完了後のカーネルリセットなど）。このプロセスの一般的条件は、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションについて説明した条件（実際の編集処理段階）と同じであり、このようなオペレーティングシステムに熟知したユーザーは再起動を実行することができる。
【００３８】
最後に、システム障害が発生した場合にドライバを回復・削除できることが望ましい。したがって、システムの完全性を保持するために必要なデータまたはプロセスはすべて本発明の好ましい実施形態である。さらに、いずれの種類のデバイスドライバも本発明によって都合良くまたは効果的に提供されるとは限らず、このことは、特に常設のハードウェアの付加デバイスに関連するものに成り立つこともまた当業者に了解されることである。
【００３９】
その他の項目
本発明では、代替オペレーティングシステム上ではそれらの動作または存在形態が異なるものとなる発明のいくつかのコンポーネントのあることが認められる。これらのコンポーネントには、フォント、プロセス、環境変数などが含まれる。
【００４０】
一部のアプリケーションでは、正しく実行するためにフォントをインストールしなければならない。必要なフォントはいずれも、オペレーティングシステムガードの構成ファイルで指定される。オペレーティングシステムガードはアプリケーションの実行に先立ってこれらのフォントを有効にし、必要であれば、実行後にフォントを削除する。ほとんどのシステムには、フォントを登録するプロセスまたはフォントの存在をシステムに通知するプロセスの他に、フォントを格納する共有領域があり、オペレーティングシステムガードはこれらの利用可能な方法を活用する。
【００４１】
Ｗｉｎｄｏｗｓ（登録商標）では、フォントは￥ＷＩＮＤＯＷＳ（登録商標）￥ＦＯＮＴＳディレクトリにコピーされる。ただし、これによって、実行中のプログラミングでそのフォントが利用できることが保証されるわけではない。好ましい実施形態では、プログラムがＷｉｎｄｏｗｓ（登録商標） ＡＰＩを使用してフォントにアクセスする場合、ＣｒｅａｔｅＳｃａｌａｂｌｅＦｏｎｔＲｅｓｏｕｒｃｅ／ＡｄｄＦｏｎｔＲｅｓｏｕｒｃｅなどのＷｉｎ３２ ＡＰＩ呼び出しでフォントを登録する必要がある。これにより、フォントがシステムフォントテーブルに挿入される。挿入が完了すると、オペレーティングシステムガードは別の適切なＡＰＩ呼び出し（ＲｅｍｏｖｅＦｏｎｔＲｅｓｏｕｒｃｅなど）でフォントを削除し、システムからファイルを削除することができる。別の実施形態として、オペレーティングシステムガードは仮想レジストリ方法で説明したようにＡＰＩ関数をフックすることができる。さらに、オペレーティングシステムガードはファイルサブシステムを使用して、実際のフォントファイルが実行されているシステムに配置されることを防止することができる。
【００４２】
Ｍａｃｉｎｔｏｓｈでは、このプロセスは酷似しており、Ｍａｃｉｎｔｏｓｈシステムフォルダ内のファイルと登録アクティブ化に基づいている。しかしＵＮＩＸ（登録商標）では、このプロセスはアプリケーションに依存する。最も一般的には、適切な場所で解決された通常ファイルとしてフォントリソースがシステムに追加されるため、フォントリソースに名前でアクセスすることができる。多くのＭｏｔｉｆシステムでは、フォント記述をフォントリソースファイルに配置する必要がある。これにより、フォントの解決が可能になる。ＭｏｔｉｆまたはＸアプリケーションは、解決サブシステムまたはた直接呼び出しのいずれかでフォントを呼び出すことができる。最近では、ＭｏｔｉｆおよびＣＤＥベースシステムの多くで、Ａｄｏｂｅスケーラブルポストスクリプトフォントが利用されている。このフォントは、Ａｄｏｂｅタイプ管理システムで管理する必要がある。ただし例外があり、上述のように、Ｗｉｎｄｏｗｓ（登録商標）またはその他のオペレーティングシステムの既定フォント管理システムに代わるシステムが存在する。Ａｄｏｂｅ Ｔｙｐｅ Ｍａｎａｇｅｒは、他のサードパーティのタイプ管理システムと同様に、このプロセスに代替インタフェースを提供する。ほとんどの場合、このインタフェースをサポートするか無視するかを決めることが望ましい。オペレーティングシステムガードの目的は、これらのシステムすべてに対応する汎用インタフェースを提供することではなく、オペレーティングシステム固有のサブシステムに対応するインタフェースのみ提供することである。
【００４３】
環境変数の設定を必要とするアプリケーションが多い。このことはＵＮＩＸ（登録商標）システムに最もよく当てはまるが、当初ＵＮＩＸ（登録商標）上で書き込まれＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムに移植されたソフトウェアでも環境変数が頻繁に使用される。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム上のアプリケーションはＤＯＳ ＰＡＴＨ環境変数に強く依存し、アプリケーション固有のエントリを設定することが多い。Ｗｉｎｄｏｗｓ（登録商標） ９ｘ／Ｍｅ環境では、基本的にはＤＯＳサブシステムであるため適用可能である多くの環境設定が存在する。アプリケーションが特定の変数を必要とする場合、または既存の環境変数に値を設定する必要がある場合、必要な環境変数はオペレーティングシステムガードの構成ファイルで指定される。オペレーティングシステムガードは、起動時にアプリケーションのメインプロセスに対してこれらの変数を設定する。アプリケーションは通常、動作時に環境変数を変更しないため、仮想環境はこれらの呼び出しを捕捉せず、レジストリと構成サブシステムが提供する機能一式も提供しない。
【００４４】
回復
これまで示してきたいくつかのケースでは、オペレーティングシステムを実際に変更しなければならない。デバイスドライバとフォントが変更されることが多い。さらに、次回のアプリケーション実行時にも存続し利用可能でなければならない仮想環境を変更することもできる。オペレーティングシステムガードはシステムに対する変更を回復し、できるだけ早くシステムから変更を除去できなければならない。別の方法では、アプリケーション実行時にシステムがクラッシュした場合、オペレーティングシステムガードは、再起動時などにシステムに対する変更を除去するために十分な情報を追跡し、仮想環境に対する変更を追跡することが望ましい。好ましい実施形態では、この追跡はトランザクションログとして実現化される。ただし別の実施形態では、変更を取り消すことができるようにシステムの起動時に読み取ることができる他の類似コンポーネントとして実現化することもできる。
【００４５】
仮想化の制御
本発明の重要な態様は、オペレーティングシステムガードが実行できる仮想化の様々な局面の制御に関する。好ましい実施形態では、ソフトウェアシステムの正しい状態を確実に制御できる計装プログラムが存在する。また、システムによって仮想化される項目を管理者とエンドユーザーが視認および変更できるようにする方法も含まれる。
【００４６】
自動プログラムでは、制御の状態を評価するために制御対象のアプリケーションが監視される。自動プログラムは、アプリケーションのインストールプロセス時、アプリケーションの実行時、またはその両方でこの監視タスクを実行できる。好ましい実施形態では、オペレーティングシステムガードがラッパーアプリケーションに組み込まれる。インストール後、またはソフトウェアを１回以上使用した後、ラッパーアプリケーションはソフトウェアの活動すべての詳細リストについてオペレーティングシステムガードに問い合わせる。この活動リストを基に、ラッパーアプリケーションは、以降の使用時にオペレーティングシステムガードをロードし作動させるために必要な構成ファイルを作成する。
【００４７】
好ましい実施形態では、オペレーティングシステムをインストールプロセスの一部として使用する場合、オペレーティングシステムガードは、インストールをその環境にのみ入れることを許可する仮想レイヤとして機能する。インストール後、後の再ロードに備えてすべてのファイルや設定などをダンプすることができる。この方法では、インストールによって元のシステムが変更されることはなく、必要な構成ファイルが自動的に作成される。アプリケーションの使用中にオペレーティングシステムガードを使用すると、環境に対する差分変更の記録、または構成ファイルの再作成が可能になる。
【００４８】
オペレーティングシステムガードは、後処理のために情報をラッパーアプリケーションに渡す。好ましい実施形態では、システムが作成できる自動エントリに加え、オペレーティングシステム固有、アプリケーション固有、またはドメイン固有の知識でラッパーアプリケーションがプログラムされる。この知識は、構成項目またはその他のエントリの周知の使用状況を反映するようにプロセスの出力を変更するために使用される。好ましい実施形態では、コーディングを変更するために、ルールベースシステムを利用して、監視された動作と周知のシナリオを比較する。
【００４９】
ラッパーアプリケーションは、プロセスの構成出力に対するビューアおよび／またはエディタとしても使用される。好ましい実施形態では、このエディタを使用してシステム管理者は、構成に対する項目または項目グループの追加、編集、または削除ができる。エディタによって構成を観察する際、管理者は構成の複製を作成し、アプリケーションレベルの変更またはユーザー独自の変更を行うために必要に応じて特定の項目を変更することもできる。
【００５０】
図１では、本発明の一実施形態の機能を示している。この実施形態では、アプリケーション／ユーザーデータ（６０）が２セットある。オペレーティングシステムガード（１００）は、アプリケーション（５０）の２つのインスタンスが互いに干渉することを防止する。また上述のように、オペレーティングシステムガード（１００）は抽象化レイヤとして機能し、クライアントコンピュータのアプリケーションソフトウェア（５０）と実際のオペレーティングシステム（１０）との間でコマンドと通信を収集する。矢印で示したように、一部のコマンドはオペレーティングシステムガードとソフトウェアアプリケーションとの間にある。このことが、一般的なインストールと違う点である。一般的なインストールでは、これらのコマンドはオペレーティングシステム自身によって実行されるため、オペレータの意図とは必ずしも一致しない変更がクライアントコンピュータに生じる。一方、その他のコマンドはオペレーティングシステムガードを経由してオペレーティングシステム自身に転送される。
【００５１】
好ましい実施形態と合わせて本発明を詳述してきたが、添付した請求項によって網羅される本発明の範囲から逸脱することなく形態と詳細を様々に変更できることは当業者にとって理解されるであろう。
【図面の簡単な説明】
【００５２】
【図１】本発明、オペレーティングシステム、およびソフトウェアアプリケーションの相対的関係を示すブロック略図である。
【図２】を示すブロック略図である。
【図３】を示すブロック略図である。
【図４】を示すブロック略図である。
【符号の説明】
【００５３】
１０：オペレーティングシステム
５０：アプリケーション
５２：アプリケーション１、インスタンス１
５４：アプリケーション１、インスタンス２
６０：アプリケーション／ユーザーデータ
１００：オペレーティングシステムガード
１０２：コア
１０４：構成マネージャ
１０６：ファイルマネージャ
１０８：共有オブジェクトマネージャ
１１０：デバイスマネージャ
１１２：フォントマネージャ
１１４：プロセス環境マネージャ
１１６：ローダー（サブシステム）
１１８：リカバリマネージャ
１２０：プロセスマネージャ
１５２：構成
１５４：構成

Claims (17)

1. クライアントコンピュータのオペレーティングシステムを変更することなくアプリケーションソフトウェア環境を作成するための、オペレーティングシステム抽象化／保護レイヤから成るシステムであって、実行されているソフトウェアアプリケーションと前記オペレーティングシステムとの間に前記抽象化／保護レイヤを挿入するようにし、これにより、アプリケーションを実行できる仮想環境を提供しアプリケーションレベル間の相互作用を実質的に除去するものであることを特徴とするシステム。
2. オペレーティングシステムに対する直接的な変更が、実行されているアプリケーションのコンテキスト内で選択的に行われるものであることを特徴とする請求項１記載のシステム。
3. 抽象化／保護レイヤが管理設定に従って仮想環境を動的に変更するものであることを特徴とする請求項２記載のシステム。
4. システムが共有システムリソースの使用状況を継続的に監視し、システムコンポーネントに対する変更を適用および除去するサービスとして機能するものであることを特徴とする請求項１記載のシステム。
5. オペレーティングシステムがＷｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステムであるようにし、Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙと．ｉｎｉファイルに対する操作はすべてＷｉｎ３２ ＡＰＩによって行われるものであり、関数が呼び出されるたびに別の関数またはアプリケーションがその呼び出しを中断するように前記関数をフックするための手段からさらに有することを特徴とする請求項１記載のシステム。
6. サーバーから実行されているアプリケーションによる要求であれ、アクティブに管理されている構成キーに対してアプリケーションが出した要求であれ、要求に応えるためにシステムが該当するＡＰＩ関数それぞれをフックするものであることを特徴とする請求項５記載のシステム。
7. 前記オペレーティングシステム抽象化／保護レイヤは、実行されているアプリケーションインスタンスの数を認識することで、１つのアプリケーションの多重のインスタンスの統合を管理するものであることを特徴とする請求項１記載のシステム。
8. 実行されているアプリケーションインスタンスが１つのみではない場合、前記オペレーティングシステム抽象化／保護レイヤは、起動時とシャットダウン時の変更を避けるものであることを特徴とする請求項７記載のシステム。
9. 前記オペレーティングシステム抽象化／保護レイヤが、インストールを実行しないでもインストール環境のように出現する環境をアプリケーションに提供することにより、アプリケーションの実行時にすべての設定が仮想環境にもたらされる「擬似インストール」が作成されるものであることを特徴とする請求項１記載のシステム。
10. クライアントコンピュータ上の情報によってアプリケーションの動作が干渉されたり変更されることを防止するための手段をさらに有することを特徴とする請求項９記載のシステム。
11. 管理設定に従って仮想環境を動的に変更するための手段をさらに有することを特徴とする請求項９記載のシステム。
12. 単一ソフトウェアアプリケーションの複数のインスタンスが同じクライアントコンピュータ上で実行されるものであり、前記複数のインスタンスの各々が１つの異なるデータベースに接続されるものであることを特徴とする請求項９記載のシステム。
13. 単一アプリケーションの前記の複数のインスタンスのうち少なくとも２つが、１つ以上の仮想設定を共有するような、共有・制御されたコンテキストを提供するものであることを特徴とする請求項１２記載のシステム。
14. 特定のアプリケーションについてインストール時に命令を受け取るデバイスドライバモニターをさらに有することを特徴とする請求項１記載のシステム。
15. 全機能レジストリをアプリケーションに提供するが、基本システムレジストリに対する変更は防止する仮想Ｗｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙコンポーネントをさらに有することを特徴とする請求項１記載のシステム。
16. キーおよびキーの値がオペレーティングシステム抽象化／保護レイヤに格納されている場合は、オペレーティングシステム抽象化／保護レイヤが前記キーおよびキーの値で応答し、格納されていない場合は、オペレーティングシステム抽象化／保護レイヤが要求をＷｉｎｄｏｗｓ（登録商標） Ｒｅｇｉｓｔｒｙまで通過させることを許容するものであることを特徴とする請求項１記載のシステム。
17. 前記キーの値の変更が試みられた場合、オペレーティングシステム抽象化／保護レイヤは、それ自身に対する変更のみを許容するものであることを特徴とする請求項１６記載のシステム。

Images