JP2002529812A

JP2002529812A - 実行時にコンパイルされたコンピュータコードの機能を改変するためのシステム

Info

Publication number: JP2002529812A
Application number: JP2000580089A
Authority: JP
Inventors: タカシコサカ，; マイケルプレート，
Original assignee: セガソフト，インコーポレイテッド
Priority date: 1998-10-30
Filing date: 1999-10-29
Publication date: 2002-09-10
Also published as: AU1519100A; US6898788B2; US6298481B1; US20020100028A1; WO2000026780A1

Abstract

(57)【要約】プログラムのシンボルリファレンスの１以上がリダイレクトに適するように変更されるように、コンピュータプログラムが変換され得るシステム。リダイレクト可能なシンボルが備えられると、プログラムの機能は後に、たとえば、起動時またはランタイム時に、容易に変更される。第１のフェーズ（３０４）は、シンボルがリダイレクトされ得るように、存在するコンピュータプログラムを変換する。この第１のフェーズ（３０４）はさらに、後のフェーズにおいて用いられる補助ファイルを生成する。第２のフェーズ（３０６）において、変換されたコンピュータプログラムがユーザのコンピュータにロードされて実行される。第３のフェーズ（３０８、３０９、３１０）において、コンピュータプログラムのオリジナルの機能が改変される。第４のフェーズ（３１２）において、改変された機能がエンドユーザのコンピュータにロードされ、変換されたプログラムと共に実行される。

Description

【発明の詳細な説明】

【０００１】（著作権表示）本明細書中に記載される開示の一部は、著作権保護を条件とする資料を含む。
詳細には、本発明をコンピュータシステムで実施するプロセスに関するソースコ
ード命令を表にした、３７ＣＦＲＳｅｃｔｉｏｎ１．９６に従ったマイク
ロフィッシュ付属書類を含む。このマイクロフィッシュＡｐｐｅｎｄｉｘは、６
３フレームまたはページ分のソースコードＡｐｐｅｎｄｉｘを含む１シートのマ
イクロフィッシュから成る。本著作権所有者は、米国特許商標庁に出願される明
細書の複製に異議を唱えない。その他に関しては、全ての著作権が留保される。

【０００２】（発明の背景）本発明は、一般に、コンピュータプログラムの実行に関し、さらに詳細には、
コンパイルされたコンピュータプログラムの実行時機能の改変を可能にするシス
テムに関する。

【０００３】コンピュータプログラムまたはコードは、多くの異なる方法で実行することが
可能である。翻訳コードを実行することによるもの、またはコンパイルコードを
実行することによるものが、２つの主要で、且つ基本的に異なる方法である。

【０００４】翻訳コードは、一般に、人間が読むことができるコードに基づいて、行ごとに
動作することをプロセッサに要求する。すなわち、コンピュータプログラム表現
が、テキストベースの形式であるか、またはコードが「トークン化」されている
ようなテキストベースの形式からかけ離れていないので、人間のプログラマーに
よって書かれるコードとプロセッサによって実行されるコードは非常に類似して
いる。コンパイルコードとは異なり、翻訳コードは、長い「構築」時間を必要と
しないという利点を有する。本質的に、プログラマーは、翻訳コードを書き、且
つそのコードをテストする目的で、コードをすぐに実行することが可能である。
この点で、翻訳コードは、ラピッドプロトタイピング（ｒａｐｉｄｐｒｏｔｏ
ｔｙｐｉｎｇ）に有用である。翻訳コードは、一般に、速度が重要な問題ではな
い些細な用途によく適する。これは、翻訳コードの大きな欠点が、コンパイルコ
ードと比較して、よく知られているとおり遅いからである。

【０００５】コンパイルコードは、非常に高速な実行プログラムである。しかしながら、コ
ンパイルコードの生成および維持は、翻訳コードよりもはるかに困難である。ま
た、コンパイルプログラムアプローチで作成されたプログラムは、開発および改
変がより複雑である。通常、変更がテストできる前、または受渡し可能な実行可
能なもの（ｄｅｌｉｖｅｒａｂｌｅｅｘｅｃｕｔａｂｌｅ）が作成される前に
、コンパイル、リンク、およびロードされなければならないプログラムモジュー
ルが多く必要とされる。時に「プロジェクト」と呼ばれる、大型のコンパイルさ
れたコンピュータプログラム内には、数百の異なるモジュールまたはファイルが
存在する。これらのプロジェクトの構築プロセスは、それ自体が複雑であり、記
号、プロセス、リソース、およびプログラム開発の他の局面の正確な調整を必要
とする。コンピュータプログラムの完全な構築は、プログラムのサイズによって
は、何時間も要する可能性がある。さらに、コンパイルコードの開発は、モジュ
ール、ユーティリティー、ツール、および他の開発者支援ソフトウェアの正確な
アーカイビング、ブックキーピング（ｂｏｏｋｅｅｐｉｎｇ）、ならびにトラッ
キングを必要とする。コンピュータプログラムが古くなるにつれて、たとえ実行
可能なバージョンのプログラムがまだ使用中であっても、特定のバージョンのプ
ログラムを再構築することが困難または不可能になり得る。これは、プログラム
を構築するために用いられるオペレーティングシステム、開発環境、ツール、ユ
ーティリティー、または他のソフトウェア（またはハードウェア）が変更され得
るからである。

【０００６】プログラマーが、コンパイルプログラムおよび開発環境の詳細な知識を有して
いなければならないので、コンパイルプログラムプロジェクトの元々のプログラ
マーでないプログラマーが、「予備知識を得て（ｃｏｍｅｕｐｔｏｓｐｅ
ｅｄ）」、別のプログラマーによって書かれたソフトウェアに改変することは困
難である。コンパイル、リンク、およびロードされた実行可能コードは、いずれ
の実際的な意味においても、人間のプログラマーには読むことができず、プログ
ラマーに人間が読むことができる「ソース」コードバージョンのプログラムの学
習を強要するだけでなく、そのプログラムに関する構築プロセスの詳細な実用的
な知識を有することも強要する。よって、コンパイルコードの維持および改変に
は問題がある。

【０００７】翻訳およびコンパイルコードの両方の別の特性は、コードの実行時機能または
行動を変更することが困難であることである。翻訳コードアプローチでは、全く
新しい翻訳コード命令の集合が、ユーザコンピュータにロードされなければなら
ない。コンパイルコードは、通常、後述するアプローチが完全に新しいバージョ
ンのコンパイル実行可能物のローディングを回避するために開発された、翻訳コ
ードよりもはるかに大きい。翻訳コードは比較的に小さく、よって、新たなバー
ジョンのロードを容易にするが、非常に大きなプログラムの高速な実行を必要と
するアプリケーションプログラムの大部分には適さない。翻訳コードの例として
は、ＢＡＳＩＣ、Ｌｉｓｐ、ならびにＰｅｒｌおよびＪａｖａ（登録商標）等の
スクリプト言語がある。コンパイルコードアプローチで用いられる言語の例とし
ては、Ｆｏｒｔｒａｎ、「Ｃ」、アセンブリ言語、その他がある。しかしながら
、これらのカテゴリーは、適切な「インタープリタ」または「コンパイラ」がそ
のコードを実行することが意図されるターゲットマシンのために書かれることを
仮定すると、いずれのコンピュータ言語も、コンパイルコードまたは翻訳コード
アプローチとしてインプリメントされ得るので、幾分あいまいに定義される。

【０００８】図１Ａ〜Ｆを参照して、従来技術に関して以下に述べる。

【０００９】図１Ａは、翻訳コードを実行するためのプロセスを示す簡略図である。

【００１０】図１Ａにおいて、プログラム１０は、プログラマーによって生成される。通常
、これはワードプロセッシングプログラムでなされ、人間が読むことができるテ
キストとなる。このプログラムは、ユーザコンピュータ１２にロードされる。転
送またはローディングは、フロッピー（登録商標）ディスク、コンパクトディス
ク読み出し専用メモリ（ＣＤＲＯＭ）、ネットワークからのダウンロード、また
は他の手段によってなされ得る。ロードプログラム１４は、通常、プログラマー
によって作成されるオリジナルテキストの完全なコピーである。ロードプログラ
ム１４は、インタープリタ１６によって翻訳され、ユーザコンピュータ内で所望
の実行時機能を作成するために、プログラムコード、またはスクリプトによって
特定される機能を実行する。よって、翻訳コードアプローチでは、単一のプログ
ラム定義のみが存在する。プログラム１０のプログラム定義は、プログラムの人
間が読むことができる定義、およびユーザコンピュータ内の実行イメージとして
役立つ。

【００１１】図１Ｂは、コンパイルコードを実行するためのプロセスを示す簡略図である。

【００１２】図１Ｂにおいて、アイテム２０〜３０は、ソフトウェア構築プロセスの一部で
あり、それによって、機械が読むことができる実行可能オブジェクトが、人間が
読むことができるソースコードモジュールから生成される。アイテム３４〜３８
は、ユーザコンピュータ３２上のコンパイルソフトウェアプログラムの実行に関
連するアイテムを示す。

【００１３】図１Ｂにおいて、ソースコード２０がプログラマーによって生成され、これは
、人間が読むことができるバージョンのプログラムである。通常、コンパイルコ
ード開発環境にあるプログラマーは、ソースコードの個別のファイルを処理し、
例えば、図１Ｂのソースコード２０は、プログラムプロジェクト内で用いられる
多くのモジュールのうちの単一のモジュールを表わす。１つのモジュールは、数
行から数百以上の行までのコードを有することが可能である。ソースコード２０
は、コンパイラ２２によってコンパイルされ、オブジェクトファイル２４となる
。各モジュールは、プログラムプロジェクト内の他のいずれのモジュールからも
独立してコンパイルすることが可能である。これによって、プログラムの断片が
、モジュールごとに、プログラムプロジェクト内の多くのモジュールの全てのコ
ンパイルを必要とせずに、改変することが可能である。しかしながら、モジュー
ル内の１行を変更することでさえも、後述のとおり、モジュール全体の再コンパ
イル、およびプロジェクト全体の再構築を必要とすることに留意されたい。

【００１４】一旦コンパイルされると、オブジェクトファイルは、プログラムプロジェクト
内の他のオブジェクトファイルにリンクすることが可能である。他のオブジェク
トファイルは、そのプログラマーまたは別のプログラマーが書いた他のコンパイ
ルソースコードモジュールからのものであり得る。リンク可能なオブジェクトモ
ジュールのための他のソースは、共通して必要とされる機能を提供するために、
予め存在するライブラリオブジェクト２６を含む。プログラプロジェクトのため
のオブジェクトファイルの全てが、単一の実行可能オブジェクト３０を作成する
ために、リンカー２８を介してリンクされる。実行可能オブジェクト３０を作成
することにより、プログラムの構築が完結する。（後述するダイナミックリンキ
ング（ｄｙｎａｍｉｃｌｉｎｋｉｎｇ）は別にして）一般に、構築のためには
、モジュール、ライブラリ、および他のオブジェクトファイルソースの全てから
のオブジェクトファイルの全てを手近に有する必要があることに留意されたい。
これは、異なるオブジェクトが、異なるプログラマーの行動の結果として、異な
る時点に変更され得るので、大型のプログラムでは問題となる。後にコンパイル
プログラムの機能を、プログラムの再構築によって、変更することが所望される
場合、例えば、相互に互換性のあるオブジェクトファイルの集合を有する必要が
ある。本質的に、これは、オブジェクトファイル中の全ての「記号」リファレン
スが一致しなければならないことを意味する。記号は、プロセス、ルーチン、サ
ブルーチン、関数、およびデータ構造等のソースコード内の異なるオブジェクト
または項目を参照する、単なるテキストラベルにすぎない。この構築プロセスが
非常に複雑なために、プログラマーの「開発者環境」は、モジュール、オブジェ
クトファィル、記号リファレンスの調整、および他の関連するタスクの実施を支
援する、ソフトウェア開発「ツール」製造者によって提供される。

【００１５】図１Ｂに戻って、オブジェクトファイルのリンクの結果が、実行可能オブジェ
クト３０である。実行可能オブジェクト３０は、実行のために、ターゲット、ま
たはユーザコンピュータ３２に次に転送される、受渡し可能な生成物を表わす。
通常、実行可能オブジェクト３０は、実行可能イメージ３４を作成するために、
実行可能オブジェクトをシステムランダムアクセスメモリ（ＲＡＭ）に配置する
、ローダ３２によってロードされる。翻訳コードの場合と同様に、実行可能オブ
ジェクトが、任意のコンピュータ可読媒体で転送されるか、インターネット等の
通信リンク上を転送されるか、または他の手段によって、ユーザコンピュータ内
に格納されることが可能である。実行可能イメージ３４は、ユーザコンピュータ
内のプロセッサによってアクセスされ、コンパイル命令を実行することにより、
元々のソースコード命令に従って機能を提供する。

【００１６】コンパイルコードの実行が、いくつかの工程および多くの異なるファイル、な
らびに元々のソースコード命令の変換を必要とすることに留意されたい。これは
、翻訳コードの実行とは対照的である。コンパイルコードの調整および処理の複
雑さは、今日のコンピュータの用途の多くで所望される最大速度および効率を達
成するために必要である。

【００１７】しかしながら、問題は、これらのプログラムの機能を実行時に改変することが
困難であるという点で、翻訳およびコンパイルプログラムアプローチの両方に存
在する。すなわち、ユーザがプログラムを実行しているときに、元々のプログラ
ムの開発者、製造者、または他の提供者が、ユーザに提供されるプログラムの機
能を改変することが困難または不可能である。このことを十分に示すために、翻
訳コードおよびコンパイルコードアプローチの両方について、さらに詳細に示す
。

【００１８】図１Ｃは、翻訳ソースコードのごく一部の一例を示す。図１Ｃにおいて、Ｊａ
ｖａ（登録商標）タイプのコードの一部を示す。この一例として、１９９７年に
、Ｏ’Ｒｅｉｌｌｙ＆Ａｓｓｏｃｉａｔｅｓ，Ｉｎｃによって出版された
、ＤａｖｉｄＦｌａｎａｇａｎによる「Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ，Ｔｈｅ
ＤｅｆｉｎｉｔｉｖｅＧｕｉｄ」等の参考文献に記載のＪａｖａ（登録商標）
Ｓｃｒｉｐｔ言語がある。図１Ａは、図１Ａのロードプログラム１０内等のユー
ザコンピュータシステム内に常駐しているように見えるＪａｖａ（登録商標）Ｓ
ｃｒｉｐｔを示す。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔは特殊構文で書かれてい
るが、標準的な英数字の英語文字を用いており、人間が読むことができる。よっ
て、当業者は、ユーザコンピュータ上に常駐する３行のスクリプトをすぐに見る
ことが可能であり、且つそれらの行がコンピュータに、各数字の間の間隔で、１
〜１０までの数字を印刷するように指示していると判断することが可能である。

【００１９】例えば、このコードの１〜２０までの数字を印刷すること等の機能を改変する
ために、全く新しいソースコードモジュール、またはドキュメントが、獲得され
、且つ図１Ｃに示す行を含むソースコードモジュールの書き換えられなければな
らない。通常、これは、ソースコードモジュールが非常に小さなサイズであれば
問題ではない。例えば、Ｊａｖａ（登録商標）タイプの言語は、ＷｏｒｌｄＷ
ｉｄｅＷｅｂページ内に埋めこまれて、あるいはそれに関連してロードされて
用いられるインターネットでは非常に一般的である。Ｊａｖａ（登録商標）「ア
プレット」が、非常に小さくなる傾向にあるので、新たなバージョンのアプレッ
トが、ユーザが情報のページにアクセス（すなわち、ロード）するたびに提供さ
れる。このようにして、ソースコードへの変更が、ユーザが実行しているバージ
ョン内で、常に可能である。

【００２０】しかしながら、上述のとおり、翻訳ソースコードは、（コンパイルコードと比
較して）実行が非常に遅いという大きな欠点を有する。また、人間が読むことが
できる形式が空間効率がよくない（ｎｏｔｓｐａｃｅ−ｅｆｆｉｃｉｅｎｔ）
ために、大型のプログラムは翻訳コードで書かれない。

【００２１】図１Ｄは、コンパイル実行可能オブジェクト部分がどのように見えるかの一例
を示す。実行可能オブジェクトは単に、１６進数として図１Ｄに表わす、一連の
数字である。通常、これらの数字は、専用のビューイングプログラムが用いられ
ない限り、読むことができる数字として見ることすらできない。これらの数字は
、ユーザコンピュータシステム内の中央処理装置（ＣＰＵ）が、間接的な翻訳ア
プローチではなく、直接的に実行する、機械レベルの命令を表わす。

【００２２】例えば、図１Ｃの翻訳コード命令において、行ごとの翻訳が起こり得る。コン
ピュータは、１行のスクリプトを読み込み、その行の構文解析を行い、一連の機
械命令にその行を変換して、命令を実行する。いくつかの場合において、この変
換は、翻訳コードが代わりにコンパイルされた場合に、結果として生じる数字と
、結果として類似した数字となる。しかしながら、多くの場合において、翻訳コ
ードは、単一の行の翻訳コードを実行することだけを考慮した場合でも、高速ま
たは簡潔ではない。当然、翻訳された行の読み込み、構文解析、変換、および実
行は、プログラマーによって意図された機能を実際に実施するたった数個の機械
命令の最終的実行を達成するために、多くの余分な「オーバーヘッド」工程を実
行することをプロセッサに要求する。他方、コンパイルプログラムアプローチの
実行可能なオブジェクトは、すでに機械が読むことができる形式であり、プログ
ラマーが所望する機能を実現するための命令のみを含む。よって、コンピュータ
は、各機械命令を、そのプロセッサに直接ロードし、翻訳コードアプローチの実
行時オーバーヘッドを経ることなく、命令を実行することが可能である。コンパ
イルコードの使用は、プロセッサの速度、ならびにコンピュータの制限されたメ
モリおよびディスクスペースを十分に利用するために、絶対的に必要である。

【００２３】図１Ｄの実行可能オブジェクトコード部分から分かるとおり、数字が、メモリ
内の隣接する位置を占める。これによって、実行可能物に命令またはデータを加
える改変を実施することが困難になる。また、ユーザコンピュータ内に常駐する
実行可能オブジェクトの機能を適切に変更するために、新たな、または改変され
た実行可能オブジェクトが、作成されて、エンドユーザに提供されなければなら
ない。これは、インターネット等の通信リンク上でのダウンロードによって行う
ことが可能であるが、今日の実行可能オブジェクトのサイズが大きいために、数
時間のダウンロード時間を要し、コンパイル実行可能オブジェクトの実行時機能
を変更することは非実際的であり、望ましくない。

【００２４】ソフトウェア産業は、実行時にコンパイル実行可能オブジェクトの機能を変更
する２つの基本的アプローチを開発してきた。これらは、（１）既存の実行可能
オブジェクトに「パッチを当てる」こと、または（２）ダイナミックにリンクさ
れるライブラリ（ＤＬＬ）を用いることである。

【００２５】図１Ｅに、コンパイルされた実行可能オブジェクトのパッチングの一例を示す
。

【００２６】図１Ｅにおいて、実行可能オブジェクト５２は、パッチデータ５６を用いるパ
ッチアプライコード５４によって変更され得る。このアプローチにおいて、１６
ビットワードを表す、値０００Ａのような命令または値は、パッチアプライコー
ド５４内の命令を実行することによって、０００５のような異なる値に変更され
得る。パッチアプライコード５４は、パッチデータ５６から新たな値０００５を
入手し、実行可能オブジェクト５２内の適切な位置にデータを挿入する。この例
において、図１Ｄに示すコードの一部分は、パッチをあてた結果として、実行可
能オブジェクト５２内に示すコードを有し得る。

【００２７】実行可能オブジェクト５２のサイズが数十メガバイトのオーダーであり得る場
合、パッチアプライコード５４およびパッチデータ５６（集合的には、「パッチ
」）は、数千バイトのオーダーであり得る。パッチは、典型的には、前の実行可
能オブジェクト（すなわち、図１Ｄの実行可能オブジェクト）内のデータを用い
、変化を作り出し、前の実行可能オブジェクトの代わりとして、新たな実行可能
オブジェクト（図１Ｅの実行可能オブジェクト５２）をセーブすることによって
、新たな実行可能オブジェクトを構成する。当然、発生し得るパッチングのタイ
プには、古い実行可能オブジェクトの一部分を消去することと、古い実行可能オ
ブジェクトに新たな部分を加えることと、古い実行可能オブジェクトの存在する
部分を変更することとが含まれる。

【００２８】パッチアプライコードおよびパッチデータは実行可能オブジェクトよりずっと
小さいので、大きなコンパイルされた実行可能オブジェクトの新たなバージョン
全体のダウンロードより、パッチングがより効率的である。しかし、パッチング
は、プログラムの機能性に、１度の変化を提供するのみである。また、機能性に
おける変化は、プログラムが実行される前に起こる。この点に関して、パッチン
グアプローチは、コンピュータコードの機能性の実行時変更を提供しない。また
、パッチをダウンロードするプロセス、および、パッチをあてて新たな実行可能
オブジェクトを作成するプロセスは、時間が掛かり、パッチを進める認証を与え
ること、パッチがあてられた実行可能オブジェクトがどのディレクトリに保存さ
れ得るのかをを指定すること等によって、しばしばパッチングプロセスに参加す
る必要があるユーザに対してトランスペアレントでない。１つのプログラムに対
して複数のパッチが存在し、ユーザによって適切な順序でパッチがあてられない
場合、パッチは問題の原因となり得る。また、パッチがあてられたプログラムが
実行を開始する前にパッチが入手され、実行される（しばしば、時間が掛かるプ
ロセスである）必要があるので、ユーザのプログラムの実行において、パッチは
厄介な遅延の原因となり得る。

【００２９】第２のアプローチは、ＤＬＬを用いるアプローチであり、機能性の実行時変更
をある程度可能にする。しかし、このアプローチは、制限され、以下で説明する
所望の柔軟性を欠いている。

【００３０】図１Ｆに、ＤＬＬの使用を示す。

【００３１】図１Ｆにおいて、実行可能イメージ６０は、実行の直前、または実行の間に、
ＤＬＬ６２内のルーチン、関数、および他のアイテムにリンクする。ＤＬＬにリ
ンクするプロセスは、概念において、上で簡略的に説明した、プログラムの構築
の間に図１Ｂのリンカー２８によって行われるプロセスに類似する。ＤＬＬへの
ダイナミックリンクを理解するために、プログラム構築の間のリンクがまず説明
される。

【００３２】上述したように、モジュールは、プログラム開発の間、別個のエンティティと
して処理される。モジュールの情報は、プログラム構築の間に１つの実行可能プ
ログラムを作成するために、結合される必要がある。モジュールの結合における
主なタスクは、他のモジュールにおいて規定され得る、プロセス、ルーチン、サ
ブルーチン、関数、オブジェクト、データ構造、および他のリソースのようなア
イテム（集合的に「アイテム」と呼ぶ）へのシンボリックリファレンスを決定す
ることである。シンボリックリファレンス、またはシンボルは、ソースコードを
書く間にプログラマが用いる、英数字の人間可読名に過ぎない。これらのシンボ
ルは、後でアドレスにマッピングされて、マシン可読コードを発生する。シンボ
ルをアドレスにマッピングするために、シンボルは、対応するアイテムの定義に
関連付けられる必要がある。

【００３３】いくつかのアイテム定義は、アイテムにアクセスする必要がある所与のモジュ
ール内に存在しない。この場合、所与のモジュールは、アイテムがモジュールに
対して外部にあると「宣言」する。コンパイラは、外部で定義されるアイテムへ
のリファレンスを無視し得、そのことにより、コンパイルにおいて他のモジュー
ルを含む必要なしに、所与のモジュールがコンパイルされ得る（かつ、内部エラ
ーについてチェックされ得る）。後に、コンパイラが検出したエラーに関して、
モジュールが固定された場合、所与のモジュールは、実際にアイテム定義を有す
るモジュールに「リンク」される。リンカーは、シンボルが用いられる場所、シ
ンボルが定義される場所、シンボルがマッピングする関連アドレス等のような、
シンボル名についての詳細な情報を提供し得る。大きなコンピュータプログラム
は、何千、何万、あるいはそれより多いシンボリックリファレンスを用い得る。
各プログラマが、典型的には、独自のシンボル名を作り出すので、シンボル名の
記憶および理解が、他のプログラマがプログラムを変更するために十分な程度プ
ログラムを理解しようとする場合、通常越えなければならない主なハードルであ
る。上述したように、シンボルは、１つのモジュールで定義され、他のモジュー
ルにシンボルがモジュールの外部にあると宣言させることによって、他のモジュ
ール、または他の多数のモジュールによって用いられ得る。シンボリックリファ
レンスを処理する、いくつかの他のタイプのメカニズムがある。これらのメカニ
ズムは、特定のコンピュータ言語によって変わる。しかし、コンピュータ言語の
各々は、コンパイルされた言語であると仮定すると、最終的には、リンカーのよ
うなプロセスを用いることによって、複数のソースコードモジュール（または他
のソースコードエンティティ）の中から、シンボル定義およびシンボルの使用を
決定する必要がある。シンボル決定が非常に大きく、プログラムプロジェクトの
全体に渡っているので、コンパイルされたコンピュータプログラムに対する大き
な変化がソースコードモジュールの変更、追加、または消去によって起こり、続
くプログラム全体の再構築が起こって新たなバージョンが作成される必要がある
。上述したように、プログラム全体の構築には、かなりの時間が掛かり、様々な
モジュール、ツール、ユーティリティ、および追加情報の正確なアーカイビング
、ブックキーピング、およびトラッキングを必要とする。

【００３４】ダイナミックリンクは、リンクがスタートアップ時、またはプログラムの実行
時の間に起こることを可能にする。ＤＬＬの基本的な方法は、ある特定のシンボ
ルが、実行において決定される、「エクスポート」（ｅｘｐｏｒｔｅｄ）または
「インポート」（ｉｍｐｏｒｔｅｄ）されたシンボルであると宣言することであ
る。シンボルを決定するコード（すなわち、各シンボリックリファレンスをシン
ボル定義に関連付ける）は、プログラム構築の間、それ自体がプログラムにリン
クされ、実行イメージ６０の一部となる「ＤＬＬリンク」コードである。実行時
、ＤＬＬリンクコードは、実行されて、ＤＬＬに含まれるアイテムへのアクセス
を実行するプログラムに提供する。

【００３５】典型的には、ＤＬＬ６２は、実行イメージ内の命令によって参照され得る、多
くの関数、ルーチン、データ構造、または他のアイテムを含む。ＤＬＬの使用は
、実行可能イメージの実行の前にＤＬＬの関数を変化させることによって、実行
の直前、または実行時に実行可能イメージの機能性を変更する方法を提供する。
例えば、ＤＬＬは、ＭｉｃｒｏｓｏｆｔのＤｉｒｅｃｔＸｌｉｂｒａｒｙのよ
うなグラフィックスライブラリを含み得る。グラフィックスルーチンが変化する
場合、ユーザは、新たなＤＬＬを入手する（例えば、ＣＤＲＯＭ、インターネ
ットからダウンロード等）ことによって自身のＤＬＬをアップデートし、次いで
アップデートされたＤＬＬによって提供される、新たな機能性を利用する同じ実
行可能イメージを実行することができる。

【００３６】このようなＤＬＬの使用には、利点があるが、欠点もある。欠点の１つは、Ｄ
ＬＬ内のいずれか１つのアイテムが実行可能イメージ内の命令によって参照され
る必要がある場合はいつも、ＤＬＬ全体がロードされることである。ＤＬＬ内の
アイテムをグループとして処理する必要性は、アップデートされるＤＬＬ内のア
イテムの割合が小さい場合、非効率的である。すなわち、ユーザは、変化したコ
ードを少量しか含まない、完全に新たなＤＬＬを入手しなければならない。

【００３７】ＤＬＬの第２の欠点は、ＤＬＬを利用し得る実行可能イメージを生じるアプリ
ケーションプログラムにおける特定の準備を必要とすることである。図１Ｂを参
照すると、この準備は、プログラマがソースコード２０のようなソースコードを
書くときに、最初に起こる。典型的には、プログラマは、コードの様々な部分で
ＤＬＬアイテムリファレンスを宣言する必要がある。また、特定のサポートファ
イルが、後で実際にリンクされるＤＬＬアイテムへのリファレンスを決定するた
め、リンカー２８によってリンクされる必要がある。オペレーティングシステム
ごとに異なるＤＬＬを正確にインプリメントするためにさらなる準備をとる必要
がある。ＤＬＬ使用の詳細の多くは、プログラマーによって作り出され、この点
において、後のプログラマが詳細を学ぶ必要がある。概して、ＤＬＬアプローチ
は、依然、小さい、選択的な機能の変化についてうまく作用しない「ライブラリ
」に基づくアプローチである。ＤＬＬと共に用いるアプリケーションプログラム
の準備の説明については、ＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ（登録商標）
９５、ＳｕｎＭｉｃｒｏＳｙｓｔｅｍｓ、およびＳｕｎＯＳのようなオペレーティング
システムを説明する参考文献を参照されたい。

【００３８】従って、従来技術の問題点を解消する実行時機能性の変更を提供するシステム
が所望されることが明らかである。このようなシステムは、ユーザがＤＬＬのよ
うな大きいファイルをアップデートする必要なく、実行の直前、または実行の間
のトランスペアレントで、かつ効率的な機能性の変更を可能にするべきである。
このようなシステムは、プログラマまたは他の開発者による複雑な準備またはオ
ーバーヘッドを必要とすることなく、一般的なアプリケーションプログラムが変
更されることも可能にするべきである。理想的には、システムは、アプリケーシ
ョンのプログラム変換に参加していない人が、アプリケーションプログラムの機
能性を素早く、かつ正確に変更することを可能にし得る。システムは、実行イメ
ージの機能性を変更する命令の効率的な実行を提供し、加えられた、または変化
した機能性に適応する大量のシステムＲＡＭを必要としない。システムは、解釈
されたコードの簡略性および柔軟性を提供し、コンパイルされたコードによって
提供される実行の小型化および速度を維持する。

【００３９】（発明の要旨）本発明は、コンピュータプログラムが変換されて、１つ以上のプログラムシン
ボリックリファレンスをリダイレクト（ｒｅｄｉｒｅｃｔｉｏｎ）に適するよう
にさせるシステムを提供する。リダイレクト可能なシンボルが提供されると、プ
ログラムの機能性は、後で、例えば、スタートアップ時、または実行時に容易に
変化され得る。

【００４０】本発明の他の局面は、本発明の４段階の記載に含まれる。第１段階は、以前に
存在したコンピュータプログラムが変換され、シンボルがリダイレクトされ得る
段階である。また、この第１段階は、後の段階で用いられる補助ファイルを発生
する。第２段階は、変換されたコンピュータプログラムがユーザのコンピュータ
にロードされ、その上で実行される段階である。第３段階は、元のコンピュータ
プログラム機能性が改変される段階である。改変は、高いレベルで起こり、元の
プログラムのプログラミングに関わっていない人によって容易に行われ得る。改
変は、プログラマでない人が、コンピュータプログラムの機能性を変化させ得る
程度まで簡略化される。この第３段階は、第１段階において発生された補助ファ
イルを用いる。第４段階は、改変された機能性がエンドユーザのコンピュータに
ロードされ、変更されたプログラムと共に実行される段階である。

【００４１】本発明の細部によって、ＳｏｆｔｗａｒｅＤｅｖｅｌｏｐｅｒ’ｓＴｏｏ
ｌｋｉｔを構成する１組のツール、ユーティリティールーチン、および工程が提
供されて、ＭｉｃｒｏｓｏｆｔＤｅｖｅｌｏｐｅｒ'ｓＥｎｖｉｒｏｎｍｅ
ｎｔにおいて本発明が実施される。

【００４２】第１段階において、シンボルテーブルが用いられて、リダイレクト能力を備え
るために適切なシンボルを識別する。場合によっては、プログラムの全てのシン
ボルが、所望に応じて、リダイレクトが可能である。コンピュータプログラム命
令、データ、または他のアイテムを参照するシンボル名は、全て、リダイレクト
に対して準備され得る。第１段階のデフォルトの方法は、元のプログラムと同じ
様式で動作する元のプログラムの実行可能オブジェクトバージョンを提供する。
シンボルは、テーブルを通じてマッピングされ、所望の加えられたレベルのリダ
イレクトを提供し、そのことにより、リダイレクト能力を提供する。

【００４３】第２段階において、第１段階の変換されたプログラムから入手された実行可能
イメージがユーザのコンピュータにおいて実行される。第２の段階の実行可能イ
メージの動作は、元の（変換されていない）ソースコードによって定義されるプ
ログラムの機能性と同じである。実際には、変換された実行可能オブジェクトは
、僅かに大きく、元のバージョンより僅かに遅く実行され得るが、この影響は、
通常、無視できる。

【００４４】第３段階において、第１段階から入手された情報を用いて、シンボルがリダイ
レクトされることを可能にする。従って、例えば、データイメージが、前のイメ
ージの代わりになり得、新たなサブルーチンまたは関数が、プログラムの実行に
挿入され得、元のサブルーチン内の命令が編集され得たりする。第３段階は、ユ
ーザのコンピュータにダウンロードされ得るファイルまたファイルのセットを生
成して、段階２の実行可能オブジェクトと共にメモリに常駐させる。これらのフ
ァイルは、「アドオン」モジュールと呼ばれる。

【００４５】第４段階において、アドオンモジュールによって提供される機能性は、スター
トアップ時か、または実行の間に、実行可能イメージに組み込まれる。本発明の
局面の１つは、シンボルのリダイレクトが変更され、従って機能性が変更される
様式を制御するように、言語の記入を提供する。本発明の他の局面は、上述の特
定の段階の各々の細部と関係し、シンボルのリダイレクトを容易にするテーブル
の使用、シンボルの自動識別、ならびにプログラムおよびアドオンモジュール構
築のために必要なコンパイルステップを達成する補助ファイルおよび中間ファイ
ルの発生が含まれる。

【００４６】実行時にリダイレクトされ得るシンボリックリファレンスを有する実行可能オ
ブジェクトにコンピュータプログラムを変換する方法、コンピュータで実行する
方法、プロセッサ兼格納デバイスを有するコンピュータシステム、元の定義への
シンボリックリファレンスを有する元のコンピュータプログラムをさらに含むコ
ンピュータシステム、シンボリックリファレンスについてコンピュータプログラ
ムを走査するプロセスを実行する工程と、１つ以上のシンボリックリファレンス
について代わりのリファレンスを定義する工程と、１つ以上のシンボリックリフ
ァレンスと対応する代わりのリファレンスとの間にリンクを作成する工程と、コ
ンピュータプログラムにおいて代わりのリファレンスと元の定義との間にリンク
を作成する工程とを包含する方法。

【００４７】（特定の実施形態の詳細な説明）本発明を以下のセクションに分けて説明する。第１のセクションにおいて、本
発明における使用に適切な基本的なハードウェア（例えば、コンピュータ、サブ
システムおよびネットワーク等）について説明する。第２のセクションでは、本
発明の概要を提供する。第３のセクションでは、ランタイム改変（ｍｏｄｉｆｉ
ｃａｔｉｏｎ）能力用の初期プログラムを作成するためのツール、ユーティリテ
ィルーチンおよび他のプログラムの特定のセットについて説明する。第４のセク
ションでは、ランタイムにおいて改変された機能を提供するアドオンモジュール
を生成するプロセスについて説明する。第５のセクションにおいて、スクリプト
言語等を用いて、スタートアップまたはランタイム時のアイテムへのリファレン
ス（ｒｅｆｅｒｅｎｃｅ）を部分変更する方法について説明する。第６のセクシ
ョンにおいて、本発明の他の詳細および機能について説明する。

【００４８】１．ハードウェアの説明図２Ａ〜Ｃは、本発明を実施するのに適切な基本的ハードウェア構成要素を示
す。

【００４９】図２Ａは、表示画面２０４を有するディスプレイ２０２を含むコンピュータシ
ステム２００を示す。キャビネット２０６は、標準的なコンピュータ構成要素（
例えば、ディスクドライブ、ＣＤＲＯＭドライブ、表示アダプタ、ネットワーク
カード、ランダムアクセスメモリ（ＲＡＭ）、中央処理装置（ＣＰＵ）および他
の構成要素等）（図示せず）、サブシステムならびにデバイスを収容する。ユー
ザ入力デバイス（例えば、ボタン２１０を有するマウス２０８およびキーボード
２１２等）が図示されている。他のユーザ入力デバイス（例えば、トラックボー
ル、タッチスクリーン、デジタイジングタブレット（ｄｉｇｉｔｉｚｉｎｇｔ
ａｂｌｅｔ）等）も使用可能である。このコンピュータシステムは一般的には、
本発明における使用に適した１つの種類のコンピュータシステム（例えば、デス
クトップコンピュータ）を例示したものに過ぎない。コンピュータは、多くの異
なるハードウェア構成要素で構成可能であり、様々なサイズおよび様式（例えば
、ラップトップ、パームトップ、ペントップ、メインフレーム等）で作成可能で
ある。本明細書に記載の処理を行うのに適切な任意のプラットフォームが、本発
明における使用に適切である。

【００５０】図２Ｂは、コンピュータ（例えば、コンピュータ２００）に通常見受けられ得
るサブシステムを示す。

【００５１】図２Ｂにおいて、ボックス２２０内のサブシステムは、内部バス２２８と直接
インターフェースをとる。このようなサブシステムは典型的には、コンピュータ
システム（例えば、図２Ａのキャビネット２０６）に収容される。サブシステム
は、Ｉ／Ｏコントローラ２２２、システムメモリ（または「ＲＡＭ」）２２４、
ＣＰＵ２２６、表示アダプタ２３０、シリアルポート２４０、固定ディスク２４
２、ネットワークインターフェースアダプタ２４４を含む。バス２２８を用いる
と、サブシステム間で各サブシステムがデータのやり取りを行うことが可能とな
り、また、最も重要なことに、各サブシステムがＣＰＵとデータのやり取りを行
うことが可能となる。外部デバイスは、バス２２８上のサブシステムとインター
フェースをとることにより、バス２２８を介してＣＰＵまたは他のサブシステム
と通信を行うことができる。したがって、モニタ２４６は表示アダプタ２３０に
接続し、相対（ｒｅｌａｔｉｖｅ）ポインティングデバイス（例えば、マウス）
はシリアルポート２４０を通じて接続する。キーボード２５０等のいくつかのデ
バイスは、例えば割込みコントローラおよび関連付けられたレジスタを介して通
信を行うため、主データバスを用いずに直接的手段によってＣＰＵと通信するこ
とができる。

【００５２】図２Ａに示す外部の物理的コンフィギュレーションの場合と同様に、多くのサ
ブシステムコンフィギュレーションが可能である。図２Ｂは、１つの適切なコン
フィギュレーションを例示したものに過ぎない。図２Ｂに示すもの以外のサブシ
ステム、構成要素またはデバイスの追加が可能である。図２Ｂに示すサブシステ
ムを全て使用しなくても、適切なコンピュータシステムが達成可能である。例え
ば、スタンドアロンコンピュータはネットワークに接続する必要がないため、ネ
ットワークインターフェース２４４は不要となる。他のサブシステム（例えば、
ＣＤＲＯＭドライブ、グラフィックアクセラレータ等）が、本発明のシステムの
性能に影響を与えることなくコンフィギュレーションに組み込み可能である。

【００５３】図２Ｃは、典型的なネットワークを一般化した図である。

【００５４】図２Ｃにおいて、ネットワークシステム２６０は、インターネットに接続され
ている複数のローカルネットワークを含む。本明細書中、特定のネットワークプ
ロトコル、物理層、トポロジーおよび他のネットワークプロパティを提示するが
、本発明は、コンピュータシステム間でデータのやり取りを行う任意のスキーム
での使用に適切である。また、本発明は、ネットワークに接続されていないスタ
ンドアロンコンピュータにおいても実施可能である。

【００５５】ユーザ１のコンピュータは、サーバ１に接続される。この接続は、ネットワー
ク（例えば、イーサネット（登録商標）、非同期伝送モード（Ａｓｙｎｃｈｒｏ
ｎｏｕｓＴｒａｎｓｆｅｒＭｏｄｅ）、ＩＥＥＥ規格１５５３のバス、モデ
ム接続、ユニバーサルシリアルバス等）によって為され得る。通信リンクは、有
線である必要はなく、赤外線、電波伝送等であり得る。サーバ１は、インターネ
ットに接続される。インターネットは、サーバルータ２６２の集合として象徴的
に図示されている。情報の配信または通信用にインターネットを用いることは、
本発明の実施にとって必ずしも必要ではなく、これは、単に以下の好適な実施形
態を説明するためだけに使用されるという点に留意されたい。また、サーバコン
ピュータの使用ならびにサーバ機器およびクライアント機器の指定は、本発明の
実施にとってそれほど重要ではない。ユーザ１のコンピュータは、インターネッ
トに直接接続可能である。サーバ１のインターネットへの接続は典型的には、比
較的高帯域の伝送媒体（例えば、ラインＴ１またはラインＴ３等）で為される。

【００５６】同様に、ユーザ１のコンピュータとは別の場所に、ローカルネットワークを用
いた他のコンピュータが２６４に示されている。２６４におけるコンピュータは
、サーバ２を介してインターネットに接続される。ユーザ３およびサーバ３はさ
らに第３の設備を示す。

【００５７】２．本発明の概要図３Ａは、ランタイム時にコンパイルプログラムに機能を付加するアプローチ
全体における基本的工程を示すフローチャート１００を示す。

【００５８】このシステムは、４つの段階を有するとみなすことができる。第１の段階はプ
ログラム変換段階であり、この段階では、既存のプログラム（例えば、アプリケ
ーションプログラム等）を変換して初期実行可能オブジェクトに組み込む。第２
の段階は初期実行段階であり、この段階では、初期実行可能オブジェクトをエン
ドユーザのコンピュータに転送し、そのオブジェクトをエンドユーザのコンピュ
ータで実行する。この段階では、プログラムは既に変換されているものの、プロ
グラムには改変された機能は未だ供給されていない点に留意されたい。すなわち
、この段階では、プログラムは未だオリジナルのソースコードによって規定され
たオリジナルの目的通りに実行する。第３の段階はアドオン開発段階であり、こ
の段階において、ソースコード中のアイテムを改変し、プログラムの初期構造か
らの情報を用いて新規モジュールを構築する。第４の段階はアドオン実行段階で
あり、この段階において、新規モジュールを、エンドユーザ機器に転送し、初期
実行可能オブジェクトに「フック」し、そして実行する。第４の段階において、
オリジナルの実行可能オブジェクトが新規モジュール中の機能にアクセスする様
式を制御することにより、スタートアップおよびランタイムの両方のダイナミッ
クな改変が達成される。

【００５９】図３Ａにおいて、サブ工程３０４は、プログラム変換段階において、オリジナ
ルのアプリケーションプログラムを作成および実行する第１の段階を構成する。
プログラマが標準的な方法でプログラム（例えば、アプリケーションプログラム
等）を作成するサブ工程３０２が行われており、これによりシンボルリファレン
スのリダイレクトを提供できるように変換可能なプログラムが存在すると仮定す
る。好適な実施形態は既存のプログラムを変換するように設計されるが、プログ
ラムは、本発明のリダイレクトメカニズムのプログラムへの提供と同時に作成可
能である点に留意されたい。サブ工程３０４において、サブ工程３０２において
作成されたソースコードを本発明のソフトウェアルーチンによって処理し、ラン
タイムにおいて１つ以上のシンボルリファレンスのリダイレクトを提供する。図
３Ａ中にサブ工程３０４として示すプロセスにおいて、補助ファイルを生成し、
これにより、その後のアドオン開発段階においてプログラムのランタイム動作を
改変するための新規モジュールの作成、コンパイルおよびリンク接続を支援する
。

【００６０】次いで、サブ工程３０６を行う。このサブ工程３０６では、サブ工程３０４の
結果生成されたプログラムをロードし、実行する。サブ工程３０６は本発明の初
期実行段階を示し、プログラムが自身のシンボルリファレンスを効率的にリダイ
レクトする手段を備える場合、初期プログラムを実行する。サブ工程３０６にお
いてロードされ、実行されるプログラムの動作は、サブ工程３０２において開発
されたソースコード仕様から作成された従来のプログラムの動作と同一である。
以下により詳細に説明するように、ランタイムにおいて本発明の様式でシンボル
リファレンスをリダイレクトすると、実行プログラムのサイズが少し増加し、実
行プログラムの実行時間も少し増加し得る。しかし、これらの増加は、ほとんど
の場合に無視できるほどのごくわずかなものである。また、これらの増加は、ラ
ンタイムの機能を完全に改変することができるコンパイルプログラムを有する利
点とのトレードオフである。

【００６１】図３Ａに戻って、本発明の第３の段階すなわちアドオン開発段階は、サブ工程
３０８、３０９および３１０を含む。

【００６２】サブ工程３０８において、プログラマは、サブ工程３０２において作成された
オリジナルのプログラムコードまたはデータの一部を改変する。以下に示すよう
に、本発明の利点は、サブ工程３０２を行うプログラマと異なるプログラマが、
サブ工程３０８を容易に行うことができる点である。オリジナルのプログラムを
改変するプログラマまたは他の人物は、従来のアプローチの場合に必要とされる
ようなオリジナルのプログラムについての設計、構造およびインプリメンテーシ
ョンについての深い知識を持っていなくてもよい。本発明の主要な利点は、デー
タ構造（例えば、画像、音声および映像等）の変更が非常に簡単である点である
。これらのアドオン開発段階のサブ工程は非常に簡単であるため、プログラムミ
ングの知識は不要であり、設計者または他の人物がこれらのサブ工程を達成する
ことができる。好適な実施形態ではプログラマによるオリジナルコードの改変を
想定しているが、アドオンコードをスクラッチから新規に開発することも可能で
ある。しかし、オリジナルのコードの作業部分から開始する方がより効率の良い
アプローチである場合が多い。サブ工程３０８において、既存のコードまたはデ
ータ構造を改変し、新規コードまたはデータ構造を導入し、既存のコードまたは
データ構造をディセーブルすること等ができる。

【００６３】サブ工程３０８に示すような改変を行った後、サブ工程３１０を行う。サブ工
程３１０では、サブ工程３０４において生成された補助ファイルを用いて改変を
コンパイルする。サブ工程３０９はオプションのサブ工程であり、サブ工程３０
９において、プログラマもしくは別の人物またはプロセスが、シンボルリファレ
ンスをリダイレクトする様式を規定する。通常は、アイテムの置換を簡単にする
ために、サブ工程３０９は、コンパイル中に呼び出されるルーチンによって自動
的に行われる。しかし、シンボルリダイレクトの発生様式への制御をより良好に
するために、プログラマは、スクリプト言語を生成および改変することによって
命令を手入力で提供し得る。この点について、以下のセクション５においてより
詳細に説明する。

【００６４】サブ工程３１０では、改変をコンパイルするだけでよく、この点において、プ
ログラムのコンパイルバージョンを作成する場合に、使用されるモジュール全て
における全規定、リファレンスおよび他の構造を必要とする従来技術のほとんど
のアプローチと異なる。本発明のサブ工程３１０は、リンク接続に必要な（通常
は非常に多くの）シンボルリファレンスのいずれかを解明するよう機能する補助
ファイルを用いることにより、コード、データ等のごく一部をコンパイルするこ
とを可能にする。

【００６５】サブ工程３１２は、プログラムのアドオン実行の第４の段階である。この段階
では、ランタイムプログラムへの改変は、実行可能な命令、データ、リソース等
を含む改変された「新規モジュール」の形態であり、このランタイムプログラム
への改変は初期プログラムとして同じコンピュータにロードされていると仮定す
る。ローディングを同じコンピュータに行うと、実行速度が高速化することが確
実になる。しかし、プログラムの一部、データ、プロセスまたは他のアイテムを
ネットワーク中の異なる機器に配置および実行することができる。例えば、初期
実行可能オブジェクトがユーザ２の機器に常駐する新規モジュールにアクセスす
る間に、その初期実行可能オブジェクトはユーザ１のコンピュータ（図２Ｃ）上
で動作可能である。

【００６６】スタートアップ時またはランタイム間のいずれかにおいて、オリジナルのプロ
グラムのシンボルリファレンスを改変して、新規モジュールによって提供される
新規アイテムを「指示（ｐｏｉｎｔ）」させる。シンボルリファレンスのリダイ
レクトは、プログラムコードを実行する前のスタートアップ時に１回だけ行うか
、または、スクリプト命令を同時実行するメカニズム等のメカニズムを用いてプ
ログラムコードを実行するときにダイナミックに何回も行うことができ、これに
ついて以下のセクション５において説明する。

【００６７】したがって、図３Ａは、本発明の方法の広範な基本的工程およびサブ工程を示
す。本発明の局面は、コンピュータプログラムの開発の間および実行の間のどち
らにでも発生する点に留意されたい。すなわち、サブ工程３０２、３０４、３０
８、３０９および３１０は一般的には、コンピュータプログラムの開発と関連す
る。サブ工程３０６および３１２は一般的には、例えば市販のプログラムの購入
者またはライセンスを受けたコンピュータプログラムの「エンドユーザ」による
コンピュータプログラムの実行または末端使用と関連する。

【００６８】本発明は、コンピュータプログラムの開発および使用の様々な局面において利
点を提供する。コンピュータプログラムの開発者にとって、本発明は、オリジナ
ルのプログラマが、本発明を取り入れるために自身のプログラミングツール、環
境、方法論等を変更する必要なく、コンピュータプログラムを従来通りに開発す
ることを可能にする。実際、任意のコンパイルされたコンピュータプログラムは
本発明の利点の影響を受け易い。本発明は、既存のプログラムを改良してランタ
イムの改変が可能となった場合、コンピュータプログラムの既存のソースコード
が利用可能な状態（ｏｎ−ｈａｎｄ）であることさえも必要としない。本発明の
プロセスのいくつかの関数は、オブジェクトコードモジュールおよびコンパイラ
により生成されたファイル（例えば、シンボルテーブル）において行われるため
、オリジナルのソースコードを利用可能な状態にする必要はない。したがって、
例えば、ソースコードが利用不可能である場合、広範囲のリバースエンジニアリ
ングを行わずにデータ構造をプログラムにフックすることができる。

【００６９】本発明の技術は、あらゆるコンピュータ言語、開発環境、プログラムの種類等
に適応可能である。サブ工程３０４は、オリジナルのプログラマ以外の人物によ
っても行うことができ、オリジナルのプログラムの詳細な知識が無くても行うこ
とができる。実際、サブ工程３０２、３０４および３０８〜３１０は、互いに影
響を受けることなく、かつ他のサブ工程のいずれかを行うために必要な詳細な知
識を実質的に必要とすることなく行うことができる。

【００７０】本発明の利点は、エンドユーザが本発明により提供される利点を達成する際に
何らかの特殊な工程を行うことを必要としない点である。サブ工程３０６では、
サブ工程３０４において生成された提供物（ｐｒｏｖｉｓｉｏｎ）に関係なく、
任意のプログラムと同様にプログラムをロードし、実行する。サブ工程３１２に
おいて、シンボルリファレンスのリダイレクトは全て、実行プログラムの一部ま
たは実行プログラムに従属するプログラムであるコードによって自動的に実行さ
れ、オペレーティングシステムによって開始され得、または、これは、エンドユ
ーザの介入を有するかあるいは有さない他の手段によって行われ得る。

【００７１】表Ｉは、ソースコードモジュールおよびそのコンテンツの例である。表Ｉは、
サブ工程３０２（すなわち、プログラム作成動作）においてプログラマが書き得
る具体例を大幅に簡略化した例である。

【００７２】

【表１】プログラムは典型的には多くのモジュールから構成される。モジュールは実質
的には、人間が読むことのできる形式のプログラムコードまたはデータを含む別
個のファイルに過ぎない。ファイルを別個にすると、プログラムの一部をワード
プロセッサにロードする点およびプログラムの一部を操作する点に関して、プロ
グラムの動作が容易になる。また、各モジュールは、関連の関数を実行するコー
ドの一部を論理的に含む。各モジュールは典型的には、そのモジュール内に内蔵
される関数、処理、データ等の種類を示す名称を有する。

【００７３】表Ｉにおいて、モジュール「Ｅｘａｍｐｌｅ」は、１１行のソースコードを含
む。このコードはＣコンピュータ言語で書かれており、非常に単純な形式ではあ
るが、このアプリケーションにおいて以下に説明するような使用可能なオブジェ
クトモジュールを実際にコンパイルおよび生成する。

【００７４】当業者には明らかなように、このＥｘａｍｐｌｅのモジュール中のコードは、
「シンボル」を用いることにより、コード構造およびデータ構造をリファレンス
する。シンボルは、プログラマが作業を行う際に論理的かつ容易に記憶可能な環
境を提供するよう選択される、英数字の名称に過ぎない。

【００７５】例えば、表Ｉにおいて、モジュールＥｘａｍｐｌｅは、以下のシンボルに対す
るリファレンスを含む：「ｆｕｎｃｔ＿Ｂ、」「ｓｔｒｉｎｇ＿ｐｔｒ、」「ｆ
ｕｎｃｔ＿Ａ」および「ｐｒｉｎｔｆ」。各リファレンス対象シンボルは、プロ
グラムを構成するモジュールの１つにおいて「規定」されなければならない。例
えば、シンボル「ｆｕｎｃｔ＿Ａ」は、シンボル「ｆｕｎｃｔ＿Ａ」をリファレ
ンスする同じモジュール（すなわち、Ｅｘａｍｐｌｅモジュール）において規定
される。

【００７６】それとは対照的に、シンボル「ｆｕｎｃｔ＿Ｂ」は、別のモジュール（すなわ
ち、モジュールＥｘａｍｐｌｅ２）において規定される。このＥｘａｍｐｌｅに
おいて、シンボル「ｆｕｎｃｔ＿Ａ」および「ｆｕｎｃｔ＿Ｂ」は、この場合は
何らかのアクションを全く行わない関数またはサブルーチンである。「ｆｕｎｃ
ｔｉｏｎ＿Ａ」および「ｆｕｎｃｔ＿Ｂ」に対するリファレンスを、モジュール
Ｅｘａｍｐｌｅの５行目および６行目にそれぞれ示す。

【００７７】シンボル「ｓｔｒｉｎｇ＿ｐｔｒ」は、モジュールデータにおいて規定される
。

【００７８】シンボル「ｐｒｉｎｔｆ」は、表Ｉに示すモジュールのいずれにおいても規定
されず、その代わり、このシンボルは、Ｃコンピュータ言語のインプリメンテー
ション全てを備える標準的ライブラリにおいて規定される関数である。通常は、
シンボルをリファレンスするモジュールの外部に規定を有するシンボルは、モジ
ュールの開始部分において「外部」シンボルとして宣言される。これは、モジュ
ールＥｘａｍｐｌｅの最初の２行にそれぞれ示すシンボル「ｆｕｎｃ＿Ｂ」およ
び「ｓｔｒｉｎｇ＿ｐｔｒ」にも当てはまる。シンボル「ｐｒｉｎｔｆ」は、Ｃ
コンピュータ言語に対して暗黙であり、Ｃ「ライブラリ」によって指定されてい
るため、外部シンボルとして宣言されない。

【００７９】モジュールＥｘａｍｐｌｅ、Ｄａｔａ、Ｅｘａｍｐｌｅ２、の各々がコンパイ
ルされて、対応するオブジェクトファイルが生成される。例えば、モジュールＥ
ｘａｍｐｌｅは、通常、「Ｅｘａｍｐｌｅ．ｃ」または「Ｅｘａｍｐｌｅ．ｃｃ
ｐ」の名前を有し、これらは、「Ｅｘａｍｐｌｅ．ｏｂｊ．」の名前を有するオ
ブジェクトモジュールにコンパイルされる。これらのモジュールは、「．ｌｉｂ
」拡張子を有するライブラリファイルと共に、リンカーを介してリンクされて、
ファイル名に「．ｅｘｅ」拡張子を有する実行可能オブジェクトまたは実行可能
イメージとしばしば呼ばれる単一の「実行可能な」ファイルを生成する。

【００８０】図３Ｂは、上の表Ｉに示したソースコードに対応する実行可能オブジェクトの
「メモリマップ」の図を示す。図３Ｂは、従来の技術を用いて達成される、結果
として得られる実行可能オブジェクトの典型例であることに留意されたい。実行
可能オブジェクトおよびランタイムイメージを扱う本発明の局面の概観を提供す
るために、従来技術のメモリマップと並べて、本発明を用いて得られるメモリマ
ップを図３Ｃに示す。本発明を用いて得られるメモリマップは、後で説明する。

【００８１】図３Ｂは、表Ｉのオリジナルプログラムの４個の異なるコンポーネントまたは
モジュールならびにさらなるスタートアップセクションに対応する５つの独立し
た領域を有する、実行可能オブジェクトを示す。

【００８２】図３Ｂにおいて、実行可能オブジェクト３２０は、スタートアップセクション
３２２、Ｅｘａｍｐｌｅモジュールに対応するセクション３２４、Ｅｘａｍｐｌ
ｅ２モジュールに対応するセクション３２６、Ｄａｔａモジュールに対応するセ
クション３２８、およびライブラリルーチンに対応するセクション３３０を含む
。スタートアップセクション３２２については、ランタイムイメージ実行を参照
しつつ、後でより詳細に説明する。Ｅｘａｍｐｌｅモジュールに対応するセクシ
ョン３２４は、Ｗ０、Ｗ１、Ｗ２等で示すワードの例（通常、それぞれ１６ビッ
ト、３２ビット、または６４ビット）を含む。概して、コンピュータプログラム
内には、数千、数万、あるいは数百万以上のワードが含まれる。コンピュータプ
ログラムはまた、コンピュータプログラムのサイズに応じて、数十または数百の
モジュールを含み得る。

【００８３】図３Ｂはまた、「ＷＮ１」、「ＷＮ２」等のワードの例を示す。これらのワー
ドは、シンボル参照を実行するコンピュータマシン命令に対応する。そのような
ワードの例は、データ構造、命令の呼び出し（ｉｎｖｏｃａｔｉｏｎ）、サブル
ーチンへのジャンプまたはサブルーチンの呼び出し、トラップまたは例外、ある
いは任意の他の参照、フロー制御、または命令またはデータアイテムの使用に対
して、可変な名前または参照を使用することであり得る。

【００８４】例えば、ワードＷＮ１は、表Ｉに示すシンボル「ｆｕｎｃｔ＿Ａ」への参照を
示し得る。シンボル「ｆｕｎｃｔ＿Ａ」についての規定はＷＮ１と同じモジュー
ル内に存在するので、ＷＮ１〜ＷＮ５による参照は、Ｅｘａｍｐｌｅモジュール
に対応する同じセクション３２４内の別のロケーションへの矢印によって示され
る。同様に、ワードＷＮ２は、シンボル「ｆｕｎｃｔ＿Ｂ」に対応する規定に対
する参照に対応する。「ｆｕｎｃｔ＿Ｂ」についての規定はモジュールＥｘａｍ
ｐｌｅ２内に存在するので、図３Ｂは、ＷＮ２〜ＷＮ６までの参照を示す。ここ
で、ＷＮ６は、モジュールＥｘａｍｐｌｅ２に対応するセクション３２６内に存
在する。

【００８５】同様の様態で、ＷＮ３は、セクション３３０内にＷＮ８として示す、シンボル
名「ｐｒｉｎｔｆ」を有するライブラリ関数のアクセスまたは参照を示す。ＷＮ
４は、Ｄａｔａモジュールに対応する、セクション１２８内のＷＮ７において開
始される、規定された「ｓｔｒｉｎｇ＿ｐｔｒ」への参照を実行する。

【００８６】通常、このような参照は、アドレス、あるいは命令またはデータアイテムのロ
ケーションを識別する他の手段を用いる。アイテムへの参照を達成する任意の手
段が、本発明と共に使用するのに適している。

【００８７】図３Ｄは、図３Ｂの実行可能オブジェクト３２０に対応するランタイムイメー
ジ３４０を示す。

【００８８】図３Ｃにおいて、ランタイムイメージ１４０は、図３Ｂの実行可能オブジェク
ト１２０と同じセクションを含む。ランタイム時において、実行可能オブジェク
ト３２０はメモリ内にロードされ、固定されたアドレスが、実行プログラムによ
って使用され得る命令、データ、ならびに他のオブジェクトまたはアイテムに割
り当てられる。従来技術のデバイスの処理は、ダイナミックリンクライブラリ（
ｄｙｎａｍｉｃａｌｌｙｌｉｎｋｅｄｌｉｂｒａｒｙ）（ＤＬＬ）３４２と
呼ばれることに留意されたい。スタートアップ時に、スタートアップセクション
３４４におけるスタートアップコードが、実際のプログラムにおける命令の実行
に先立って呼び出される。セクション３４４におけるスタートアップコードは、
ＤＬＬ３４２をロードし、ＤＬＬ３４２内のアイテムへの参照を解消することに
よって「ダイナミックにリンクする」ことを確立し得る。

【００８９】例えば、図３Ｃにおいて、セクション３４８は、ＤＬＬ３４２のローディング
、ロードされた情報のランタイムイメージ３４０との関連づけに対応する。ラン
タイムイメージ３４０内において、マシンワードＷＮ８は、ロードされたＤＬＬ
のセクション３４８内のＷＮ９において開始されるオブジェクトを参照する命令
である。例えば、ＷＮ８は、ＤＬＬ３４２によって提供された関数への参照であ
り得る。それは参照されたアイテムが存在するＤＬＬ３４２のローディングより
も前に知られていないので、ＷＮ９への参照は、ＤＬＬ３４２のローディングが
完了するまで確立され得ない。従来技術におけるＤＬＬの使用は、オリジナルプ
ログラムのプログラマーが、参照されている関数が、ランタイム時にロードされ
るＤＬＬ内に存在することを明確に宣言（ｄｅｃｌａｒｅ）することを要求する
。さらに、関数は、通常、所与のＤＬＬ内に存在する多くの関数のうちの１つで
ある。ＤＬＬに関する関数の集合体全体が、ランタイム時にロードされる。プロ
グラムのコード内の、ＤＬＬ内のアイテムへの参照を解消することは、「暗黙の
」リンクを用いることにより、スタートアップ時またはランタイムの間に実行さ
れ得る。

【００９０】従来技術の図３Ｂおよび図３Ｄについて上で説明したが、図３Ｃおよび図３Ｅ
を以下に提示して、本発明の実行可能オブジェクトおよびランタイムイメージ構
成がどのように異なるかを示す。

【００９１】図３Ｃは、本発明の実行可能オブジェクト３６０を示す。実行可能オブジェク
ト３６０は、表Ｉのソースコードによって説明したのと同じモジュールおよび関
数を実行する。参照の各々が実行可能オブジェクト３６０のメモリマップの下部
に示した表３６２を介することを除いては、従来技術の例における図３Ｂの実行
可能オブジェクト３２０においてと同様に、同じワードまたはアイテムの間の同
じ参照が、図３Ｃの実行可能オブジェクト３６０内に存在することに留意された
い。例えば、ＷＮ１は、従来技術の図３ＢにおいてＷＮ５を直接参照するが、こ
こでは、表３６２内のエントリＶＦ１を参照する。表３６２内のエントリＶＦ１
は、次はＷＮ５を参照する。この、実行可能オブジェクト３６０内の、シンボル
の「間接的な」または「一般化された」参照は、プログラム変換段階（Ｐｒｏｇ
ｒａｍＣｏｎｖｅｒｓｉｏｎＰｈａｓｅ）内のプログラムを構築するために
使用される本発明のツールおよびユーティリティによって自動的に形成される。
プログラム変換段階および他の段階については、好適な実施形態の詳細な説明の
セクションにおいて後で説明する。

【００９２】図３Ｅは、本発明のランタイムイメージ３８０を示す。図３Ｂと図３Ｃとの間
の対応が、本発明と従来技術との差を示すのと同様に、同じセクションを用いた
点で図３Ｅは図３Ｄに対応する。しかし、参照は表３６２を介しているので、シ
ンボル参照（ｓｙｍｂｏｌｉｃｒｅｆｅｒｅｎｃｅ）を所望のように恣意的に
変更して、ランタイム時に、コンパイルされたコードの関数を変更することが可
能である。

【００９３】例えば、（表ＩのモジュールＥｘａｍｐｌｅにおけるシンボルｓｔｒｉｎｇ＿
ｐｔｒへの参照に対応する）ＷＮ４からの参照は、本来はＶＦ３からＷＮ７にわ
たるものであったが、図３Ｅにおいては、ＶＦ３を介してＷＮ９へ参照するよう
に示す。同様に、ＷＮ３からＶＦ４を介したＷＮ８への参照は、代わりの参照Ｗ
Ｎ７に修正されている。ＷＮ９で開始するオブジェクトは、ランタイム時におい
て追加され、表３６２を介したシンボル参照にリンクされたプログラムコード、
データ等であり得ることに留意されたい。図３Ｅの新たなモジュール３６４は、
最初のプログラムコードにおいて新たなモジュール３６４が参照されている必要
がない点で、図３ＣのＤＬＬ３４２とは異なる様態で振る舞う。言い換えると、
新たなモジュール３６４は、表Ｉに示すソースコード内に規定または宣言されて
いない「ｎｅｗ＿ｆｕｎｃｔ」等のシンボルを有し得る。

【００９４】あるいは、ワードＷＮ９で始まるオブジェクトは、本来ＷＮ７において開始す
るように規定されたｓｔｒｉｎｇ＿ｐｔｒ等の、修正、置換、または変更された
バージョンのオリジナルオブジェクトであり得る。この様態で、新たなオブジェ
クトが、オリジナルプログラム内のオリジナルオブジェクトと同じ名前で、置換
され得る。「ヌル（ｎｕｌｌ）」関数を既存の関数と置換することにより、その
関数は効果的に除去され得る。例えば、ビットマップイメージにおける全てのデ
ータバイトを除去することにより、そのイメージは、効果的にオリジナルプログ
ラムから消去され得る。異なるイメージを置換し、オリジナルプログラム内の名
前と同じシンボル名を用いることにより、そのオリジナルイメージは、効果的に
置換される。新たなシンボルを、新たなモジュールからロードされた、新たに規
定されたオブジェクトについてのテーブルエントリとして提供することにより、
コンパイルされたプログラムのランタイムイメージにアイテムが追加され得る。

【００９５】以下に説明するように、新たなモジュール３６４は、修正された関数を提供す
るのに非常に適している。ＤＬＬとは異なり、新たなモジュール３６４は、オリ
ジナルプログラムモジュールならびに後で説明する適切な補助ファイルが利用可
能である場合の環境についての詳細な知識無しで、コンパイルされ、リンクされ
得る。したがって、本発明のシステムで、コンパイルされたプログラムの関数を
変更することは、特にプログラマー、デザイナー、またはオリジナルプログラム
の詳細の全てに精通しているわけではない他の人にとって、かなり簡単である。
プログラムを修正するために、ランタイムイメージが既にローディングされてい
るかもしれないＤＬＬを処理することに関する知識および準備は必要でない。こ
の様態で生成された新たなモジュールは、類似のＤＬＬアプローチよりも大幅に
小さくなり得る。

【００９６】本発明の特徴は、ランタイムイメージ３８０を実行している間に、参照の変更
を可能にする。つまり、本発明の一実施形態は、いつシンボル参照がリダイレク
トされる（ｒｅｄｉｒｅｃｔ）かを特定する、解釈された制御言語を提供する。
そこで、例えば、ランタイムイメージ３８０の実行中における任意の時点におい
て、ＷＮ１からＶＦ５を介してＷＮ５への参照を、代わりにＷＮ８を参照するよ
うに切り換え得る。そのような参照スイッチングは、（１）特定された時間間隔
の後、（２）特定の命令が実行される時、（３）割り込み（ｉｎｔｅｒｒｕｐｔ
）が受け取られる時、または（４）所定のユーザ入力信号が検出される時等の、
異なる基準に基づいて実行され得る。他の基準も可能である。コンピュータプロ
グラムまたは検出された信号の任意の条件または状態が、基準となり得る。

【００９７】プログラム内の全てのシンボルは、別のアイテム（例えば、命令、データ、リ
ソース等）にリダイレクトする、または「フック」しておくことが可能であるの
で、オリジナルプログラムは、その内部でさらなるプログラムの展開（ｄｅｖｅ
ｌｏｐｍｅｎｔ）が起こり得る、単なるフレームワークとみなし得る。何処でど
のようにサブルーチンまたはデータ構造が使用されるか等、プログラムの広い上
位の設計（ｔｏｐ−ｌｅｖｅｌｄｅｓｉｇｎ）のみが明らかになればよい。例
えば、コンピュータゲームプログラムにおいて、背景シーン内に広告イメージを
表示するデータ構造は、新たなイメージを含む新たなモジュールの１回のダウン
ロードによって更新され得る。新たな「アドオン」モジュールを構成するために
は、プログラムにおいて元々使用されたデータ構造のシンボル名を知ることが要
求されるだけである。既存のランタイムプログラム内に新たなイメージ（つまり
、アドオンモジュール）をフックするためにシステムによって提示されたオーバ
ーヘッドは無視できるので、「アドオン」モジュールサイズは、新たなイメージ
と実質的に同じサイズである。

【００９８】既存のプログラムにおける任意のサブルーチンまたは関数は、新たなモジュー
ルサブルーチンまたは関数でフックされて、オリジナルのサブルーチンまたは関
数と置換され得る。この様態で、従来はパッチによって達成されたバグ訂正（ｂ
ｕｇｆｉｘ）が、いっそう簡単に設計され、自動的且つ迅速に組み込まれる。
つまり、新たなサブルーチンを実行するために、ユーザの介入が必要でなく、且
つ、スタートアップ時に認知可能な遅延がない。ベースプログラムが同じであっ
ても、異なるユーザがそれぞれのマシン上で異なる関数を有するプログラムを実
行できるように、カスタマイズされたプログラムが可能である。例えば、音楽シ
ーケンシングプログラム（ｍｕｓｉｃｓｅｑｕｅｎｃｉｎｇｐｒｏｇｒａｍ
）において、垂直タイムライン関数を有する新たなモジュールをダウンロードす
ることを選択したユーザについてのみ、水平タイムラインを表示するサブルーチ
ンを、垂直の様態にタイムラインを合わせる新たなモジュールと置換することが
できる。第三者のアドオン（ａｄｄ−ｏｎ）は簡単な事項となり、ソフトウェア
の正規製造者とは異なる会社が関数を修正して、改良された、または単に異なる
だけの、ソフトウェア製品を提供することができる。

【００９９】本明細書中、プログラム内の全てのシンボルをリダイレクトするものとして本
発明を説明するが、リダイレクトされるシンボルの数は自由に選択される。ある
プログラムについて、本発明の利点の多くが、シンボルのサブセットのみをリダ
イレクトすることにより達成され得る。しかし、プログラムを変換して全シンボ
ルのリダイレクトを提供することの利点は、任意の予測されないシンボルを、後
からリダイレクトすることができる点にある。

【０１００】３．オリジナルプログラムの変換本発明の好適な実施形態は、ＳｅｇａＳｏｆｔＣｏｒｐｏｒａｔｉｏｎによ
って開発された「ＤｙｎａＰｌａｙ^TM」と呼ばれるシステムである。ＤｙｎａＰ
ｌａｙシステムは、後で説明する「ｄｙｎａｏｂｊ」、「ｄｙｎａｍａｐ」、お
よび「ｄｙｎａｇｅｎ」等の実行可能ルーチンを含む、ＳｏｆｔｗａｒｅＤｅ
ｖｅｌｏｐｅｒ’ｓＴｏｏｌｋｉｔ（ＳＤＫ）を提供する。これらのルーチン
についてのソースコードは、これらのルーチンの動作ならびにそれらの正確な入
力要件および出力フォーマットについての完全な詳細について顧慮されるべき添
付されたソースコードＡｐｐｅｎｄｉｘ内に含まれる。本明細書中に説明するス
テップを自動化するバッチ制御ファイルも、Ａｐｐｅｎｄｉｘ内に含まれる。詳
細には、「ｄｙｎａｍｉｚｅ．ｂａｔ」ファイルが「ｄｙｎａｂａｔ．ｂａｔ」
を呼び出して、本発明のＰｒｏｇｒａｍＣｏｎｖｅｒｓｉｏｎＰｈａｓｅ内
のステップを自動的に実行する。「ｄｙｎａｍｏｄ．ｂａｔ」が「ｄｙｎａｂａ
ｔ２．ｂａｔ」を呼び出して、本発明のＡｄｄ−ＯｎＤｅｖｅｌｏｐｍｅｎｔ
Ｐｈａｓｅ内のステップを実行する。

【０１０１】ＳＤＫによって提供されるＤｙｎａＰｌａｙツールにおいて、プログラムを変
換して、プログラム内のシンボル参照をリダイレクトすることを提供するプロセ
ス（すなわち、図３Ａのサブステップ３０４を実行すること）を、プログラムを
「ダイナマイズする（ｄｙｎａｍｉｚｉｎｇ）」と呼ぶ。サブステップ３０４を
実行した後、プログラムは、ランタイム時にそのシンボル参照を容易にリダイレ
クトし得るという点で、「ダイナマイズ」されていると言える。

【０１０２】Ａｄｄ−ＯｎＤｅｖｅｌｏｐｍｅｎｔＰｈａｓｅプロセスの一部として形
成された新たなモジュールを、「ダイナモジュール」と呼ぶ。ダイナモジュール
は、図３Ａのステップ３０８および３１０を実行した結果である。

【０１０３】図４は、本発明のシステムのＰｒｏｇｒａｍＣｏｎｖｅｒｓｉｏｎＰｈａ
ｓｅを示す。

【０１０４】図４において、「Ｈａｎｇｍａｎ３２．ｃｐｐ」と呼ばれるプログラムの例示
的な変換を示す。ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎから市販されて
いるＭｉｃｒｏｓｏｆｔＤｅｖｅｌｏｐｅｒ’ｓＥｎｖｉｒｏｎｍｅｎｔ
ｖｅｒｓｉｏｎ４．７で開発されたＨａｎｇｍａｎ３２．ｃｐｐはＣ＋＋言語
プログラムである。当然、本発明は、任意のコンピュータ言語、開発者環境（ｄ
ｅｖｅｌｏｐｅｒ’ｓｅｎｖｉｒｏｎｍｅｎｔ）、または動作システムに適用
可能である。この変換プロセスは、プログラムを「ダイナマイズする」と呼ばれ
る。Ｈａｎｇｍａｎ３２．ｃｐｐプログラムをダイナマイズした後、ダイナマイ
ズされた実行可能オブジェクトは、「Ｈａｎｇｍａｎ３２．ｅｘｅ」として製造
される。ダイナマイズされた実行可能オブジェクト（ｅｘｅｃｕｔａｂｌｅ）は
、ランタイム時にシンボルへのフッキングを提供することが存在する点を除いて
、ダイナマイズされていない実行可能オブジェクトとほぼ同じである。つまり、
プロセス、サブルーチン、関数、データ構造、およびリソース等のアイテムへの
シンボル参照を、ランタイム時にリダイレクトすることができる。ダイナマイズ
プロセスはまた、「Ｈａｎｇｍａｎ３２．ｖｆｓ」および「Ｄｙｎａｐｌａｙ．
ｌｉｂ」というファイルを生成する。これらのファイルはそれぞれ、ダイナマイ
ズされたプログラムを実行するため、ならびに、新たなアドオンモジュールまた
は「ダイナモジュール」を構築するために使用される。

【０１０５】図４は、フローチャート４００を示す。図４において、ファイルを四角の中に
示し、プロセスを楕円の中に示す。ステップ４０２におけるファイルＨａｎｇｍ
ａｎ３２．ｃｐｐは、コンパイラ４０４によって処理されるソースコードファイ
ルである。コンパイラ４０４は、標準コンパイラであり得る。好適な実施形態に
おいて、コンパイラは、シンボル名を出力（．ｏｂｊ）ファイル内に挿入するこ
とに向けられている。これらのシンボル名は、以下に説明するように、後で置換
される。コンパイルプロセス（ｃｏｍｐｉｌａｔｉｏｎｐｒｏｃｅｓｓ）の結
果は、ステップ４０６における「Ｈａｎｇｍａｎ３２．ｏｂｊ」というオブジェ
クトファイルである。本実施例は１つのモジュールおよびそれから得られる１つ
のオブジェクトファイルを用いるが、任意の数のモジュール、オブジェクトファ
イル、ライブラリ等が使用され得る。オブジェクトファイルは、任意の標準リン
カであり得るリンカ４１０に提出される。リンカは、全てのシンボルおよびそれ
らのシンボルを規定しかつ用いるモジュールのリストが、ステップ４１６におけ
るＨａｎｇｍａｎ３２．ｍａｐファイル等のファイル内に生成されるように、．
ｍａｐファイルを生成するように向けられる必要がある。

【０１０６】マップファイルは、Ｄｙｎａｍａｐ．ｅｘｅ４２０への入力として用いられる
。Ｄｙｎａｍａｐ．ｅｘｅは、．ｍａｐファイル中のエントリを処理することに
より、４２２において、各シンボルが「エクスポート」された．ｄｅｆファイル
を作成する。Ｈａｎｇｍａｎ３２．ｃｐｐ中の典型的なダイナマイズされる（ｄ
ｙｎａｍｉｚｅｄ）関数は、「ＯｎＧａｍｅＮｅｗ（）」関数である。この関数
は、ユーザが新しいゲームを選択するときに呼び出される。このように、関数の
後の改変を可能にすることは、例えば、新しいパラメータを初期化するために有
用である。Ｈａｎｇｍａｎ３２．ｍａｐファイル中のＯｎＧａｍｅＮｅｗ（）の
エントリは、表ＩＩに示す通りである。

【０１０７】

【表２】ＤＹＮＡＭＡＰコマンドによって生成されるＤＥＦファイルにおいて、表ＩＩ
Ｉに示されるように同じシンボルがＥＸＰＯＲＴＳセクションに現れる。表ＩＶ
は、．ｄｅｆファイル中のエントリのより大きな（それでも部分であるが）リス
トを示す。完全なリストは、数百個のエントリを含む。

【０１０８】

【表３】

【０１０９】

【表４】

【０１１０】

【表５】

【０１１１】

【表６】

【０１１２】

【表７】．ｄｅｆファイルは、エクスポートされる各シンボルを指定することにより、
プログラムプロジェクト中のいかなるモジュールに対してもこれらのシンボルが
外的に定義されているとシンボルへのリファレンスを扱うプロセスが仮定するこ
とを可能にすることによって、リダイレクトを受けるシンボルのさらなる構築を
セットアップしている。シンボルは、その強制された「エクスポート」指定とと
もに、構築物に用いられている他の標準的なファイルに伝播する。例えば、．ｄ
ｅｆファイルは、標準的なライブラリマネージャであるライブラリマネージャ４
２４に供給される。ライブラリマネージャは、アドオンダイナモジュールが作成
されるアドオン開発（Ａｄｄ−ＯｎＤｅｖｅｌｏｐｍｅｎｔ）フェーズ（後述
）で後に用いられる補助的ファイルである、ＤｙｎａＰｌａｙ．ｌｉｂファイル
を生成するように指示される。ライブラリマネージャはまた、プログラムプロジ
ェクトのオブジェクトモジュールの第２のリンキングに用いられるＤｙｎａｐｌ
ａｙ．ｅｘｐファイルを、４２８において生成する。

【０１１３】オブジェクトモジュールの第２のリンキングは、置換されたシンボル名を有す
るプログラムを作成するために用いられる。これが最初の本当のリンクである。
なぜなら、リンカ４１０による第１のリンキングは、．ｍａｐファイルを生成す
るためのみに用いられたからである。第２のリンキングの前に、Ｄｙｎａｏｂｊ
．ｅｘｅ４０８は、プログラムの．ｏｂｊファイル（この場合Ｈａｎｇｍａｎ３
２．ｏｂｊ）をＤｙｎａｏｂｊ．ｅｘｅへの入力として、実行される。これによ
り、．ｄｂｊ拡張子を有する「ダイナマイズ」されたオブジェクトファイルが得
られる。

【０１１４】各ダイナマイズされたオブジェクトファイルの定義は、オリジナルのシンボル
とは異なる改変シンボルを有する。すなわち、各オリジナルのシンボル定義の前
に「ｄｙｎａ＿」が付されることにより、例えば「ＯｎＧａｍｅＮｅｗ（）」の
定義は、Ｈａｎｇｍａｎ３２．ｄｂｊ内において「ｄｙｎａ＿ＯｎＧａｍｅＮｅ
ｗ（）」となる。．ｄｂｊファイルは、ランタイム時においてｄｙｎａｌｉｂ．
ｄｌｌライブラリからルーチンを呼び出すためのコードを挿入する、Ｄｙｎａｌ
ｉｂ．ｏｂｊとリンクされる。これらのルーチンは、プログラム実行以前および
プログラム実行中の両方において、シンボルのリファレンシングのリダイレクト
を決定する。ｄｙｎａｌｉｂ．ｄｌｌ内のルーチンは、セクション５において後
述される。

【０１１５】．ｄｂｊファイルはまた、４１４に示すようにＤｙｎａｏｂｊ．ｅｘｅによっ
て作成される構造であるＤｙｎａｔａｂ．ｏｂｊにリンクされる。Ｄｙｎａｔａ
ｂ．ｏｂｊは、間接的シンボルリファレンスを扱うためのテーブル構造を提供す
る。Ｄｙｎａｔａｂ．ｏｂｊは、リファレンスのシンボルとの関連付けに関する
バイナリ情報を含んでいる。これは．ｄｅｆファイルから作成される。このフォ
ーマットの詳細な説明に関しては、Ｄｙｎａｏｂｊ．ｅｘｅプログラムのソース
コードＡｐｐｅｎｄｉｘを参照されたい。Ｄｙｎａｔａｂ．ｏｂｊは、最初の（
オリジナルの）シンボルと、新しいリネームされた「プロキシ」シンボルリファ
レンスとの間の関連付けを定義する、テーブル構造である。例えば図３Ｃおよび
３Ｅにおいてこれはテーブル３６２であり、ここでＶＦ１は、マシン命令ＷＮ５
（オリジナルのシンボルのアドレス値）へのジャンプ命令のアドレス（すなわち
テーブルエントリまたは新しいシンボルのアドレス値）である。テーブルの正確
なフォーマットについては、Ａｐｐｅｎｄｉｘ中のＤｙｎａｏｂｊ．ｅｘｅのソ
ースコードを参照されたい。また、図３Ｃおよび３Ｅ中のメモリマップの下部に
テーブルを示しているが、テーブルは、システムＲＡＭ内のどこに位置していて
もよい。テーブルは、仮想メモリ、外部格納装置、ネットワークサーバ等上に位
置していてもよい。また、１つ以上のテーブルが存在してもよい。

【０１１６】好適な実施形態においてはシンボル定義が改変されるが、シンボル定義を同一
に保持しながらシンボルリファレンスを改変することにより、同じシンボルイン
ダイレクション効果を達成することが可能である。すなわち、接頭辞「ｄｙｎａ
＿」が、シンボル定義に対する各リファレンスに対して付加され得る。次に、テ
ーブルは、置換されたシンボルリファレンスを、オリジナルの名前を有する定義
と対応付ける。

【０１１７】間接シンボルリファレンシングを達成するための他のメカニズムが可能である
。例えば、テーブルに代えて、コードのうち変更されるべきシンボルリファレン
スを有する部分へのポインタのリストを用い得る。こうすれば、２つのアドレス
フェッチの必要がなくなる。例えば、図３Ｃにおいて、ＷＮ１におけるマシン命
令がＶＦ１にあるアドレスのフェッチを起こした後、ターゲット命令ＷＮ５のフ
ェッチが行われるという本アプローチは、ＷＮ５が実行され得る前に余分なアド
レスフェッチを起こしている。もし代わりに、ＷＮ１が直接ＷＮ５を指すことに
よりＷＮ５を直接得ることができれば、プログラムの実行はより速くなる。その
場合テーブル３６２がＷＮ１へのポインタを有することにより、ＷＮ１からＷＮ
５へのリファレンスがリダイレクトされる必要がある場合にはＷＮ１の値を改変
することにより実現可能である（これは、ＷＮ１が直接アドレスターゲット分岐
を含んでいることを前提としている）。しかしこのアプローチにおける欠点は、
ＷＮ５を元々アクセスするプログラム中の各位置に対して、ポインタが存在して
いなければならないことである。本アプローチでは、単一のテーブルエントリを
、任意のシンボルに対する以前のリファレンスの全てをリダイレクトするように
変更することのみを必要とする。

【０１１８】リンカ４１８は、全てのオリジナルのシンボルリファレンスを、Ｄｙｎａｐｌ
ａｙ．ｅｘｐ４２８中のオリジナルのシンボル名を用いて解決する。図４のリン
カ４１８によりおこなわれるリンク動作の結果は、Ｈａｎｇｍａｎ３２．ｅｘｅ
という実行可能物４２６である。この実行可能物は、図３Ｃのテーブル３６２な
どのデータ構造を介してシンボルリファレンスがリダイレクトされるようになっ
たという意味において、図３Ｃの構造と同様な構造を有している。

【０１１９】最後に、ｄｙｎａｇｅｎ．ｅｘｅ４３２が、実行可能なアプリケーションであ
るＨａｎｇｍａｎ３２．ｅｘｅ上で実行されることにより、Ｈａｎｇｍａｎ３２
．ｖｆｓが作成される。．ｖｆｓファイルは、「仮想ファイルシステム（ｖｉｒ
ｔｕａｌｆｉｌｅｓｙｓｔｅｍ）」の一部である。このファイルは、ランタ
イムにおいてシンボルリファレンスを満たすためにどのモジュール、関数、プロ
セス、データ構造などが用いられるかを指定するために、用いられる。システム
のこれらの特徴を以下により詳細に説明する。

【０１２０】図４に示すステップを実行することによりプログラムがダイナマイズされた後
、「送達可能な」ファイルが作成される。好適な実施形態においては、送達可能
なファイルは、解凍されて実行可能オブジェクトｈａｎｇｍａｎ３２．ｅｘｅ；
仮想ファイルシステムファイル、ｈａｎｇｍａｎ３２．ｖｆｓ；およびダイナミ
ックリンクされたライブラリｄｙｎａｌｉｂ．ｄｌｌとなる、圧縮ファイルであ
る。ユーザのマシン内におけるこれらのファイルの所在を、図６Ａにおいてファ
イル５５６、５５８および５６０としてそれぞれ示している。好適な実施形態に
おいて、送達可能なファイルは拡張子「．ｄｙｐ」を有する。ユーザは、．ｄｙ
ｐファイルを解凍し、「ｄｙｎａｉｎｓｔａｌｌ．ｅｘｅ」プログラム（解凍フ
ァイルとして提供される）を実行し、インストールされたプログラムを実行する
ことにより、ファイルをインストールしなければならない。ユーザは、プログラ
ムのダイナマイズされたバージョンを、標準的な方法でロードして実行すること
かできる（すなわち、実行可能物に対応付けられたアイコンをクリックして、Ｗ
ｉｎｄｏｗｓ（登録商標）９５において実行可能物の名前を指定することにより
）。

【０１２１】図６Ａは、ユーザのコンピュータ内のダイナマイズされたプログラムを実行す
るプロセスを示している。この図は図３Ａのステップ３０６をより詳細にしたも
のである。この場合ユーザは、アドオンモジュール（後述）なしで、オリジナル
のアプリケーションプログラムのダイナマイズされたバージョンを実行している
。したがって、シンボルリファレンスにはリダイレクトが提供されているが、全
てのシンボルは、アプリケーションの元々のプログラマが考えた通りの本来意図
されたアイテムへ、対応している。すなわち、プログラムのランタイム機能はま
だ改変されていない。

【０１２２】図６Ａにおいて、実行可能オブジェクト５５２は、実行イメージ５５６として
、ローダ５５４によってユーザのマシンのシステムＲＡＭにロードされる。実行
イメージ５５６は、オリジナルのシンボルリファレンスとオリジナルのアイテム
定義との間に対応付けがなされる領域としての、ダイナマップ領域５６２を含む
。実行イメージ５５６の開始時において、ｄｙｎａｌｉｂ．ｄｌｌ５５８内のル
ーチンが呼び出されて、Ｈａｎｇｍａｎ３２．ｖｆｓ５６０内のプロシージャお
よびデータにアクセスする。．ｖｆｓファイル内のこれらのルーチンおよびデー
タは、実行イメージ５５６内のリファレンスを、ダイナテーブル５６２の値を変
更することによって、どのようにリダイレクトするかを指定する。ただし、これ
はアドオンモジュールを有さないプログラムのダイナマイズされたオリジナルの
バージョンであるため、ダイナテーブルに変更は加えられない。．ｖｆｓファイ
ルが処理された後、実行イメージ５５６は、オリジナルのソースコードで指定さ
れた通りの機能を、ユーザのマシンにおいて提供する。シンボルリファレンスリ
ンクの一例として、実行イメージ５５６がポインタＷ１を介してシンボルをリフ
ァレンスしている例を示している。Ｗ１は、実行イメージ５５６内のある１つの
アイテム定義を指している。

【０１２３】プログラムが、そのシンボルリファレンスが容易にリダイレクトされ得るよう
にダイナマイズされると、図３Ａのステップ３０６に示すようにプログラムはロ
ードされて実行され得る。プログラムは、元々設計された通りに振る舞う。すな
わち、ダイナマイズされたプログラムは、プログラムがダイナマイズされなかっ
たかのように同じ機能を実行する。しかし、シンボルリファレンスがリダイレク
トされているので、各リファレンスの実行は、プログラムの元々のダイナマイズ
されていないバージョンにおけるより遅くなり得る。リファレンスが遅くならな
い場合は、リダイレクトされたアクセスの実行が実行時間を増加させないような
プロセッサにおける場合である。これは、パイプライン化プロセッサ、最適化さ
れたキャッシングを有するプロセッサなどの場合にそうであり得る。また、シン
ボルアクセスがそもそも間接的な手段による場合（例えばオリジナルのソースコ
ードにおけるサブルーチンへのポインタを介してサブルーチンを呼び出すなど）
、シンボルリファレンスをダイナマイズすることは、シンボルアクセスのオーバ
ヘッドを増大させない。

【０１２４】実行可能物のダイナマイズされたバージョンは、シンボルへの間接的リンクを
提供するダイナテーブルを保持するために余分な格納領域が必要である点におい
て、非ダイナマイズバージョンとは異なる。テーブルのサイズは、ダイナマイズ
されるシンボルの数に依存する。例えば、全てのシンボルがダイナマイズされる
ことを防ぐための「＃ｄｙｎａ−ｏｎ」および「＃ｄｙｎａ−ｏｆｆ」のような
コンパイラ指示が、プログラマに提供され得る。後述の補助ファイルもまた、プ
ログラムのランタイム改変を達成するためのオーバヘッドを増大させる。しかし
、サイズおよびスピードの影響は通常無視し得るものである。容易に改変可能な
実行可能物を有することの利点は、典型的には、あったとしてもわずかな実行可
能物のサイズの増加、ファイル数の増加、および実行時間の増加（大部分のアプ
リケーションにおいてユーザにはまったく感知され得ない）を、はるかにしのぐ
ものである。

【０１２５】４．アドオン（「ダイナ」）モジュールの作成図５は、本発明のアドオン開発フェーズを説明するフローチャート５００を示
している。アドオン開発フェーズは、改変された実行可能オブジェクト情報を、
ランタイム時においてオリジナルのプログラムにリンクするためのＤＬＬ形式で
、生成する。アドオン開発フェーズはまた、ランタイム時またはその直前におい
て、シンボルリンクがどのようにリダイレクトされるかを決定する、補助ファイ
ルを生成する。基本的に、ランタイム機能の改変は、オリジナルのプログラム内
で定義されたアイテム（すなわち、実行可能コード、データ構造など）に異なる
定義を代入することによって得られる。

【０１２６】図５において、プログラマは、オリジナルのアプリケーションプログラムから
のソースコードモジュールを改変することにより、改変されたソースコードモジ
ュール５０２を生成する。プログラマはオリジナルのソースコードモジュールか
ら開始する必要はないが、全てのシンボルリファレンスおよびプログラム構造が
既に存在しているため、実際はそうした方がオリジナルのプログラムの改変が容
易になる。改変は、関数、プロセス、データ構造などの新しいアイテムを含み得
る。改変はまた、既存のアイテムの削除も含み得るが、削除する場合は、関数を
「スタブアウト（ｓｔｕｂｏｕｔ）」するのが最もよい。すなわちある構造か
ら、その構造またはリソースの「ダミー」シンボル定義をそのまま残しながら、
全てのデータを除去することにより、その構造またはリソースへのリファレンス
の全てを削除する必要がないようにする。シンボル定義を残しておくことで、削
除されたアイテムに後でデータを容易に足し戻すことが可能である。

【０１２７】改変されたソースコードモジュール５０２は、コンパイラ５０４によってコン
パイルされる。コンパイルは、プログラムの改変された部分以上に対して行われ
得ることに留意されたい。なぜなら、プログラムの改変された部分を含むモジュ
ールは、ソースコードのうち他の改変されていない部分を含み得るからである。

【０１２８】リンカ５０８を用いて、コンパイルされた改変済みオブジェクトモジュールを
ライブラリ定義５１２とリンクする。ライブラリ定義５１２は、図４のファイル
４３０と同じファイルである。このファイルは、改変されたモジュールのリンキ
ングが、シンボルリファレンスエラーなしでなされ得るように、オリジナルのア
プリケーションプログラム中のシンボルのためのシンボル定義の全てを提供する
。リンクの結果は、ランタイム時においてオリジナルのプログラムにフックされ
るべき新しいアイテムを含むＤＬＬである、ｄｙｎａｐｌａｙ．ｄｌｌとなる。

【０１２９】本発明の．ｄｌｌは、共通のファイル拡張子すなわち「．ｄｌｌ」を用いてい
るが、本発明の．ｄｌｌは、従来技術における．ｄｌｌ形式および用途とは大き
く異なっている。本明細書に記載したように、本発明におけるプログラムの機能
の変更は、ランタイムプログラムに存在するテーブル内のシンボルリファレンス
を介して行われる。旧来のＤＬＬは、ＤＬＬ機能にアクセスするためにＡＰＩル
ーチンの使用を必要とするが、これは、旧来のＤＬＬアプローチにおいて、サイ
ズおよび動作オーバーヘッドを導入するものである。ＤＬＬライブラリとともに
ＡＰＩインターフェースを運ばなければならず、これは、機能を変更するための
少量の新しいコードまたはデータを導入するための媒体としては、非効率的なも
のとなってしまう。ＡＰＩインターフェースを用いることはまた、ＤＬＬルーチ
ンとやりとりするためにはインターフェースルーチンが実行されなければならな
いため、プログラムの実行を遅めてしまう。ＡＰＩルーチンを使用することをア
プリケーションプログラムに要求することはまた、本発明のアプローチによって
提供される機能変更のタイプよりも、機能変更のタイプを減少させることになる
。

【０１３０】リンカ５０８はまた、新しいモジュールのリンキングに用いられるシンボルを
含む、ｄｙｎａｐｌａｙ．ｍａｐ５１４を生成する。Ｄｙｎａｐｌａｙ．ｍａｐ
は、図４のｄｙｎａｍａｐ．ｅｘｅ４２０によってｈａｎｇｍａｎ３２．ｄｅｆ
ファイルが生成されたのと同様にして．ｄｅｆファイル５１８を生成する、ｄｙ
ｎａｍａｐ．ｅｘｅへの入力である。ダイナモジュールからの．ｄｅｆファイル
の一例を、下記の表Ｖに示す。

【０１３１】

【表８】

【０１３２】

【表９】．ｄｅｆファイルは、．ｖｆｓファイル５２２を生成するｄｙｎａｇｅｎ．ｅ
ｘｅ５２０への入力として用いられる。．ｖｆｓファイルは、ランタイム時また
はランタイム以前にどのようにシンボルリファレンスをリダイレクトするかに関
する情報を含んでいる。．ｖｆｓファイルの機能はより詳細に後述される。

【０１３３】５．ランタイム時におけるアドオンモジュールのリファレンシングダイナマイズされたプログラムおよびアドオンダイナモジュールがユーザのマ
シンにロードされた後、ダイナマイズされたプログラムの機能の改変は、ダイナ
マップテーブルにおけるシンボルリファレンスリンクを変更することにより、制
御される。

【０１３４】図６Ａおよび図６Ｂは、ユーザ機器内で起こるシンボルリファレンスリンク改
変を示す。上記したように、図６Ａは、アドオンダイナモジュールがない状態で
初期動作を行うときの、ダイナマイズされたプログラムを示す。図６Ｂは、ダイ
ナマイズされたプログラムであって、リンクのリダイレクトによって、リンクに
関連づけられたシンボルがダイナモジュール、すなわち、Ｈａｎｇｍａｎ３２．
ｖｆｓファイル内のアイテムを参照する、ダイナマイズされたプログラムを示す
。

【０１３５】図６Ｂにおいて、送達可能ファイル５８２が、オリジナルのダイナマイズされ
たプログラムをすでに有しているユーザによって、受け取られる。たとえば、ユ
ーザは、２つのキャラクタ間の戦いをシミュレートするコンピュータゲームを獲
得し得る。その場合、ゲームの送達可能ファイル（たとえば、図６Ａの送達可能
ファイル５６４）が、インターネットサイトまたはＣＤ−ＲＯＭディスクなどか
らダウンロードすることにより得られる、ゲームのダイナマイズされたバージョ
ンが得られ得る。ユーザは、上記セクション３に記載したように、ゲームをイン
ストールし、ロードし、実行する。ゲームは、キャラクタおよびシーンの背景の
ためのアートワーク、キャラクタの戦いの動きを動画化するプロセス、ユーザか
らの入力を受け取ってキャラクタを制御するプロセス、ならびにスコアをとるプ
ロセスなどを含む、すべての機能を備えたスタンドアローン型プログラムである
。数ヶ月後、オリジナルゲームの製造者（または別の製造者）がオリジナルゲー
ムに特徴を追加することを決定する。たとえば、新しい戦闘キャラクタが追加さ
れ、背景シーンの掲示板の広告が変更される。製造者は、送達可能ファイル５８
２という形態でアドオンダイナモジュールを提供することにより、これを行う。

【０１３６】送達可能ファイル５８２は、解凍され、ｄｙｎａｌｉｂ．ｄｌｌファイル５８
４およびｈａｎｇｍａｎ３２．ｖｆｓ５８６を置換する。通常、新しいダイナモ
ジュールをインプリメントするためには、．ｖｆｓファイルのみを置換する必要
がある。しかし、ｄｙｎａｌｉｂ．ｄｌｌをアップグレードするために、これも
置換され得る。従って、機能を追加するためのダウンロードサイズは、通常、ち
ょうど、変更されるアイテムのサイズである。これは、プログラム全体が数１０
メガバイトであるのに比べて、数１０キロバイトのオーダーであり得る。次回、
実行可能オブジェクト５５２によって表されるゲームがローダ５５４によってロ
ードされて実行イメージ５５６として実行されるとき、アイテムリファレンスは
、新しい戦闘キャラクタをインプリメントするプロセスが呼び出され、かつ、新
しい広告画像をインプリメントするデータ構造およびプロセスがアクセスされる
ように、リダイレクトされる。シンボルリファレンスリンクの実際の変更は、ダ
イナモジュールを実行することに関して図６Ａに示したものと同一である。しか
し、今回は、新しいアイテムが参照されるように、リンクが実際に置換される。
従って、図６Ｂは、この時点でｈａｎｇｍａｎ３２．ｖｆｓファイル５８６内の
アイテムを指し示しているダイナテーブル内のＷ１を介したリファレンスを示す
。このことは、Ｗ１を介してマッピングされたすべてのリファレンスがこの時点
で、ｈａｎｇｍａｎ３２．ｖｆｓ内のダイナモジュール内に設けられたアイテム
にアクセスすることを意味する。

【０１３７】図７は、．ｖｆｓファイル内のオブジェクトの詳細、および、いかにしてこれ
らのオブジェクトが生成されるかを示す。

【０１３８】図７において、プログラムｄｙｎａｇｅｎ．ｅｘｅ６０６は、アイテム定義６
２０とＳＣＨＥＭＥスクリプト６０８とを、．ｅｘｅまたは．ｄｌｌファイル６
０２および．ｄｅｆファイル６０４から生成する。これらのファイルはすべて、
ＳＣＨＥＭＥスクリプトを除いて、上記に詳細に説明されている。アイテム定義
は、．ｖｆｓファイルの一部となる、実行可能なバイナリの命令、データ、また
は他の情報である。これらは、ランタイム時に、リファレンスがリダイレクトさ
れる先の定義である。ｄｙｎａｇｅｎ．ｅｘｅプロセスの入力および出力の詳細
に関しては、ソースコードＡｐｐｅｎｄｉｘのｄｙｎａｇｅｎリストを参照され
たい。

【０１３９】ＳＣＨＥＭＥスクリプトは、シンボルリファレンスリンクのリダイレクトを行
うために、アプリケーションプログラムのランタイム時に、解釈され得るソース
コードファイルである。すなわち、ＳＣＨＥＭＥスクリプトは、図６Ｂ内のダイ
ナテーブル５６２などのダイナテーブル内のポインタをスワップまたはリダイレ
クトする様式を制御する。好適な実施形態は、言語を規定するパブリックドメイ
ンＳＣＨＥＭＥスクリプトインタープリタを用いる。任意の適切なスクリプト言
語、または他の制御メカニズムが用いられ得る。いずれの言語も用いることがで
きるため、シンボルリファレンスのスワッピングまたはリダイレクトを制御する
特定のメカニズムには選択の余地がある。たとえば、この言語は、スワッピング
を行うためにマシンコードを用いる場合のように、人間にとって読取り可能な言
語である必要さえない。しかし、人間にとって読取り可能な、フレキシブルなス
クリプト言語を、メカニズムとして提供することは、以下に述べるように有利で
ある。

【０１４０】図７に示すように、ＳＣＨＥＭＥスクリプトは、ｄｙｎａｇｅｎ．ｅｘｅプロ
グラム以外のソースから提供され得る。たとえば、ＳＣＨＥＭＥスクリプト６１
０は、人間のプログラマによって手動で作成され得るし、すでに存在するファイ
ルであり得るし、第三者などによって自動的にまたは手動で作成され得る。ＳＣ
ＨＥＭＥスクリプトは、スクリプトインタープリタに提供され、スクリプトイン
タープリタは、スクリプトの、「中間言語」バージョンを生成するように命令さ
れる。典型的には、このような中間言語は、スクリプトの、人間にとって読取り
可能な形態と等価であるが、よりコンパクトであり、コンピュータプロセスが読
取りかつ実行するにより容易である。中間言語は、バイナリ命令同様、人間にと
って容易に読取り可能ではない。

【０１４１】中間言語６１４は、．ｖｆｓファイル内に、たとえばファイル６２４および６
２６として、インタープリタ６２２のインスタンスと共に含まれる。ランタイム
時には、実行可能イメージが起動されると、ｄｙｎａｐｌａｙ．ｄｌｌルーチン
「ＤｌｌＭａｉｎ（）」を呼び出すことにより、ＳＣＨＥＭＥ中間言語ファイル
が解釈されて、リファレンスのリダイレクトが処理される。

【０１４２】図８は、ｄｙｎａｇｅｎ．ｅｘｅによって生成されたＳＣＨＥＭＥスクリプト
の一例である。

【０１４３】図８において、６５０で示す行は、リファレンスリンクの置換を行うための、
「ｅｎａｂｌｅ−ｄｙｎａｍｏｄ」の関数呼び出しを表す。リンクされるダイナ
モジュールのファイル位置は、「ｓｅｌｆａｎｄｈｅａｔ．ｄｌｌ」として６５
２で特定される。ダイナモジュールにアクセスする実行可能物は、「ｎｅｔ＿ｆ
ｉｇｈｔｅｒ．ｅｘｅ」として６５４で特定される。それに続く数字対のそれぞ
れは、新しいアドレス位置によって置換される、ダイナモジュール内のインデッ
クスを指定する。これらは、実行可能物用（ｎｅｔ＿ｆｉｇｈｔｅｒ．ｅｘｅ）
の．ｄｅｆファイルおよびダイナモジュール（ｓｅｌｆｈａｎｄｈｅａｔ．ｄｌ
ｌ）用の．ｄｅｆファイルに対応する。

【０１４４】テーブルＶを、ダイナモジュールからの．ｄｅｆファイルとして用い、かつ、
テーブルＩＶを、実行可能物からの（部分）テーブルとして用いることにより、
図８のＳＣＨＥＭＥスクリプトファイル内の対（８４．＃ｘ１０００）は、イン
デックス８４を有する実行可能物内のシンボルＤｒａｗＧａｍｅが．ｄｌｌ内の
１６進数１０００のアドレスにマッピングされることを特定する。テーブルＶは
、同一の名前であるＤｒａｗＧａｍｅによる新しい手続きのアドレスがこうして
アクセスされることを示す。

【０１４５】スクリプト言語はシンボルリファレンスのリダイレクトを制御するために用い
られるため、リファレンスの多様な組み合わせのスワッピングをすることが可能
である。たとえば、図８のスクリプトは、特定のファイルが存在する場合に、あ
るいは１日のうちのある時刻に、あるいは１ヶ月のうちのある日より後に、ある
いはインターネットからの条件がチェックされた時などに、リファレンスのスワ
ッピングが起こるように、改変され得る。このようにして、ユーザが追加料金を
支払っているか否か、期限がすぎているか否か、関係するプレーヤの数、などに
依存して、プログラムの特徴がオンまたはオフされ得る。このことにより、プロ
グラムは、ユーザの興味に適合する、スポンサの順番が回ってきたときに変更さ
れる、などというようにカスタマイズされた、広告などの情報のためのフレキシ
ブルな媒体となる。本発明は、ダウンロードされ得、かつ、既存のダイナマイズ
されたコンピュータプログラムに組み込まれ得る非常に小さいダイナモジュール
を介して、このフレキシビリティをすべて提供する。さらに本発明は、いずれの
既存のプログラムもが、専門的作業をほとんど必要とすることなくダイナマイズ
されることを可能にする。

【０１４６】スクリプト命令は、起動時のみに実行されることに限定される必要はない。マ
ルチスレッド環境において、スクリプト命令は、オリジナルのコンピュータプロ
グラムおよびダイナモジュールによって提供される命令の実行と「同時に」実行
され得る。このことにより、フレキシビリティが増加し、たとえば、ユーザの入
力、リアルタイムクロック、このプログラムまたは他のプログラムを実行した結
果起こる状況などに基づいてリファレンスが変更されるようになる。

【０１４７】図７に戻って、．ｖｆｓファイルシステムの特徴は、．ｖｆｓファイル中のす
べてが人間にとって読取り不可能であるということである。アイテム定義６２０
は、ＳＣＨＥＭＥインタープリタ６２２同様、バイナリ形式である。ＳＣＨＥＭ
Ｅ中間言語ファイルもまた、読取り不可能である。なぜなら、人間にとって読取
り可能なスクリプトからコンピュータ読取り可能な中間言語を引き出すように予
備処理されているからである。従って、．ｖｆｓファイルは、製造者にセキュリ
ティを提供して、ユーザのプログラムの「ハッキング」を防止し、かつ、他の製
造者が、たとえばライセンスなどで許可されない限り、オリジナルの製造者の製
品と共に用いられるアドオンモジュールを製造することを防止する。

【０１４８】．ｖｆｓフォーマットの別の特徴は、ＳＣＨＥＭＥ中間言語命令によるファイ
ルに対するリファレンスが．ｖｆｓファイル内のリファレンスに限定されている
ことである。このことは、たとえば、ＳＣＨＥＭＥ命令のエラーが、ユーザ機器
上のファイルまたは他の情報またはデバイスを害することを防止する。

【０１４９】本発明を特定の実施形態に照らして述べてきたが、多くの変更が可能であるこ
とが明らかであるはずである。たとえば、．ｖｆｓファイルフォーマットは広範
囲に変更され得る。．ｖｆｓファイルは、ユーザが通常はその存在を知らない隠
しファイルであり得る。インタープリタは．ｖｆｓファイル内に存在する必要は
なく、ｄｙｎａｐｌａｙ．ｄｌｌライブラリ、異なるライブラリ、プログラムま
たは他のエンティティの一部であり得る。概して、本発明によって述べた処理は
、任意の数のプロセス、プログラム、またはルーチンによっても実行され得、本
明細書に述べたように、任意の適切なプラットフォーム上の機能を実行すること
により達成され得る。従って、本明細書における実施形態は、本発明の説明のみ
のために提供され、本発明の範囲は添付の請求の範囲によってのみ限定される。

【０１５０】

【表１０】

【０１５１】

【表１１】

【０１５２】

【表１２】

【０１５３】

【表１３】

【０１５４】

【表１４】

【０１５５】

【表１５】

【０１５６】

【表１６】

【０１５７】

【表１７】

【０１５８】

【表１８】

【０１５９】

【表１９】

【０１６０】

【表２０】

【０１６１】

【表２１】

【０１６２】

【表２２】

【０１６３】

【表２３】

【０１６４】

【表２４】

【０１６５】

【表２５】

【０１６６】

【表２６】

【０１６７】

【表２７】

【０１６８】

【表２８】

【０１６９】

【表２９】

【０１７０】

【表３０】

【０１７１】

【表３１】

【０１７２】

【表３２】

【０１７３】

【表３３】

【０１７４】

【表３４】

【０１７５】

【表３５】

【０１７６】

【表３６】

【０１７７】

【表３７】

【０１７８】

【表３８】

【０１７９】

【表３９】

【０１８０】

【表４０】

【０１８１】

【表４１】

【０１８２】

【表４２】

【０１８３】

【表４３】

【０１８４】

【表４４】

【０１８５】

【表４５】

【０１８６】

【表４６】

【０１８７】

【表４７】

【０１８８】

【表４８】

【０１８９】

【表４９】

【０１９０】

【表５０】

【０１９１】

【表５１】

【０１９２】

【表５２】

【０１９３】

【表５３】

【０１９４】

【表５４】

【０１９５】

【表５５】

【０１９６】

【表５６】

【０１９７】

【表５７】

【０１９８】

【表５８】

【０１９９】

【表５９】

【０２００】

【表６０】

【０２０１】

【表６１】

【０２０２】

【表６２】

【０２０３】

【表６３】

【０２０４】

【表６４】

【０２０５】

【表６５】

【０２０６】

【表６６】

【０２０７】

【表６７】

【０２０８】

【表６８】

【０２０９】

【表６９】

【０２１０】

【表７０】

【０２１１】

【表７１】

【０２１２】

【表７２】

【０２１３】

【表７３】

【０２１４】

【表７４】

【０２１５】

【表７５】

【０２１６】

【表７６】

【０２１７】

【表７７】

【０２１８】

【表７８】

【０２１９】

【表７９】

【０２２０】

【表８０】

【０２２１】

【表８１】

【０２２２】

【表８２】

【０２２３】

【表８３】

【０２２４】

【表８４】

【０２２５】

【表８５】

【０２２６】

【表８６】

【０２２７】

【表８７】

【０２２８】

【表８８】

【０２２９】

【表８９】

【０２３０】

【表９０】

【０２３１】

【表９１】

【０２３２】

【表９２】

【０２３３】

【表９３】

【０２３４】

【表９４】

【０２３５】

【表９５】

【０２３６】

【表９６】

【０２３７】

【表９７】

【０２３８】

【表９８】

【０２３９】

【表９９】

【０２４０】

【表１００】

【０２４１】

【表１０１】

【０２４２】

【表１０２】

【０２４３】

【表１０３】

【０２４４】

【表１０４】

【０２４５】

【表１０５】

【０２４６】

【表１０６】

【０２４７】

【表１０７】

【０２４８】

【表１０８】

【０２４９】

【表１０９】

【０２５０】

【表１１０】

【０２５１】

【表１１１】

【０２５２】

【表１１２】

【０２５３】

【表１１３】

【０２５４】

【表１１４】

【０２５５】

【表１１５】

【０２５６】

【表１１６】

【０２５７】

【表１１７】

【図面の簡単な説明】

【図１Ａ】図１Ａは、変換されたコードを実行する、従来技術のプロセスを示す簡略図で
ある。

【図１Ｂ】図１Ｂは、コンパイルされたコードを実行する、従来技術のプロセスを示す簡
略図である。

【図１Ｃ】図１Ｃは、変換されたソースコードの一部の一例を示す図である。

【図１Ｄ】図１Ｄは、コンパイルされた実行可能オブジェクトの部分の一例を示す図であ
る。

【図１Ｅ】図１Ｅは、コンパイルされた実行可能オブジェクトのパッチングの一例を示す
図である。

【図２Ａ】図２Ａは、本発明と共に用いられるために適切なコンピュータシステムを例示
する図である。

【図２Ｂ】図２Ｂは、図２Ａのコンピュータシステムのようなコンピュータシステムにお
けるサブシステムを示す図である。

【図２Ｃ】図２Ｃは、典型的なネットワークの一般化された図である。

【図３Ａ】図３Ａは、実行時にコンパイルされたプログラムに機能性を加える、全体的な
アプローチの基本的な工程を示すフローチャートである。

【図３Ｂ】図３Ｂは、従来技術の実行可能オブジェクトのメモリマップの図である。

【図３Ｃ】図３Ｃは、本発明の実行可能オブジェクトのメモリマップの図である。

【図３Ｄ】図３Ｄは、従来技術の実行イメージの図である。

【図３Ｅ】図３Ｅは、本発明の実行イメージの図である。

【図４】図４は、本発明のシステムのプログラム変換段階を示す図である。

【図５】図５は、本発明のアドオン開発段階の工程を示すフローチャートである。

【図６Ａ】図６Ａは、ユーザのコンピュータにおいてダイマナミズされた（ｄｙｎａｍｉ
ｚｅｄ）プログラムを実行するプロセスを示す図である。

【図６Ｂ】図６Ｂは、ユーザのコンピュータにおいてダイナモジュール（ｄｙｎａｍｏｄ
ｕｌｅ）を実行するプロセスを示す図である。

【図７】図７は、．ｖｆｓファイル内のオブジェクトの細部、およびそれらのオブジェ
クトがどのように発生されるかを示す図である。

【図８】図８は、制御スクリプトの一例を示す図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷＦターム(参考） 5B081 AA01 AA03 AA04 AA06 AA09 CC12 CC13

Claims

【特許請求の範囲】

【請求項１】コンピュータプログラムを、ランタイム時にリダイレクトさ
れ得るシンボルリファレンスを有する実行可能オブジェクトに変換する方法であ
って、プロセッサ兼格納デバイスを含み、オリジナルの名前を有するオリジナル
の定義に対するシンボルリファレンスを有するコンピュータプログラムをさらに
含むコンピュータシステム上で実行される、方法であって、１以上の該オリジナルの名前を識別する工程と、該コンピュータプログラム内で用いられる１以上の該オリジナルの名前を新し
い名前に再ネーミングする工程と、該オリジナルの名前に対するシンボルリファレンスが該新しい名前に対するリ
ファレンスを呼び出すように、該オリジナルの名前と該新しい名前との関連づけ
を作成する工程と、を含む、方法。
【請求項２】前記関連づけに関する情報をテーブルフォーマットで格納す
る工程をさらに含む、請求項１に記載の方法。
【請求項３】シンボルリファレンスに、前記テーブル内のエントリを参照
させる工程と、該オリジナルの定義へのポインタを該エントリに関連づける工程と、をさらに含む、請求項２に記載の方法。
【請求項４】前記コンピュータプログラムをコンパイルするためにコンパ
イラが用いられ、該コンパイラによって生成された情報を用いて、該コンピュータプログラム内
のオリジナルの名前を識別する前記工程を実行する工程をさらに含む、請求項１
に記載の方法。
【請求項５】前記シンボルリファレンスが、データ構造に対するものであ
る、請求項１に記載の方法。
【請求項６】前記シンボルリファレンスが、プログラム命令に対するもの
である、請求項１に記載の方法。
【請求項７】前記シンボルリファレンスが、リソースに対するものである
、請求項１に記載の方法。
【請求項８】前記シンボルリファレンスが、オブジェクトに対するもので
ある、請求項１に記載の方法。
【請求項９】前記コンピュータプログラムをコンパイルするために、Ｍｉ
ｃｒｏｓｏｆｔＤｅｖｅｌｏｐｅｒ’ｓＥｎｖｉｒｏｎｍｅｎｔが用いられ
、該ＭｉｃｒｏｓｏｆｔＤｅｖｅｌｏｐｅｒ’ｓＥｎｖｉｒｏｎｍｅｎｔが
、該コンピュータプログラム内のシンボルリファレンスに関する情報を生成する
ユーティリティを含み、１以上のファイルからの情報を用いて、前記オリジナルの名前に関する情報を
含む１以上の補助ファイルを生成する工程と、該補助ファイルを用いて、該コンピュータプログラムと共に実行されるアドオ
ンモジュールをコンパイルする工程と、をさらに含む、請求項１に記載の方法。
【請求項１０】ＭｉｃｒｏｓｏｆｔＤｅｖｅｌｏｐｅｒ’ｓＥｎｖｉ
ｒｏｎｍｅｎｔが、．ｍａｐファイルを生成するリンカを用いることにより、前
記コンピュータプログラムをコンパイルし、１以上のファイルからの情報を用いて補助ファイルを生成する前記工程が、該
．ｍａｐファイルを用いて、該補助ファイルの少なくとも一部として含まれる．
ｄｅｆファイルを引き出すサブ工程を含む、請求項１に記載の方法。
【請求項１１】コンピュータプログラム内で用いられる１以上のシンボル
リファレンスに対する代替リファレンスを有する機能を、該コンピュータプログ
ラム内でランタイム時に改変する方法であって、プロセッサ兼格納デバイスを含
むコンピュータシステム上で実行される方法であって、該コンピュータプログラムを該コンピュータシステムにロードする工程と、アイテム定義を含むモジュールを該コンピュータシステムにロードする工程と
、該代替リファレンスを該アイテム定義に関連づけるプロセスを実行する工程と
、を含む、方法。
【請求項１２】スクリプト言語命令を実行することによって、前記代替リ
ファレンスを前記アイテム定義に関連づける工程をさらに含む、請求項１１に記
載の方法。
【請求項１３】前記コンピュータプログラムの実行中に、同時にスクリプ
ト言語命令を実行することによって、前記代替リファレンスを前記アイテム定義
に関連づけ、それにより、前記関連づけを制御する工程をさらに含む、請求項１
１に記載の方法。