JP2003535415A - コンパイルの前に、プロジェクト・コンポーネントの論理ビューを提示し、その選択を容易にし、欠けているリンクを知らせるソフトウェア開発システム - Google Patents

Abstract

(57)【要約】 ソフトウェア開発システム（１００）によって、ソース・コード要素のコア・ライブラリから製品が開発され（９００）、コア・ライブラリが、１つまたは複数の機能を有するコンポーネントに分類される。コンフィギュレータ（７００）によって、指定されたプラットフォーム・タイプおよびソース・コード要素に基づいて、構成状態データを展開する。グラフィカル・ユーザ・インターフェース（２００）に、未解決の依存性の視覚的表示を含む、構成状態データに従う製品（１０００）の視覚的および論理的表現を表示する。その後、製品メイク（８００）ルーチンが、構成状態データに従ってソース・コード要素から製品を生成する。

Description

【発明の詳細な説明】

【０００１】 （関連出願の相互参照） 本願は、１９９８年９月２４日出願の米国特許第０９／４０４２９８号の一部
継続出願である。

【０００２】 （発明の背景） 発明の分野／概要 本発明は、全般的に、ソース・コード・ライブラリをカスタマイズし組み合わ
せることと、ソフトウェア製品を形成するためにそれらを統合することによる、
ソフトウェア製品の開発および統合の方法およびシステムに関する。より具体的
かつ例示的には、本発明は、基本入出力システム（ＢＩＯＳ）の開発を単純にし
、すばやい製品開発、機能強化、および修正を可能にする、拡張可能でありなが
ら保守可能なコア・ライブラリのアーキテクチャを提供する、パーソナル・コン
ピュータ（ＰＣ）のＢＩＯＳのコア・コンポーネントを保守し、再利用するソフ
トウェア・システムに関する。

【０００３】 （技術の背景および最新技術） ＢＩＯＳ製品は、ＰＣが起動または「ブート」される時に実行され、その後に
ＰＣの走行中にさまざまなサービスを提供するために呼び出されるソフトウェア
・コードである。ＢＩＯＳ製品の開発システムは、ローエンドの基本的ＰＣから
最新技術の高度にカスタマイズされたハイエンド・サーバまたはポータブル製品
までのすべてのタイプのＰＣにインストールされる可能性があるすべての周辺機
器をサポートしなければならない。ＢＩＯＳ作成のさまざまな態様を、下で説明
して、コアＢＩＯＳソフトウェア・コンポーネントのライブラリを保守し、使用
するソフトウェア・システムが提供しなければならない能力を示す。

【０００４】 特定の計算機のＢＩＯＳを作成することを望む顧客は、その計算機にインスト
ールされる周辺機器をサポートするために、コアＢＩＯＳソフトウェア・コンポ
ーネントをそのようなコンポーネントのライブラリから選択する。各ソフトウェ
ア・コンポーネントに、１つまたは複数の機能を含めることができ、使用可能な
機能の組から機能のコードを追加または除去することと、このコードの任意選択
のパラメータ（「オプション」）の値を指定することによって、各ソフトウェア
・コンポーネントを構成することができる。顧客は、顧客によってカスタム製造
された周辺装置の、ＢＩＯＳベンダから入手可能でない特別なＢＩＯＳコードの
追加を望む場合がある。

【０００５】 構成可能な機能は、コアＢＩＯＳコンポーネント・ライブラリ内の別のコード
として実装される。このコードは、各機能のコードを、正しく構成されアドレッ
シングされる時に限って最終製品にリンクできるようにするために、名前と、デ
ィレクトリ／サブディレクトリまたはライブラリ名とによって他のコード・コン
ポーネントをアドレッシングする、コード内の外部参照および定義を有する。現
在の最新技術は、選択されていない、呼び出されるか命名されるかアドレッシン
グされるオプション機能のコードを、単純に呼出し元にリターンするスタブ・ル
ーチンに置換することである。もう１つの可能性は、機能が除去される場合にヌ
ルをセットすることができるポインタを介して間接的にオプション機能を参照す
ることであるが、しかし、これは、呼出し元のそれぞれが、ポインタが有効であ
るどうかを検証することを必要とする。理想的には、オプション機能を呼び出す
コードを、コンポーネントのビルド時にコードから除去して、そのプログラムが
占める実行時間とメモリ・サイズの両方の節約を実現しなければならない。

【０００６】 現在の最新技術では、たとえば「ＢＵＦＦＥＲ＿ＳＩＺＥ ＥＱＵ ２５６」
などの宣言済み定数として、ソフトウェア・コンポーネントのオプション・パラ
メータ（以下では「オプション」と呼ぶ）を定義する。宣言済み定数の名前（Ｂ
ＵＦＦＥＲ＿ＳＩＺＥ）およびそれが表す値（２５６）は、宣言済み定数が定義
される時に関連付けられる。配列の長さまたは変数の値などでの宣言済み定数の
名前の参照のそれぞれは、ソース・コードがコンパイルされる時に関連する定数
に置換される。これによって、各オプションに記述的な名前を与えることができ
、１つの定義を変更することによって、参照されているすべての場所でオプショ
ンの値を変更することが可能になる。このようなオプションは、通常は、「イン
クルード(include)」ファイルを手で定義または修正することによって、設定ま
たは調整される。その後、「インクルード」ファイルが、他のソース・コード・
ファイルに、参照によって組み込まれる。オプション名への参照を含むファイル
を見失うこと、または異なるシステム・コンポーネントで同一の名前を有するオ
プションを混同することは、簡単である。

【０００７】 コアＢＩＯＳコンポーネント・ライブラリの生産者および販売者は、市場で入
手可能になる新しいデバイスにすばやく応答する必要がある。試行された正しい
方法の１つが、類似する既存デバイスのコードをコピーし、新しいデバイスをサ
ポートするのに必要な場合に限ってそれを修正することである。元のコードは、
新しいデバイスについても使用可能になった、サポートされる複数の構成可能な
機能を有する。別のコア・コンポーネントからコードをコピーすることは、同一
の機能だけではなく、それらを参照する同一の外部名も有する同一のライブラリ
内の２つのコンポーネントを生じさせる。この曖昧さが、コンパイルおよびリン
クの時にさらなる混乱を引き起こすことになる。

【０００８】 顧客は、古いデバイスまたは新しいデバイスのいずれかを組み込んだ計算機を
売ることができる。したがって、顧客は、古いデバイスをサポートする古いソフ
トウェア・コンポーネントと、新しいデバイスをサポートする、古いコンポーネ
ントを修正することによって生成された、同一の外部名を有する新しいコンポー
ネントの両方を組み込んだＢＩＯＳを作成することができる。このＢＩＯＳには
、古いコンポーネントと新しいコンポーネントの各プロシージャへの呼出しをイ
ンターセプトする追加コードが含まれる。その後、顧客は、新しいコンポーネン
ト内と古いコンポーネント内のどちらのプロシージャを呼び出さなければならな
いかを判断する判断コードを、インターセプトされるプロシージャごとに追加す
る。これによって、同一の外部名を有する２つのコンポーネントと、インターセ
プトされずに同一の名前を有する２つのプロシージャの一方を呼び出さなければ
ならない、インターセプトされる呼出しごとの判断コードとを含むＢＩＯＳが生
じる。各コンポーネント内の同一の外部名が衝突しないように、両方のソフトウ
ェア・コンポーネントが、別々にコンパイルされ、リンクされなければならない
。また、これらのコンポーネントは、それらを呼び出す判断コードと一緒にリン
クされなければならない。

【０００９】 古いコンポーネントと、古いコンポーネントを修正することによって生成され
、同一の外部名を有する新しいコンポーネントの両方が、ＩＮＩＴという名前の
初期化機能を有すると仮定する。上で述べた追加の判断コードは、古いコンポー
ネントと新しいコンポーネントのどちらのＩＮＩＴプロシージャを呼び出さなけ
ればならないかを判定できるように、ＩＮＩＴプロシージャの代わりに呼び出さ
れなければならない。現在の技術では、ＩＮＩＴへの各呼出しが、ポインタ・テ
ーブルを介して間接的に進み、その結果、ポインタを変更して、そのような呼出
しのそれぞれをインターセプトまたはフックできるようにする必要がある。ＢＩ
ＯＳ全体を通じてＩＮＩＴへのすべての呼出しが、この形でインターセプトまた
はフックされる。そのような呼出しをインターセプトする能力は、デバッグの目
的にも重要である。

【００１０】 コアＢＩＯＳコンポーネント・ライブラリのプロシージャは、ライブラリの新
しいバージョンをすばやく公開することによって、市場で入手可能になる新しい
デバイスに応答する。ライブラリの保守および機能強化の過程で、機能性を追加
するかバグを修正するために一部のインターフェースが修正される場合がある。
既存のＢＩＯＳを有する顧客は、新しい機能性およびバグ修正ならびに新たにサ
ポートされたデバイスを組み込むことを望む。顧客は、変更された既存インター
フェースへの呼出しが、互換性を有することを検証し、現在は互換性がなく、変
更されなければならないインターフェースをすばやく識別しなければならない。
現在の技術では、パラメータの数、各パラメータの型、および値の範囲を突き合
わせることによって、インターフェースを検証する。

【００１１】 特定のデバイスのＢＩＯＳコードは、通常は、ＰＣが起動される時に実行され
る初期化コードと、呼び出された時にサービスを提供するサポート・コードから
なる。サポート・コード内に初期化コードへの参照がないか、その逆の場合があ
る。これが、両方のコードがＢＩＯＳビルドに含まれる原因である。それでも、
サポート・コードは明らかに初期化コードに依存する。現在の技術では、両方の
コードがビルドに含まれることを保証するために、手動の介入が必要である。

【００１２】 整合性に関してソース・コード・モジュールを最終的にテストする従来の方法
は、別々のソース・コード・ファイルをコンパイルし、かつ／またはアセンブル
し、すべてのエラーを識別し、訂正し、この処理を繰り返し；オブジェクト・コ
ード・ファイルをリンクし、すべてのエラーを識別し、訂正し、この処理の両方
を繰り返し；最後に、別々にリンクされたシステム要素を相互リンクされたイメ
ージに組み合わせ、すべてのエラーを識別し、訂正し、この３つの処理のすべて
を、エラーが見つからなくなるまで繰り返し再帰的に繰り返すことである。その
後であっても、不正なリンクが、ソース・ファイルの異なる組で異なることを意
味するのに使用される同一の名前から、２つの非常に似たソース・ファイルの組
の誤った組の選択から、またはコンパイラおよびアセンブラが検出できないバー
ジョン非互換性から、生じる可能性がある。これらの問題のすべてが、組み合わ
されて、ソフトウェア・システムの開発および統合が、理想的な状態より時間の
かかるものになっている。

【００１３】 したがって、本発明の主目的は、アセンブル、コンパイル、またはリンクの前
に上のタイプのエラーを識別でき、訂正のために人を支援することができ；対応
するソース・コードがどこに保管されているかに無関係に、単純に、コンポーネ
ント、機能、および変形を見られ、選択するようにし；製品が「サーバ」または
「ポータブル」になることをグローバルに指定でき、これによって全く異なるシ
ステム構成を達成できるようにし；複数のコンポーネント変形形態の正しい１つ
を選択することと、オプションの値およびスコープを調整し、制御することと、
ソース・コード依存性に従って必要なシステム・コンポーネントの選択を自動化
することの、上で述べた問題に対処する、ソフトウェア開発システムの達成であ
る。

【００１４】 （発明の要旨） 簡単に説明すると、上記および他の目的および長所によれば、本発明は、ソー
ス・コード・ライブラリを使用するソフトウェア製品の作成のためのソース・コ
ード・ライブラリを管理するソフトウェア開発システムで実現される。本発明は
、システム設計者が情報の収集をサポートするのを容易にし、可能にするように
構成されたソース・コード・ファイル・システムから大量の情報を収集する。収
集された情報は、さまざまな用途を有するが、その１つが、開発中の製品を構成
することである。製品構成には、最終製品イメージに組み込まれるソース・コー
ド・ライブラリ部分の選択が含まれる。構成は、作成される製品のタイプについ
て自動化されると同時に、完全でコヒーレントな製品を作成するためにサブルー
チンを持ち込むことによってコード依存性を満足することに関して自動化される
。システム設計者は、適用され、開発中の製品に組み込まれるソース・コードの
ビューを提示され、本発明によってサポートされる単純化されたカスタマイズ機
能を与えられる。提供されるカスタマイズ技法は、アップグレードおよび保守を
介して製品の寿命にわたって保守可能である。

【００１５】 製品構成は、製品ビルド処理に渡され、これによって、コンパイルおよびオブ
ジェクト作成に獲得された製品の知識を利用することが可能になる。構成データ
は、コード・ツリーに追加される動的に作成されるファイルで定義される式によ
ってコンパイル処理に渡される。プリプロセッサ・マクロが、サイズ最適化また
はフロー制御のいずれかのために、これらの式を展開して利用する。たとえば、
オプションのプロシージャ呼出しを、作成されるファイルで供給される式の値に
応じて、コンパイル・インまたはコンパイル・アウトすることができる。この式
の値は、呼び出されるプロシージャが製品構成の一部であるかどうかに基づく。
製品構成では、最終製品イメージにコンパイルされる特定のファイルが判定され
る。本発明の好ましい実施態様では、Ｕｎｉｘ（登録商標）スタイルのメイクフ
ァイルが、製品構成に基づいて動的に生成される。この処理では、検索オブジェ
クト・ライブラリの使用が置換され、作成されたすべてのオブジェクト・ライブ
ラリがロード・ライブラリになる。また、本発明では、コンパイル処理を介して
、本発明の製品リンカに情報を渡す。この製品リンカは、普通のアドレス・リン
ク以外に、追加のカスタマイズ・サポート、リソース最適化、実行配置管理、お
よび製品検証をサポートすることができる。

【００１６】 本発明の一部として、ソース・コード・ファイルが、ディレクトリ階層内に配
置される。異なるサブディレクトリが、異なるソフトウェア「コンポーネント」
に対応することができる。ディレクトリ階層内の各「コンポーネント」は、真の
ソフトウェア・コンポーネントであれ、特定のハードウェア・デバイスの必要を
サポートするソフトウェアを意味する「ハードウェア」コンポーネントであれ、
下位のサブディレクトリに保管される１つまたは複数の「機能」によってさらに
定義することができ、その結果、１つまたは複数の機能が各コンポーネントを構
成することができ、さらに下位のサブディレクトリに保管される「サブ機能」も
設けることができる。１つまたは複数のソース・コード・ファイルを、各機能サ
ブディレクトリに置くことができる。各コンポーネントおよび各機能を、さらに
、情報ファイルによって記述することができ、この情報ファイルは、それに対応
するサブディレクトリ内に配置され、機能が意図されたプラットホームのタイプ
（サーバ、ノートブックなど）、それがどのクラスに割り当てられるかなどを定
義する。

【００１７】 本発明の好ましい実施態様では、ソース・コード・ファイルが、特別なプリプ
ロセッサ・マクロに頼って、各外部プロシージャを定義し、それをパブリック（
コンポーネント間で呼出し可能）またはプライベート（１つのコンポーネント内
の親または兄弟だけによって呼出し可能）として分類する。そのような外部プロ
シージャへの呼出しのそれぞれも、特別なマクロ・ルーチンによって行われ、そ
のような呼出しを含む各ソース・ファイルで、プロシージャが、別の特別なマク
ロ・ルーチンへの呼出しを用いて、パブリックにまたはプライベートに参照され
ていることを宣言する。この特別なマクロ・ルーチンは、とりわけ、プログラム
・リビジョン番号およびプログラム・クラス指定を渡すことができる。特別なマ
クロは、パブリックおよびプライベートの「インクルード」ファイルを定義する
ことと、それらに対する参照を宣言することにも使用することができる。さらに
、特別なマクロを使用して、リストを作成し、そのようなリストを形成し、別の
ソース・コード・コンポーネントから引き出されたエントリを定義し、かつ、リ
スト・エントリのソート判断基準を指定することができる。

【００１８】 コンポーネント情報ファイルおよび機能情報ファイルが、スキャンされ、その
内容が、特別なデータベースに保管される。これらのファイルは、コンポーネン
トまたは機能を特定のクラスに関連させることができ、コンポーネントが適当ま
たは必須であるプラットフォームのタイプ（デスクトップ、ポータブル、サーバ
など）を指定することができる。各機能に割り当てられたソース・コード・ファ
イルも、スキャンされ、クラスおよびバージョン番号などの特別なマクロに関連
するパラメータも、各機能のディレクトリ・アドレスと共にデータベースに入力
される。このデータベースはソース・コード・ライブラリの完全な記述を保持す
る。そのライブラリには、使用可能なコンポーネント、各コンポーネントが提供
する機能、後で一緒にリンクできるようにするための機能をクラス分けする形、
および特定のプラットフォーム・タイプ（ポータブル、サーバなど）に含まれる
コンポーネントと機能を選択するルールが含まれている。各機能の情報には、各
機能を提供するためにコンパイルされなければならないソース・ファイル、各機
能への外部インターフェース、外部で定義されるサブルーチンおよびオプション
に対する各機能の依存性、および、異なるクラス内の同一の名前が混同されず、
クロスリンクされないようにするクラス割当が含まれる。

【００１９】 本発明を使用するシステム設計者が、プラットフォームのタイプを指定した後
に、指定されたプラットフォームのタイプに必要なすべてのコンポーネントおよ
びすべての機能を含む、そのプラットフォームの構成を指定するのに必要な最小
限の情報がデータベースから抽出される。このプラットフォーム指定によって、
所望のシステム構成を提供するためにコンパイルされリンクされなければならな
いソース・コード・ファイルの予備セットが識別される。本発明のマクロのパラ
メータから、各プロシージャ呼出しおよびオプションを正しい定義と関連付ける
のに十分以上の情報が得られる。

【００２０】 本発明は、各プロシージャ呼出しをその定義と関連付け、すべての欠けている
プロシージャを識別する点でリンカのように動作する。しかし、このテスト「リ
ンク」処理は、コンパイルまたはアセンブリとリンクのかなり前に行われ、ライ
ブラリ内で見つかるすべての特別なマクロのパラメータから入手可能なすべての
情報が利用される。これによって、本発明が、プロシージャ名および引数の数の
突合せに加えて、それ以外の判断基準を使用して、プロシージャ呼出しをその定
義に関連付けることができ、プログラムの互換性のないバージョンなどの非互換
インターフェースを使用しているプロシージャ呼出しを識別し、シグナルするこ
とと、クラス指定によるプロシージャ呼出しの間の区別が可能になる。

【００２１】 本発明は、コンパイルまたはアセンブリの前に、現在の構成内の問題およびエ
ラーをすばやく識別し、設計者がソース・コード・ファイルを選択し、編集する
ことによって問題をすばやく突き止め、修正できるようにするビジュアル・イン
ターフェースを提供する。同一のビジュアル・インターフェースを用いると、設
計者が、必要に応じて構成を調整するために、マウス・ボタンのクリックでコン
ポーネントまたは機能を追加するか除去することができ、ソース・ファイル選択
を追加またはオーバーライドすることもできるようになる。

【００２２】 設計者は、有効な構成を選択した後に、構成された製品をビルドするように本
発明に指示することができる。本発明は、構成データによって指定されたソース
・ファイルだけをコンパイルまたはアセンブルし、各機能を別々にリンクして、
コンポーネント内のプライベート外部参照を解決し、クラス指定を特定のアドレ
スに変換して、パブリック外部参照の曖昧さを解決し、これによって、各コンポ
ーネントのリンクされた実行可能ファイルを作る。最後に、別々のコンポーネン
ト実行可能ファイルを一緒に最終的な統合された製品にリンクすることができる
特別な製品コンポーネント・リンカが、第２ステージ・リンカとして呼び出され
る。各パブリック・プロシージャ呼出しは、それが参照するパブリック・プロシ
ージャのアドレスを用いてフィックス・アップされる。本発明のリスト・マクロ
によって定義されたリストが、集められ、ソートされ、それが定義されたコード
・セグメントに保管される。

【００２３】 製品コンポーネント・リンカは、マクロに関連するデータ、好ましい実施態様
では、コンポーネント・リンカによって読み取られ、破棄される特別なコード・
セグメント内でコンポーネント・リンカに渡されるデータによって制御され、指
示される。さまざまなオプションおよびプロシージャ呼出しとプロシージャ・エ
ントリ・ポイントの間のリンクの解決（ｓｏｌｕｔｉｏｎ）も、好ましい実施態
様では、自動的に生成される特別な「インクルード（ｉｎｃｌｕｄｅ）」ファイ
ルによって制御される。このインクルード・ファイルは、各マクロが所与のプロ
シージャ呼出しステートメントの再定義、リダイレクトまたは省略を行えるよう
にし、各オプションのスコープを制御し、かつビジュアル・インターフェースに
よって設計者がオプション値を調整できるようにする情報を各ソース・コード・
ファイルに渡す。また、ＲＡＭなし（ＲＡＭ−ｌｅｓｓ）環境で行われるプログ
ラム呼出しは、リターン・アドレス記憶に自動的にレジスタを使用し、ＲＯＭコ
ード内で、プロシージャの「リターン」命令をインターセプトするためにダミー
・スタックとレジスタによって制御されるリターン・ジャンプを自動的に提供す
るマクロを介して達成することができる。

【００２４】 本発明の他の目的、特徴、および長所は、図面および以下の好ましい実施形態
の詳細な説明で明白になる。本発明の特徴を表す新規性の特徴は、本明細書に添
付され、その一部を形成する請求項で具体的に指摘される。

【００２５】 （発明の詳細な説明） 本発明の好ましい実施形態は、さまざまな異なるプロセッサ、バス、および周
辺機器を有するポータブル機、デスクトップ機、およびサーバのＲＯＭ ＢＩＯ
Ｓコード・イメージを開発するために、コードの共有ライブラリが多数のベンダ
によって使用される、ＩＢＭ互換ＰＣ ＲＯＭコード・イメージ・ソフトウェア
開発環境での使用に最適化される。本発明は、普通の、修正されないアセンブラ
、コンパイラ、およびリンカならびに標準的なＵＮＩＸ（登録商標）スタイルの
メイク・ユーティリティを使用して開発された。さらに、特別な製品コンポーネ
ント・リンカ３６００（図３６）が、本発明と共に使用するために開発された。
コンポーネント・リンカ３６００は、多くの形態で、別々にコンパイルされ、リ
ンクされた＊．ｅｘｅファイルを、ＲＯＭに格納するのに適する単一の統合され
たコード・イメージに組み合わせるための普通のリンカである。それがこの目的
に使用される従来のツールと異なる形を、下で指摘する。

【００２６】 本発明が、ＲＯＭ ＢＩＯＳイメージの開発を超えて、すべてのタイプの組込
みシステムならびにソフトウェア開発全般への適用可能性を有することが企図さ
れている。より一般的な特徴において、本発明は、ソフトウェア・コンポーネン
トと機能（ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔ ａｎｄ ｆｅａｔｕｒｅ）
を、管理し、選択し、特定のクライアントの特殊な要件に合わせて変更する必要
があるすべてのソフトウェア開発環境に適用可能である。

【００２７】 普通のコンパイラ、アセンブラ、およびリンカが、特別なファイル・プリプロ
セッサなしで本発明の好ましい実施形態に使用されるので、また、本発明（その
好ましい実施形態で）の一部のステップを、そのようなコンパイラおよびアセン
ブラの中から実行させることが望ましく、便利であり、効率的なので、これらの
標準コンポーネントの実行を変更する方法が必要であった。したがって、本発明
の好ましい実施形態では、「ＣＡＬＬ」または「ＰＲＯＣ」または「ＩＮＣＬＵ
ＤＥ」または類似物などの普通のプログラミング・コマンドが普通に現れる、ソ
ース・コード内の多くの点に、特別に定義されたマクロを挿入することが企図さ
れている。これらの特別なマクロは、本発明のより全般的な概要の説明に続いて
、下の本明細書の末尾で詳細に説明する。しかし、そのような特別なマクロの一
部またはすべての使用の必要なしで本発明の機能性を達成することができるプリ
プロセッサを使用することまたは修正されたコンパイラおよびアセンブラを使用
することも可能である。結局、特別なマクロの使用を介して本発明の好ましい実
施形態で達成される結果は、単に、「ＣＡＬＬ」および「ＰＲＯＣ」および「Ｉ
ＮＣＬＵＤＥ」などのコマンドに対して、本発明がプリプロセッサまたはコンパ
イラおよびアセンブラにこれらのコマンドと置換されるマクロに応答させるのと
実質的に同一の形でプリプロセッサまたはコンパイラおよびアセンブラに応答さ
せることによって、ソース・コード・ファイルの作成者に特別なマクロを使用さ
せずに達成することができる。本発明は、その範囲に含まれるものとしてそのよ
うな設計の変形を含む。

【００２８】 さらに、本発明の好ましい実施形態では、特別なマクロによって定義され、作
成される特別なコード・セグメントに、製品コンポーネント・リンカを制御する
データが配置されるが、これは、セグメント化が他の目的にも多量に使用される
ＩＢＭ ＰＣ環境に特に適する技法でもある。やはり、このデータ（リストの定
義および内容など）を多数のソース・コード・ファイルから、たとえば処理のは
るかに早い段階で集め、このデータをコンポーネント・リンカまたはその同等物
に渡して、本発明の目標を達成する、他の同等の方法を、簡単に提供することが
できる。

【００２９】 本発明の好ましい実施形態であるプログラム開発システム１００の概要を、図
１に示す。図１では、システムの諸部分を構成する主要なソフトウェア・ルーチ
ンと、それらがどのように互いに依り、関係するかが強調されている。

【００３０】 システム１００の中心に、統合開発環境１０２があり、統合開発環境１０２に
は、図２に機能を示されているユーザ・インターフェース２００が含まれる。ユ
ーザ・インターフェース自体は、図３３Ａから３３Ｆに示されている。図３３Ａ
を参照すると、設計者は、ソース・コード・ライブラリの論理ビュー（図示）ま
たはディレクトリ−サブディレクトリ・ビューを見ることができる第１ウィンド
ウ（左側）を提示される。「論理ビュー」は、編成されるコード・ライブラリの
ユーザ・ビューであり、コード・ライブラリのコンポーネントおよび機能が、ま
ずクラスによって、次にコンポーネントによって、次に機能によって、次にサブ
機能によってなど、階層的に表示され、各個々のソース・コード・ファイルが、
対応するコンポーネント、機能、およびサブ機能に関連する。

【００３１】 図３３Ａに示されているように、論理ビューには、ルート・ノード３３０８が
含まれ、これは、Ｐｌａｔｆｏｒｍ − Ｄｅｓｋｔｏｐ − ＩＡ３２として
示されている。ルート・ノード３３０８の下の第１レベルに、ＦＤｉｓｋ３３１
０、Ｉｎｔｅｌ３７１ａｂ（ＰＩＩＸ４）３３１４、ＰＯＳＴ ｓｅｒｖｉｃｅ
ｓ３３０６などの一連のコンポーネントがある。コンポーネントのそれぞれの下
のレベルには、１つまたは複数の機能がある場合がある。たとえば、図３３Ａで
は、ＰＯＳＴ ｓｅｒｖｉｃｅｓコンポーネント３３０６に、Ｄｅｃｏｍｐｒｅ
ｓｓ Ｍａｎａｇｅｒ３３０４、Ｍｅｍｏｒｙ Ｍａｎａｇｅｒ３３０７、およ
びＰＯＳＴ Ｄｉｓｐａｔｃｈｅｒ３３０９などの複数の機能が含まれる。コン
ポーネントの真下のレベルにある以外に、機能は、親機能に対する子機能である
サブ機能として、より低いレベルに表示される場合もある。図３３Ａでは、ＬＺ
ＩＮＴ機能３３１１が、Ｄｅｃｏｍｐｒｅｓｓ Ｍａｎａｇｅｒ機能３３０４に
対するサブ機能である。

【００３２】 以下では、用語「オブジェクト」を使用して、「コンポーネント（ｃｏｍｐｏ
ｎｅｎｔ）」、「機能（ｆｅａｔｕｒｅ）」、または「サブ機能（ｓｕｂｆｅａ
ｔｕｒｅ）」を包括的に意味する（本明細書でのこの用語「オブジェクト」の特
別な使用法を、オブジェクト指向プログラミングの分野の用語「オブジェクト」
に割り当てられる全く異なる意味と混同してはならない）。しかし、クラスによ
って副分割されたコードを有する「論理ビュー」（図３３Ａの、コンポーネント
３３０６のクラス指定「ｐｏｓｔ」３３２１および機能Ｄｅｃｏｍｐｒｅｓｓ
Ｍａｎａｇｅｒ３３０４のクラス指定「ｄｅｃｏｍｐｍｇｒ」３３２３に留意さ
れたい）は、単なるユーザ・ビューを超えている。ソース・コード・ファイルで
、インクルード・ファイル、プロシージャ、オプションなどの外部の名前に対す
る参照が行われる時に、クラス指定によって、普通のソフトウェア開発システム
で使用される、これらの正確なディレクトリ／サブディレクトリ・アドレスを置
換することができ、したがって、プログラマが、外部プロシージャまたはインク
ルードされたファイルがどこにあるかを正確に意識する必要がなく、外部プロシ
ージャを含むソース・コード・ファイルが割り当てられるクラスだけにかかわれ
ばよい。

【００３３】 図２に、ユーザ・インターフェース２００によって実行される主な機能および
ユーザ・インターフェース２００によって提供されるビューをリストする。設計
者は、キーボードまたはマウス２０２を使用して、ファイルまたはディレクトリ
の修正３０２（図３）、有効な構成からの製品のビルド３０６、ビルドにフォー
ス・イン（ｆｏｒｃｅ ｉｎ）またはフォース・アウト（ｆｏｒｃｅ ｏｕｔ）
することによる機能のカスタマイズ３０４、コンポーネント・ソース・コード・
ライブラリからのコードに追加してまたはそれに代わるカスタム・コードの指定
（ファイル・オーバーライド）３０４、およびオプション値のカスタマイズまた
は変更３０４を行うことができる。更新されたユーザ・ビュー２０４は、これら
の変更の結果として、コンポーネントおよび機能ツリー（図３３Ａの左側）を表
示し：コンポーネントおよび機能が、ビルドの中（太字）または外（細字）とし
て明瞭にマークされ（図３３Ａ）；コンポーネントおよび機能が、設計者がそれ
らをビルドにフォース・イン（チェックを用いてマーク）またはフォース・アウ
ト（「禁止」の斜線が入った円を用いてマーク）し、デフォルト構成をオーバー
ライドした場合に明瞭にマークされ（図３３Ｄ）；元のソース・ファイルが示さ
れ、それに加えて、カスタム・ファイル３３３２およびオーバーライド・ファイ
ル３３２６が明瞭にマークされ（図３３Ｃ）；依存性３３２５および３３２７が
、個別にリストされ、アイコンに縮小可能であり（図３３Ｂ）；インターフェー
ス宣言３３２９（図３３Ｂ）、オプション宣言３３３６（図３３Ｅ）が表示可能
であり；機能／ファイルのエラーおよび警告が、３３１８、３３２０、３３２２
、３３２４、および３３２５に明瞭に示されている（図３３Ｂ）。

【００３４】 ユーザ・インターフェース２００は、設計者が、その概要ビューを図３に示さ
れたコマンド・エクスキュータ（ｅｘｅｃｕｔｏｒ）ルーチン３００を介してコ
マンドを発行できるようにする。図３および以下の類似するすべての図面で、ル
ーチン３００のコンポーネントを含んでいる大きい長方形の境界に重なる長方形
に、ルーチンの１つまたは複数のエントリ・ポイント（設計者または呼出し側ル
ーチンによって発行される可能性がある１つまたは複数のコマンド）が含まれる
。

【００３５】 設計者は、ソース・コード・ファイルの更新または修正、新しいディレクトリ
へのファイルの移動、またはシステムのディレクトリ構造の変更を望む場合に、
図３３Ａに示されたユーザ・インターフェースを使用してそれを行う。たとえば
、ソース・コード・ファイルを改訂するために、設計者は、マウスおよびポイン
タを使用して、ファイルの名前３３２６（図３３Ｃ）をクリックし、「Ｏｐｅｎ
」を選択する。ファイルが、編集可能ウィンドウ（図３３Ａの右半分）に表示さ
れ、設計者は、このウィンドウでソース・コード・ファイルを再検討し、任意選
択として修正することができる（図５Ａのステップ５０２）。設計者は、作業を
終えた時に、従来の形でウィンドウを閉じ、修正を「保存」する。その後、コマ
ンド・エクスキュータ３００が自動的に呼び出されて、図３の３０２から始まる
、図５Ａに流れ図形式でも示されているステップを実行する。まず、図３、４、
および５Ａのステップ４０２で、データベース更新ルーチン４００（図４）を呼
び出して、ファイルが変更されたと仮定してファイルをスキャンする（図４のス
テップ４０４、４０６、および４０８）。ルーチン４００は、ソースコードに存
在する特別なマクロから、および図１８（ソース・ライブラリ・データベース１
８００）の１８２６から１８３０に示されているように、各ソース・コード・フ
ァイルの内部名、エントリ・ポイント、およびエグジットを定義するコンポーネ
ントおよび機能情報ファイル内のコマンドから、情報を収集する（図４および２
７のステップ２７００）。収集される情報には、たとえば「ＴＩＭＥＲ」クラス
・プロシージャを「ＤＭＡ」クラス・プロシージャと区別し、その結果、同一の
プロシージャ名が混同されない（たとえば「ＴＩＭＥＲ．ＲＥＳＥＴ」を「ＤＭ
Ａ．ＲＥＳＥＴ」と混同することはできない）ようにする、各プロシージャ呼出
しに割り当てられる「クラス」；非互換バージョンの検査に後に使用するための
、「３．２」などのバージョン番号；および類似する情報が含まれる。この情報
のすべてが、データ・アクセス・ルーチン６００の書込ＡＰＩルーチン６０２（
図６）によってデータベース１８００（図６および１８）に格納される。

【００３６】 次に、ＲＡＭ内で構成状況データ１９００を維持するコンフィギュレータ（ｃ
ｏｎｆｉｇｕｒａｔｏｒ）ルーチン７００（図７）が、エントリ７０４で呼び出
されて、データベース１８００を使用して、製品構成状況データ１９００を更新
し、その後、選択されたプラットフォーム・タイプ（サーバ、デスクトップなど
）、満足する必要がある依存性（オプション、関数の呼出し、ファイル・インク
ルードなど）などに応じて、どのオブジェクト（コンポーネントおよび機能）を
含め、どのオブジェクトを除外するか、どのオブジェクトをどのデフォルト値を
用いて設計者オプションでメイクするかを再判定することによって、ビルドする
製品を構成する３０００（図３０）。最後に、ステップ２０４（図３、５Ａ、お
よび７）で、ルーチンＵＩビュー更新（図２）を呼び出して、図３３Ａの左側の
ウィンドウ内のソフトウェア・システムの論理ビューを再生成して、システムの
新しい状態を設計者と共有し、設計者が、デフォルト・オブジェクト選択を変更
する（図３３Ｄのメニュー３３３４を参照されたい）か、オプションの値を調整
する（図３３Ｅのメニュー３３３８を参照されたい）ことができるようにする。
この早いつつましい形で、設計者によって行われるすべての変更がすばやく正確
に記録され、ビルドされる製品がそれ相応に再構成され、設計者にこのアクティ
ビティのすべての結果が即座に提示される。

【００３７】 設計者が、たとえば、「ｃａｌｌ」ステートメントをリンクすることができる
外部プロシージャのどれかがライブラリにないことによるなど（これは、たとえ
ば、単純にプロシージャの名前をつづり間違えることによって引き起こされる可
能性がある）、満足することができない依存性のゆえに普通のシステム内の最終
リンカに障害を発生させる可能性があることを行う場合に、図３３Ｂに示されて
いるように、小さい「×」が、トラブルを引き起こした項目の横に表示される。
設計者は、表示されるツリーを単に下にクリックすることによって、たとえば問
題を引き起こした特定の「依存性」（たとえば、図３３Ｂの３３２４に「ｐｉｃ
．ＳｅｎｄＥＯＩ」として示されているクラス「ｐｉｃ」のサブルーチン名「Ｓ
ｅｎｄＥＯＩ」）をすばやく見つけることができる。「ｆｉｎｄ」ユーティリテ
ィを用いて、この参照を含むファイルをすばやく見つけ、オープンし、訂正し、
クローズすることができ、システムは、訂正を反映するように自動的にもう一度
更新され、訂正される（「×」が表示されなくなる）。

【００３８】 図３および５Ｂを参照すると、最終製品をビルドする時に、コマンド・エクス
キュータ・ルーチン３００のエントリ３０６「フル製品ビルド（ｆｕｌｌ ｐｒ
ｏｄｕｃｔ ｂｕｉｌｄ）」が、ユーザ・キーボード／マウス・コマンド２０２
に応答してユーザ・インターフェース２００によって呼び出される。やはり、（
図４の）データベース更新ルーチン４００、エントリ４０２が呼び出されて、今
回はライブラリ全体すなわちソース・コード・ファイル；コンポーネント情報フ
ァイル；および機能情報ファイルのスキャンを実行する。図１５および１７を簡
単に参照すると、「ｃｏｍｐｏｎｅｎｔ．ｉｎｆ」コンポーネント情報ファイル
および「ｆｅａｔｕｒｅ．ｉｎｆ」機能情報ファイルに、オプションの値（たと
えば行１５２８）を定義するビルド・コマンドが含まれ、特定のオブジェクト（
コンポーネントまたは機能）が選択される時を論理的に決定する形式的なルール
（たとえば図１５の行１５１４、１５１６、および１５１８）も含まれる。これ
らのファイルは、対応するコンポーネントおよび／または機能のクラス指定（た
とえば行１５０４）も提供する。このようなクラス指定は、そのようなクラス指
定を含む「ｃｏｍｐｏｎｅｎｔ．ｉｎｆ」ファイルまたは「ｆｅａｔｕｒｅ．ｉ
ｎｆ」ファイルと同一のサブディレクトリに格納されるすべてのソース・コード
・ファイル内のプロシージャおよびラベルに自動的に適用される。これによって
、たとえば、個々の呼出し側ソース・コード・ファイルが、呼び出されるプロシ
ージャのソース・コード・ファイルへのソース・コード・ライブラリ・ツリーを
介する実際のパスを指定せずに、「パス」であるかのようにクラスを指定するプ
ロシージャへの外部呼出し（「ＴＩＭＥＲ」がクラスであり、「ＲＥＳＥＴ」が
プロシージャ名である場合の「ＴＩＭＥＲ．ＲＥＳＥＴ」などの「クラス・パス
」指定）を正しく見つけ、リンク・アップすることが可能になる。このクラス指
定では、オブジェクトが、ライブラリ内容の「ディレクトリ／サブディレクトリ
」ビューではなくユーザの「論理」ビューでどのように編成されるかも判定され
る（図３３Ａ）。どのサブルーチンまたはプロシージャ呼出しがどのソース・コ
ード・ファイルのどのサブルーチンまたはプロシージャにリンクされるかがクラ
スによって判定されることに加えて、依存性は必ずクラスに対して指定されるの
で、クラス指定によって、依存性によるすべてのタイプの外部参照が満足される
時に、必ず他の類似するリンクも指定される。したがって、同一の関数名および
プロシージャ名、および他の名前（たとえばインクルード・ファイル名）を、混
乱または誤リンクを引き起こさずに、異なるクラスに割り当てられる機能および
オブジェクトに使用することができる。クラス指定によって、ファイルおよびプ
ロシージャが、コンポーネント・ソース・コード・ライブラリ・ファイル・ディ
レクトリ・ツリー内のどこに実際に格納されているかに無関係に、インクルード
・ファイルおよびプロシージャを見つけることが可能になる。たとえば、アセン
ブルまたはコンパイルの前に、インクルード・ファイル・パス（またはアドレス
）が、ユーザの介入またはそのインクルード・ファイルが実際に格納されている
場所の知識なしに、自動的に生成され、挿入される。

【００３９】 次に、データベース１８００（図６）を更新する（図４、５Ｂ、および６のス
テップ６０２）。その後、コンフィギュレータ７００をもう一度呼び出して、製
品構成状態データを改訂し（ステップ７０６）；変更が行われる場合には、ルー
チンＵＩＵＰＤＡＴＥビュー更新２０４（図２）を呼び出して、ユーザのビュー
を更新し；赤い「×」が現れる場合（図３３Ｂ）には、製品ビルドをキャンセル
する。

【００４０】 図７で、コンフィギュレータが、ファイル「ｐｌａｔｆｏｒｍ．ｃｆｇ」から
取り出される製品構成データ２１００を用いて構成を開始することに留意された
い。図２２を参照すると、この製品構成ファイルでは、ＰＬＡＴＦＯＲＭＴＹＰ
Ｅ２２０１（サーバ、デスクトップなどおよび特定のアーキテクチャ）、システ
ム・オプション値２２０２、含まれるまたは含まれない機能２２１２、インクル
ードされる追加ファイル２２１５、置換されるファイル２２１６（オーバーライ
ドされる）、オプション値２２１８から２２２０、および類似物などが指定され
る。この情報のすべてが、ユーザ・インターフェースから来るものであり、その
すべてがユーザの下で作成される。単純な質問ルーチン（図示せず）を使用して
、プラットフォーム・タイプ、システム・アーキテクチャ、および他のそのよう
な基本的なことを判定するための単純な質問を設計者に問うことによって、新し
い構成を作成することができる。このファイルに含まれる残りのデータは、設計
者が自分のオプションを行使して、デフォルトのオブジェクト選択およびオプシ
ョン値を、やはりユーザ・インターフェースとの対話を介してオーバーライドす
る時に、必ず累積される（もちろん、このファイルを手動で編集することもでき
；プログラム開発システム全体を、ユーザ・インターフェースなしで、図１の右
側に示されたルーチンを１時に１つずつ手動で実行することができる；しかし、
本発明の機能性の多くが、対話的ユーザ・インターフェースにある）。

【００４１】 コンフィギュレータ７００は、次に、データベース１８００に行き、それ自体
に、データベースに含まれるデータのすべてすなわち、ソース・コード・ファイ
ルのスキャンから得られたデータ、具体的にはプログラマが特別なマクロ呼出し
ステートメントに供給したパラメータ（クラス、名前、バージョン番号、および
各タイプのマクロから得られる類似物）と、対応するクラスおよび機能のソース
・コード・ファイルと同一のサブディレクトリを占有する特別なクラス・ファイ
ルおよび機能ファイルから収集されたデータの両方をロードする。この情報のす
べてが組み合わされて、製品構成状態データ１９００と呼ばれる。図１９に示さ
れているように、このデータには、コンポーネント名１９０２、１９０４、およ
び１９０６と、コンポーネントの説明１９０８と、機能名１９１０および１９１
２と、クラス１９１４、ファイル１９１６、定義１９１７、および参照１９１９
などの各機能に関連する情報とが含まれる。これは、ユーザ・ディスプレイの性
質を管理する情報である。各オブジェクト（機能またはコンポーネント）の「ｉ
ｎ」１９２２および１９２６と、「ｏｕｔ」１９２４および１９２８状況が、構
成状態データ内でフラグ・ビットまたは数字によって明瞭にマークされる（図１
９の×の有無によって示される）ことに留意されたい。

【００４２】 プログラム制御は、次に、図８に示された製品メイク・ルーチン８００（図３
および５Ｂのステップ８００）の呼出しに継続する。製品メイク・ルーチンは、
コンフィギュレータ７００を呼び出してすべてのアクティブな（または選択され
た）コンポーネントのリストを提供することによって、ステップ８０２で開始さ
れる。製品メイク・ルーチン８００は、最終的に、図１９に示された選択された
（または「×」がついている）情報のすべてを取り出す。この選択された情報が
、図２０の２０００に示されている。

【００４３】 図８の製品メイク・ルーチン８００に戻って、ステップ９００で、別々のコン
ポーネントごとに、製品メイク・ルーチンが図９Ｂのコンポーネント・ビルド準
備ルーチン９００を呼び出す。このルーチンは、ステップ９０２で、コンフィギ
ュレータ７００およびそのＲＡＭ構成状態データ２１００を呼び出して、コンポ
ーネントのソース・コード・ファイルおよびファイル依存性情報を提供する。次
に、ステップ９５０で、ビルド準備−機能インクルード・ファイル・ルーチン（
図９Ａ）を呼び出して、コンポーネントの機能サブディレクトリのそれぞれを調
べる。ステップ９５２で、コンフィギュレータ７００がもう一度呼び出され、今
回は特定の機能に関する情報を得る。ステップ９５４で、提供された情報を、機
能の「ｆｅａｔｕｒｅ．ｉｎｃ」ファイル（存在する場合に）で見つかった既存
の情報と比較する。情報が変更されている場合（ステップ９５６）には、新しい
「ｆｅａｔｕｒｅ．ｉｎｃ」ファイル２３００を生成し、書き込む。次に、ステ
ップ９６０で、まだ機能がある場合に、ステップ９６２ですべての機能が検査さ
れるまでこの処理を繰り返す。その後、プログラム制御は、ステップ９０４に戻
り、ここで、コンポーネント情報が既存のコンポーネント・メイクファイルの内
容と比較される。ステップ９０６で、変更がある場合に、ステップ９８０で、コ
ンポーネントおよびその機能のすべての、「＊．ｏｂｊ」オブジェクト・ファイ
ルへの正しいコンパイルおよび／またはアセンブルとリンクを管理する新しいコ
ンポーネント・メイクファイル２４００（図２４）を作成する。ビルド準備−コ
ンポーネント・メイクファイル・ルーチン９００は、この形で、完成した製品に
含めるために選択されたコンポーネントごとに１回ずつ、繰り返して呼び出され
る。

【００４４】 下で補足される、簡単な説明として、「ｆｅａｔｕｒｅ．ｉｎｃ」ファイルは
、各機能を実際に定義するソース・コード・ファイルと共に、各機能サブディレ
クトリに置かれる。機能ソース・コード・ファイルのそれぞれに、コマンド「Ｉ
ＮＣＬＵＤＥ ｆｅａｔｕｒｅ．ｉｎｃ」が含まれる。これは、コンパイラまた
はアセンブラに、この機能に関するすべてのソース・コード・ファイルに機能の
「ｆｅａｔｕｒｅ．ｉｎｃ」ファイルを挿入させ、コンパイラまたはアセンブラ
は、クラス参照をファイル・パス参照に変更することなどの作業を実行し、オプ
ションを定義し、選択されていないコンポーネントまたはたとえば特定のコンポ
ーネント名を用いてマークされなければならない（ｃａｌｌステートメントにリ
ンクされるプロシージャが、命名されたコンポーネントの機能内に存在すること
を要求するため）コンポーネントを呼び出す場合に、プロシージャ呼出しをソー
ス・コードから削除させるスイッチをセットする（たとえば図２３を参照された
い。この図では、値ＴＲＵＥが、「Ｄ＿ＴＩＭＥＲ＿ＤＥＬＡＹ」に割り当てら
れて、「ＴＩＭＥＲ＿ＤＥＬＡＹ」関数への関数呼出しがソース・コードに含ま
れるようになる）ことができる。同様に、プロシージャ・エントリ・ポイントを
、「ｏｖｅｒｒｉｄｅ」とマークして、他のソース・コード・ファイル内の同一
のプロシージャ名に優先してそれを選択させることができる。自動的に生成され
る「ｆｅａｔｕｒｅ．ｉｎｃ」ファイルの機構を介して、そのようなユーザ・オ
プション機構のすべてを、ソース・コード・ファイル自体を編集または変更する
必要なしに、システム設計者がグラフィカル・ユーザ・インターフェースから調
整することができる。これによって、システム設計者に、最小限の労力で、完成
した製品の構成に対する前例のない制御が与えられる。

【００４５】 すべてのコンポーネントを処理した後に、プログラム制御は製品メイク・ルー
チン（図８）に戻り、ステップ９０８で、製品メイクファイル２５００が作成さ
れる。この製品メイクファイル２５００には、コンピュータの焦点をさまざまな
コンポーネント・サブディレクトリに切り換え、各サブディレクトリ内で見つか
ったコンポーネント・メイクファイル２４００をコンピュータに実行させ、これ
によって各オブジェクトのオブジェクト・コード・モジュールをビルドさせるデ
ィレクティブが含まれる。その後、製品コンポーネント・リンカ３６００を呼び
出して、コンポーネント・オブジェクト・コード・ファイル１１０４（図１１）
のすべてを、一緒に完成した製品１１０６（図１１）にリンクする。

【００４６】 次に、図８のステップ１０００で、標準Ｕｎｉｘ「ｍａｋｅ」ユーティリティ
を呼び出して、上で説明したコンポーネント・メイクファイル２４００および製
品メイクファイル２５００の制御の下で製品をビルドする。この処理の概要を図
１０に示す。ステップ１００２で、コンポーネントのサブディレクトリを選択す
る（ステップ１００６）コマンドをマスタ・メイクファイルから読み取る。ｍａ
ｋｅユーティリティは、製品メイクファイル２５００によって管理されるが、そ
れ自体を呼び出して、コンポーネント・サブディレクトリ内で見つかったコンポ
ーネント・メイクファイル２４００を処理する。これによって、ステップ１００
８から１０１６が実行される。ステップ１００８で、コンポーネント・メイクフ
ァイル２４００から、機能ソース・コード・ファイルのコンパイル１０１０、ア
センブル１０１２、またはリンク１０１４を呼び出すコマンドを読み取る。この
処理はすべてのコマンドが実行される（ステップ１０１６）まで繰り返して継続
される。これによって、ビルドされた製品コンポーネント・ファイル１１０４が
作られ、製品コンポーネント・ファイル１１０４には、製品コンポーネント・リ
ンカ３６００が後に、完成した統一された製品に１つまたは複数の別々にリンク
された実行可能オブジェクト・コード・ファイルをパッチするのに使用する「フ
ィックスアップ」データを含む特別なセグメントも含まれる（他の特別なセグメ
ントに、リスト要素などを含めることができる）。ｍａｋｅユーティリティは、
１０１８で、製品メイクファイル２５００にまだコマンドがあるかどうかを調べ
、このファイル２５００からのコマンドの読取を継続し、真ぐ上で説明したよう
に、追加のコンポーネント・サブディレクトリを選択し、各追加のコンポーネン
トに関連するメイクファイル内で見つかったコンポーネント・メイク・コマンド
を実行するためにそれ自体を呼び出し、最終的にすべてのコンポーネント・ソー
ス・コード・ファイルが、コンパイルまたはアセンブルされ、リンクされるまで
これを継続する。

【００４７】 ステップ１００４で、ｍａｋｅユーティリティは、最終的に製品コンポーネン
ト・リンカ命令（図２５の２５２８および２５３０）に達するが、この命令は、
製品コンポーネント・リンカ３６００に、別々にリンクされたコンポーネント実
行可能ファイルのすべてを組み合わせて、単一のコード・イメージにマージさせ
る。この際に、アドレスは、クラス参照および名前参照のすべてが絶対イメージ
・アドレスに置換され、ＲＯＭベースの完成した製品１１０６への組込みの準備
ができるようにフィックス・アップされる。

【００４８】 図３を参照すると、複数の他のユーザ・コマンドが使用可能である。エントリ
３０４で、設計者が、コンフィギュレータ７００を呼び出して製品構成を変更す
ることによって機能をフォース・インまたはフォース・アウトすることができる
。これらの変更は、プロジェクト構成データ・ファイル２１００「ｐｒｏｊｅｃ
ｔ．ｃｆｇ」内で反映され、保管される。オプション値を同一の形で変更するこ
とができ、完成した製品の製造に含まれることを指定されたファイルを、設計者
によって指定される他のファイルを用いてオーバーライドし、置換することがで
きる。

【００４９】 もう１つのオプションが、エントリ３０８のクイック製品ビルドまたは単一コ
ンポーネントまたは単一ファイル・ビルドであり、ここでは、ステップ４０２お
よび７０６のツリー・スキャンおよびコンフィギュレータが迂回される。新規ソ
ース・ツリー・エントリ３１２は、ソース・コード・ライブラリ・ツリーが、前
に一度も処理されてない時に使用され、これによって、既存の特別なファイルを
訂正する必要があるかどうかを検査する図９Ａおよび９Ｂのステップ９５６およ
び９０４などのステップの実行が不要になる（そのようなファイルが存在しない
可能性が高いので）。ステップ４０２で、ツリー全体のスキャン（図４）を呼び
出す。その後、コンフィギュレータ７００への製品構成エントリ７０２に進み、
ステップ６０４で、データベース１８００（図６）内のデータにアクセスするた
めに呼び出し、その後、ステップ３０００で製品を構成する（詳細については図
３０を参照されたい）。ステップ２０４（図２）で、設計者のためにレポートを
生成し、製品構成状態データ１９００をディスク・ストレージに書き出す。

【００５０】 マクロは、本明細書の末尾付近で詳細に説明する。その機能の概要を、ここで
説明する。

【００５１】 プログラム開発システム１００は参照と宣言の間の依存性を解決するのに有用
である。プログラム開発システム１００がこれらの依存性を解決できる方法の１
つがマクロの使用によるものである。たとえば、同一の名前を有する２つのルー
チンが存在し、この共通の名前を有するルーチンが参照されている状況で、依存
性を解決するのにマクロを使用することができる。そのような状況は、複数の同
一のコンポーネントがシステム内で使用され、各コンポーネントが同一のルーチ
ン名を有する時に発生する可能性がある。

【００５２】 この問題を克服するために、コード実行を分岐させるためのマクロ、ＥＸＴＪ
ＭＰおよびＥＸＴＣＡＬＬが使用される。これらのマクロは、ファイル内で、Ｐ
ＢＵＥＸＴパブリック外部宣言マクロの後になければならない。ＥＸＴＪＭＰお
よびＥＸＴＣＡＬＬは、あるコンポーネントのルーチンから別のコンポーネント
内のルーチンに分岐するのに使用されるマクロである。両方のマクロが、ＥＸＴ
ＪＭＰまたはＥＸＴＣＡＬＬマクロのアドレスと、分岐先のルーチンの名前（ク
ラスとプロシージャ名）をリストした製品コンポーネント・リンカ用の（図３８
に示された外部セグメント３８０２に配置される）フィックスアップ・データを
生成する。フィックスアップ・データは中間ライブラリに格納される。中間ライ
ブラリは外部セグメント３８０２内にある。外部セグメント３８０２は、実際に
フィックスアップを実行する製品コンポーネント・リンカ３６００からアクセス
可能である。ＥＸＴＪＭＰまたはＥＸＴＣＡＬＬマクロによって生成される名前
およびクラスは、デフォルトの名前およびクラスとすることができ；呼出しまた
はジャンプが、ＰＵＢＥＸＴによって代替の名前およびクラスを有すると宣言さ
れる場合に、代替の名前およびクラスとすることができ；呼出しまたはジャンプ
が、ＰＵＢＥＸＴによってオプションであると宣言される場合には、呼出しまた
はジャンプが完全に削除され、フィックスアップ・データが生成されない。「ｆ
ｅａｔｕｒｅ．ｉｎｃ」ファイルの一部として渡され、デフォルト・プロシージ
ャが存在するか否かに基づいて製品メイク・ユーティリティによって計算される
データ・スイッチが、マクロを、デフォルトの名前およびクラスと他の２つのオ
プションの間で切り換える。この形で、デフォルト宛先が存在しない場合にオプ
ションの呼出し宛先を達成することができ、あるいは、デフォルト宛先が存在し
ない場合に呼出しまたはジャンプを自動的に削除することができる。

【００５３】 ＰＵＢＥＸＴマクロ、ＥＸＴＣＡＬＬマクロ、およびＥＸＴＪＭＰマクロのど
れでも、名前によってコンポーネントを指定することができる。その場合に、２
つのコンポーネントに同一のプロシージャ名が含まれる場合に、ＥＸＴＪＭＰマ
クロおよびＥＸＴＣＡＬＬマクロによって生成されるフィックスアップ・データ
にコンポーネント名指定が含まれる。この場合に、製品コンポーネント・リンカ
３６００は、名前を指定されたコンポーネント内に存在するプロシージャへの呼
出しまたはジャンプだけをリンクする。この形で、上で述べた名前の曖昧さを解
決することができる。

【００５４】 ＰＵＢＬＩＣ＿ＰＲＯＣマクロは、コンポーネント内のプロシージャの位置を
示す。このマクロが受け入れる引数の１つが、キー・ワードＩＮＴＥＲＣＥＰＴ
であり、これは、このプロシージャによって生成される「フィックスアップ」デ
ータに追加される。すべてのパブリック・プロシージャ・マクロが、プロシージ
ャの名前（クラスと名前）およびオブジェクト・コード内でのその絶対アドレス
を含むフィックスアップ・データを生成し、このフィックスアップ・データによ
って、プロシージャを含むコンポーネントも識別される。このフィックスアップ
・データはパブリック・セグメント３８０４に置かれる。このパブリック・セグ
メント３８０４から、製品コンポーネント・リンカ３６００がフィックスアップ
・データにアクセスできる。製品コンポーネント・リンカ３６００はデータの実
際のフィックス・アップを行う。

【００５５】 キー・ワードＩＮＴＥＲＣＥＰＴが所与のプロシージャのフィックスアップ・
データに存在し、かつ、同一の名前（名前とクラス）を有する他のプロシージャ
がある場合に、製品コンポーネント・リンカ３６００は、すべてのプロシージャ
呼出し（外部セグメント３８０２内のフィックスアップ・データによって識別さ
れる）を、たとえば同一のクラスに割り当てられ、おそらくは同一のコンポーネ
ント名を有する、他の同一の名前を与えられたプロシージャではなく、ＩＮＴＥ
ＲＣＥＰＴプロシージャを指定されたプロシージャにリンクする。

【００５６】 下記は、マクロおよびシステム開発の、およびマクロを使用する方法およびシ
ステムを設計する方法の、より一般的な議論である。これは、特に「フィックス
アップ」ステップが製品コンポーネント・リンカによって実行されると必ず仮定
されるのではないので、本発明の好ましい実施形態に完全には一致しない。もち
ろん、フィックスアップ・データは、何らかの形の中間ライブラリに格納するこ
とができ、コードのフィックス・アップを他の形で実行することができる（好ま
しい実施形態の説明は段落の始めになる図１１の詳細な説明から再開される）。

【００５７】 ＰＵＢＬＩＣ＿ＰＲＯＣマクロを使用してディスパッチ・ルーチンを宣言する
ことができる。ディスパッチ・ルーチンとは２つの異なるルーチンに分岐するデ
ィスパッチャとして働くルーチンである。ルーチンの名前およびアドレスがフィ
ックスアップ・データとして保管される。このフィックスアップ・データは中間
ライブラリにも格納される。ビルド・ツールは、最終的なバイナリ・イメージを
生成する前に、これらのマクロによって生成されたフィックスアップ・データを
破棄する。

【００５８】 ルーチン名を指定するＥＸＴＣＡＬＬマクロおよびＥＸＴＪＭＰマクロの引数
のほかに、これらのマクロのもう１つの引数で、特定の分岐を解決するのに使用
されるコンポーネント・ライブラリの名前が指定される。特定の分岐を解決する
のに使用されるコンポーネント・ライブラリの名前は、ユーザ・インターフェー
ス２００を介して設計者が指定することができる。設計者は、ユーザ・インター
フェースから情報を得て、どのコンポーネント・ライブラリを指定できるかを判
定することができる。その代わりに、自動化ユーティリティ（ウィザード）が、
共通のルーチンが見つかるコンポーネントを解析し、コンポーネント間の共通ル
ーチンごとにディスパッチ・ルーチンを有するソース・コード・テンプレートを
生成することができる。このウィザードは、共通のルーチンの検索を自動化し、
ディスパッチ・ルーチンのコーディングを単純にすると同時に、コンポーネント
間のデバッグを自動化する方法を提供する。

【００５９】 すべての分岐のアドレス、分岐先のルーチンの名前、およびディスパッチ・ル
ーチンの名前およびアドレスと同様に、指定されたコンポーネント・ライブラリ
に関する情報が中間ライブラリ内にフィックスアップ・データとして格納され、
この情報は、ビルド・ツールが最終バイナリ・イメージを生成する前に破棄され
る。バイナリ・リンカは、中間ライブラリに格納されたこのフィックスアップ・
データのすべてを使用して、分岐命令に正しいコンポーネント・ライブラリから
の正しいルーチンのアドレスをパッチし、これによって依存性を解決する。

【００６０】 これらのマクロを使用して、そのような依存性を解決することによって、既存
のコンポーネント・ルーチンが、それが属するコンポーネントの事前の知識を必
要としなくなる。というのは、ルーチンが、それがコンパイルされコンポーネン
ト・ライブラリにリンクされるコンポーネントによって自動的に区別されるから
である。既存のコンポーネント・ルーチンを、再コンパイルする必要もない。さ
らに、すべてのコンポーネント・ルーチンを単一のコンポーネント・ライブラリ
内にカプセル化し、コンポーネントを介して区別することができ、これによって
、コード・カプセル化が機能強化される。

【００６１】 少なくとも２つのコンポーネントに存在する共通の名前を付けられたルーチン
への参照を解決するのに使用されるこれらのマクロは必須ではない。外部参照（
すなわち分岐）を追跡する方法を使用することができる。使用することができる
他の追跡機構に、たとえば、プリプロセッサ、アセンブラ・キーワードまたはコ
ンパイラ・キーワード、およびカスタム・リンカを含めることができる。同様に
、本発明は、パブリック宣言を追跡するあらゆる方法を使用することができる。
パブリック宣言および宣言の型（すなわち、インターセプトまたは非インターセ
プト）を追跡できるようにするすべての方法を、使用することができる。

【００６２】 マクロを使用できるもう１つの形が、ビルドのオブジェクト内の未解決のコン
パイル参照に対する可能な解決の中から選択することである。オブジェクトの名
前およびその位置がデータベース内で維持される。ファイルシステム・ディレク
トリごとに１つのオブジェクトだけを設けることができ、各オブジェクト・ディ
レクトリに、ＣＯＭＰＮＥＮＴ．ＩＮＦファイルまたはＦＥＡＴＵＲＥ．ＩＮＦ
ファイルが含まれる。そのようなＩＮＦファイルについてファイル・システムを
スキャンすることによるか、ＡＰＩを使用するデータベースの操作を介してのい
ずれかでデータベースを更新することができる。

【００６３】 オブジェクトを明示的に指定することができる。ディレクトリまたはディレク
トリのリストを指定し、それらをオブジェクトについて検索して、順序を判定す
るのではなく、有無を判定することができる。検出は、タイムリーな形で行われ
、自動的に処理することができる。データベースまたは他の記憶手段を使用する
ことができる。

【００６４】 ＩＮＦファイルには、ソフトウェア・プロジェクトをブラウズし、コンパイル
処理を制御するのに使用される属性を含むＡＳＣＩＩテキストが含まれる。さら
に、ＢａｓｅＣｌａｓｓを使用して、２つの機能が同一のインターフェースを有
し、同一の基本的な機能性を提供することを識別する。通常、最終的なソフトウ
ェア製品には、同一のＢａｓｅＣｌａｓｓを有する２つの機能が含まれない。

【００６５】 ビルドは、多数のタイプのターゲット・ハードウェア・プラットフォームに関
するものである可能性があるので、これらのプラットフォームを、ＢａｓｉｃＰ
Ｃ、Ｎｏｔｅｂｏｏｋ、またはｅｍｂｅｄｄｅｄなどの一般的なカテゴリに分類
することが有用である。これらのプラットフォーム・タイプのそれぞれについて
、デフォルト挙動を指定することが可能であり、このデフォルト挙動は設計者が
手動で変更することができる。これらのデフォルト挙動の１つが、「ＯｎＤｅｍ
ａｎｄ」属性であり、これは、あるオブジェクトへの別のオブジェクトによる参
照があり、同一のＢａｓｅＣｌａｓｓを有する別のオブジェクトが、システム設
計者によって明示的にインクルードされておらず、システム設計者が、ハードウ
ェアがＰｌａｔｆｏｒｍＴｙｐｅコマンドでリストされる一般的なカテゴリに含
まれることを指定した場合に、オブジェクトが最終ソフトウェア製品に含まれる
ことを示す。

【００６６】 ＯｎＤｅｍａｎｄ属性は、ソース・ファイル内（別のファイルではなく）に配
置することができる。この属性は、ツリー内ではなく、ある種のマスタ・データ
ベース内にあるものとすることもできる。その代わりに、この属性を、１つまた
は複数のプラットフォーム・タイプ用とするか、ＯｎＤｅｍａｎｄ属性を使用す
べきか否かを判定する際にプラットフォーム・タイプを全く使用しないことがで
きる。ＯｎＤｅｍａｎｄ属性は、任意の数のユーザ指定ソフトウェア・プロジェ
クト属性（プラットフォーム・タイプだけではなく）にリンクすることができ、
どれにもリンクしないこともできる。ＯｎＤｅｍａｎｄ属性は、インターフェー
ス関数自体に（関数レベルの除外のために）移動することもできる。

【００６７】 インターフェース関数（すなわち、オブジェクトの間で呼び出すことができる
関数）は、マクロＰＵＢＬＩＣ＿ＰＲＯＣおよびＰＲＩＶＡＴＥ＿ＰＲＯＣを使
用して宣言される。これらのマクロでは、関数のスコープおよび他の属性情報が
指定される。インターフェース関数を使用するオブジェクトは、関数と同一のフ
ァイル内にあるか、ＰＵＢＥＸＴマクロまたはＰＲＶＥＸＴマクロを使用して関
数のプロトタイプを宣言するかのいずれかでなければならない。実際の関数呼出
しでは、ＥＸＴＣＡＬＬマクロを使用する。コンフィギュレータ７００は、すべ
てのインターフェース関数およびそのような関数へのすべての参照の位置を判定
するために、普通のコンパイル処理が開始される前に、ソース・ファイルをスキ
ャンする。その後、プラットフォーム・タイプおよびシステム設計者からの明示
的コマンドに基づいて、インターフェース関数への参照のリストをインターフェ
ース関数宣言のリストと比較する。宣言がない非オプション参照がある時には、
その参照は未解決とみなされる。

【００６８】 未解決の参照の検出は、マクロを使用せずに行うことができる。コンパイルの
リンク・ステージまでそのような検出を行わないことを含めて、標準的な方法を
使用することができる。ライブラリおよびその属性のリストを使用する、ダイナ
ミック・ロード・ライブラリを用いるレイト・バインディングを使用することも
できる。

【００６９】 この点で、ＯｎＤｅｍａｎｄとしてリストされたすべてのオブジェクトを検査
して、それらを含めることによって１つまたは複数の未解決の参照が解決される
かどうかを調べる。そうである場合には、そのオブジェクトを含める。オブジェ
クトが最終ソフトウェア製品に含まれることの決定は、普通のコンパイルが開始
される前に決定される。これは、コンパイル処理からのオブジェクトのファイル
を含めるか除外するかのいずれかによって達成される。一部のオブジェクトにつ
いて、その中のすべてのファイルが含まれるか除外される。それ以外のオブジェ
クトについて、これが、ファイルごとに行われる。どちらの場合でも、メイクフ
ァイルが修正される。エラー状態は、同一のＢａｓｅＣｌａｓｓを有する２つの
コンポーネントが、ＯｎＤｅｍａｎｄとマークされ、その一方または両方が、未
解決の参照を解決する時に検出される。好ましくはコンパイルの前に行われるが
、オブジェクトを最終メイク製品に含めることの決定を、その代わりに、リンク
・ステージ・バインドまたは実行時バインドを使用して行うことができる。

【００７０】 この、コンパイルの前に参照を解決する方法を用いると、オブジェクトの開発
者がデフォルトで含めなければならないオブジェクトを判定できるようになる。
これによって、エラーの可能性が減り、生産性が高まる。これによって、より高
速のビルドも可能になる。というのは、すべてのオブジェクトおよびすべての依
存性のコンパイル前の知識によって、アセンブルされるファイルの数が正確な最
小値に制限されるからである。

【００７１】 マクロは、参照され宣言されるオブジェクトのバージョン管理に基づいて依存
性を解決するのに使用することもできる。パブリック関数インターフェースの宣
言にＰＵＢＬＩＣ＿ＰＲＯＣマクロが使用される。このマクロのパラメータの１
つが、ｘ．ｙの形のバージョン番号であり、このｘは、メジャー・バージョン番
号、ｙはマイナー・バージョン番号である。

【００７２】 メジャー・バージョン番号の増分は、インターフェースの後のリビジョンを示
し、これは、入力、出力、および／または副作用に関して後方互換性がない。マ
イナー・バージョン番号の増分は、インターフェースの後のリビジョンを示し、
これは、同一のメジャー・バージョン番号とより小さいマイナー・バージョン番
号を有するバージョンのインターフェースとの後方互換性がある。これは、より
小さいマイナー・バージョン番号によって期待される入力および出力のすべてが
サポートされ、同様の副作用を有することを示す。しかし、新しい入力が、新し
い出力および異なる副作用を作る可能性がある。このバージョン管理法式は、非
数値、単一バージョン番号、および一方が現在のバージョン、他方が後方互換性
バージョンである二重バージョン番号を含む、多数の可能な方式の１つにすぎな
い。

【００７３】 ＰＵＢＥＸＴマクロは、関数または配列のいずれかのパブリック・インターフ
ェースへの参照を宣言するのに使用される。パラメータの１つに、呼出し側によ
って期待されるバージョン番号が含まれる。バージョン番号は、ＰＵＢＬＩＣ＿
ＰＲＯＣマクロおよびＬＩＳＴ＿ＣＲＥＡＴＥマクロのバージョン番号に類似す
るフォーマットを有する。呼出し側と呼び出される側のメジャー・バージョン番
号が異なる場合、または呼出し側が呼び出される側より大きいバージョン番号を
有する場合に、警告が生成される。

【００７４】 データベースにアクセスして、「呼び出される側」の位置とそのバージョンを
判定する。データベース内の情報は、ＤＢＵＰＤＡＴＥ（データベース更新）ユ
ーティリティを使用して更新され、このＤＢＵＰＤＡＴＥは、呼び出された時に
、各オブジェクトのすべてのソース・コード・ファイル内の前に説明したマクロ
をスキャンし、インターフェースの名前およびそのバージョンをデータベースに
置く。ＤＢＵＰＤＡＴＥは、ＰＵＢＥＸＴについてスキャンし、呼出し側の位置
およびバージョンをデータベースに記録することによって、これらのインターフ
ェースへの参照も見つける。

【００７５】 その後、各呼出し側についてデータベースを検索して、バージョンが呼び出さ
れる側との互換性を有するかどうかを調べる。バージョンは、呼出し側と呼び出
される側のメジャー・バージョン番号が同一であり、呼び出される側のマイナー
・バージョン番号が呼び出す側のバージョン番号以上である場合に、互換性があ
るとみなされる。この情報は、表示、ファイルに出力などを行うことができ、そ
の結果、設計者が、潜在的な非互換性のすべてについて知らされる。

【００７６】 データベースは必須ではなく、スキャン処理でデータベースを使用する必要が
ない。そうではなくて、バージョン情報を、プリプロセッサまたはコンパイラの
特別なバージョンによって処理される特別なキーワードとしてデータ・プロトタ
イプに追加することができる。たとえば、Ｃ言語では、関数のバージョン番号を
、関数プロトタイプにおける、_ｓｔｙｌｅキーワードとしてエンコードするこ
とができる。

【００７７】 さらに、バージョン番号を呼出し側および呼び出される側にアタッチする正確
な方法はプログラミング言語によって異なる。たとえば、Ｃ言語では、ＭＡＳＭ
マクロが使用される場合に、関数プロトタイプにアタッチすることができる。他
の実施形態では、バージョンを、外部ファイルを使用してアタッチすることがで
きる。バージョン管理は、スタティック変数またはスタティック・データ構造体
にも適用することができる。

【００７８】 入力パラメータのセマンティック変更を追跡する（バグ・フィックス−修正済
みパラメータ定義）ことによって、このバージョン管理を使用して大規模ソフト
ウェア・プロジェクトをより独立にビルドできるようになる。バージョン管理に
よって、コンパイルおよび実行時の前に、ソフトウェア・プロジェクトが機能す
る可能性が高いかどうかに関する改善されたフィードバックも与えられる。バー
ジョン管理によって、エラーを減らすこともできる。というのは、関数の変更が
、バージョン番号を検査することによって簡単に識別可能になるからである。

【００７９】 マクロのもう１つの使用は、第１のルーチンへの呼出しをインターセプトし、
第１ルーチンへの呼出しをインターセプト・ルーチンである第２ルーチンによっ
て置換することである。まず、コード実行を分岐させるのに使用される２つのマ
クロ、ＥＸＴＪＭＰおよびＥＸＴＣＡＬＬを使用する。ＥＸＴＪＭＰおよびＥＸ
ＴＣＡＬＬは、コンポーネントの間でルーチンにジャンプするかルーチンを呼び
出すのに使用されるマクロである。両方のマクロが、すべての呼出しおよびジャ
ンプのアドレスと、呼び出されるルーチンの名前をリストしたフィックスアップ
・データを生成する。このフィックスアップ・データは、中間ライブラリに格納
され、ビルド・ツールが最終バイナリ・イメージを作成する前に破棄される。

【００８０】 別のルーチンへの呼出しをインターセプトするルーチンは、インターセプトさ
れるルーチンと同一の名前を有しなければならない。インターセプト・ルーチン
では、ＰＵＢＬＩＣ＿ＰＲＯＣマクロを使用して、マクロ引数としてＩＮＴＥＲ
ＣＥＰＴキーワードを指定されたインターフェース・ルーチンとしてそれ自体を
宣言する。ＰＵＢＬＩＣ＿ＰＲＯＣマクロは、インターセプト・ルーチンのアド
レス、インターセプト・ルーチンの名前（元のルーチンと同一）、およびこのル
ーチンが別のルーチンのインターセプトに使用されるという属性をリストしたフ
ィックスアップ情報を生成する。やはり、フィックスアップ・データは、中間ラ
イブラリに格納され、ビルド・ツールが最終バイナリ・イメージを作成する前に
破棄される。

【００８１】 中間ライブラリに格納された、生成されたフィックスアップ・データを使用し
て、各分岐を正しくリンクし、最終的なバイナリ・イメージを生成するためにリ
ンク・ユーティリティが使用される。ルーチンがインターセプトされない場合に
は、呼び出されるルーチンのアドレスが、分岐を開始するコンポーネント内の分
岐命令について直接にパッチされる。しかし、インターセプト・ルーチンが存在
する時には、必ず、インターセプト・ルーチンのアドレスが、元の呼び出される
ルーチンの代わりにパッチされる。

【００８２】 インターセプト・ルーチンのアドレスが、元の呼び出されるルーチンの代わり
にパッチされるが、任意選択として、ＥＸＴＪＭＰマクロまたはＥＸＴＣＡＬＬ
マクロを使用して、インターセプト・ルーチン内から元の呼び出されるルーチン
に分岐することができる。リンク・ユーティリティは、中間ライブラリ内のフィ
ックスアップ情報を使用して、分岐命令を元のルーチンに正しくリンクすること
によって、これを実行する。さらに、インターセプト・ルーチンが、元の呼び出
されるルーチンを絶対に呼び出さず、最終バイナリ・イメージ内のコードのどの
部分もそれを参照しない場合に、任意選択として、元の呼び出されるルーチンを
除去することができる。

【００８３】 このインターセプト処理を拡張して、呼び出されるルーチンを参照される変数
に置換することができる。このインターセプト処理は、同一コンポーネント内の
ルーチン間の呼出しもインターセプトできるように拡張することもできる。この
処理を修正して、インターセプト・ルーチン名が、インターセプトされるルーチ
ンすなわち元の呼び出されるルーチンと異なる名前にすることができる。これは
、単に、インターセプト・ルーチンを呼出し側に結合する代替の別の機構を必要
とする。

【００８４】 このインターセプト処理を用いて、呼出しをそのルーチンに直接にリンクさせ
ることができ、間接指定が不要になる。さらに、呼出し側は、潜在的に呼出しを
インターセプトするルーチンについて予測または知る必要がない。呼出し側は、
単に、他のプロシージャとしてそれ自体を宣言する。この処理は、元の呼び出さ
れるルーチンが、絶対に呼び出されず参照もされない場合に、そのルーチンが最
終イメージにあることも必要としない。

【００８５】 最終的なバイナリ・イメージからのインターセプトされるルーチンの除去によ
って、使用されないコードを除去することによるより効率的なスペースの使用が
可能になる。この効率性を拡張して、不要な呼出しを行うコードを除去すること
ができる。１プロジェクトを構成するすべてのソース・ファイルが存在する時に
、スキャンおよび更新ユーティリティが、他のファイル内の宣言を参照する特定
のマクロについて、各プロジェクト・ソース・ファイルをスキャンする。２つの
分岐マクロＥＸＴＣＡＬＬおよびＥＸＴＪＭＰで、すべての参照を宣言するのに
マクロＰＵＢＥＸＴおよびＰＲＶＥＸＴが使用される。スキャン・ユーティリテ
ィは、ＰＵＢＥＸＴおよびＰＲＶＥＸＴマクロについてスキャンする。分岐命令
が参照する（ＰＵＢＥＸＴおよびＰＲＶＥＸＴを介して）宣言の名前が、スキャ
ン・ユーティリティによって、ソース・ファイル名および位置と共にデータベー
スに記録される。

【００８６】 ２つの分岐マクロＥＸＴＣＡＬＬおよびＥＸＴＪＭＰは、２つのＢＩＯＳ外部
宣言マクロの１つすなわちＰＵＢＥＸＴまたはＰＲＶＥＸＴを必要とする。マク
ロは、マクロが分岐宣言への参照を「オプション」として宣言できるようにする
属性フィールドを有する。分岐命令が参照する宣言がオプションであり、かつ宣
言を定義するソース・ファイルがビルド内にない場合に、最終的なバイナリ・イ
メージから不要なコードを除去するために分岐命令はコンパイルされない。

【００８７】 すべての分岐が、異なるファイル内にあるその分岐のパブリック宣言と一致さ
せられる。宣言参照のそれぞれについて、あるフラグが特定の宣言がビルドに存
在するかどうかを示す。プロジェクト・ソース・ファイル内にない、参照される
宣言については、フラグが生成されない。このフラグは、コンパイル中にマクロ
によって選択されるために、インクルード・ファイルに格納される。

【００８８】 ２つの分岐マクロＥＸＴＣＡＬＬおよびＥＸＴＪＭＰは、スキャン・ユーティ
リティによって生成された（インクルード・ファイルを介して渡される）データ
を解釈し、任意選択として、コンパイルに必要な分岐命令を生成する。宣言がプ
ロジェクト内になく、分岐がＰＵＢＥＸＴマクロまたはＰＲＶＥＲＴマクロのい
ずれかを使用してオプションとしてマークされた場合には、分岐コードが生成さ
れない。ＥＸＴＣＡＬＬマクロおよびＥＸＴＪＭＰマクロも、分岐命令の宣言が
解決される場合にコンパイルされる追加コードを挿入する機構を提供する。逆に
、分岐命令の宣言が解決されない場合には、分岐命令に加えて追加のコードを除
去することができる。

【００８９】 この処理を拡張して、分岐されるルーチンを参照されるデータ型に置換するこ
とができる。使用される機構はコード分岐に使用されるものと同一である。さら
に、この処理の実施形態で述べたマクロはその実装に必須ではない。マクロの代
わりに、この処理を、コンパイルの前ではなくプロジェクトが一緒に結合される
時に、宣言について動的にスキャンする事によって、実施することができる。宣
言を宣言し、宣言参照を記録するのに使用されるマクロは、その代わりに、コン
パイラまたはプリプロセッサなどの他のユーティリティによって解釈されるキー
ワードとすることができる。また、上で述べたように、形式的なデータベース以
外の異なる方法を使用して、宣言およびその参照を記録することができる。情報
について構文解析されたモノリシックなファイルを、データ記録の他の方法に加
えて使用することができる。さらに、インクルード・ファイル以外の機構を使用
して、フラグを渡すことができる。

【００９０】 オプションの分岐コードを除去するこの処理を用いると、システムの前の知識
を使用するソース・コンパイルの前にコードの除去が可能になり、コンパイル時
間が減る。宣言自体のほかに宣言参照を除去することは、スタブなしで完了する
。この処理は複数の変換単位にまたがって動作する。

【００９１】 宣言および参照の解決と、バージョン管理の使用をラベルにも適用することが
できる。プロシージャすなわちルーチンと同じように、ＰＵＢＬＩＣ＿ＰＲＯＣ
マクロおよびＰＲＩＶＡＴＥ＿ＰＲＯＣマクロを使用して、各ラベル定義を宣言
する。ＰＵＢＬＩＣ＿ＰＲＯＣマクロまたはＰＲＩＶＡＴＥ＿ＰＲＯＣマクロに
よって定義されたラベルは、パブリックまたはプライベートのいずれかのラベル
参照を解決するのに使用することができる。各ラベル定義に、定義されるラベル
の名前、ラベルの位置、およびラベルのバージョンが含まれる。ＰＵＢＥＸＴマ
クロおよびＰＲＶＥＸＴマクロを使用して、各ラベル参照を宣言する。各ラベル
参照には、参照されるラベルの名前、ラベルの位置、およびラベルのバージョン
が含まれる。

【００９２】 検証ユーティリティを使用して、各ラベル参照を検証する。検証ユーティリテ
ィの機能を、コンパイラまたは統合開発環境などの別のユーティリティと統合す
ることができる。このユーティリティは、各ラベル参照がめいめいのラベル定義
を有することを保証する。その後、このユーティリティは、各ラベルのバージョ
ン情報を比較する。参照されるラベルが存在しない場合、または参照されるラベ
ルが不正なバージョンである場合に、このユーティリティがエラーを報告する。
検証ユーティリティは、すべてのラベル参照を解決した後に、各ラベル参照の解
決状況を報告する。各ラベルの解決状況は、ビルド処理のデバッグを助けるため
に報告することができる。

【００９３】 この処理を用いると、ビルド処理を実行する設計者が、時間のかかるビルド処
理を実行する前に、ビルド関連のラベル解決エラーのすべてをすばやく検出し、
訂正することによって、時間を節約できるようになる。ビルド関連のラベル解決
エラーを検出するために、ソフトウェア製品のコードベースの外部のライブラリ
またはコンポーネントを前にビルドすることも必要でない。

【００９４】 プログラム開発システム１００で、主要なデータ構造体を「リスト」と呼ぶ。
リストは、固定サイズ要素の配列であり、エントリが、すべてのソース・コード
・ファイルによって追加される可能性がある。リストは、ＬＩＳＴ＿ＣＲＥＡＴ
Ｅマクロを使用して１回だけ作成されなければならない。これによって、リスト
の名前と、各リスト・エントリのサイズが指定される。リスト・エントリは、グ
ループに追加される。グループは、ＬＩＳＴ＿ＳＴＡＲＴマクロによって開始さ
れ、ＬＩＳＴ＿ＥＮＤマクロによって終了する。各リスト・エントリに、名前が
割り当てられる。

【００９５】 置換リスト・エントリを含むグループについて、ＬＩＳＴ＿ＳＴＡＲＴマクロ
の余分なパラメータによって、オーバーライド優先順位が指定される。オーバー
ライド優先順位は、グループ内のすべてのリスト・エントリに適用される。ソフ
トウェア・プロジェクトに、同一の名前を有するが異なるオーバーライド優先順
位を有する２つのリスト・エントリが含まれる場合に、より高い優先順位を有す
るリスト・エントリが保存され、他方のリスト・エントリは破棄される。２つの
エントリが同一の名前および優先順位を有することはエラー状態である。

【００９６】 バイナリ・リンカがすべてのリスト・エントリを含む最終リストを作成する。
バイナリ・リンカはすべてのエントリを見つける。同一の名前を有するエントリ
について、バイナリ・リンカはそのオーバーライド優先順位を比較する。最高の
優先順位のエントリが保存され、他のエントリは破棄される。特定のリストに関
するリスト・エントリは、リストおよびそのエントリのアドレスおよびすべての
参照が解決されたと仮定して、シーケンシャルに配置される。

【００９７】 このリスト処理は、スタティックに初期化されるデータ構造体と共に使用する
ことができる。リストは、置換データ構造体を識別できる限り、データ構造体を
作成し初期化する異なるキーワードを使用するか、何も使用しないことができる
。オーバーライド・レベルの数を、単純な１レベルからｎレベルまで変更するこ
とができ、ｎは、１を超える整数である。リストのマージは、通常のリンカまた
はコンパイラによって実行することができる。

【００９８】 リスト処理を使用して、データ構造体を普通に作成することができる。さらに
、複数レベルの置換を行うことができ、これによって、「コア」、「製品ライン
」、および「プラットフォーム」の区別が可能になる。

【００９９】 プログラム開発システム１００は、ビルド内の他のライブラリの存在に基づい
て、ビルドにライブラリを含める機構も提供する。ロード・ライブラリは、ライ
ブラリのコード・セット全体がビルドに含まれるので、従来技術のロード・ライ
ブラリに似た動的にトリガされるロード・ライブラリである。検索ライブラリは
、ビルドに条件的にコードを含める、従来技術の検索ライブラリに似た機構を提
供する、動的にトリガされるロード・ライブラリである。この２タイプのライブ
ラリの間の相違は、使用される参照のタイプにある。

【０１００】 検索ライブラリでは、ビルドにライブラリ・コードを含めるために、「前方」
参照が使用される。たとえば、ライブラリＡが検索ライブラリＢのオブジェクト
に依存する場合に、検索ライブラリＢからのオブジェクト・コードがビルドに含
まれる。その一方で、動的にトリガされるロード・ライブラリでは、「後方」参
照を使用して、ビルドにライブラリ・コードを含める。たとえば、ライブラリＡ
がライブラリＢに対する依存性を有しない場合であっても、ライブラリＢは、ラ
イブラリＡがビルドに含まれる時にビルドに含まれるべきであると宣言する。

【０１０１】 動的にトリガされるロード・ライブラリを実施するには、３つのものすなわち
、構成スクリプト、トリガ・コマンド、およびビルド・スクリプト・ジェネレー
タが必要である。構成スクリプトは、どのモジュールが最終製品に含まれること
を意図されているかを識別するために必要である。これは、単純なメイクファイ
ルとすることができ、あるいは、単純にモジュール名をリストしたカスタム・フ
ァイルとすることもできる。

【０１０２】 「外部トリガ」コマンドは、外部判断基準に基づいてロードされるライブラリ
に関連する。たとえば、特別なファイル（ＭｏｄｕｌｅＹ．ＩＮＦ）を、トリガ
されるコンポーネントに関連付けることができる。このＩＮＦファイルには、た
とえば「ＭｏｄｕｌｅＸ」が含まれている場合に、「ＭｏｄｕｌｅＹ」を最終製
品に含めなければならないことを示す外部トリガ・コマンドが含まれる。この例
のトリガ宣言は、．ＩＮＦファイルで行われるが、トリガ宣言は、ライブラリの
コード内のどこにでも含めることができる。これらの宣言を突き止め、適切に使
用するのはスクリプト・ジェネレータの責任である。

【０１０３】 ビルド・スクリプト・ジェネレータの主な作業は、実行可能製品をビルドする
ためのメイクファイル（または適切なコンパイラ／リンカ・スクリプト）を生成
することである。ジェネレータは、すべての潜在的なライブラリのＩＮＦファイ
ルおよび構成スクリプトを入力として使用する。スクリプト生成フェーズ中に、
ジェネレータは、外部トリガに基づいて、ライブラリのいずれかを最終ビルドに
含めなければならないかどうかを判定する。メイクファイルの使用は、そのよう
なスクリプトを使用するツールの使用を前提とする。しかし、これは必須ではな
く、同一の効果を得る、製造業者のビルド・ツールに置換することができる。

【０１０４】 動的にトリガされるロード・ライブラリを使用することによって、トリガをか
けるモジュール・コードまたはビルド・スクリプトを直接に修正する必要なしに
、製品にライブラリを含める能力がもたらされる。動的にトリガされるロード・
ライブラリの利益は、ライブラリの数およびモジュール間の依存性が増える時に
もみつかる。たとえば、設計者が、４００個の可能な選択肢から、ソフトウェア
・プロジェクト・ビルドに２０個のモジュールを含めることを選択する時に、「
後方」参照されるライブラリが存在するかどうかを知ることは困難である。外部
的にトリガされるロード・ライブラリは、後方参照ライブラリがそれ自体を最終
製品に含めるので、この問題を解決する。

【０１０５】 プログラム開発システム１００で、ユーティリティは、システムのソース・コ
ード・ファイルをスキャンして、パブリック宣言および外部参照を検出し、記録
することができる。パブリック宣言および外部参照は、ソース・コード・ファイ
ル内のスキャン可能なキーワードである。ソース・コード・ライブラリとして使
用されるソース・ファイルのリスト（ビルドに含まれると仮定されるファイルで
はなく）が作成される。

【０１０６】 上で述べたように、あるユーティリティが、ソース・コード内で検出されたパ
ブリック宣言への外部参照を解決することができる。リンカと同様に、このユー
ティリティは、まず、ビルドに含まれるファイル内の外部宣言への参照を見つけ
る。このユーティリティは、ビルドに含まれるファイルと、その後にライブラリ
内のファイルを用いて、これらの解決を試みる。これは、再帰的処理であり；ビ
ルドに持ち込まれるファイルまたはモジュールが、他のファイルまたはモジュー
ルを参照する可能性がある。この解決処理は、ビルドの一部になるソース・コー
ド・ファイルの結果のリストを出力することを必要とする。普通のコンパイルお
よびリンクをこれに続けることができ、オブジェクト・ライブラリを作成する必
要はない。

【０１０７】 生成されたリスト内では、オブジェクト・ライブラリの作成について行われる
のと同様に、ファイルを、メイクファイル、バッチ・ファイル、またはコマンド
・ライン・アプリケーションにリストすることができる。集中リストに、プロジ
ェクトのライブラリ・ファイルをリストすることができる。パブリック宣言への
外部参照の解決は、開発およびビルドの交番するフェーズで行うことができる。
これは、開発者へのリアルタイム・フィードバックのために、ソース・コード・
ファイルの編集中に動的に行うことができ、あるいは、コンパイル出力をパブリ
ック情報および参照情報を提供するのに使用して、個々のファイルのコンパイル
の後に行うことができる。さらに、コンパイルされリンクされるオブジェクト・
モジュールのリストを、バッチ・ファイルから、またはコマンド・ライン・リン
ク実行のリスト入力から、行うことができる。

【０１０８】 このリストおよび解決は開発時間を節約するのに役立つ。第１に、実際のファ
イルおよびその位置がリストされ、表示可能なので、デバッグ・トラブル・シュ
ーティング中に開発者が誤ったソース・コードを誤って見ることを防ぐのに役立
つ。ビルドに使用される特定のファイルの知識は、問題の位置、追加された欠け
ている機能または未定義の機能を開発者が検出するのも助ける。第２に、開発者
は、システムをビルドする前に、未解決の参照の即時のフィードバックも得る。
これは、開発時間を節約する。というのは、未解決の外部参照が、通常は、ビル
ド処理の最後に、リンクが行われる時にのみ報告されるからである。

【０１０９】 プログラム開発システム１００は、インクルード・ファイルがある場所を指定
する必要をなくすことによって、特的の機能クラスのファイルをインクルードす
るソース・コードに対する柔軟性も提供する。プログラム開発システム１００で
使用されるソース・コード・ファイル内に、マクロ・クラスとインクルード・フ
ァイルのファイル名を置くことができる。このインクルード・ファイルには、マ
クロ内でそのクラス情報がリストされる。コンパイルの前に、システム・ユーテ
ィリティによって、ソース・コード・ファイルがスキャンされ、適切なインクル
ード・ファイルの位置が判定される。

【０１１０】 システム・ユーティリティ・ソース・コード・ファイルには静的なシステムに
よって決定される名前のローカル・インクルード・ファイルが含まれる。このイ
ンクルード・ファイルは、ソース・コードのコンパイルの前に、システムによっ
て動的に作成される。ソース・コード・ファイルには、このマクロがリストされ
る前に、ローカルな固定された名前のインクルード・ファイルがリストされる。

【０１１１】 システム・スキャン・ユーティリティを使用して、コンパイルの前に、ソフト
ウェア・システムのソース・コード・ツリーが、上で定義したマクロについてス
キャンされる。システム構成ユーティリティは、システムのスキャンから取り出
された情報を使用し、ファイルのクラス情報を、見つかったインクルード・ファ
イルと一致させる。システム・ユーティリティは、ソース・コード・ファイルに
対してローカルなインクルード・ファイルを生成する。生成されたローカル・イ
ンクルード・ファイルは、インクルードされるファイルの物理的な位置を指定す
るマクロ展開を提供する。システム・ユーティリティは、インクルード依存性の
正しい位置を有するメイクファイルも動的に作成する。

【０１１２】 異なる位置に配置されたインクルード・ファイルに対する変更の制御を維持す
るために、バージョン管理法式を使用することができる。この場合には、ソース
・コード・ファイルとインクルード・ファイルの両方に、そのマクロのパラメー
タとしてインクルード・ファイルのバージョンがリストされる。システム・ユー
ティリティは、それらに互換性があることを検証する。

【０１１３】 このシステムを使用すると、ソース・コードは、どのインクルード・ファイル
が使用されるかを知る必要がなくなり、システムの配布で、それを手動で指定す
る必要がなくなる。これは、インクルード・ファイルに関する多形機能または異
なる位置の複数のバージョンの機能（アップグレード…）において有利である。
システム・ユーティリティは、インクルード・ファイルを、自動的に適切なファ
イルに解決する。クラス情報によって、同一の名前のインクルード・ファイルの
複数のインスタンスが問題にならなくなる。

【０１１４】 以下の説明では、プログラム開発システム１００のより詳細な説明を提供する
。図１１は、ルーチン（図の中央）およびグラフィカル・ユーザ・インターフェ
ース２００を管理する設計者へ、それらから、およびそれらの間の、完成した製
品１１０６（図の左下）への情報（図の右側）の流れを強調したプログラム開発
システム１００の概要を示す図である。データの流れは、二重線の矢印によって
示され、ルーチン・コマンド・パスは、単一線の矢印によって示される。下で提
示する図１１の説明は、主に、本発明のデータ、データ構造体、およびデータの
流れの諸形態を強調したものである。

【０１１５】 当初、コンポーネント・ソース・コード・ライブラリ１２００が、固定ディス
ク・ドライブなどの媒体上のディレクトリ内でセット・アップされる。ライブラ
リ・ディレクトリ内で、サブディレクトリが、ソフトウェア製品の各コンポーネ
ントに割り当てられる。各コンポーネントのサブディレクトリの下で、機能につ
いてサブサブディレクトリがセット・アップされ、このサブサブディレクトリの
それぞれに、その機能に対応する１つまたは複数のソース・コード・ファイルが
含まれ、さらに、機能サブディレクトリの第１層の下のサブ・ディレクトリでサ
ブ機能を定義することができ、以下同様である。各コンポーネント・サブディレ
クトリには、「ｃｏｍｐｏｎｅｎｔ．ｉｎｆ」ファイル１４００も含まれ、この
ファイルでは、特定のコンポーネントをどのようにコンパイルし、リンクするか
、それと共にどのタイプのプラットフォームを使用することができる、使用しな
ければならない、または使用してはならないか、などが定義される。各機能サブ
ディレクトリには、「ｆｅａｔｕｒｅ．ｉｎｆ」ファイル１６００も含まれ、こ
のファイルでは、とりわけ、特定のコンポーネントをどのようにコンパイルし、
リンクするか、それと共にどのタイプのプラットフォームを使用することができ
る、使用しなければならない、または使用してはならないか、などが定義される
。これらのファイルによってサポートされるオプションを、下で提示する図１４
から１７の説明に関して詳細に説明する。

【０１１６】 データベース更新ルーチン４００は、これらのファイルのすべてをスキャンし
、データベース１８００を作成する。このデータベース１８００には、特別なマ
クロ（そのマクロへの呼出しがソース・コード・ファイルに挿入される）のすべ
てに渡される引数から抽出された情報と、「ｆｅａｔｕｒｅ．ｉｎｆ」ファイル
および「ｃｏｍｐｎｅｎｔ．ｉｎｆ」ファイルから収集されたすべての情報が含
まれる。このデータに、コンフィギュレータ７００によってアクセスすることが
できる。具体的に言うと、データベース・システムは、下記の質問に答えること
ができるように設計され、構成される。コンポーネントはどれか？。機能はどれ
か？。オブジェクト（コンポーネントまたは機能）に関して、関数的依存性（ジ
ャンプ、呼出しなど）を含めて、その依存性、オプション、およびインクルード
・ファイル依存性は何か？。プロシージャ、ラベル、およびリストを含めて、そ
のインターフェースはどれか？。そのオプションは何か？。そのファイルは何か
？。その詳細は何か？。データベース・システムは、外部トリガ（Ｙが含まれる
場合にＸを含めなければならない）；推奨されるトリガ（サーバについて使用が
推奨される；および「オン・デマンド」トリガ（コンポーネントＺがその存在を
必要とするので含めなければならない）など、特別なトリガ・タイプによって最
終製品に含めることがトリガされるコンポーネントおよび／または機能のリスト
を表すことができる。データベース・システムは、ファイル（名前、パス、日付
およびタイム・スタンプによって識別される）が存在することを確認することが
できる。データベース・システムは、名前によって識別される特定のオプション
に関する情報も提示することができる。最後に、データベース・システムは、特
定のオプションに関する「Ｅｎｕｍ」（または列挙されたデータ名および値）の
リストを提示することができる。

【０１１７】 コンフィギュレータ・プロシージャ７００は、データベース１８００から引き
出された情報および製品構成ファイル「ｐｌａｔｆｏｒｍ．ｃｆｇ」２１００か
ら引き出された情報を使用して、完成した製品の構成を定義する構成状態データ
を作成する。コンフィギュレータ７００は、好ましい実施形態ではＣ＋＋で記述
されるが、この情報を、図３２に示されているようにクラスのＣ＋＋ＲＡＭデー
タ構造体（クラスという単語のＣプログラミングでの意味で）内でこの情報を維
持する。図からわかるように、任意の数の製品構成３２０２を、このＲＡＭデー
タ構造体に格納することができる。そのような製品構成のそれぞれを、任意の数
のクラス３２０４（本発明の意味での）、コンポーネント３２０６、および機能
３２０８にリンクすることができる。クラス３２０４を、任意の数のコンポーネ
ント３２０６および機能３２０８にリンクすることもできる（コンポーネントが
、ソース・コード・ファイルに関連しない場合（一般に関連しない）に、コンポ
ーネントにクラスを割り当てる必要がないことに留意されたい）。各機能３２０
８を、任意の数のサブ機能３２０８にリンクすることができる。コンポーネント
３２０６および機能３２０８に、ファイル３２１４（ソース・コード・ファイル
およびインクルード・ファイル）を関連付けることができ、また、オプション３
２１０（たとえば普通の「インクルード」ファイルの「ＳＴＡＲＴ＿ＤＥＬＡＹ ＥＱＵ １２」などの形式的に表現される型の式または宣言済み定数など）も
関連付けることができる。ソース・コード・ファイル３２１４の場合には、それ
ぞれを、任意の数の依存性３２１６（「インクルード」、「オプション」、マク
ロ、および関数。関数には、リスト、ラベル、関数呼出し、文字列が含まれる）
ならびに任意の数のインターフェース３２１８（プロシージャなど、パブリック
に（コンポーネント間で）またはプライベートに（アクセスが親と兄弟に制限さ
れる）参照することができるもののすべて）にリンクすることができる。したが
って、ソース・コード・ファイル内の名前の「可視性」は、まず、クラスによっ
て制限され、その後、名前がパブリックに宣言されていない場合に、コンポーネ
ント／関数（親／兄弟）関係によって制限される。オプションの場合に、単純な
例を提示すると、「Ｆａｓｔ＝３；Ｓｌｏｗ＝２；Ｏｆｆ＝１」など、各列挙に
数値が割り当てられる、Ｐａｓｃａｌコンピュータ・プログラムのように、すべ
てのオプションに１組の列挙３２１２を任意選択として割り当てることができる
。その場合に、列挙のメニューが、ユーザ・インターフェースを介して設計者に
提示される（図３３Ｅに示されたメニュー３３３８の「Ｍｏｄｉｆｙ」選択が行
われた時に）。

【０１１８】 図１１のグラフィカル・ユーザ・インターフェース２００は、他所で詳細に説
明する。短く要約すると、設計者は、２０６で、ソース・コード・ファイル、「
ｆｅａｔｕｒｅ．ｉｎｆ」ファイルおよび「ｃｏｍｐｎｅｎｔ．ｉｎｆ」ファイ
ルを表すアイコンをダブル・クリックすることができ、これによってどのファイ
ルでも編集することができ、その後、自動的な呼出しがデータベース更新ルーチ
ン４００、コンフィギュレータ・プロシージャ７００、およびグラフィカル構成
ディスプレイ２１２に対して行われて、データベース１８００、構成状態データ
１９００、およびユーザ・ディスプレイが更新される（図３３Ａ）。２０８で、
設計者は、提供されるツールを使用して、さまざまな、名前を付けられたシステ
ム・コンポーネントを参照し、検索し、それらを参照し、それらが定義されてい
る可能性がある場所を探してライブラリをナビゲートし、その後、上で説明した
ように、それらの定義を表示し、改訂することができる。２１０で、設計者は、
コンフィギュレータ・プロシージャ７００を呼び出して、完成した製品の構成を
修正する。その変更は、構成状態データ１９００（図１９に示された「×」に）
およびディスク常駐の製品構成データ・ファイル２１００「ｐｌａｔｆｏｒｍ．
ｃｆｇ」に忠実に記録される。そのような変更のすべてが、やはり、グラフィカ
ル構成ディスプレイ２１２に表示される。

【０１１９】 最後のユーザ・コマンドは、図１１のユーザ・ビルド要求コマンド２１４であ
る。図７に関して前に説明したように、このコマンドは、ユーザ選択およびシス
テム選択の構成状態データ（図２０に示された（図１９と比較されたい））を製
品メイク・ルーチン８００（概要を図８、詳細を図３４で説明する）に供給させ
て、まず、コンポーネント・メイクファイル２４００および製品メイクファイル
２５００を構築させるが、この２つのメイクファイルは、コンパイルおよびリン
クのすべての形態を制御し、各機能に対応する機能インクルード・ファイル２３
００「ｆｅａｔｕｒｅ．ｉｎｃ」および機能依存性のスイッチ・オンまたはスイ
ッチ・オフ（「呼出し」を含めることまたは除外することおよび類似物を含む）
を構築または更新させる。

【０１２０】 作業を終了した時に、図１１の製品メイク・ルーチン９００は、単純に、標準
Ｕｎｉｘのｍａｋｅユーティリティを呼び出して、製品メイクファイル２５００
を実行し、これによて、図１０で概要を説明した製品ビルド・ルーチン１０００
を実行させ、この製品ビルド・ルーチン１０００が、コンパイラ、アセンブラ、
およびリンカを呼び出して、個々のコンポーネント・メイクファイルの制御の下
で、個々の機能ごとに機能インクルード・ファイル２３００の必要に応じてソー
ス・コードを修正して、すべてのコンポーネントに関して、ビルドされた製品コ
ンポーネント・ファイル１１０４を作成する。

【０１２１】 最後に、図１１の製品コンポーネント・リンカ３６００が呼び出されて、ビル
ドされた製品コンポーネント・ファイル１１０４を受け入れ、それらから、オブ
ジェクト・コード・イメージの最後の「フィックスアップ」を実行する時に製品
コンポーネント・リンカを制御することが意図された、特別なマクロが生成した
セグメントに含まれるデータをはぎとり、完全にリンクされた単一のＲＯＭイメ
ージに一緒につなぎ合わせ、このＲＯＭイメージでは、名前およびクラスによる
呼出しが、ＲＯＭイメージ内の絶対アドレスへの正しい呼出しに置換され、特別
なセグメントから取り出されたリスト・コンポーネントが、独立のリストに編成
され、指令に従ってソートされ、指示された位置で正しいコード・セグメントに
挿入され、オプションが完全に解決され、リンクの他の最終ステップのすべてが
完全に完了している。この形で、製品コンポーネント・リンカは、ＥＥＰＲＯＭ
またはフラッシュＲＯＭまたは類似物へのインストールの準備ができた完成した
製品１１０６を生成する。

【０１２２】 図１２に、コンポーネント・ソース・コード・ライブラリ１２００の全般的な
構造を示す。このライブラリは、コンピュータまたはサーバのハード・ディスク
・ドライブ上で、都合のよいルート・ディレクトリに構築される。好ましい実施
形態では、すべてのシステム要素が、このルート・ディレクトリの範囲内に存在
しなければならず、この範囲は、データベース更新ルーチン４００によってスキ
ャンされるディスク・ドライブの一部にすぎない。

【０１２３】 任意の数のシステム・コンポーネントが存在してもよい。各コンポーネントが
、ライブラリに割り当てられたルート・ディレクトリ内のそれ自体のサブディレ
クトリ内に常駐する。図１２では、テキスト表現の線の輪郭の構造によって、も
のが格納されるディレクトリおよびサブディレクトリのレベルが象徴的に表され
、長方形が単一のサブディレクトリおよびその内容を囲んでいる。

【０１２４】 したがって、図１２のルート・ディレクトリは、ソース・ライブラリＡ１２０
２である。このソース・ライブラリ内のすべてのものが、データベース更新ルー
チン４００によってスキャンされる。このルート・ディレクトリ内には、２つの
サブディレクトリが図示され、一方はコンポーネントＡ１２０４に割り当てられ
、他方はコンポーネントＢ１２０６に割り当てられる。各コンポーネント・サブ
ディレクトリに、コンポーネント情報ファイルが含まれる。コンポーネントＡの
サブディレクトリには、コンポーネントＡ情報ファイル１４００（図１４にその
詳細が示されている）が含まれ、コンポーネントＢのサブディレクトリには、同
様に、コンポーネントＢ情報ファイル１２１０が含まれる。各コンポーネント・
サブディレクトリに、１つまたは複数の機能サブサブディレクトリが含まれる。
図１２では、コンポーネントＡサブディレクトリに、２つの機能サブディレクト
リ１２１２および１２１４が含まれる。各機能サブサブディレクトリには、図示
のように、機能ソース・コード・ファイル１３００、１２２０、１２２４、およ
び１２２６と、機能情報ファイル１６００および１２２２が含まれる。機能１サ
ブサブディレクトリを参照すると、これには、その詳細が図１６に示されている
機能１情報ファイル１６００と、その詳細が図１３に示されている機能１ソース
・コード・ファイルＡが含まれる。

【０１２５】 図１３は、本発明のマクロ呼出しが強調されているアセンブリ言語ソース・フ
ァイルである、ソース・コード・ファイル「ＢＥＥＰ．ＡＳＭ」を表す。このフ
ァイルは、構成ディスプレイ（図３３Ａ）を示すのに使用され、コンポーネント
・ソース・コード・ライブラリ１２００内でのその位置が、付録Ａに示されてい
る。

【０１２６】 本発明と共に使用されるすべてのソース・ファイルに、本発明によって使用さ
れる他のインクルード・ファイルをインクルードする「ＳＹＳＴＥＭ．ＩＮＣ」
１３０６をインクルードしなければならない。とりわけ、このインクルード・フ
ァイルには、本発明の多くの形態を実施するのに使用することができる特別なマ
クロが含まれる。本発明と共に使用されるすべてのソース・ファイルに、「ＦＥ
ＡＴＵＲＥ．ＩＮＣ」１３０８もインクルードしなければならず、これは、製品
ビルド準備（図９）によって生成される、各機能の機能インクルード・ファイル
をビルドする（図３５、機能インクルード・ファイルのビルドＡ）機能インクル
ード・ファイルである。機能ＢＥＥＰのために本発明によってビルドされ、ＢＥ
ＥＰ．ＡＳＭにインクルードされる機能インクルード・ファイルを、図２３に示
す。後で説明するように、「ＦＥＡＴＵＲＥ．ＩＮＣ」インクルード・ファイル
には、マクロＰＵＢＥＸＴ１３１２およびＥＸＴＣＡＬＬ１３１８によって生成
されるコードを制御するマクロ変数が含まれ、これによって、設計者が、ソース
・コードに対する変更なしにプロシージャのリンクアップを直接に制御できるよ
うになる。

【０１２７】 ＰＵＢＥＸＴマクロ１３１２は、インターフェース・バージョン１．０でクラ
スＴＩＭＥＲの外部プロシージャＤＥＬＡＹを宣言する。マクロ名自体が、この
プロシージャは別にリンクされるコンポーネントに含まれるＰＵＢＬＩＣ＿ＰＲ
ＯＣマクロによって定義されたものであることを宣言している。これらの参照は
、製品コンポーネント・リンカ（図３６）によってフィックス・アップされる。
ＰＵＢＥＸＴマクロは、下で提示するマクロの行単位の説明の節２．１で説明す
る。

【０１２８】 ＰＵＢＬＩＣ＿ＰＲＯＣマクロ１３１６では、インターフェース・バージョン
１．０のクラスＢＥＥＰの外部プロシージャＥＲＲＯＲＢＥＥＰを定義する。マ
クロ名自体が、ＰＵＢＥＸＴマクロでそれを定義する別々にリンクされるコンポ
ーネントで参照可能であるプロシージャを定義している。ＰＵＢＬＩＣ＿ＰＲＯ
Ｃマクロは、マクロの行単位の説明の節３．１で説明する。後で説明するように
、クラス定義が、コンパイルまたはアセンブルの前にマクロによって絶対ライブ
ラリ・アドレスに置換される。

【０１２９】 ＥＸＴＣＡＬＬマクロ１３１８は、ＰＵＢＥＸＴマクロ１３１２での宣言を使
用して、クラスＴＩＭＥＲに割り当てられた外部プロシージャＤＥＬＡＹを呼び
出す。このプロシージャは、別にリンクされるコンポーネント内で定義されるの
で、それへの参照は、製品コンポーネント・リンカ（図３６）によってフィック
ス・アップされる。ＥＸＴＣＡＬＬマクロは、マクロの行単位の説明の節１．１
で説明する。

【０１３０】 ＥＮＤ＿ＰＲＯＣマクロ１３２０によって、ＰＵＢＬＩＣ＿ＰＲＯＣマクロ１
３１６によってオープンされたプロシージャが終了する。これは、マクロの行単
位の説明の節３．３で説明する。

【０１３１】 各オブジェクトすなわちコンポーネントまたは機能は、対応する情報ファイル
を有する。このファイルは、．ＩＮＦファイルとして表すことができる。この情
報ファイルの目的は、ＢＩＯＳツールまたは、開発中のソフトウェア製品に関し
て使用されるすべてのツールに必要な情報であって、木構造またはアセンブリ・
ファイルのスキャンから導出することができない情報を含めることである。デー
タベース更新プロセスが、これらの．ＩＮＦファイルおよびアセンブリ・ファイ
ルをスキャンして、情報を収集し、集中データベースに置く。

【０１３２】 コンポーネント情報ファイル（ＣＯＭＰＮＥＮＴ．ＩＮＦ）はすべてのコンポ
ーネント・チップに含まれる。機能情報ファイル（ＦＥＡＴＵＲＥ．ＩＮＦ）は
コンポーネント・ディレクトリまたは機能ディレクトリの各サブディレクトリに
含まれる。ＣＯＭＰＮＥＮＴ．ＩＮＦファイルとＦＥＡＴＵＲＥ．ＩＮＦファイ
ルは事実上同一なので、以下の説明では、これらを単にＩＮＦファイルと呼び、
相違が存在する場合に限ってこの２つを区別する。一般に、ＩＮＦファイル内の
情報には、オブジェクトおよび関連するライブラリまたはバイナリの名前、オブ
ジェクトに関する自由形式の記述情報、オブジェクトが属するクラスまたはサブ
クラス、およびオプション宣言が含まれる。

【０１３３】 ＩＮＦファイルのそれぞれに、１つまたは複数のコマンドを含めることができ
る。これらのコマンドは、大文字小文字の区別がなく、単一の行を超えないこと
が好ましい。さらに、１行に１つのコマンドだけが存在することが好ましい。コ
メントは、「／／」などの識別子を前において、単独で行に配置することができ
、また、コマンド行の末尾に置くことができる。

【０１３４】 ＩＮＦファイルの本体で使用することができるコマンドは、オプション、必須
、条件付き必須とすることができる。さらに、一部のコマンドを、コンポーネン
ト情報ファイル専用または機能情報ファイル専用とすることができる。オプショ
ン・コマンドの中にＢｒｉｎｇＵｐコマンドがある。このコマンドは、そのオブ
ジェクトを、ＰＬＡＴＦＯＲＭ．ＣＦＧファイル内で「ＢｒｉｎｇＵｐ」として
識別されるプラットフォームＢＩＯＳに含めなければならないことを識別するの
に使用される。これは、マザーボードをブートするのに必要な最小限のオブジェ
クトを有するＢＩＯＳをすばやく構成するのを支援するのに使用される。このコ
マンドがＰＬＡＴＦＯＲＭ．ＣＦＧファイルに追加される時にシステムをＤＯＳ
にブートするのに必要なオブジェクトだけが、ＢＩＯＳにインストールされる。

【０１３５】 Ｃｌａｓｓコマンドは条件付き必須コマンドである。これは、オブジェクトが
属するクラスの名前を提供する。ＩＮＦファイルごとに１つのクラスまたはサブ
クラスだけが許容される。オブジェクトのパブリック・プロシージャは、ｃｌａ
ｓｓ．ｓｕｂｃｌａｓｓ［．ｓｕｂｃｌａｓｓ…］パスが付けられた関数名によ
って参照される。コンポーネントは、クラスの宣言を必要としない。しかし、機
能は、その親オブジェクトでクラスまたはサブクラスが宣言される場合に、クラ
スまたはサブクラスを宣言する必要がある。言い換えると、機能情報ファイルの
Ｃｌａｓｓコマンドは、その親オブジェクトがクラスまたはサブクラスを宣言す
るかどうかに依存して条件付きで必須になる。

【０１３６】 Ｃｌａｓｓｉｆｉｃａｔｉｏｎコマンドは、コンポーネント情報ファイルだけ
に適用されるが、すべてのコンポーネント情報ファイルに必須である。このコマ
ンドは、たとえばＢＩＯＳツールを使用してコンポーネントをソートし、分類す
ることを可能にする情報を指定するのに使用される。Ｃｌａｓｓｉｆｉｃａｔｉ
ｏｎコマンドには、ＣｏｍｐｏｎｅｎｔＴｙｐｅ、ＤｅｖｉｃｅＶｅｎｄｏｒ、
ＤｅｖｉｃｅＡｌｉａｓ、ＰａｒｔＮｕｍｂｅｒ、およびＣａｔｅｇｏｒｙなど
の、１つまたは複数のフィールド名を含めることができる。

【０１３７】 ＣｏｍｐｏｎｅｎｔＴｙｐｅフィールド名の値は、ｈａｒｄｗａｒｅまたはｓ
ｏｆｔｗａｒｅのいずれかであり、Ｃｌａｓｓｉｆｉｃａｔｉｏｎコマンドに必
ず必要である。ＤｅｖｉｃｅＶｅｎｄｏｒフィールド名は、ベンダを定義し、ハ
ードウェア・コンポーネント・タイプだけに必要かつ適用可能である。Ｄｅｖｉ
ｃｅＡｌｉａｓフィールド名は、コンポーネント・タイプの一般に既知のニック
ネームを定義し、ハードウェア・コンポーネント・タイプだけに必要かつ適用可
能である。ＰａｒｔＮｕｍｂｅｒフィールド名は、コンポーネント部品番号を定
義し、ハードウェア・コンポーネント・タイプだけに必要かつ適用可能である。
Ｃａｔｅｇｏｒｙフィールド名は、デバイスまたはソフトウェア・コンポーネン
トがおさまるカテゴリを定義するのに使用され、ソフトウェアおよびハードウェ
アの両方のコンポーネント・タイプでオプションである。

【０１３８】 ＣｏｍｐｉｌｅＵｓｉｎｇコマンドは、オプション・コマンドであり、ＣＯＭ
ＰＭＡＫＥによって生成されるデフォルト・コマンドではなく、指定された拡張
子について、コンポーネントのメイクファイルで使用されるカスタム・コンパイ
ル・コマンドを識別する。このコマンドには、３つのフィールドすなわち、Ｃｏ
ｍｍａｎｄ、ＳｏｕｒｃｅＥｘｔｅｎｓｉｏｎ、およびＤｅｓｔｉｎａｔｉｏｎ
Ｅｘｔｅｎｓｉｏｎが含まれる。Ｃｏｍｍａｎｄフィールドは、たとえば、指定
されたファイル情報が配置される場所を識別するパラメータおよび他の制御情報
に関するパラメータを有するカスタムＤＯＳコマンドである。ＳｏｕｒｃｅＥｘ
ｔｅｎｓｉｏｎフィールドは、カスタム・コマンドによる影響を受けなければな
らないソース・コード・ファイルのファイル拡張子を提供する。Ｄｅｓｔｉｎａ
ｔｉｏｎＥｘｔｅｎｓｉｏｎは、カスタム・コマンドによって作成されるデステ
ィネーション・ファイルのファイル拡張子を提供する。

【０１３９】 ＣｏｒｅＶｅｒｓｉｏｎコマンドは、オブジェクトと互換性のあるコア・バー
ジョンを識別する必須コマンドである。このコマンドには、それぞれが互換性の
あるコア・バージョンを表す１つまたは複数の値を含めることができる。

【０１４０】 Ｄｅｓｃｒｉｐｔｉｏｎコマンドは、必須コマンドであり、記述されるコンポ
ーネント、機能、またはオプションに関する詳細を提供するために高水準インタ
ーフェースによって使用することができるテキスト・コメントを提供する。記述
は、たとえば、５１２文字までの長さとすることができる。

【０１４１】 ＬｉｎｋＵｓｉｎｇコマンドは、ＣＯＭＰＭＡＫＥによって生成されるデフォ
ルト・コマンドではなく、コンポーネントのメイクファイルで使用されるカスタ
ム・リンク・コマンドを識別するオプション・コマンドである。Ｃｏｍｐｉｌｅ
Ｕｓｉｎｇコマンドと同様に、ＬｉｎｋＵｓｉｎｇコマンドには、Ｃｏｍｍａｎ
ｄフィールド、ＳｏｕｒｃｅＥｘｔｅｎｓｉｏｎフィールド、およびＤｅｓｔｉ
ｎａｔｉｏｎＥｘｔｅｎｓｉｏｎフィールドが含まれる。これらのフィールドは
上で説明したものと同一の機能を提供する。

【０１４２】 Ｎａｍｅコマンドは、必須コマンドであり、オブジェクトの名前を提供する。
オブジェクトの名前を指定する、Ｎａｍｅコマンドの識別子はオブジェクトの名
前を指定するが、たとえば４０文字の長さの英数字文字列とすることができ、数
字から始まらず、空白を含まないことが好ましい。

【０１４３】 Ｏｐｔｉｏｎコマンドは、構成可能なオプションを宣言し、そのデフォルト値
を与えるオプション・コマンドである。設計者は、ＰＬＡＴＦＯＲＭ．ＣＦＧフ
ァイルを使用して、オプションの設定を変更することができる。このコマンドは
、オプションのサポートされる値の説明的な名前を提供する「本体」セクション
をサポートする。これらの名前は、ＰＬＡＴＦＯＲＭ．ＣＦＧファイル内でデフ
ォルト値を宣言するか値を変更するために数値の代わりに使用することができる
。値の名前は別の行で定義しなければならない。本体セクションを除外すること
は値の設定に数値だけが使用可能であることを意味する。

【０１４４】 オプション名を定義する名前フィールドのほかに、Ｏｐｔｉｏｎコマンドには
複数の他のフィールドがある。ＤｅｆａｕｌｔＶａｌｕｅＮａｍｅフィールドは
、本体セクションで定義される有効な「値名（ｖａｌｕｅ ｎａｍｅ）」を提供
し、このコマンドの本体セクションで値名が定義されている時に必須である。Ｄ
ｅｆａｕｌｔ＿ｎｕｍｅｒｉｃ＿ｖａｌｕｅフィールドは、指定された長さを越
えないことが好ましい有効な数値を提供する。列挙名が存在する時には、数値を
デフォルトとして使用することができない。Ｓｉｚｅフィールドはオプション空
間のサイズを指定する。ＲｏｍＥｄｉｔＤｅｓｃｒｉｐｔｉｏｎフィールドは、
設計者がＰＬＡＴＦＯＲＭ．ＣＦＧファイル内で「Ｒｏｍｅｄｉｔ」を選択した
場合にＲＯＭに保存される、オプションの記述文字列である。ＶａｌｕｅＮａｍ
ｅフィールドは、オプション値を設定する時に数値の代わりに使用することがで
きる、説明的な名前である。ＶａｌｕｅフィールドはＶａｌｕｅＮａｍｅに関連
する特定の数値を表す。ＶａｌｕｅＤｅｓｃｒｉｐｔｉｏｎフィールドは値の意
味のテキスト記述を提供する。

【０１４５】 Ｏｗｎｅｒコマンドはオブジェクトのオーナーの会社名を提供する必須コマン
ドである。このコマンドは、コア・ツリーを顧客サイトに公開または複製する時
に顧客のコンポーネントをフィルタリングするのに使用される。

【０１４６】 ＰｌａｔｆｏｒｍＴｙｐｅコマンドは、ＰＬＡＴＦＯＲＭ．ＣＦＧファイルの
プラットフォーム・タイプの識別に基づいて、オブジェクトをデフォルトでビル
ドに含めなければならない時を記述するオプション・コマンドである。このコマ
ンドには、それぞれが対応するＵｓａｇｅフィールドを有する１つまたは複数の
ＰｌａｔｆｏｒｍＴｙｐｅフィールドが含まれる。ＰｌａｔｆｏｒｍＴｙｐｅフ
ィールドは、たとえば、ＢａｓｉｃＰＣ、Ｄｅｓｋｔｏｐ、Ｓｅｒｖｅｒ、Ｎｏ
ｔｅｂｏｏｋ、ＰＩＣＯ、またはＡｌｌＯｔｈｅｒｓとすることができる。

【０１４７】 Ｕｓａｇｅフィールドは、ビルドにオブジェクトを含める条件を記述するのに
使用される。このフィールドが「Ｒｅｃｏｍｍｅｎｄｅｄ」である場合には、オ
ブジェクトはデフォルトで含まれるが、その推奨される（ｒｅｃｏｍｍｅｎｄｅ
ｄ）オブジェクトを手動でビルドから設計者が除去することができる。このフィ
ールドが「Ｔｅｓｔ」である場合には、オブジェクトがテストのためにデフォル
トでビルドに含まれるが、製品リリースからは排除される。「ＯｎＤｅｍａｎｄ
」の場合には、オブジェクトが、ハード外部参照を解決するのに必要である時に
、オブジェクトが自動的に含まれる。「Ｅｘｐｌｉｃｉｔ」の場合には、オブジ
ェクトは、明示的にＰＬＡＴＦＯＲＭ．ＣＦＧファイルに追加されない限り、関
連するＰｌａｔｆｏｒｍＴｙｐｅのビルドに含まれなくなる。「Ｅｘｔｅｒｎａ
ｌ Ｔｒｉｇｇｅｒ」は、ビルドにオブジェクトを含めることをトリガするＣｌ
ａｓｓ．ＳｕｂＣｌａｓｓの名前を識別する。

【０１４８】 １つのクラスが、単一のプラットフォーム・タイプについて「Ｅｘｔｅｒｎａ
ｌ Ｔｒｉｇｇｅｒ」と「ＯｎＤｅｍａｎｄ」または「Ｒｅｃｏｍｍｅｎｄｅｄ
」を組み合わせることができる。しかし、単一のプラットフォーム・タイプに関
するＵｓａｇｅフィールドの他の組合せは、許可されず、検証障害を引き起こす
。さらに、単一のクラスの１つのオブジェクトだけが、コア・ファイル内でそれ
自体をＯｎＤｅｍａｎｄ、Ｒｅｃｏｍｍｅｎｄｅｄ、またはＥｘｔｅｒｎａｌｌ
ｙ Ｔｒｉｇｇｅｒｅｄと宣言することができる。そうではなく、依存性に対す
る複数のデフォルト解決を有すると、検証障害がもたらされる。単一のコンポー
ネント内では、特定のサブクラスの１つの機能だけが、それ自体をＯｎＤｅｍａ
ｎｄ、Ｒｅｃｏｍｍｅｎｄｅｄ、またはＥｘｔｅｒｎａｌｌｙ Ｔｒｉｇｇｅｒ
ｅｄと宣言することができる。複数を有することは、１つの依存性に対する複数
の解決をもたらし、検証障害を引き起こす可能性がある。

【０１４９】 ＳｈｉｅｌｄＰｒｉｖａｔｅｓコマンドは、オブジェクトのプライベート・プ
ロシージャを、その兄弟オブジェクトによるアクセスから保護するオプション・
コマンドである。このコマンドは、機能的に関連しない雑多なオブジェクトのリ
ポジトリとして使用されるオブジェクトに有用である。図４１に、Ｓｈｉｅｌｄ
Ｐｒｉｖａｔｅｓコマンドによって、どのようにプライベート・アクセス・レベ
ルを超えてコード・アクセスがさらに制限されるかを示す。この図には、関数呼
出しのアクセスが、ある機能レベルでパブリック、プライベート、またはシール
デッドのいずれかの適切なレベルにどのようにカプセル化されるかが示されてい
る。これは、プロシージャ、ラベル、およびインクルードを含む依存性に適用さ
れる。

【０１５０】 ＳｕｂＣｌａｓｓコマンドは、機能が属するサブクラスの名前を提供する条件
付き必須コマンドである。各ＩＮＦファイルが、クラスまたはサブクラスを１つ
だけ許容される。オブジェクトのパブリック・プロシージャは、ｃｌａｓｓ．ｓ
ｕｂｃｌａｓｓパスが付けられた関数名によって参照される。上でＣｌａｓｓコ
マンドに関して説明したように、コンポーネントは、クラスを宣言する必要がな
いが、機能は、親オブジェクトでクラスまたはサブクラスが宣言される場合に、
クラスまたはサブクラスを宣言する必要がある。

【０１５１】 Ｔａｒｇｅｔコマンドは、コンポーネント情報ファイルだけに適用可能なオプ
ション・コマンドである。このコマンドでは、特定のコンポーネントのビルドか
ら生じるライブラリまたはバイナリの名前を提供する。Ｔａｒｇｅｔコマンドに
は、ＴａｒｇｅｔＮａｍｅフィールドおよびＴｙｐｅＫｅｙフィールドが含まれ
る。ＴａｒｇｅｔＮａｍｅフィールドは文字ファイル名を定義する。ＴｙｐｅＫ
ｅｙフィールドは非標準タイプのファイルを識別するのに使用される４文字のコ
ードである。このコードは、これらのファイルを参照するディスパッチ・テーブ
ルのフィックスアップに対して、ＢＩＯＳＭＡＫＥユーティリティによって使用
される。

【０１５２】 Ｕｓｅｓコマンドは、記述されるオブジェクトによって使用される共有コード
の位置を識別するのに使用されるオプション・コマンドである。ビルド・ツール
は、このコマンドを使用して、オブジェクトのために作成されたメイクファイル
内の依存性としてファイルを識別する。共有ファイルの使用は制限される。具体
的に言うと、オブジェクトは、たとえば「Ｓｈａｒｅｄ」属性と共にＰＲＩＶＡ
ＴＥ＿ＰＲＯＣコマンドまたはＰＲＩＶＡＴＥ＿ＩＮＣＬＵＤＥコマンドを使用
して、それ自体を共用として識別するファイルだけを使用することができる。さ
らに、オブジェクトは、兄弟ディレクトリにあるか上流ディレクトリ・ノードの
直接の子である共有ソース・ファイルだけを使用することができる。Ｕｓｅｓコ
マンドには、オブジェクトによって使用される共有ファイルの相対パスおよびフ
ァイル名を提供するＦｉｌｅＰａｔｈフィールドが含まれる。

【０１５３】 図１４に、付録ＡのパスＣ：￥ＢＩＯＳ￥ＣＯＲＥ￥ＣＯＭＰＮＥＮＴ．ＩＮ
Ｆに示されたクラスＣＯＲＥ１４０６のコンポーネント情報ファイルを提示する
。これは、機能ＢＥＥＰ（図１６）を含むコンポーネントであり、機能ＢＥＥＰ
には、ソース・コード・ファイルＢＥＥＰ．ＡＳＭ（図１３）が含まれる。本発
明のこの部分には、コンポーネントを記述するコマンドと、コンポーネントの構
成に使用されるコマンド（図１５）が含まれる。

【０１５４】 ＢＲＩＮＧＵＰコマンド１４１２は、本発明を使用する顧客が、すばやく開始
するために最小限の機能性を有する新しいＢＩＯＳのビルドを開始する時に、こ
のコンポーネントを構成の一部として含めなければならないことを示す。

【０１５５】 ＰＬＡＴＦＯＲＭＴＹＰＥコマンド１４２４は、ＩＡ３２アーキテクチャで走
る製品をビルドする時に、このコンポーネントを使用することができることを示
す。ＡＬＬＯＴＨＥＲＳコマンド１４２８は、ＰＬＡＴＦＯＲＭＴＹＰＥコマン
ド１４２４で明示的に指定されなかったすべてのプラットフォーム・タイプにつ
いて、このコンポーネントがＲＥＣＯＭＭＥＮＤＥＤであることを示す。このＣ
ＯＲＥ１４０６コンポーネントは、明示的にフォース・アウトされない限り、Ｉ
Ａ３２アーキテクチャで走る本発明によって作られるすべての構成に含まれる。

【０１５６】 図１５に、コンポーネントの構成に使用される、本発明のコンポーネント情報
ファイル内のコマンドを示す。太字の名前は、キーワードであり、太字でない名
前は、設計者によって指定される。文字「／／」は、その行の残りがコメントで
あることを示す。コマンドの括弧｛｝の間にあるすべてのコマンドが、そのコマ
ンドのスコープ内にある。

【０１５７】 ＰＬＡＴＦＯＲＭＴＹＰＥコマンド１５０６は、コンポーネントを構成に含め
るルールを指定する。ルールは、「ＤｅｓｋＴｏｐ」または「ＮｏｔｅＢｏｏｋ
」などの特定のＰｌａｔｆｏｒｍＴｙｐｅもしくは明示的に言及されないすべて
のＰｌａｔｆｏｒｍＴｙｐｅ（ＡＬＬＯＴＨＥＲＳ）の構成に適用される。ルー
ル１５１６には、ＲＥＣＯＭＭＥＮＤＥＤ（構成から明示的にフォース・アウト
されない限りコンポーネントを含める）、ＯＮＤＥＭＡＮＤ（コンポーネント内
のプロシージャが構成内の別のコンポーネントによって既に参照されている場合
にコンポーネントを含める）、ＥＸＰＬＩＣＩＴ（明示的に構成にフォース・イ
ンされる場合に限ってコンポーネントを含める）、およびＥＸＴＥＲＮＡＬＴＲ
ＩＧＧＥＲ（ＣｌａｓｓＰａｔｈによって指定されるコンポーネントまたは機能
が構成に含まれる場合にこのコンポーネントを含める）が含まれる。

【０１５８】 ＯＰＴＩＯＮコマンド１５２２は、コンポーネントを構成するソース・コード
・ファイル内で使用することができるオプションの名前およびデフォルト値を定
義する。製品構成で指定することができるオプションの許容可能な値の名前を定
義することもできる（図２２）。

【０１５９】 図１６に、付録ＡのパスＣ：￥ＢＩＯＳ￥ＣＯＲＥ￥ＢＥＥＰ￥ＦＥＡＴＵＲ
Ｅ．ＩＮＦに示されたクラスＢＥＥＰ１６０２の機能情報ファイルを提示する。
これは、ソース・コード・ファイルＢＥＥＰ．ＡＳＭ（図１３）に含まれる機能
である。本発明のこの部分には、機能を記述するコマンドおよび機能の構成に使
用されるコマンド（図１７）が含まれる。

【０１６０】 ＢＲＩＮＧＵＰコマンド１６１２は、本発明を使用する顧客が、すばやく開始
するために最小限の機能性を有する新しいＢＩＯＳのビルドを開始する時に、こ
の機能を構成の一部として含めなければならないことを示す。

【０１６１】 ＰＬＡＴＦＯＲＭＴＹＰＥコマンド１６１６は、ＩＡ３２アーキテクチャで走
る製品をビルドする時にこの機能を使用することができることを示す。ＡＬＬＯ
ＴＨＥＲＳコマンド１６２０は、ＰＬＡＴＦＯＲＭＴＹＰＥコマンド１６１６で
明示的に指定されなかったすべてのプラットフォーム・タイプについて、この機
能がＲＥＣＯＭＭＥＮＤＥＤであることを示す。このＢＥＥＰ１６０２機能は、
明示的にフォース・アウトされない限り、ＩＡ３２アーキテクチャで走り、ＣＯ
ＲＥコンポーネントを含む本発明によって作られるすべての構成に含まれる。

【０１６２】 図１７に、機能の構成に使用される、本発明の機能情報ファイル内のコマンド
を示す。太字の名前は、キーワードであり、太字でない名前は、設計者によって
指定される。文字「／／」は、その行の残りがコメントであることを示す。コマ
ンドの括弧｛｝の間にあるすべてのコマンドが、そのコマンドのスコープ内にあ
るとみなされる。

【０１６３】 ＰＬＡＴＦＯＲＭＴＹＰＥコマンド１７０６は、機能を構成に含めるルールを
指定する。ルールは、ＤｅｓｋＴｏｐまたはＮｏｔｅＢｏｏｋなどの特定のＰｌ
ａｔｆｏｒｍＴｙｐｅもしくは明示的に言及されないすべてのＰｌａｔｆｏｒｍ
Ｔｙｐｅ（ＡＬＬＯＴＨＥＲＳ）の構成に適用される。ルールには、ＲＥＣＯＭ
ＭＥＮＤＥＤ（構成から明示的にフォース・アウトされない限り機能を含める）
、ＯＮＤＥＭＡＮＤ（機能のプロシージャが構成内の別のコンポーネントによっ
て既に参照されている場合に機能を含める）、ＥＸＰＬＩＣＩＴ（明示的に構成
にフォース・インされる場合に限って機能を含める）、およびＥＸＴＥＲＮＡＬ
ＴＲＩＧＧＥＲ（ＣｌａｓｓＰａｔｈによって指定されるコンポーネントまたは
機能が構成に含まれる場合にこの機能を含める）が含まれる。

【０１６４】 ＯＰＴＩＯＮコマンド１７２１は、機能のソース・コード・ファイルで使用す
ることができる、宣言済み定数の名前およびデフォルト値を定義する。製品構成
で指定することができるオプションの許容可能な値の名前を定義することもでき
る（図２２）。

【０１６５】 ＰＬＡＴＦＯＲＭ．ＣＦＧファイルは、ビルドに対するカスタマイズを指定す
るテキスト・ファイルであり、このファイルには、ビルドを指示するステートメ
ントが含まれる。ＯＥＭが、ＯＥＭ機能、ＯＥＭフック、およびＯＥＭファイル
・オーバーライドを識別する情報を含むのが、ＰＬＡＴＦＯＲＭ．ＣＦＧファイ
ルである。また、ＰＬＡＴＦＯＲＭ．ＣＦＧファイルは、ユーザ・インターフェ
ース２００によって保守されるが、設計者が構成パラメータを明示的に示すこと
ができる編集可能ファイルである。

【０１６６】 ＰＬＡＴＦＯＲＭ．ＣＦＧファイルにはＢＩＯＳの最小限の記述が含まれる。
この情報に基づいて、コンフィギュレータ７００が、ＢＩＯＳ構成のより包括的
な記述を導出することができる。たとえば、設計者が、あるコンポーネントをビ
ルドに含めなければならないことを明示的に宣言する場合に、コンフィギュレー
タ７００は、ＰＬＡＴＦＯＲＭ．ＣＦＧファイル内で明示的に宣言されていない
ものであっても、別のコンポーネントまたは機能もＢＩＯＳに含めなければなら
ないことを判定することができる。

【０１６７】 ＰＬＡＴＦＯＲＭ．ＣＦＧファイルに関連する複数のコマンドがある。Ｂｕｉ
ｌｄＯｐｔｉｏｎコマンドでは、特定のソフトウェア製品のビルドに固有の情報
を指定する。ＢｕｉｌｄＯｐｔｉｏｎコマンドの本体のコマンドは、格納される
情報の詳細を指定する。このコマンドには、ビルド・オプションのタイプを指定
するＴｙｐｅ、ビルド・オプションが適用される項目の名前を指定するＮａｍｅ
、および、項目にセットされる値を指定するＶａｌｕｅが含まれる。

【０１６８】 ＢｒｉｎｇＵｐＢｉｏｓコマンドは、特別な構成オーバーライドを示すのに使
用される。この特別なオーバーライドによって、コンフィギュレータ７００に、
最小限のＢＩＯＳを作るのに必要な最小限の要素の組だけを含む最小限のＢＩＯ
Ｓをビルドすることが指示される。ＢｒｉｎｇＵｐＢｉｏｓコマンドは、ＰＬＡ
ＴＦＯＲＭ．ＣＦＧファイルに１回だけ現れることができる。

【０１６９】 Ｃｌａｓｓｉｆｉｃａｔｉｏｎコマンドでは、プラットフォーム固有情報を指
定する。この情報によって、ベンダ名、エイリアス、プラットフォーム番号、リ
ビジョン番号またはバージョン番号、およびカテゴリを含む、一連のプラットフ
ォーム固有データに対する名前または値を定義することができる。

【０１７０】 Ｃｏｍｐｏｎｅｎｔコマンドでは、意図されるプラットフォーム・タイプに無
関係に、ビルドへのコンポーネントの追加、構成、または除去を指定する。コン
ポーネントの構成は、Ｃｏｍｐｏｎｅｎｔコマンド内で指定されるＦｅａｔｕｒ
ｅｓ、Ｏｐｔｉｏｎｓ、ＳｙｓｔｅｍＯｐｔｉｏｎｓ、Ｆｉｌｅｓ、およびＯｖ
ｅｒｒｉｄｅＦｉｌｅｓによって定義される。指定されたプラットフォーム・タ
イプに基づいてデフォルトで含まれる時に、コンポーネントは、ＰＬＡＴＦＯＲ
Ｍ．ＣＦＧファイルにリストされない。

【０１７１】 Ｃｏｍｐｏｎｅｎｔコマンドに、ＦｏｒｃｅＦｌａｇが含まれることが好まし
い。このフラグは、コンポーネントがビルドにフォース・インされるか、ビルド
からフォース・アウトされるか、デフォルトのビルド・インクルード依存性およ
びトリガを使用するように設定されるかを指定する。フラグにＦｏｒｃｅＩｎが
セットされた時には、それがコンポーネントの既存のデフォルト定義とマージさ
れる。コンポーネントにＮｏＦｏｒｃｅがセットされる時には、デフォルト状態
に戻るが、これは、他の依存性およびトリガ選択に依存するようになることを意
味する。コンポーネントにＦｏｒｃｅＯｕｔがセットされる時には、そのコンポ
ーネントは明示的にビルドに含まれなくなる。

【０１７２】 各Ｃｏｍｐｏｎｅｎｔコマンドに、システムに含まれるコンポーネントの名前
も含まれる。このコマンドで使用される名前は、命名されるコンポーネントの．
ＩＮＦファイルから導出される。各コンポーネントが一意の名前を有することが
好ましいので、Ｃｏｍｐｏｎｅｎｔコマンドで命名されるコンポーネントに曖昧
さがあってはならない。

【０１７３】 Ｃｏｍｐｏｎｅｎｔコマンドの括弧（Ｃｏｍｐｏｎｅｎｔコマンドに含まれる
ものを区切る）内にあるすべてのコマンドが、名前を付けられるコンポーネント
のスコープ内にあるとされる。これらのコマンドの例が、Ｆｅａｔｕｒｅコマン
ド、Ｏｐｔｉｏｎコマンド、およびＳｙｓｔｅｍＯｐｔｉｏｎコマンドである。
コンポーネント自体は、他のコンポーネントの中に配置することができない。さ
らに、Ｃｏｍｐｏｎｅｎｔコマンドは、一意のコンポーネントごとに１回だけ使
用することができる。言い換えると、同一のコンポーネントを記述する複数のＣ
ｏｍｐｏｎｅｎｔコマンドが存在することはできない。

【０１７４】 Ｆｅａｔｕｒｅコマンドを用いると、所与のコンポーネント内の機能（ｆｅａ
ｔｕｒｅ）の追加、構成、および除去が可能になる。このコマンドで名前を指定
される機能は、それがその中に存在するコンポーネントについて有効でなければ
ならない。コンポーネントと同様に、機能の構成は、Ｆｅａｔｕｒｅコマンド内
で指定されるＦｅａｔｕｒｅｓ、Ｏｐｔｉｏｎｓ、ＳｙｓｔｅｍＯｐｔｉｏｎｓ
、Ｆｉｌｅｓ、およびＯｖｅｒｒｉｄｅＦｉｌｅｓによって定義される。さらに
、Ｃｏｍｐｏｎｅｎｔコマンドと同様に、Ｆｅａｔｕｒｅコマンドには、機能が
ビルドにフォース・インされるか、ビルドからフォース・アウトされるか、依存
性およびトリガを含むデフォルト・ビルドを使用するように設定されるかを指定
するＦｏｒｃｅＦｌａｇが含まれる。

【０１７５】 すべての機能が、コンポーネント定義内に存在しなければならないが、機能を
、別の機能の定義の中で定義することができる。機能が、別の機能の中で指定さ
れる時に、内側の機能が子機能になり、外側の機能が親機能になる。機能内のす
べてのコマンドが、その機能のスコープと、その機能が定義されたコンポーネン
トのスコープに含まれるとみなされる。Ｆｅａｔｕｒｅコマンドに含まれるもの
を区切る、機能の括弧の中に配置することができるコマンドまたはステートメン
トの例に、Ｆｅａｔｕｒｅ、Ｏｐｔｉｏｎ、ＳｙｓｔｅｍＯｐｔｉｏｎ、Ｆｉｌ
ｅ、およびＯｖｅｒｒｉｄｅＦｉｌｅが含まれる。

【０１７６】 Ｆｉｌｅコマンドを用いると、追加ファイルをビルドに含めることが可能にな
る。このコマンドは、コンポーネントまたは機能のスコープ内でのみ使用可能で
ある。Ｆｉｌｅコマンドに含まれるパラメータには、ＦｉｌｅＮａｍｅおよびＦ
ｉｌｅＰａｔｈが含まれる。ＦｉｌｅＮａｍｅは、ビルドに含まれるファイルの
名前を定義する。ＦｉｌｅＰａｔｈは、ビルドに含まれるファイルの相対物理位
置を提供する。

【０１７７】 Ｏｐｔｉｏｎコマンドでは、コンポーネントおよび機能のインクルード・ファ
イルを生成するのに使用されるオプションの設定を指定する。Ｏｐｔｉｏｎコマ
ンドは、コンポーネントまたは機能のスコープ内でのみ使用可能である。Ｏｐｔ
ｉｏｎコマンドに含まれるパラメータには、Ｎａｍｅ、Ｖａｌｕｅ、ＲｏｍＥｄ
ｉｔＦｌａｇ、およびＤｅｓｃｒｉｐｔｉｏｎが含まれる。Ｎａｍｅパラメータ
では、変更するオプションの名前を定義する。Ｖａｌｕｅパラメータでは、．Ｉ
ＮＦファイル内のオプションによって定義される有効な値を示す。ＲｏｍＥｄｉ
ｔＦｌａｇパラメータは、ブール値であり、このオプションについてＲｏｍＥｄ
ｉｔがイネーブルされるか否かを示す。Ｄｅｓｃｒｉｐｔｉｏｎパラメータは、
オプション・パラメータであり、ＲｏｍＥｄｉｔユーティリティに表示すること
ができるオプションの説明を提供する。

【０１７８】 ＯｖｅｒｒｉｄｅＦｉｌｅコマンドは、コンポーネント・ファイルをオーバー
ライドする。ファイル・バージョンによって、オーバーライドが新しくない場合
に、設計者に警告を表示することができる。このコマンドは、コンポーネントま
たは機能のスコープ内でのみ使用可能である。新しいオーバーライドするファイ
ルの名前は、オーバーライドされるファイルと同一でなければならない。Ｏｖｅ
ｒｒｉｄｅＦｉｌｅコマンドのパラメータには、オーバーライド・ファイルの名
前を提供するＦｉｌｅＮａｍｅ、オーバーライド・ファイルの相対物理パスを提
供するＮｅｗＰａｔｈ、および元のファイルのバージョンを提供するＯｒｉｇｉ
ｎａｌＶｅｒｓｉｏｎが含まれる。

【０１７９】 ＰｌａｔｆｏｒｍＴｙｐｅコマンドでは、ビルドに関するプラットフォームの
タイプを指定する。このコマンドは、指定されたプラットフォーム・タイプに基
づいて、デフォルトのコンポーネントおよび機能を含めるのに使用される。ＰＬ
ＡＴＦＯＲＭ．ＣＦＧファイル内で、１つのＰｌａｔｆｏｒｍＴｙｐｅコマンド
だけを使用することができる。ＰｌａｔｆｏｒｍＴｙｐｅコマンドのパラメータ
には、プラットフォームの名前を定義するＮａｍｅと、ＣＰＵおよび命令セット
によって判定され、同一のコードを実行するシステムのグループを指定するＡｒ
ｃｈｉｔｅｃｔｕｒｅが含まれる。Ａｒｃｈｉｔｅｃｔｕｒｅパラメータは、た
とえば、ＩＡ−３２命令セット・アーキテクチャについてＩＡ３２、ＩＡ−６４
命令セット・アーキテクチャについてＩＡ６４とすることができる。

【０１８０】 ＳｙｓｔｅｍＯｐｔｉｏｎコマンドは、ビルド記述のスコープ全体にまたがっ
て可視のオプションを確立するのに使用される。事前に定義されたオプションを
、グローバル・レベル、コンポーネント・レベル、または機能レベルなど、処理
の異なるレベルでセットし、リセットすることができる。ＳｙｓｔｅｍＯｐｔｉ
ｏｎコマンドのパラメータには、ＮａｍｅおよびＶａｌｕｅが含まれる。Ｎａｍ
ｅパラメータでは、ビルド記述に関連するＳｙｓｔｅｍＯｐｔｉｏｎの名前を与
える。この名前は、事前に定義されたオプションの組の１つでなければならない
。Ｖａｌｕｅパラメータによって、名前を付けられたＳｙｓｔｅｍＯｐｔｉｏｎ
に関連する値を示す。

【０１８１】 図１８に、ソース・ライブラリＡのコンポーネント・データベース１８００の
表現を象徴的に示す。各コンポーネントのデータが長方形に含まれて図示されて
いる。２つのコンポーネント、コンポーネントＡ１８０２およびコンポーネント
Ｂ１８０４が図示され、他のコンポーネントは、たぶん存在するが、明瞭さと単
純さのために省略されている。コンポーネントＡ１８０２のデータの詳細だけが
図示されている。

【０１８２】 各コンポーネントが名前および説明を有する（行１８０６）。各コンポーネン
トが、データ・オプション・テーブルを有する。このデータ・オプション・テー
ブルは、このコンポーネント内のソース・コード・ファイルに影響するすべての
ユーザ設定可能オプション１８０８をリストしたテーブルである。これらのオプ
ションは、ユーザ・インターフェースの使用を介して調整され（たとえば図３３
Ｅを参照されたい）、オプション値は、リンカ３６００が完成した製品１１０６
をビルドする時に、「フィックスアップ」処理の一部として、製品コンポーネン
ト・リンカ３６００（図３６）によってバイナリ・イメージに実際にロードされ
る。コンポーネントについて指定されたすべてのコンパイル・オプション、アセ
ンブル・オプション、およびリンク・オプション１８１０が、存在する。

【０１８３】 コンポーネントを、そのディレクトリにソース・コード・ファイルが含まれる
場合に、その「ｃｏｍｐｏｎｅｎｔ．ｉｎｆ」ファイルによってクラスに割り当
てることができるが、好ましい実施形態の現在のプラクティスは、ソース・コー
ド・ファイルを機能サブディレクトリに置き、各機能をその「ｆｅａｔｕｒｅ．
ｉｎｆ」ファイルによってクラスに割り当てることである。したがって、すべて
の機能が明確にクラスに割り当てられる。したがって、複数の機能を、図示のよ
うにデータベース内でクラスによって編成することができる。２つのクラス、ク
ラスＡ１８１２およびクラスＢ１８１４が図示されている。クラスＡ１８１２内
に、２つの機能、機能１ １８１６および機能２ １８１８（機能２の詳細は図
示されていない）がある。たぶん、通常のシステムは、多数の機能ならびにサブ
機能などを有することができる。機能１ １８１６は、名前および説明１８２０
、データ・オプション・テーブル１８２２（本質的にコンポーネントのそれらと
同一であるが、機能ソース・コード・ファイルに適用可能である）、コンパイラ
・オプションおよびリンク・オプション１８２４（機能ソース・コード・ファイ
ルが別々にコンパイルされ、アセンブリされ、かつ／またはリンクされる場合に
）、機能ソース・コード・ファイルの名前１８２６、および、これらのソース・
コード・ファイルへのエントリ１８２８およびそれらからのエグジット１８３０
（ほかの場合には、より正確に、インターフェースおよび依存性と呼ばれる）の
完全なリストを有する。

【０１８４】 図１９および２０は、図１８に示されたデータベースに類似する形で編成され
た、構成状態データ１９００内に含まれるデータ構造体の象徴的表現である。３
つのコンポーネント、コンポーネントＡ１９０２、コンポーネントＢ１９０４、
およびコンポーネントＣ１９０６が図示され、それぞれに、所与のコンポーネン
トが完成した製品１１０６に含めるために選択されているか否かを示すために「
×」を伴うか伴わない可決正方形によって象徴的に表される「選択」または「非
選択」フラグが設けられる。コンポーネントＡおよびＣのフラグ１９２２および
１９３０は、「×」を伴って図示され、これらのコンポーネントが、現在、完成
した製品１１０６の一部であることが示される。コンポーネントＢのフラグ１９
２８は、「×」なしで図示され、デフォルトでまたはシステム設計者介入のゆえ
にのいずれかで、このコンポーネントが選択されていないことが示される。コン
ポーネントＡは、名前および説明１９０８を有し、そのフラグ１９２４からそれ
が選択されていないことが示される機能１ １９１０と、そのフラグ１９２６か
ら（「×」によって）それが選択されていることが示される機能２ １９１２を
有する。機能１ １９１０は、クラス割当１９１４、それに割り当てられるソー
ス・コード・ファイル１９１６、オプションの定義１９１７、および参照１９１
９（依存性およびインターフェース）を有するものとして図示されている（ＲＡ
Ｍ内のこのデータの構造体のより詳細な図が、上で説明した、下の図３２に示さ
れている）。

【０１８５】 図１９は、単に、選択されたコンポーネントおよび機能のデータ２０００が、
構成状態データからとられ、完成した製品１１０６を作成する時に製品メイク・
ルーチン９００に渡されることを示している。図示されているように、オプショ
ンのグローバル定数が、製品コンポーネント・リンカ３６００によって完成した
製品１１０６に適用される「フィックスアップ」データの一部としての使用のた
めに渡される。選択されたコンポーネントＡ２００２およびＣ２００４が、選択
されたコンポーネントの一部である選択された機能のそれぞれの機能データと一
緒に渡される。選択された機能２ ２００６は、選択フラグ１９２６がセットさ
れた、図１９の機能２ １９１２に対応する。この機能２ ２００６には、その
ソース・コード・ファイルの名前２００８、ならびにこれらのソース・コード・
ファイルからのエグジット２０１０および他の依存性およびインターフェース、
ならびに機能固有オプションに割り当てられる機能固有定数２０１２が付随する
。

【０１８６】 図２１に、付録ＡのパスＣ：￥ＢＩＯＳ￥ＤＥＶＲＥＦ￥ＩＮＴＥＬ￥４４０
ＢＸ￥ＰＬＡＴＦＯＲＭ．ＣＦＧに示されたＤｅｓｋＴｏｐプラットフォーム２
１０２の製品構成データを提示する。これは、コンポーネントＣＯＲＥ（図１４
）を含む構成である。本発明のこの部分には、製品の構成に使用されるコマンド
が含まれる（図２２）。

【０１８７】 ＰＬＡＴＦＯＲＭＴＹＰＥコマンド２１０２は、この構成が、ＩＡ３２アーキ
テクチャ上で走るＰｌａｔｆｏｒｍＴｙｐｅ「ＤｅｓｋＴｏｐ」用であることを
示す。ＤｅｓｋＴｏｐ（Ｒｕｌｅ）またはＡｌｌＯｔｈｅｒｓ（Ｒｕｌｅ）を指
定するコンポーネント情報ファイル内のＰｌａｔｆｏｒｍＴｙｐｅ（ＩＡ３２）
コマンドを含むすべてのコンポーネントが、そのＲｕｌｅに従って、構成に含め
るために検討される。同様に、ＤｅｓｋＴｏｐ（Ｒｕｌｅ）またはＡｌｌＯｔｈ
ｅｒｓ（Ｒｕｌｅ）を指定する機能情報ファイル内のＰｌａｔｆｏｒｍＴｙｐｅ
（ＩＡ３２）コマンドを含むコンポーネントのすべての機能が、そのＲｕｌｅに
従って、構成に含めるために検討される。

【０１８８】 ＣＯＭＰＯＮＥＮＴコマンド２１０４を用いると、コンポーネントＰＮＰのた
めに追加のソース・ファイルを構成できるようになる。

【０１８９】 ＦＩＬＥコマンド２１０８を用いると、現在のコンポーネント・ソース・コー
ド・ライブラリ内のディレクトリ￥ＤＥＶＲＥＦ￥ＩＮＴＥＬ￥４４０ＢＸから
の追加のソース・コード・ファイルＭＹＦＩＬＥ．ＡＳＭを、コンポーネントＰ
ＮＰの一部として構成に含めることができるようになる。

【０１９０】 図２２に、本発明のプラットフォーム構成ファイル内の可能なコマンドのリス
トを示す。太字の名前は、キーワードであり、太字でない名前は、設計者によっ
て指定される。文字「／／」は、その行の残りがコメントであることを示す。コ
マンドの括弧｛｝の間にあるすべてのコマンドが、そのコマンドのスコープ内に
あるとみなされる。

【０１９１】 ＳＹＳＴＥＭＯＰＴＩＯＮコマンド２２０２は、製品構成内のすべてのソース
・コード・ファイル内で使用可能なオプション名および値を確立するのに使用さ
れる。ＦＥＡＴＵＲＥコマンド２２１０を用いると、所与のコンポーネント内の
機能の追加、除去、または構成が可能になる。機能構成２２１２は、その機能の
開き括弧および閉じ括弧｛｝内で定義されるＦｅａｔｕｒｅコマンド、Ｏｐｔｉ
ｏｎコマンド、ＳｙｓｔｅｍＯｐｔｉｏｎコマンド、Ｆｉｌｅコマンド、および
ＯｖｅｒｒｉｄｅＦｉｌｅコマンドとして、本発明によって定義される。

【０１９２】 ＯＶＥＲＲＩＤＥＦＩＬＥコマンド２２１６は、コンポーネント・コマンドま
たは機能コマンド内で、そのコンポーネントまたは機能のファイルを、その代わ
りに指定されたｎｅｗｐａｔｈを使用することによってオーバーライドするのに
使用される。ＯＰＴＩＯＮコマンド２２１８は、コンポーネント・コマンドまた
は機能コマンド内で、そのコンポーネントまたは機能の情報ファイル内で定義さ
れたオプションの名前および新しい値を指定するのに使用される。オプションの
新しい値は、そのコンポーネントまたは機能に関して生成される機能インクルー
ド・ファイルに現れる。

【０１９３】 図２３に、付録ＡのパスＣ：￥ＢＩＯＳ￥ＣＯＲＥ￥ＢＥＥＰ￥ＦＥＡＴＵＲ
Ｅ．ＩＮＣに示された機能インクルード・ファイルを提示する。これは、ソース
・コード・ファイルＢＥＥＰ．ＡＳＭ（図１３）がアセンブルされる時にインク
ルードされる機能インクルード・ファイルである。Ｄ＿ＴＩＭＥＲ＿ＤＥＬＡＹ
変数は、図１３のマクロＰＵＢＥＸＴ１３１２（マクロの行単位の説明の節２．
１）およびＥＸＴＣＡＬＬ１３１８（マクロの行単位の説明の節１．１）が期待
するｄｅｆｉｎｅＮａｍｅである。

【０１９４】 図２４に、本発明によって生成された、付録ＡのパスＣ：￥ＢＩＯＳ￥ＣＯＲ
Ｅ￥ＭＡＫＥＦＩＬＥに示されたコンポーネントＣＯＲＥのコンポーネント・メ
イクファイルを提示する。コンポーネントＣＯＲＥ（図１４）には、ソース・コ
ード・ファイルＢＥＥＰ．ＡＳＭ（図１３）を含む機能ＢＥＥＰ（図１６）が含
まれる。メイクファイルは、デフォルトでＭＡＫＥＦＩＬＥという名前のファイ
ルについてｍａｋｅプログラムが現在の作業ディレクトリをヒストリカルに調べ
るのでこう呼ばれるが、メイクファイルには、ｍａｋｅプログラムによって解釈
されるコマンドが含まれる。

【０１９５】 ＥＸＴＡＳＭＳ２４０４は、アセンブルされる外部アセンブリ・ソース・ファ
イルのそれぞれのパスを含むマクロとして定義される。各行の終りのバックスラ
ッシュ＼は継続を示す。ジェネリック・ルール２４３６によって、．ＡＳＭ拡張
子を有するファイルを．ＯＢＪ拡張子を有する同一のファイルに変換するのに必
要なアセンブラ・コマンド・ラインが指定される。ＣＯＭＰＯＮＥＮＴ＿ＮＡＭ
Ｅルール２４４０では、マクロＥＸＴＡＳＭＳおよびＡＳＭＳによって定義され
たすべてのアセンブリ・ソース・ファイルから作られたオブジェクト・ファイル
からコンポーネントをリンクするリンカ・コマンド・ラインが指定される。副作
用として、存在しないオブジェクト・ファイルが、ジェネリック・ルール２４３
６を使用してアセンブリ・ソースから生成される。ＣＬＥＡＮルール２４５６は
、ｍａｋｅプログラムのコマンド・ライン（図２５）で明示的に指定されなけれ
ばならない。これは、ＣＯＲＥコンポーネント・メイクファイルによって生成さ
れたファイルを削除し、その結果、次にＣＯＲＥコンポーネント・メイクファイ
ルが解釈される時に、すべてのファイルが再生成されるようにする。

【０１９６】 図２５に、本発明によって生成される、コンポーネントＣＯＲＥ（図２４）を
含む製品をビルドするのに使用される製品メイクファイルを提示する。ＢＩＯＳ
．ＲＯＭルール２５０２は、この構成内の各コンポーネントを含むディレクトリ
に進み、本発明によってそのディレクトリ内で生成されたコンポーネント・メイ
クファイルを解釈するためにＮＭＡＫＥＲメイク・ユーティリティを実行する。
これによって、コンポーネントごとに、オブジェクト・ファイルのリンクされた
組「＊．ｅｘｅ」ファイルが作られる。このフォーマットを用いると、宣言され
たパブリック・インターフェース、依存性、およびリソース使用を表示するよう
に設計された統計ツールとしてのコンポーネントの実行が可能になる。これらの
リンクされたファイルを、製品コンポーネント・リンカ「ＢＩＮＬＩＮＫ」３６
００（図３６）によって単一のＲＯＭイメージ実行可能ファイルにマージするこ
とができる。

【０１９７】 ＣＬＥＡＮルール２５３２は、構成内の各コンポーネントを含むディレクトリ
に進み、各コンポーネント・メイクファイル（図２４）のＣＬＥＡＮルールを実
行し、その後、プラットフォーム構成ファイルを含むディレクトリに進み、ビル
ド処理で生成されたファイルをクリーン・アップし、すべてのファイルが次のビ
ルドによって再生成されるようにする。

【０１９８】 図２６に、コンポーネント・ソース・コード・ライブラリ１２００をスキャン
するデータベース更新ルーチン４００を示す。検索は、コンポーネント・ソース
・コード・ライブラリ１２００のルート・ディレクトリでコンポーネントを探す
ことによって開始され２６０２、このコンポーネントは、「ＣＯＭＰＮＥＮＴ．
ＩＮＦ」という名前のコンポーネント情報ファイルを含むルート・ディレクトリ
のサブディレクトリである２６０４。コンポーネントのそれぞれについて２６０
６、ファイル・スキャン・ルーチン２７００を呼び出して、コンポーネント・デ
ィレクトリ内にある可能性があるコンポーネント情報ファイル２６１０と、ソー
ス・ファイルまたはインクルード・ファイル２６１２をスキャンする。その後、
検索をコンポーネント・ディレクトリ内で継続して、コンポーネントの機能を探
すが、この機能は、「ＦＥＡＴＵＲＥ．ＩＮＦ」という名前の機能情報ファイル
を含むコンポーネント・ディレクトリに従属するディレクトリである２６１４。
機能のそれぞれについて２６１６、ファイル・スキャン・ルーチン２７００を呼
び出して、機能情報ファイル２６２０と、機能ディレクトリ内のソース・ファイ
ルおよびインクルード・ファイル２６２２をスキャンする。

【０１９９】 図２７に、ファイル・スキャン・ルーチン２７００を示す。ファイルをスキャ
ンするためにデータベース更新ルーチン（図２６）によって呼び出された時に、
ファイル・スキャン・ルーチンは、スキャンされるファイルが最後に修正された
日付および時刻をデータベースから入手し２７１６、ファイル自体からの最後の
修正の日付および時刻と比較する２７０２。ファイルが変更されていない場合に
は、データベースを更新しない２７０４。ファイルが変更されたか、ファイル・
スキャン・ルーチンが変更入力ルーチン２０６（図１１）によって呼び出された
場合には、ファイルをスキャンする２７０６。ファイルが、「ＣＯＭＰＮＥＮＴ
．ＩＮＦ」という名前のコンポーネント情報ファイルである場合には２７０８、
コンポーネント情報をデータベース２７１６に追加する２７０９。ファイルが、
「ＦＥＡＴＵＲＥ．ＩＮＦ」という名前の機能情報ファイルである場合には２７
１０、機能情報をデータベース２７１６に追加する２７１１。そうでない場合に
は、ファイルは、ソース・ファイルまたはインクルード・ファイルである２７１
２。ファイル内のエグジット宣言マクロ、エントリ・マクロ、インクルード・マ
クロ、およびリスト・マクロのパラメータからの情報を、データベース２７１６
に追加する２７１４。

【０２００】 図２８に、コンフィギュレータ・プロシージャ２８００の全般的な流れを示す
が、これは、初期活動化２９００（図２９）から始まり、製品構成３０００（図
３０）を介して継続され、有効な構成（図３３Ａ）または互換性のないインター
フェース、欠けているコンポーネントなど（図３３Ｂ）を表示する構成状態の報
告２８０６で終わる。

【０２０１】 コンフィギュレータ・プロシージャ２８００の初期活動化２９００は、製品構
成データ２１００からプラットフォーム・タイプ２１０２を取り出すことによっ
て開始される。その後、データベース１８００から、指定されたプラットフォー
ム・タイプで許容されるか必須であるコンポーネントに関するすべてのコンポー
ネント情報を読み取り２９０４、製品コンフィギュレータ状態データ１９００を
ランダム・アクセス・メモリ内に作成する。製品コンフィギュレータ状態データ
１９００には、各機能のソース・ファイルと、これらのソース・ファイル内のＰ
ＵＢＬＩＣ＿ＰＲＯＣマクロおよびＰＵＢＥＸＴマクロのそれぞれのパラメータ
が含まれる。製品構成ルーチン３０００による各機能の活動化（３００４、３０
０８、３０１０、３０１４）の際に、各ＰＵＢＥＸＴマクロによってそのソース
・ファイル内で参照されるプロシージャが未解決の参照のリストに追加される。
製品構成ルーチン３０００は、フォース・アウトを指定された（３３３５、２２
０４、２２１０、２２０８）オブジェクトを活動化しないように注意して３００
２、以下のステップに進む。

【０２０２】 ステップＡ３００４で、フォース・インを指定された（３３３３、２２０４、
２２１０、２２０８）すべてのオブジェクト（コンポーネントまたは機能）およ
びその親を製品コンフィギュレータ状態データ１９００内でアクティブ状態に設
定する。ステップＢ３００６で、すべての推奨されるコンポーネント・オブジェ
クト（１５１０、１５１４、１５１６）を製品コンフィギュレータ状態データ１
９００内でアクティブ状態に設定する。ステップＣ３００８で、製品コンフィギ
ュレータ状態データ１９００内のすべてのアクティブ・オブジェクトについて、
すべての推奨される子（１７１０、１７１４、１７１６）をアクティブ状態に設
定し、繰り返す。ステップＤ３０１０で、外部トリガとしてクラスを指定された
（１５１８、１７１８）、コンポーネント・オブジェクトまたはアクティブ・オ
ブジェクトの子のそれぞれについて、そのクラスのオブジェクトが製品コンフィ
ギュレータ状態データ１９００でアクティブである場合に、外部トリガされるオ
ブジェクトをアクティブ状態に設定する。ステップＥ３１００で、外部参照を解
決し（図３１）、未解決の参照および解決された参照の一致しないバージョンの
リストを維持する。ステップＦ３０１４で、アクティブに設定できるオブジェク
トがなくなり、未解決のままの参照がなくなるまで、ある機能が未解決の参照を
解決し、オン・デマンドであり（１７１６）、すべての親オブジェクトがアクテ
ィブまたはオン・デマンドである（１５１６、１７１６）場合に、そのオブジェ
クトおよび製品コンフィギュレータ状態データ１９００内のすべての親オブジェ
クトをアクティブ状態に設定し、ステップＣ、Ｄ、およびＥを繰り返す。

【０２０３】 外部参照解決ルーチン３１００は、未解決の参照のリストからＰＵＢＥＸＴマ
クロ（マクロの行単位の説明の節２．１）によって宣言されたプロシージャ参照
をとり、一致する名前を有するＰＵＢＬＩＣ＿ＰＲＯＣマクロ（マクロの行単位
の説明の節３．１）によって定義されたすべてのプロシージャを見つける３１０
２。一致するＰＵＢＥＸＴマクロのｎａｍｅパラメータおよびＰＵＢＬＩＣ＿Ｐ
ＲＯＣマクロのｐｒｏｃｅｄｕｒｅｎａｍｅパラメータの両方が、ピリオドによ
って区切られた、クラス名、０個以上のサブクラス名、および実際のプロシージ
ャ名からなるクラス・パスを有する。クラス・パスは、コンポーネント・ソース
・コード・ライブラリ１２００内での定義の位置を含むソース・ファイルの位置
から独立のコンポーネント、機能、およびサブ機能の階層内で特定のプロシージ
ャを識別するように働く。クラス・パスは、同一の名前を有する他のコンポーネ
ント内のプロシージャが異なるクラス・パスを有するので、それらと衝突しない
。同一のクラス・パスを有する複数の定義がある場合３１０４には、定義のＰＵ
ＢＥＸＴマクロでコンポーネント名が指定される場合３１０６に、名前を指定さ
れたコンポーネントの定義を選択する３１０８。また、定義のＰＵＢＬＩＣ＿Ｐ
ＲＯＣでＩＮＴＥＲＣＥＰＴキーワードが指定された場合３１１０には、その定
義を選択する３１１２。そうでない場合には、未解決の参照のリストからその参
照を除去し、複数の定義が見つかったことの表示を返す３１１４。一致する定義
が見つかり３１１６、定義がアクティブな機能のソース・ファイル内３１１８ま
たはオン・デマンド（１７１６）を指定されたアクティブでない機能のソース・
ファイル内３１２２にある場合に、参照を未解決の参照のリストから除去し、成
功を返す３１２０。参照のＰＵＢＥＸＴマクロで、ＡＬＴＥＲＮＡＴＥキーワー
ドが指定された場合３１２４、ａｌｔｎａｍｅパラメータによって指定されたク
ラス・パスを使用し３１２６、もう一度試行する３１２８。参照のＰＵＢＥＸＴ
マクロでＯＰＴＩＯＮＡＬキーワードが指定された場合３１３０、定義は不要で
あり、参照を未解決の参照のリストから除去し、定義なしを返す３１３２。そう
でない場合には、参照を未解決の参照のリストから除去し、一致なしを返す３１
３４。

【０２０４】 上で説明した図３０、３１に、製品のアクティブな機能を決定するための構成
の処理の全般的なアルゴリズムを提示する。構成処理の詳細な仕様を、付録Ｊお
よびＫに示す。

【０２０５】 図３２は、上で図１１に関して説明した。

【０２０６】 図３３Ａに、本発明を使用して、ＩＡ３２アーキテクチャ３３０８用の「Ｄｅ
ｓｋｔｏｐ」プラットフォームの「ＰＯＳＴ Ｓｅｒｖｉｃｅｓ」コンポーネン
ト３３０６の「Ｄｅｃｏｍｐｒｅｓｓ Ｍａｎａｇｅｒ」機能３３０４のソース
・ファイルＷＯＲＫＡＤＤＲ．ＡＳＭ３３０２を修正する間に設計者が見るビュ
ーを提示する。これは、ディレクトリ階層を示すコンポーネント・ソース・コー
ド・ライブラリの物理ビューではなく、図３３Ｆに示されたアイコンを使用して
、コンポーネントおよび機能を示すコンポーネント・ソース・コード・ライブラ
リ（図１２）の論理ビューである。アイコンから、「ＦＤｉｓｋ」３３１０およ
び「ｋｃＭａｎａｇｅｒ」３３１２コンポーネントがビルドからフォース・アウ
トされ、「Ｉｎｔｅｌ３７１ａｂ」３３１４および「Ｉｎｔｅｌ４４０ＢＸ」３
３１６がビルドにフォース・インされていることが示される。

【０２０７】 図３３Ｂに、本発明を使用する間に設計者が見る、コンポーネント「ＦＤｉｓ
ｋ」３３１０がもはやビルドからフォース・アウトされない、図３３Ａと同一の
コンポーネント・ソース・コード・ライブラリの論理ビューを提示する。アイコ
ン（図３３Ｆで説明する）から、コンポーネント「ＦＤｉｓｋ」３３１０、機能
「ａｔａ」３３１８、およびファイル「ＦＤＳＫＩＮＩＴ．ＡＳＭ」３３２０が
エラーを有することと、クラス「ＦＤｉｓｋ」３３２２の関数「ｐｒｏｔｏｃｏ
ｌＴａｂｌｅ」およびクラス「ｐｉｃ」３３２４の関数「ＳｅｎｄＥ０１」のパ
ブリック関数依存性がエラーを有することが示される。

【０２０８】 図３３Ｃに、図３３Ｆで説明するアイコンを使用する、図３３Ａおよび３３Ｂ
に示されたコンポーネント・ソース・コード・ライブラリの別の部分の論理ビュ
ーを示す。この論理ビューには、本発明を使用するシステム設計者が、コンポー
ネント「Ｉｎｔｅｌ４４０ＢＸ」３３３０の機能「Ｍｅｍｏｒｙ Ｃｏｎｆｉｇ
ｕｒａｔｉｏｎ」３３２８のオーバーライド・ファイル「ＥＡＲＬＹＣＦＧ．Ａ
ＳＭ」３３２６を右クリックすることによって見るものが示されている。この図
には、ファイル「ｏｅｍｆｉｌｅ．ａｓｍ」３３３２が、図３３Ｄに示された本
発明のウィンドウの「Ａｄｄ Ｃｕｓｔｏｍ Ｆｉｌｅ」行を使用して追加され
たカスタム・ファイルであることも示されている。

【０２０９】 図３３Ｄに、図３３Ｆで説明するアイコンを使用する、図３３Ａに示されたコ
ンポーネント・ソース・コード・ライブラリの部分の論理ビューを示す。この論
理ビューには、本発明を使用するシステム設計者が、ビルドからフォース・アウ
トされたコンポーネント「ＦＤｉｓｋ」３３１０を右クリックすることによって
見るものが示されている。

【０２１０】 図３３Ｅに、図３３Ｆで説明するアイコンを使用する、図３３Ｂに示されたコ
ンポーネント・ソース・コード・ライブラリの異なる部分の論理ビューを示す。
この論理ビューには、本発明を使用するシステム設計者が、コンポーネント「Ｉ
ｎｔｅｌ４４０ＢＸ」３３３０の「ＣａｃｈｅＬｉｎｅＳｉｚｅ」オプション３
３３６を右クリックすることによって見るものが示されている。「ＣａｃｈｅＬ
ｉｎｅＳｉｚｅ」オプションは、現在、１６進数で０４の値を有する。このウィ
ンドウを用いて、システム設計者が、現在の値を修正するか、コンポーネント情
報ファイルで指定されたデフォルト値にリセットすることができる。

【０２１１】 図３３Ｆに、図３３Ａから図３３Ｄに示された本発明のコンポーネント・ソー
ス・コード・ライブラリの論理ビューに現れるアイコンを提示する。各アイコン
が、論理ビューの異なる要素を表し、要素がＢＩＯＳ構成に含まれない時に、よ
り明るい色を有する。構成にフォース・インされたコンポーネントおよび機能の
アイコンには、チェック・マークが示され、構成からフォース・アウトされたコ
ンポーネントおよび機能のアイコンは、より明るい色を有し、スラッシュが貫通
している円が示される。エラーを有する要素は、×を有するアイコンが示され、
警告を有する要素は、感嘆符を含む三角形を伴うアイコンが示される。

【０２１２】 図３４に、製品メイク・ルーチン８００を示す。製品コンフィギュレータ状態
データ１９００内のアクティブ・コンポーネントのそれぞれについて３４０２、
アクティブ・コンポーネントのアクティブ機能のそれぞれについて３４０４、こ
のルーチンは機能インクルード・ファイルを作成し９５０（図３５）、その後、
現在の機能のソース・コード・ファイルのそれぞれについて３４０６、現在のコ
ンポーネントのコンポーネント「メイク」ファイルに、そのソース・コード・フ
ァイルをコンパイルする方法を説明するコマンドを追加する３４０８。現在のコ
ンポーネントのアクティブ機能のすべてを処理した時に、ＢＩＯＳコンポーネン
トを形成するためにリンクを行う方法を説明するコマンドを、現在のコンポーネ
ントのコンポーネント「メイク」ファイルに追加する３４１０。すべてのアクテ
ィブ・コンポーネントを処理した時に、各コンポーネント「メイク」ファイルを
実行するコマンドと製品コンポーネント・リンカを実行するコマンドを含む製品
「メイク」ファイル（図１０）を作成する９０８。その後、メイク・ユーティリ
ティ・プログラムを呼び出して、製品「メイク」ファイルのコマンドを実行する
１０００。

【０２１３】 図３５に、ビルド機能インクルード・ファイル・ルーチン９５０を示す。機能
の各ファイル内のＰＵＢＩＮＣマクロ（マクロの行単位の説明の節６．２）のそ
れぞれについて３５０２、このルーチンは、そのｃｌａｓｓｐａｔｈパラメータ
からＩ＿ＣＬＡＳＳＰＡＴＨシンボルを生成し３５０４、その後、インクルード
・ファイルを含むディレクトリのパスとしてＩ＿ＣＬＡＳＳＰＡＴＨシンボルを
定義するアセンブラ・ステートメントを追加する３５０６。たとえば、ＰＵＢＩ
ＮＣマクロのｃｌａｓｓｐａｔｈパラメータが「ｐｏｓｔ．ｄｉｓｐａｔｃｈｅ
ｒ」である場合に、ＰＵＢＩＮＣマクロは、Ｉ＿ＰＯＳＴ＿ＤＩＳＰＡＴＣＨＥ
Ｒという名前のＩ＿ＣＬＡＳＳＰＡＴＨシンボルが定義されることを期待する。
すべてのＰＵＢＩＮＣマクロを処理した時に、機能の各ファイル内のＰＵＢＥＸ
Ｔマクロのそれぞれについて３５０８、このルーチンは、ｎａｍｅパラメータか
らＤ＿ＮＡＭＥシンボルを生成する。ｎａｍｅパラメータによって指定されるパ
ブリック・プロシージャがビルドに含まれる場合に、このルーチンは、Ｄ＿ＮＡ
ＭＥシンボルをＴＲＵＥとして定義するアセンブラ・ステートメントを追加し３
５１４（図２３）、そうでない場合には、Ｄ＿ＮＡＭＥシンボルをＦＡＬＳＥと
して定義するアセンブラ・ステートメントを追加し、ＰＵＢＥＸＴマクロでＡＬ
ＴＥＲＮＡＴＥキーワードが指定される場合に、ＰＵＢＥＸＴマクロのａｌｔｎ
ａｍｅパラメータからＤ＿ＡＬＴＮＡＭＥシンボルを生成し、Ｄ＿ＡＬＴＮＡＭ
ＥシンボルをＴＹＰＥ＿ＲＥＳＥＲＶＥＤ＿ＴＲＵＥとして定義するアセンブラ
・ステートメントを追加する。たとえば、ＰＵＢＥＸＴマクロのｎａｍｅ（また
はａｌｔｎａｍｅ）パラメータが、「ｔｉｍｅｒ．ｄｅｌａｙ」である１３１２
場合には、ＰＵＢＥＸＴマクロは、Ｄ＿ＴＩＭＥＲ＿ＤＥＬＡＹという名前のＤ
＿ＮＡＭＥ（またはＤ＿ＡＬＴＮＡＭＥ）シンボルが定義されることを期待する
。

【０２１４】 図３６に、シンボリック・ネーム「ｂｉｎ＿ｌｉｎｋ」を割り当てられたルー
チンである製品コンポーネント・リンカ３６００の流れ図を提示する。このルー
チンは、コンパイラおよびアセンブラによって作られる「＊．ｏｂｊ」オブジェ
クト・コード・ファイルをリンクするために通常のリンカが呼び出される時に生
成される「＊．ｅｘｅ」実行可能バイナリ・ファイルを入力データとして受け入
れる。このルーチンは、やはり普通のリンカによって生成される「＊．ｍａｐ」
ファイルも入力として受け入れ、このファイルから、生成されたコード・セグメ
ントの名前と、それらが「＊．ｅｘｅ」ファイル内のどこに常駐するかを知る。
このルーチンは、１つまたは複数のスクリプト・コマンド・ファイル「ｂｉｏｓ
．ｓｃｒ」も設計者から直接に受け取り、この「ｂｉｏｓ．ｓｃｒ」には、異な
る実行可能ファイルに対してこのルーチンがどのように進行するか、すなわち、
セグメントが最終的なＲＯＭイメージを占める順序、一部のセグメントへの絶対
アドレスの割当などに関するディレクティブが含まれる。好ましい実施形態では
、製品コンポーネント・リンカ「ＢＩＮＬＩＮＫ」３６００（図３６）が、すべ
ての実行可能イメージのアドレッシングなどをフィックス・アップし、実行可能
ファイルから抽出されたさまざまな名前のセグメントを一緒に組み合わせた後に
、統一されたＲＯＭイメージを形成するために実行可能ファイルを一緒につなぎ
合わせることをせず、実行可能イメージの圧縮および必要な場合のイメージの複
製などの作業を実行しない。これらの作業は、「ｒｏｍ＿ｉｍａｇｅ」という名
前のルーチンによって実行され、この「ｒｏｍ＿ｉｍａｇｅ」は、出力ファイル
「ｂｉｏｓ．ｓｃｒ」を「ｂｉｎ＿ｌｉｎｋ」から受け取り、これらの最終的な
作業を実行すると同時に、サウンド・ファイルおよびイメージ・ファイルを実際
の最終的なＲＯＭ化可能イメージに統合する作業を実行する。

【０２１５】 製品コンポーネント・リンカ３６００に流れる入力制御情報を図３７に示し、
下で説明する。完成した製品に含まれるコンポーネントのリストから開始し、検
査される「＊．ｅｘｅ」ファイルを設計者が指定したコンポーネント（通常はコ
ンポーネント・サブディレクトリで見つかる）に制限し；リンカが生成した「＊
．ｍａｐ」ファイルから得た情報を使用して、「＊．ｅｘｅ」ファイルのそれぞ
れに含まれる名前付きセグメントを突き止め、分離し；選択されたコンポーネン
ト「＊．ｅｘｅ」ファイルを直接に操作することによって、製品コンポーネント
・リンカ３６００は、以下で完成した製品１１０６の「ビルド・コンポーネント
」と呼ぶ名前付きコード・セグメントのすべてを、各「＊．ｅｘｅ」ファイル内
で識別することができる。完成した製品で単一のセグメントに含まれる予定の実
行可能オブジェクトのコードおよびデータが、多数の異なる「＊．ｅｘｅ」実行
可能ファイル全体に分散されていることが多い。同様に、製品コンポーネント・
リンカのオペレーションを制御することが意図され、その後、破棄され、完成し
た製品１１０６に含まれないデータも、通常は多数の異なる「＊．ｅｘｅ」ファ
イルファイルにまたがって分散される。しかし、必ず２つの「フィックスアップ
」データ・セグメントであるパブリック・セグメント３８０４（図３８）（「ｐ
ｕｂｌｉｃＳｅｇｍｅｎｔ」）（パブリック・プロシージャ・テーブルなどの名
前が含まれる）及び外部セグメント３８０２（図３８）（「ｅｘｔｅｒｎＳｅｇ
ｍｅｎｔ」）内に配置される。外部セグメント３８０２には、セグメント・アド
レスおよびオフセット・アドレスが製品コンポーネント・リンカ３６００によっ
て決定され、フィックスされた後に、パブリック・エントリ・ポイントのアドレ
スの挿入によって製品コンポーネント・リンカによってフィックス・アップされ
なければならないアドレスを有する呼出し、ジャンプ、読取などの名前が含まれ
る。

【０２１６】 したがって、その第１ステップ３６０２として、製品コンポーネント・リンカ
３６００は、ビルドされたコンポーネントをすべて収集し、セグメント名によっ
てそれらをソートし、別々にコンパイルされリンクされた場合であっても、同一
の名前を有するセグメントを統一されたセグメント（「モジュール」と呼ぶ場合
がある）にマージし、プロシージャへの呼出しなどをリンク・アップして、複数
の異なるコンポーネントによって提供されるコード・セグメント断片からアセン
ブルされた統一された実行可能プログラム・モジュールを作成する。たとえば、
多数の異なるコンポーネント・ソース・ファイル内で作成されるが、単一のセグ
メントに割り当てられるさまざまなコンポーネントを初期化する呼出しを、単一
のモジュールに一緒に含めて統一された初期化ルーチンを構成することができ、
自動的にコマンド実行の特定の順序にソートすることさえできる。

【０２１７】 モジュールを構築するのに使用されるセグメントの大多数が、単純にさまざま
なコンポーネント・ファイルから読み取られる。しかし、いくつかのセグメント
は、製品コンポーネント・リンカ３６００によって作成されて、最終バイナリ・
イメージのうちで、リンカ３６００の実行までに存在しない部分が含まれる。

【０２１８】 リンカ３６００によって作成される追加の内容が、「ｎｅａｒ」アドレッシン
グ方法によってアクセスされる場合には、その内容が、参照と同一のセグメント
に常駐しなければならない。これは、リンカ３６００が、追加内容の余地を作る
ために既存セグメントのサイズを増やさなければならないことを意味する。新し
いセグメント・サイズを扱う時に、既存のアライメント要件を保存しなければな
らないことに留意されたい。

【０２１９】 セグメントを一緒に集めてモジュールを作成する時に、ギャップの可能性が現
れる。これらのギャップは、個々のセグメントのアライメント特性を維持した結
果である。これらのギャップの影響を減らすために、リンカ３６００は、セグメ
ントを組み合わせることができるさまざまな順序を検査し、セグメント間ギャッ
プ・スペースの量が最小になる順序を選択する。また、これらのギャップに配置
されるバイナリ・データを指定することができ、これによって、圧縮されるモジ
ュールの圧縮率の改善が可能になる場合がある。

【０２２０】 いくつかの場合に、モジュール配置のデスティネーションが、単一のモノリシ
ックなアドレス範囲を構成しない可能性がある。これが発生するのは、デスティ
ネーション範囲内の特定のアドレスが、特別な目的のために予約されている時で
ある。これは、モジュール全体を保持するのに十分に大きい単一のサブ範囲がな
い状況につながる可能性がある。リンカ３６００に、使用可能なサブ範囲におさ
まるのに十分に小さい複数のセグメント・グループを構築し、断片化されたモジ
ュールをもたらすように指示することができる。

【０２２１】 同一のコードが、最終的なバイナリ・イメージの複数の位置に現れなければな
らない時がある。製品コンポーネント・リンカ３６００は、構築されたモジュー
ルのコピーを作り、そのコピーを元のモジュールと異なるアドレスに配置する能
力を有する。これによって、ソース・コードを複数回アセンブル／コンパイルす
る必要がなくなる。

【０２２２】 モジュールを特定のアドレスに配置することができ、あるいは単純に１つのア
ドレス範囲にパックすることができる。これは、モジュールが配置される領域（
またはアドレス範囲）を指定することによって達成される。領域の使用によって
、実行の異なるフェーズ中に使用するために、アドレス範囲を複数回指定するこ
とも可能になる。また、モジュールを、複数の領域に配置することができ、実行
の複数のフェーズ中にそのモジュールを使用することが可能になる。

【０２２３】 モジュールが、実行の複数のフェーズ中に存在できるようにするため、および
、同一のアドレスに配置されるようにするために、モジュールを、所望の領域に
ミラーリングされる配置に関してマークする（ＢＩＯＳ．ＳＣＲファイル３８１
２内で）。リンカ３６００は、これらの領域内で同一のアドレスに存在する位置
を選択する。

【０２２４】 これは、ターゲット領域のすべてで使用可能なアドレス範囲だけを含む一時デ
ータ構造体（図示せず）として「プール」領域オブジェクトを作成することによ
って達成される。言い換えると、アドレス範囲が、ターゲット領域のいずれかで
既に占有されている場合に、その範囲はプール領域内で使用可能ではない。モジ
ュールが、プール領域内に配置された後に、それが占有するアドレス範囲が、す
べてのターゲット領域内で占有されているものとしてマークされる。

【０２２５】 モジュールが、実行の異なるフェーズ中に異なるアドレスに常駐することが必
要な時には、そのモジュールを、コピー配置に関してマークする（ファイル３８
１２内で）。製品コンポーネント・リンカ３６００は、指定された領域のそれぞ
れの中での、このモジュールが配置される位置を決定する。

【０２２６】 領域内の特定のアドレス範囲を特別な目的のために予約する必要が生じる時が
ある。このアドレス範囲は、排除ブロックとして指定し（パブリック・セグメン
ト３８０４内で）、製品コンポーネント・リンカ３６００に、それがモジュール
の配置に使用可能でないことを知らせることができる。

【０２２７】 次に、外部セグメント３８０２から、リンカ３６００は、コンポーネントに含
まれるプロシージャ定義および／またはラベル定義の名前を指定する外部セグメ
ント３８０２の内容を読み取り（ステップ３６０４）；後に、これらのプロシー
ジャ、テーブルなどへの他のビルドされたコンポーネントからの呼出しおよびア
クセスをフィックス・アップし、これらに同一の絶対アドレスを割り当てる時に
使用するためのテーブル内にこれらの位置を格納する。

【０２２８】 ステップ３６０６で、製品コンポーネント・リンカ３６００は、パブリック・
セグメント３８０４から、呼出し、ジャンプ、テーブル・ルックアップ・アクセ
スなどを含む、上で説明したプロシージャの外部定義へのすべての依存参照を読
み込み；絶対アドレスをプラグ・インする必要があるコード内の位置として後の
参照のためにこれらの参照のアドレスを保管する。

【０２２９】 外部セグメント３８０２内に含まれる外部のアドレスおよびパブリック・セグ
メント３８０４に含まれる依存性のアドレスの両方のこれらのアドレスのすべて
が、ソース・コード内で、絶対アドレスを外部セグメントまたはパブリック・セ
グメントに適当に配置する特別なマクロによってマークされる。その結果、外部
およびパブリックのコード内での正確な位置が、実際の呼出しおよびジャンプを
フィックス・アップする製品コンポーネント・リンカに通信されるようにする。
下で説明するマクロ・コードにみられるように、余分なエラー検査として、各マ
クロが、これらの特別な外部セグメントおよびパブリック・セグメント内にオフ
セット・アドレスを配置することに加えて、これらの同一のアドレスを実際のコ
ードにも挿入する。その結果、製品コンポーネント・リンカが、リンクされるオ
ブジェクト・コード内のエントリ・ポイントについて実際に検査する時に、各オ
フセットで、オフセット・アドレスに等しい数を見つけるようにする。

【０２３０】 次に、ステップ３６０８で、リンカ３６００が、実行可能コードの一部が、Ｒ
ＯＭイメージ内で複製されて現れるか、実行時に再配置される場合に、必要にな
る可能性がある定義および参照の両方の複製インスタンスを実行時情報によって
生成する。たとえば、コードが、移動されるか、異なる位置に複製されるか、上
書きされる可能性があり、これによって、定義および参照の両方の複製が必要に
なる場合がある。

【０２３１】 これによって、処理が、参照および定義が関連し、実際に最終的に一緒にリン
クされるステップ３６１０に移る。図３８を参照すると、これは、本発明に関し
て、たとえば所与の呼出しをあるプロシージャまたは別のプロシージャにリンク
する最終的な選択が行われる場所であり；この処理が、マクロ３８０６の直接の
制御の下で（外部セクタ３８０２およびパブリック・セクタ３８０４を介して）
製品コンポーネント・リンカ３６００によって行われるからである。しかし、こ
れらのマクロ自体が、機能インクルード・ファイル２３００の仲介作用を介して
、コンパイルまたはアセンブルの前にソース・コードを編集し（たとえば、望ま
しくない選択されていないコンポーネントへの「ｃａｌｌ」を除去し、インクル
ード・ファイル・クラス識別子をこれらのインクルード・ファイルの絶対アドレ
スに置換する）、構成状態データ１９００によってどのシグナルが製品コンポー
ネント・リンカに送られるかを制御するように指示される。この構成状態データ
１９００は、製品構成データ２１００、コンポーネント情報ファイル、および機
能情報ファイルに含まれるコマンドを反映する。これらのファイルが、作成され
、ユーザ・インターフェース２００を介する設計者の直接制御の下にあるので、
これによって、設計者に、上で説明したようにどのコンポーネントおよび機能を
選択するかを決定する処理全体に対する普通ではない量の詳細な制御が与えられ
る。

【０２３２】 参照と定義の関連付けは、下記のようにある順序で実行される。

【０２３３】 第１に、指定されたコンポーネントに向けられた参照（依存性：たとえば「ｃ
ａｌｌ」ステートメント）が、その名前のコンポーネント内で見つかる定義（外
部：たとえば「ｐｒｏｃ」ステートメント）に関連付けられる。２つの異なるコ
ンポーネントに同一の名前を有するプロシージャが含まれる場合に、コンポーネ
ント名によって、所与のｃａｌｌステートメントのデスティネーションとしてど
れが選択されるかが決定される。

【０２３４】 第２に、マクロによって生成された「ｃａｌｌ」情報によって識別される、シ
ステム設計者によって指定された「インターセプト」外部定義（「インターセプ
ト」を行い、ソース・コードによって呼び出されるプロシージャの機能をのっと
る置換プロシージャ）が、ほかで使用されたどの参照よりも優先的に、インター
セプトする参照にリンク・アップされる。

【０２３５】 第３に、完成した製品に複製されたコードまたは製品コンポーネント・リンカ
３６００によって生成されるコード（ソートされたテーブルなど）が含まれる範
囲まで、これらのリンク参照を次に確立する。

【０２３６】 最後に、リンクを所与のコンポーネント内の親および兄弟に制限するために、
すべてプライベート参照スコープを用いて、残っているすべての参照を定義にリ
ンクする。

【０２３７】 ステップ３６１２で、製品コンポーネント・リンカ３６００は、次に、ソート
およびセグメントへの挿入を必要とするリスト参照、アセンブルされ、コード内
に配置されなければならない文字列セグメント、やはり特別に処理されなければ
ならない不揮発性ＲＡＭコード、所与のプロシージャがシステム・ブートアップ
中の異なる時に見つかる可能性がある異なる位置を示す再配置テーブル、および
ＲＡＭなしサブルーチン呼出し中にサブルーチン「リターン」ポインタとして働
く必要があるＲＯＭスタックなどの、特別な処理を必要とするすべてのセグメン
トを収集し、処理する。

【０２３８】 これらのうちで、ＲＯＭスタックは説明を必要とする：ＲＯＭスタックは、ア
センブラ・ソース・コード内で次のように現れ、マクロによって生成される。 CREATE_ROM_STACK: returnAddr: DW returnAddr + 4 DW SEGMENT returnAddr jmp bx

【０２３９】 マクロＩＮＩＴ＿ＲＯＭ＿ＳＴＡＣＫは、下記のスタック・ポインタおよびス
タック・セグメント・ポインタのデフォルト値を生成する。 ... mov ss, SEGMENT returnAddr mov sp, OFFSET returnAddr

【０２４０】 マクロＲＯＭＣＡＬＬは、ＣＡＬＬステートメントの次のコードの点でＲＡＭ
なしＣＡＬＬ機能を生成する。 ... mov bx, returnOffset jmp FAR xyz returnOffset: [マクロの先の次の命令]

【０２４１】 上記からわかるように、ＲＯＭスタックは、標準的な呼び出されるプロシージ
ャがＲＥＴ命令を実行できるようにする、ダミー・スタック・フレームである。
プログラム制御のリターンの際に、ＲＥＴ命令は、スタック・フレームに含まれ
る、マイクロプロセッサのプログラム・コード・アドレスおよびセグメントをロ
ードするが、これは、ダミー・スタック・フレームの直後のアドレス「ｒｅｔｕ
ｒｎＡｄｄｒ＋４」である。したがって、マイクロプロセッサは、ダミー・スタ
ック・フレームに続く命令すなわち「ｊｍｐ ［ｂｘ］」を実行し、ｂｘレジス
タによって指定されるオフセットにある呼出し元プログラムにジャンプする。

【０２４２】 これは、リターン手順であり、明らかに、サブルーチン呼出しが呼出しの点の
次の命令のリターン・オフセット・アドレス、上に示されたアドレス「ｒｅｔｕ
ｒｎＯｆｆｓｅｔ」をｂｘレジスタに事前にロードしなければならない、ＲＡＭ
なしの他のセグメントを作成する特別なマクロである。その後、ｆａｒ「ｊｍｐ
」コマンドを用いて「ｃａｌｌ」を実行するが、このｊｍｐコマンドは、呼出し
が実行される時に、ダミー・スタック・フレームに何も保存しない。というのは
、ダミー・スタック・フレームに、ＲＥＴ命令実行によって使用されるリターン
・アドレスが、すでに事前ロードされているからである。

【０２４３】 この単純な形で、ＲＡＭなし環境（たとえば、ＰＣのメモリ・コントローラが
セット・アップされる前）で動作するＲＯＭ ＢＩＯＳシステム初期化ルーチン
が、設計において従来通りであるサブルーチンを呼び出すことができる。製品コ
ンポーネント・リンカ３６００が、ダミー・スタック・フレームを必要とするコ
ード・セグメントのそれぞれに１つのダミー・スタック・フレームだけを挿入す
る必要があることに留意されたい。というのは、プロシージャへの多数の異なる
呼出し（実際にはジャンプ）が、単一のダミー・スタック・フレームを共有でき
、どの場合でも、レジスタｂｘが、リターンを制御し、コード内の正しいオフセ
ットに向けるからである。

【０２４４】 ＲＡＭが使用可能になる前にｆａｒサブルーチン呼出しを実装する代替の手法
では、サブルーチンの完了時に呼出し元コードにリターンするのに使用されるリ
ターン・アドレスのテーブルの作成を用いる。呼出し元は、サブルーチンにジャ
ンプする前に、事前に決定されたレジスタにテーブルへのインデックスをロード
する。完了時に、サーブルーチンが、共通のディスパッチ・ルーチンにジャンプ
し、このルーチンで、インデックス値を使用して、リターン・アドレスにアクセ
スし、呼出し元のコードにジャンプする。リンカ３６００は、テーブルを作成し
、インデックス値を割り当てる。

【０２４５】 リンカ３６００は、コンポーネントから得られ、パブリック・セグメント３８
０４を介して渡されるハウスキーピング情報に基づいてリターン・アドレスのテ
ーブルを作成する。

【０２４６】 次に、ステップ３６１４で、リスト、ダミーＲＯＭスタック、文字列、不揮発
性ＲＡＭブロックおよびコード、および再配置テーブルを含むコードのモジュー
ルを、この前には時として実行不能である、統一されたコードのブロック全体に
関する最終的なアドレス空間にマッピングすることができる。ＩＢＭ ＰＣおよ
び互換機の、Ｉｎｔｅｌ ３８６クラス（Ｐｅｎｔｉｕｍ（登録商標）、４８６
など）のコンピュータでみられる「リアル・モード」では、すべてのセグメント
内アドレッシングが、実際の絶対的なセグメント・アドレスおよびセグメント内
のオフセットに基づかなければならない。したがって、この時には、製品コンポ
ーネント・リンカ３６００が、すべての外部のアドレスすなわちすべての参照ア
ドレスを仕上げる。最後に、リンカ３６００が、実際にアドレスをコードにフィ
ックス・アップし、これによって、すべてのコード依存性を最終的に解決し、満
足する。コードは、最終イメージへのインストールの準備が完全に整っている。

【０２４７】 製品コンポーネント・リンカによって実行される最後のステップ、ステップ３
６１６は、ｒｏｍモジュール、シンボル・マップ、およびログ記録情報を書き出
すステップであり、このログ記録情報は、リスト、文字列、および不揮発性ＲＡ
Ｍに関係し、システム設計者が、別の（好ましい実施形態では）「ＲＯＭ＿ＩＭ
ＡＧＥ」ルーチンを試験し、渡すためのものであり、この「ＲＯＭ＿ＩＭＡＧＥ
」ルーチンは、ＢＩＯＳ．ＳＣＲおよび複製されるイメージ部分に関する情報と
共にＲＯＭモジュールを入力し、ある部分の圧縮、サウンドおよびイメージに関
する圧縮されたコードの追加、および最終ＲＯＭディレクトリの作成を含めて、
ＲＯＭコード・イメージの最終アセンブルを実行する。

【０２４８】 図３７に、リスト作成および管理処理３７００を示す。ソース・コード・ファ
イルＡ３７０２のコード断片に示されたＬＩＳＴ＿ＣＲＥＡＴＥマクロ３７０４
（マクロの行単位の説明の節５．１）が、そのパラメータによって指定されるリ
スト名およびエントリ・サイズを保存し、呼び出された時の現在のセグメントを
識別することによって、現在のセグメント内にリストを作成する。ソース・コー
ド・ファイルＢ３７０６のコード断片には、ＬＩＳＴ＿ＣＲＥＡＴＥマクロ３７
０４と同一のリスト名およびエントリ・サイズならびにリスト・エントリ優先順
位を指定し、保存するＬＩＳＴ＿ＳＴＡＲＴマクロ３７０８（マクロの行単位の
説明の節５．３）が含まれる。このコード断片３７１０に含まれるＬＩＳＴ＿Ｅ
ＮＴＲＹマクロ（マクロの行単位の説明の節５．５）では、リスト・エントリの
データ、エントリの名前、そのソート優先順位（同一のソート・キーを有するリ
スト・エントリをソートするのに使用される数）、およびソート・キーが指定さ
れ、保存される。ＬＩＳＴ＿ＥＮＤマクロ３７１２（マクロの行単位の説明の節
５．４）は、ＬＩＳＴ＿ＳＴＡＲＴマクロ３７０８によって開始されたリスト・
エントリを終了し、複数のリスト・エントリを指定できるようにする。ソース・
コード・ファイルＣ３７１４のコード断片に、複数のリスト・エントリを、異な
るコンポーネントの一部とすることができる異なるソース・コード・ファイルで
指定できることが示されている。製品ビルド処理１０００では、ＬＩＳＴ＿ＣＲ
ＥＡＴＥマクロ３７０４によって保存された情報を使用してリスト名を識別し、
ＬＩＳＴ＿ＳＴＡＲＴ３７０８およびＬＩＳＴ＿ＥＮＴＲＹ３７１０マクロによ
って保存された情報を組み合わせ、エントリ・データをソートし、ソートされた
エントリ・データを、完成した製品３７１６の、ＬＩＳＴ＿ＣＲＥＡＴＥマクロ
３７０４によって識別されるセグメントに置く。リストのさらなる説明について
は付録Ｂを参照されたい。

【０２４９】 各リスト・エントリ宣言では、リスト内のエントリの順序を決定するのに使用
することができるソート「キー」文字列３７１１が指定される。マスタ・ソート
・リスト（図示せず）が提供される時に、実際のリスト内のエントリが、ソート
・リストの順序に一致するように順序付けられる。マスタ・ソート・リストには
、実際のリスト内のエントリに一致しないエントリを含めることができる。実際
のリスト・エントリのそれぞれは、リスト・エントリの位置を決定するために、
マスタ・ソート・リスト内に現れるソート・キーを有しなければならない（マス
タ・ソート・リストが存在する場合に）。同一のソート・キー文字列を有する複
数のリスト・エントリがある場合には、それらが、エントリ・ソート優先順位値
３７１３を使用することによってさらにソートされる。

【０２５０】 製品コンポーネント・リンカ３６００は、ソートされるリストの名前から始め
て、マスタ・ソート・リストを含むハウスキーピング・セグメント（図３８のパ
ブリック・セグメント３８０４に含まれる）を読み取る。その後、各ソート・キ
ー文字列を順番に読み取り、リスト・オブジェクトとしてコンテナに配置する。
リスト・オブジェクト（図示せず）は一時データ構造体である。リスト・エント
リの実際のソートは、インデックス値を各エントリに割り当てることによって達
成される。まず、インデックス値を、０に初期化する。その後、最初のソート・
キー文字列を、マスタ・リストから取り出す。エントリ・オブジェクトのコンテ
ナを、一致するソート・キー文字列３７１１を有するエントリについて検索する
。１つまたは複数が見つかる場合に、現在のインデックス値を、最も高いソート
優先順位値３７１３を有するエントリに割り当て、インデックス値を増分する。
これを、一致するエントリがなくなるまで継続する。この処理を、マスタ・リス
トからのソート・キー文字列のそれぞれについて繰り返す。

【０２５１】 複数のリスト・エントリが同一のソート・キー文字列を有する時、またはマス
タ・ソート・リストが提供されない時には、リスト・エントリのソート優先順位
値３７１３を使用してリスト・エントリの順序を決定する。ソート優先順位値３
７１３は、本質において数値であり、製品コンポーネント・リンカ３６００はよ
り小さい値がより大きい値の前にリストに現れるようにエントリをソートする。
優先順位によってエントリのソートを試みている時には、優先順位の値が等しい
時に、エラーが報告される。

【０２５２】 リスト・マクロおよびリスト・エントリ・マクロは、パブリック・セグメント
３８０４に入り、製品コンポーネント・リンカ３６００によってリストの配置お
よびエントリの順序を決定するのに使用されるハウスキーピング情報を生成する
。これらのパラメータによって、実際のソート処理が制御される。ソートが実行
された後に、このハウスキーピング情報を破棄することができ、これによって、
最終的な実行可能コードのサイズが減る。

【０２５３】 リスト・エントリ・データ３７０９に、「パブリック宣言」が含まれる時に、
「ｃａｌｌ」などのそれに対する参照を名前によって行うことができる。リスト
の最終的な位置およびリスト内でのこのエントリの位置は、製品コンポーネント
・リンカによって決定されるまで未知なので、これらの参照は、リスト位置およ
びリスト・エントリ位置が既知になり、決定された後に解決されなければならな
い。

【０２５４】 これは、エントリのオフセットに関するステップとセグメントに関するステッ
プの２ステップで達成される。エントリのオフセットは、リストがソートされた
後に、エントリのインデックスにエントリのサイズ３７０７をかけることによっ
て判定することができる。これによって、セグメントの先頭からのエントリの距
離が得られる。計算されたオフセット値は、リスト・セグメント・オブジェクト
へのポインタと共に使用される。エントリのセグメント値は、リスト内のすべて
のエントリに関して同一であり、リスト・セグメントが予定の領域に配置された
時に決定される。

【０２５５】 リスト・エントリのデータ領域に、製品コンポーネント・リンカ３６００によ
って外部参照に解決される必要があるパブリック定義を含めることができる。こ
れらの参照は、セグメントのアセンブルおよび配置が行われるまで解決すること
ができず、セグメントの配置はすべてのリストが作成されるまで完了することが
できない。この問題に対処するために、リスト・エントリの元の位置（パブリッ
ク・セグメント内の）とリスト・エントリの新しい位置（指定されたデスティネ
ーション・セグメント内の）を含む関連オブジェクトを作成し、一時的に保管す
ることができる。各参照が解決される時に、検査を行って、パブリック定義の位
置がパブリック・セグメント内であるかどうかを調べる。そうである場合には、
定義を含むリスト・エントリの関連オブジェクトを見つけ、参照を、リスト・エ
ントリ内の定義の新しい位置に決める。

【０２５６】 リスト処理の一部として、製品コンポーネント・リンカ３６００が結果のリス
ト構造体の「ソース・リスト」を作る。そのリストは、ユーザがコンポーネント
・ソース・コード・ライブラリの一部として保存することができる。このリスト
（図示せず）は、実際のリストの内容および構造を「ロック」するために、リス
トを定義したマクロおよびデータ３７０４、３７０８、および３７１４の置換物
およびオーバーライドとして、製品コンポーネント・リンカ３６００の後続の呼
び出しで使用することができる。ロックされたリストを提供する時に、１対１の
対応が、すべてのリスト宣言で強制される（すなわち、各リスト宣言（３７０４
、３７０８、および３７１４など）が、ロックされたリスト内の１つのエントリ
だけに一致しなければならない）。

【０２５７】 リスト・エントリ宣言に対する変更を行うのに必要な労力を減らすために、元
の宣言をその場に残し、新しい宣言を、そのマクロに付加されるオーバーライド
修飾子フラグを用いて作成することができる。これによって、リスト・エントリ
に対する単純な変更が望まれる時に、既存ファイル（コア・ディレクトリに含ま
れる可能性がある）を修正する必要がなくなる。同一の名前を有する複数のリス
ト・エントリが検出された時には、最高の数値オーバーライド優先順位値３７０
５を有する宣言だけがリストの作成に使用される。同一のオーバーライド優先順
位値を有する複数のエントリ（同一の名前を有する）は、エラーを引き起こす。

【０２５８】 製品コンポーネント・リンカ３６００の「正確におさまるセグメント（ｅｘａ
ｃｔ ｆｉｔ ｓｅｇｍｅｎｔ）」機能によって、エントリのリストのサイズお
よび位置を判定するだけのために別々の「開始」セグメントおよび「終了」セグ
メントを使用する必要がなくなる。各リスト定義に余分な識別情報ならびに各リ
スト・エントリ定義を含めることによって、ソースレベル・リスト宣言ステート
メントを、パブリック・セグメント３８０４にコンパイルすることができる。リ
ンカ３６００は、正確に必要なサイズの新しいセグメントを作成することができ
る。

【０２５９】 リスト・エントリ定義のすべてを読み取った後に、リスト・セグメントの必要
なサイズを、リストのエントリ数およびエントリのサイズから決定することがで
きる。その後、セグメント・オブジェクトを作成し、適切なモジュールのセグメ
ント・オブジェクトのコンテナに追加する。

【０２６０】 製品コンポーネント・リンカ３６００は、バッテリ・バックアップ式Ｃ−ＭＯ
Ｓ空間などの不揮発性ＲＡＭ空間を、１ビットから１６バイトまでの範囲のサイ
ズで連続して（密にパックして）割り振ることができる。バイト境界をまたがな
いように、８ビット未満のものは整列される。１６ビット以上のものは、バイト
の整数倍までまるめられる（図３９を参照されたい）。

【０２６１】 ＮＶＲＡＭ＿ＭＥＤＩＡマクロ３９０２が、バッテリ・バックアップ式ＣＭＯ
Ｓなどの特定の媒体を定義するために設けられる。このマクロは、媒体に名前を
割り当て、そのサイズを指定し、不揮発性媒体の読み取りおよび書き込みに使用
されるリーダー・サブルーチンおよびライタ・サブルーチンを名前によって宣言
する。

【０２６２】 ＮＶＲＡＭ＿ＩＴＥＭマクロ３９０４では、名前、サイズ、デフォルト値、フ
ラグ、媒体、およびアドレスを指定することによって、不揮発性ＲＡＭフィール
ドを定義する。フラグは、たとえば、フィールドをチェックサムに含めるかどう
か、およびチェックサム障害またはＮＶ−ＲＡＭがクリアされる時に初期化が必
要であるかどうかを示す。媒体パラメータでは、ＮＶＲＡＭ＿ＭＥＤＩＡマクロ
によって定義される複数の可能な媒体の特定の１つを割り当てる。アドレスおよ
び媒体は両方ともオプションである。しかし、アドレスが指定される場合には、
媒体も指定しなければならない。

【０２６３】 ＮＶＲＡＭ＿ＲＥＳＥＲＶＥＤマクロは、類似するが、たとえばリアルタイム
・クロックのために、空間を単純に予約する。

【０２６４】 ＮＶＲＡＭ＿ＳＴＲＵＣＴＵＲＥ ＳＴＡＲＴマクロおよびＮＶＲＡＭ＿ＳＴ
ＲＵＣＴＵＲＥ ＥＮＤマクロによって、検索および保管のために、一連の項目
を単一のより大きいデータ構造項目に定義するために、複数のＮＶＲＡＭ＿ＳＴ
ＲＵＣＴＵＲＥ＿ＩＴＥＭマクロをひとまとめにすることができる。

【０２６５】 ＲＥＡＤＮＶマクロ３９０６によって、名前付きのＮＶＲＡＭデータ項目を読
み取るコードが生成され、ＷＲＩＴＥＮＶマクロ３９０８によって、名前付きの
データ項目を書き込むコードが生成される。

【０２６６】 「ＲＥＡＤＮＶ ＜名前＞」マクロは、下記のコードを生成する。 MOV AX, <16ビット空間> call read.sub

【０２６７】 これによって、あるインデックス（製品コンポーネント・リンカ３６００によ
って後に挿入される）が、名前を指定された値をフェッチするのに適切なサブル
ーチン（やはり製品コンポーネント・リンカによって後に挿入される）を呼び出
す。このマクロでは、製品コンポーネント・リンカ３６００が挿入されるコード
を正しく調整できるようにするために、パブリック・セグメント３８０４内に、
この呼出しの位置の記録、それが「読取」呼出しであることの表示、およびＮＶ
＿ＲＡＭフィールドの名前も生成される。「ＷＲＩＴＥＮＶ ＜名前＞」マクロ
も同様に動作する。

【０２６８】 製品コンポーネント・リンカ３６００は、ＮＶ＿ＲＡＭをＮＶＲＡＭ＿ＩＴＥ
Ｍマクロによって定義されたフィールドに割り振り、各名前をＮＶ＿ＲＡＭへの
オフセットに関係させる一時テーブルを維持する。このテーブルは、上で説明し
たプログラム・セグメント内の読取コードおよび書込コードを調整するのに使用
される。

【０２６９】 ＳＴＲ＿ＤＥＦＩＮＥマクロおよびＳＴＲ＿ＤＥＦＩＮＥ＿ＥＮＤマクロ４０
０２は、文字列を受け入れ、その文字列に名前を割り当てる。文字列は、ＳＴＲ
＿ＬＡＮＧＵＡＧＥマクロによって指定される「言語」属性（たとえば「ＵＳ」
または「ＩＴ」）ならびにＳＴＲ＿ＴＥＸＴマクロによって指定されるＡＳＣＩ
Ｉ値も有する。

【０２７０】 リンカは、このマクロのインスタンスによって定義される文字列のすべてを収
集し、それぞれにその名前および言語を関連付ける。所与のＰＣの「アクティブ
」言語パラメータは、通常はＮＶ＿ＲＡＭに保管され、システム設計者が変更す
ることができる。

【０２７１】 「ＬＯＡＤＳＴＲ ＜名前＞」マクロ４００４は、プログラムに文字列データ
への「ソース・インデックス」ポインタ（下で説明する）を与えて、プログラム
・セグメント内に下記の言語書込準備コードを生成する。 MOV_SI, <16ビット空間>

【０２７２】 ＮＶ＿ＲＡＭマクロの場合と同様に、文字列名、１６ビット空間のアドレス、
およびこの命令の性質を含むデータが、パブリック・セグメント３８０４に配置
され、これによって、製品コンポーネント・リンカ３６００がこの参照を完成で
きるようになる。

【０２７３】 製品コンポーネント・リンカ３６００は、文字列値ポインタ配列および各言語
の実際の文字列値を含む言語ごとに別々のテーブルを作成する。各異なる言語の
同一の意味を有する文字列は、各テーブル内で、値ポインタ配列内の対応する位
置に格納された値ポインタによってポイントされる。したがって、「１８」など
の「ソース・インデックス」値ｓｉによって、各言語テーブルの文字列値ポイン
タ配列内で、テキストの対応する文字列の先頭へのインデックス値が識別される
。したがって、「ｍｏｖ ｓｉ， ＜ｐｔｒ＞」コードに続くコードで、簡単に
、特定のメッセージを識別する「ｓｉ」値および言語を識別するＮＶ＿ＲＡＭ
ｃｏｕｎｔｒｙ値を使用して、正しい言語で書かれた正しいメッセージを見つけ
、取り出すことができる。

【０２７４】 図３８に、１つの図で、システム設計者が機能およびコンポーネントの最終的
な完成した製品１１０６へのアセンブルに対する詳細な制御を維持できるように
することにかかわる、他所で説明される本発明の要素を提示する。

【０２７５】 設計者は、上で説明したように、ユーザ・インターフェースを介して、構成状
態データ（図３３Ａ）を見、コンポーネント、機能、および依存性に関する変更
を行う。このユーザ情報が、製品構成データ・ファイル２１００に保存され、構
成状態データにフィード・バックされる。コンポーネント・ソース・コード・ラ
イブラリ１２００もスキャンされ、呼出し、プロシージャ、インクルードなどに
関する詳細な情報が、コンポーネント指定、クラス指定、バージョン指定、およ
び他の有用な情報を含めて、データベース１８００に収集される。また、どのプ
ラットフォームとの互換性を有するか、またはどのプラットフォームに必要であ
るかなど、コンポーネントおよび機能に関する情報が、コンポーネント情報ファ
イルおよび機能情報ファイルから収集され、データベース１８００に置かれる。
データベース１８００の内容は、構成状態データ１９００にも転送される。

【０２７６】 構成状態データ１９００に含まれる、この情報のすべてによって、製品の構成
が決定され、ユーザ・インターフェースで論理的な形でシステム設計者に提示さ
れる。設計者は、コンポーネント・ソース・コード・ライブラリ１２００内のフ
ァイルを編集することによるか、ユーザ・インターフェースを使用して、機能お
よびコンポーネントを選択または選択解除し（図３３Ｄ）、依存性および外部に
関するオプションを調整する（図３３Ｅ）ことによって、構成を修正することが
できる。もちろん、システムを組み合わせる過程でのすべてのエラーが、ユーザ
・インターフェース（図３３Ｂ）の赤い×によって設計者に直接に知らされる。

【０２７７】 構成を行った後に、製品メイク・ルーチン８００を呼び出して、完成した製品
１１０６を作成する。まず、コンポーネント・メイクファイル２４００および製
品メイクファイル２５００を生成して、アセンブラ、コンパイラ、およびリンカ
に作業について指示する。次に、機能インクルード・ファイル２３００を生成し
、コンパイラおよびアセンブラが、コンパイルおよびアセンブルの前にソース・
コード・ファイルにそれを挿入するようにする。機能インクルード・ファイルは
、システム設計者および構成状態データからソース・コード・ファイルへの直接
につながる信号導管と見なされなければならず、これによって、コンパイルおよ
びアセンブルの前のソース・コード・ファイルの事前編集が実際に制御される。
これには、選択解除されたコンポーネントおよび機能へのすべての呼出しの削除
と；インクルード・ファイルの「クラス」宣言をコンポーネント・ソース・コー
ド・ライブラリ１２００内の絶対アドレスに置換することと；制御値をマクロに
渡して、マクロが製品コンポーネント・リンカに最終的に何を何に接続するかに
関して知らせる形を変更することが含まれる。

【０２７８】 特別なマクロは、コンパイラおよびアセンブラによって実行される時に、第１
のダミー・コード・セグメントである特別な外部セグメント３８０２への配置を
指定されたすべてのプロシージャ、ラベル、およびテーブル（外部）に関するデ
ータを生成する。特別なマクロは、第２のダミー・セグメントである特別な外部
セグメント３８０４への配置を指定されたすべての呼出し、ジャンプ、オプショ
ン、およびグローバル（依存性）に関するデータを生成する。これらのダミー・
セグメントは、個々のソース・コード・ファイル位置と製品コンポーネント・リ
ンカの間の通信経路とみなされなければならず、これを介して、最終的なアドレ
ス・フィックスアップ・オペレーションを実行する方法を定義する情報を渡すこ
とができる。この情報がシステム設計者から生じることに留意されたい。コンポ
ーネント情報、機能情報、およびソース・コード・ファイルは、構成状態データ
に含まれ、機能インクルード・ファイル２３００を介してコンパイル／アセンブ
ル処理に部分的に渡され、最終的に、特別なマクロ３８０６によって収集され、
変更され、製品コンポーネント・リンカ３６００に送られる。

【０２７９】 コンパイル、アセンブル、およびリンクの処理が、次に実行され、実行可能フ
ァイル１１０４が生成され、リンカ・マップ・ファイル３８０８によって別々の
セグメントにインデクシングされる。したがって、製品コンポーネント・リンカ
３６００は、実行される時に、実行可能ファイルをシフトし、その内容をコード
・セグメントによってソートし、その結果、すべてのセグメントの内容を一緒に
集める。この形で、外部セグメント・データ３８０２およびパブリック・セグメ
ント・データ３８０４が一緒に集められ、その結果、選択されたコンポーネント
のリスト３８１０および、絶対セクタ・アドレス、セクタの順序付け、および他
のそのようなことを指定するＢＩＯＳ．ＳＣＲファイルと共に、製品コンポーネ
ント・リンカのオペレーションを制御し、指示できるようになる。このすべてに
よって、上で説明したように、システム設計者が、コンポーネントおよび機能を
一緒に統合された製品にリンクする処理での普通でない度合の制御を維持するこ
とができるようになる。

【０２８０】 前に述べたように、開発システムは、ソース・コード・ファイルと情報ファイ
ル（ＩＮＦファイル）の両方からのデータの収集に依存する。ＩＮＦファイルお
よびソース・コード・ファイルは開発環境の実行全体を通じてスキャンされる。
具体的に言うと、作業ディレクトリにファイルが追加されるか、作業ディレクト
リ内の既存ファイルが修正される時に、必ず、どちらかのタイプのファイルが、
スキャンされ、データがデータベースに置かれる。ファイルが作業ディレクトリ
から削除される場合には、関連するデータがデータベースから除去される。この
処理によって、データベースが常に最新であることが保証される。以下の段落で
、ソース・ファイルとＩＮＦファイルから収集される特定のデータを説明し、こ
のデータの特定の使用法を提示する。

【０２８１】 この開発システムを利用するプログラム・ソース・ファイルは、前に提示し、
説明したマクロの標準セットを使用することが要求される。付録Ｃに、スキャン
されるマクロのリストを提示し、それらのマクロから収集されるデータを識別す
る。

【０２８２】 ＩＮＦファイルは、ソース・コード・マクロに格納されないが、システムの機
能の多くを促進するのに必要なさまざまなコンポーネント情報および機能情報を
保管するための好ましい実施形態を表す。ＩＮＦファイルに含まれるデータを、
データ・テーブル、ソース・ファイル、ＰＬＡＴＦＯＲＭ．ＣＦＧファイル、ま
たは特にその目的のために作成される他のファイルを含むが、これらに制限され
ないさまざまな他の方法を使用して保管できることに留意されたい。好ましい実
施形態では、すべてのコンポーネントおよび機能が、そのめいめいのディレクト
リ内にＩＮＦファイルを有しなければならない。ＩＮＦファイルでは、厳密なコ
マンド言語を使用して、データベースへの格納のためのスキャン処理中の単純な
データ収集を容易にする。付録Ｄに、ＩＮＦファイル・コマンドを提示し、これ
らのコマンドから収集されるデータを指定する。付録Ｅに、好ましい実施形態の
プラットフォーム・タイプ宣言を示す。

【０２８３】 スキャン処理中に、複数のエラーがツリー内で識別される可能性がある。これ
は有用である。というのは、開発過程の初期で、ソース・コードの使用、システ
ムのビルド、または、より重要なことに、コンパイルされたＢＩＯＳの配布の前
に、エラーが識別されるからである。識別できるエラーには、下記が含まれる。
１）各コマンドを構文解析して、コマンド仕様への追従を確認することによる、
不適切な名前を指定されたコンポーネント、機能、およびオプションの識別。２
）データベースにレコードを追加する時に一意のコンポーネント名を要求するこ
とによる、同一のコンポーネント名を有する複数のコンポーネントまたは機能の
識別。３）潜在的にトリガ解決中の未確定状態をもたらす可能性がある無効なト
リガの組み合わせ（付録Ｆ）。４）最終的にビルド処理中のアセンブル・エラー
または実行時エラーをもたらす、構文エラーまたは無効データ・エラーを含む不
正なマクロの使用の識別。

【０２８４】 さらに、初期スキャン処理の後に、データベースを開発処理中に生じるエラー
状態のリアルタイム評価に使用する。現在の最新技術の開発システムは、ビルド
処理中に限って、類似するエラー検査を行う。本発明は、エラーが発生する場合
に、ユーザが標準的なパーソナル・コンピュータ・システム（Ｐｅｎｔｉｕｍ
４００ＭＨｚ）で即座にフィードバックを受け取る（ほとんどの場合に１秒未満
）、効率的なリアルタイム環境で、ビルド処理の前にこれらの作業を達成する。
識別できるエラーには、下記が含まれる。１）未解決の依存性、２）あるコンポ
ーネントから別のコンポーネントのプライベート・プロシージャへの呼出しなど
、アクセス・レベルに違反する呼出し。３）適切なプログラム・セグメントの外
のプロシージャへの呼出し（付録Ｇ）。４）先にＰＵＢＥＸＴまたはＰＲＶＥＸ
Ｔを宣言されていないＥＸＴＣＡＬＬステートメントの使用、５）ｆａｒプロシ
ージャへのｎｅａｒ呼出し、６）ｎｅａｒプロシージャへのｆａｒ呼出し、７）
未解決の依存性、８）無効なバージョン番号への呼出し、９）古いファイル・オ
ーバーライド。１０）作業ツリー内でのユーザ変更に基づく未確定のトリガ状態
の識別（付録Ｆを参照されたい）。

【０２８５】 さまざまな統計情報が、データベースから使用可能である。この情報には、下
記が含まれる。１）未使用のインターフェース、ラベル、または変数の判定。２
）コード・フロー分析。３）あるプロシージャについて宣言されたパブリック・
インターフェースおよびプライベート・インターフェースの数。４）コンポーネ
ントまたは機能のクラスその他に基づく最小機能インターフェース要件を満たさ
ないコンポーネントおよび機能の報告。図５５に、機能追跡を使用できる方法を
示す。

【０２８６】 製品の一部であるソース・コード・ライブラリのサブセットだけを含むように
検索をフィルタリングするための情報も、構成から使用可能である。たとえば、
表示される文字列を検索するために、ソース・コード・ライブラリ内のその文字
列のすべてのインスタンスを見ることは、製品によって実際に使用されるインス
タンスをみることより有用でない。１）ハード依存性のない機能（オプション機
能）、２）使用可能なパブリック・インターフェース、３）オプションおよびセ
ット値およびデフォルト値、４）指定されたコード・セグメントを使用する機能
および多くの他の情報などの情報を開発者に与えるレポートを生成することがで
きる。

【０２８７】 カスタマイズ技法 本発明は、コンパイル前の構成と、バイナリ・リンカの最終イメージ作成ステ
ージの両方からのカスタマイズの方法をサポートする。コンパイル前の構成カス
タマイズによって、ソース・コード・ライブラリの「ポイント・アンド・クリッ
ク」カスタマイズが可能になる。上で説明したオプションによって、ユーザが、
コードを修正せずに値を変更することができる。この方法を、テーブルに拡張す
ることができる。ＢＩＯＳの場合に、レジスタ・テーブルおよびＣＭＯＳテーブ
ルをコード修正なしでカスタマイズすることができる。元のファイルを物理的に
無変更のままで、ソース・コード・ライブラリ・ファイルをオーバーライドする
ことができる。しかし、オーバーライドは、カスタム・フォルダに存在し、コン
ポーネント・イメージに組み込まれる。カスタム・ファイルを機能に追加するこ
とができる。カスタム・ファイルは、物理的にはカスタム・フォルダに常駐する
が、やはりコンポーネント・イメージに組み込まれる。図４２に、これらの技法
にかかわるステップを示し、製品コンポーネント・リンカ３６００を使用して元
のエントリをカスタマイズされたバージョンに置換し、リンク参照を調整する、
単一の項目のテーブルからのカスタマイズを示す。

【０２８８】 カスタマイズは、製品コンポーネント・リンカ３６００によってサポートされ
、これによって、テーブル順序のロックならびにテーブル・エントリのオーバー
ライドが可能になる。テーブル内のすべてのエントリをオーバーライドすること
ができ、コード・セグメント内の元のデータをオーバーライドによって置換する
ことができる。付録Ｈにこの方法を示す。製品コンポーネント・リンカ３６００
は、インターセプト・パラメータがパブリック・プロシージャ宣言で宣言されて
いる時に、パブリックの呼び出される側へのすべての呼出し元のリンクをインタ
ーセプトすることによるカスタマイズもサポートする。この方法は、パブリック
・プロシージャの前または後にカスタム・コードを実行させるのに有用である。

【０２８９】 アーカイブ この開発システムでは、変更管理システム（ＰＶＣＳ、Ｄｉｍｅｎｓｉｏｎｓ
、Ｖｉｓｕａｌ Ｓｏｕｒｃｅｓａｆｅなど）と相互作用するアプリケーション
・プログラマ・インターフェースが定義されている。このインターフェースは、
コンポーネントまたは機能のＩＮＦファイルから独自情報を変更管理システム・
データベースに直接に移植し、したがって、新しいコンポーネントまたは機能を
検査する時に、このデータを変更管理システムに再入力することをユーザに共用
する必要なしで済ませる能力を備えている。移植される情報には、ＩＮＦファイ
ルに含まれるカテゴリ化情報のすべてが含まれる（付録Ｄ）。しかし、適切なイ
ンターフェースの追加によって、同様に簡単に追加情報を移植できることに留意
されたい。変更管理システム内では、この情報を、さまざまな報告目的ならびに
特定の判断基準に基づくコンポーネントまたは機能の突き止めに使用することが
できる。たとえば、変更管理システムのユーザが、変更管理データを照会して、
デバイス番号「３７１ＡＢ」をサポートするコンポーネントまたは機能を突き止
めることができる。

【０２９０】 データベース・スキャン処理は、情報のアーカイブ作成および検索の分野でサ
ポートを提供することにも広がる。ソフトウェア開発システムが、交換可能なコ
ンポーネントおよび機能の大きいコア・セットの記述に使用される環境では、特
定のプロジェクトでの使用のためにこれらのコンポーネントおよび機能のサブセ
ットを選択することが必要になる。現在の最新技術では、ユーザが、標準ディレ
クトリ・フォルダ・リストからソフトウェア部分を単純に選択して、所望の部分
を累積することが必要であり、さもなければ、より高度なシステムが、この処理
を単純化するスクリプトを提供することができる。本発明では、前に記述された
同一のスキャン処理をコンポーネントおよび機能のコア・セットに適用して、使
用可能なソフトウェア・コア・セットの完全なデータベースを得る。グラフィカ
ル・ユーザ・インターフェース（ＧＵＩ）でこのデータベースを使用して、ユー
ザに、新しい製品に必要なコンポーネントまたは機能を選択する能力を与える。
ユーザ・インターフェースは、この選択処理を容易にするデータベースだけを必
要とする。データベースは、ローカルとすることができ、リモート・サーバに配
置することもできる（付録Ｉを参照されたい）。さらに、ＧＵＩは、特定のコン
ポーネントまたは機能の選択時に、その部分が他のコンポーネントまたは機能に
依存する場合に、即座にユーザに通知することができる。理論的には、ユーザは
、アーカイブからコードの１ビットをダウンロードする前に、エラーなしに新し
いソフトウェア製品に必要なコンポーネントおよび機能のすべてを完全に選択す
る能力を有する。

【０２９１】 通常、製品リリースには、とりわけ、リリースされる製品のすべての部分を識
別するベースライン・ラベルの作成が必然的に伴う。このラベリング処理によっ
て、後の日の製品再生可能性が生じる。最新技術の開発管理システムおよび変更
管理システムを使用すると、リリースされた製品に関する統計情報を関心を持つ
当事者が所望する場合に、その情報を、リリースされた製品をビルドするのに必
要な元のファイルのすべてを再ダウンロードし、その後、これらのファイルを使
用して必要な情報をコンパイルすることによってのみ得ることができるようにで
きる。あるいは、変更管理システムに、ある詳細に関するリリース・ノートが含
まれる場合がある。本発明によって提供される開発システムは、ユーザが、そう
でなければ現在の最新技術システムで使用不能であるかなりの量の情報を得るた
めに、製品リリースに関するＰＬＡＴＦＯＲＭ．ＣＦＧファイルおよびアーカイ
ブされたデータベース（通常はファイルの大きいセットからの２つのファイル）
だけをダウンロードできるようにすることによって、最新技術に対する改善を行
う。この情報には、すべてのインストールされたコンポーネント、機能、依存性
、インターフェース、そのバージョン番号、および標準データベースから得るこ
とのできる他の情報の完全な報告が含まれる。

【０２９２】 このシステムを使用する開発者に制御を提供するほかに、コードベースから収
集された情報のデータベースは、ソース・ライブラリ品質管理を含むさまざまな
目的に使用することができる。システム内の多数のエラーが、ファイルをコンパ
イルする前に表示可能になる。コードベースのすべての存性および定義と、対応
するバージョンとが取り込まれ、コードベース・コヒーレンシの判定が可能にな
る。参照されていないすべての関数の報告によって、デッド・コードがコードベ
ース内に存在しないようになる。ライブラリ内で互換性のあるバージョン番号を
有する依存性が使用可能でないことの報告は貴重なツールである。

【０２９３】 本発明の好ましい実施形態で使用されるシステム・マクロの説明 プロシージャおよびラベルの宣言マクロは、ＰＵＢＬＩＣ＿ＰＲＯＣ、ＰＲＩ
ＶＡＴＥ＿ＰＲＯＣ、ＥＮＤ＿ＰＲＯＣ、ＰＵＢＬＩＣ＿ＬＡＢＥＬ、ＰＲＩＶ
ＡＴＥ＿ＬＡＢＥＬ、およびＦＢＭ＿ＬＡＢＥＬからなる。

【０２９４】 ＰＵＢＬＩＣ＿ＰＲＯＣマクロは、他のコンポーネントから呼び出すことがで
きるプロシージャの先頭をマークする。これは、ＥＮＤ＿ＰＲＯＣマクロと対に
されなければならない。パラメータは、ｎａｍｅ、ｖｅｒｓｉｏｎ、およびオプ
ションのＩＮＴＥＲＣＥＰＴキーワードである。ｎａｍｅパラメータは、ピリオ
ドによって区切られた、クラス名、０個以上のサブクラス名、および実際のプロ
シージャ名から構成される。ｖｅｒｓｉｏｎパラメータは、ピリオドによって区
切られたメジャー・バージョン番号およびマイナー・バージョン番号からなる。
異なるメジャー・バージョン番号を有する呼出し側は非互換である。同一のメジ
ャー・バージョン番号を有するが、より大きいマイナー・バージョン番号を有す
る呼出し側は非互換である。マイナー・バージョン番号の増分は、後方互換性を
暗示する。オプションのＩＮＴＥＲＣＥＰＴパラメータは、複数の定義がある場
合に、製品コンポーネント・リンカが、このプロシージャを呼び出すように呼出
し側をフィックスアップすることを示す。

【０２９５】 ＰＲＩＶＡＴＥ＿ＰＲＯＣマクロは、コンポーネント内からのみ呼び出すこと
ができるプロシージャの先頭をマークする。これは、ＥＮＤ＿ＰＲＯＣマクロと
対にされなければならない。パラメータは、ｎａｍｅ、ｓｃｏｐｅキーワード、
およびオプションのｖｅｒｓｉｏｎである。ｎａｍｅパラメータは、ピリオドに
よって区切られた、クラス名、０個以上のサブクラス名、および実際のプロシー
ジャ名から構成される。ｓｃｏｐｅキーワード・パラメータは、ＮＥＡＲまたは
ＦＡＲでなければならない。オプションのｖｅｒｓｉｏｎパラメータは、プライ
ベート・プロシージャが、共有ファイルまたはｏｅｍフックなど、コンポーネン
トの外部で定義される場合にのみ必要である。指定された場合に、このパラメー
タは、上で説明したＰＵＢＬＩＣ＿ＰＲＯＣマクロのｖｅｒｓｉｏｎパラメータ
と同一である。

【０２９６】 ＥＮＤ＿ＰＲＯＣマクロは、プロシージャの終りをマークし、パラメータを有
しない。これは、先行するＰＵＢＬＩＣ＿ＰＲＯＣマクロまたはＰＲＩＶＡＴＥ
＿ＰＲＯＣマクロと対にされなければならない。

【０２９７】 ＰＵＢＬＩＣ＿ＬＡＢＥＬマクロは、たとえば固定されたエントリ・ポイント
を作成する、コード実行のために他のコンポーネントから使用することができる
ラベルを作成する。パラメータは、ｎａｍｅ、ｖｅｒｓｉｏｎ、およびオプショ
ンのＩＮＴＥＲＣＥＰＴキーワードである。ｎａｍｅパラメータは、ピリオドに
よって区切られた、クラス名、０個以上のサブクラス名、および実際のエントリ
・ポイント名から構成される。ｖｅｒｓｉｏｎパラメータは、上で説明したＰＵ
ＢＬＩＣ＿ＰＲＯＣマクロのｖｅｒｓｉｏｎパラメータと同一である。オプショ
ンのＩＮＴＥＲＣＥＰＴパラメータは、複数の定義がある場合に、製品コンポー
ネント・リンカが、このエントリ・ポイントを呼び出すように呼出し側をフィッ
クスアップすることを示す。

【０２９８】 ＰＲＩＶＡＴＥ＿ＬＡＢＥＬマクロは、たとえば固定されたエントリ・ポイン
トを作成する、コード実行のためにコンポーネント内からのみ使用することがで
きるラベルを作成する。パラメータは、ｎａｍｅおよびオプションのｖｅｒｓｉ
ｏｎである。ｎａｍｅパラメータは、ピリオドによって区切られた、クラス名、
０個以上のサブクラス名、および実際のエントリ・ポイント名から構成される。
オプションのｖｅｒｓｉｏｎパラメータは、プライベート・エントリ・ポイント
が、共有ファイルまたはｏｅｍフックなど、コンポーネントの外部で定義される
場合にのみ必要である。指定された場合に、このパラメータは、上で説明したＰ
ＵＢＬＩＣ＿ＰＲＯＣマクロのｖｅｒｓｉｏｎパラメータと同一である。

【０２９９】 ＦＢＬ＿ＬＡＢＥＬマクロは、製品コンポーネント・リンカによるｆｕｔｕｒ
ｅ ｂｉｎａｒｙ ｍａｎｉｐｕｌａｔｉｏｎ（ＦＢＭ）を指定し、コードは生
成しない。これは、スキャン・ユーティリティおよび製品コンポーネント・リン
カに、このラベルがビルド時にバイナリ・リンカによって生成されるデータを表
すことを知らせる。単一のｎａｍｅパラメータは、ピリオドによって区切られた
、クラス名、０個以上のサブクラス名、および実際のエントリ・ポイント名から
構成される。

【０３００】 外部参照マクロは、ＰＵＢＥＸＴ、ＰＲＶＥＸＴ、ＥＸＴＣＡＬＬ、ＥＸＴＪ
ＭＰ、ＥＸＴＰＴＲ、ＬＯＡＤＡＤＤＲ、ＬＯＡＤＯＦＦ、ＬＯＡＤＳＥＧ、Ｅ
ＸＴＲＥＦ、およびＥＶＡＬＲＥＦマクロからなる。

【０３０１】 ＰＵＢＥＸＴマクロは、パブリック・プロシージャ、パブリック・ラベル、パ
ブリック・リスト、またはパブリック・リスト・エントリへの外部参照を宣言す
る。パラメータは、ｎａｍｅ、ｖｅｒｓｉｏｎ、およびオプションのパラメータ
である属性キーワードまたはｃｏｍｐｏｎｅｎｔ ｎａｍｅ、ａｌｔｎａｍｅ、
およびａｌｔｖｅｒｓｉｏｎである。ｎａｍｅパラメータは、ピリオドによって
区切られた、クラス名、０個以上のサブクラス名、および実際のエントリ・ポイ
ント名からなる。ｖｅｒｓｉｏｎパラメータは、上で説明したＰＵＢＬＩＣ＿Ｐ
ＲＯＣマクロのｖｅｒｓｉｏｎパラメータと同一である。オプションの第３パラ
メータがキーワードＯＰＴＩＯＮＡＬである時には、指定されたラベルが存在し
ない場合に、ラベルへの参照が除去される。オプションの第３パラメータがキー
ワードＳＵＢＳＴＩＴＵＴＥである時には、指定されたラベルが存在しない場合
に、１６進数値ＦＦＦＦＦＦＦＦ（ｆａｒ）またはＦＦＦＦ（ｎｅａｒ）が使用
される。オプションの第３パラメータがキーワードＡＬＴＥＲＮＡＴＥである時
には、第４パラメータが、名前が定義されない場合に使用されるａｌｔｎａｍｅ
であり、第５パラメータが、ａｌｔｎａｍｅプロシージャのバージョン番号であ
る。プロシージャへの呼出しが、オプションのＩＮＴＥＲＣＥＰＴパラメータを
有するＰＵＢＬＩＣ＿ＰＲＯＣとして定義された第２のプロシージャによってイ
ンターセプトされ、このプロシージャが元のプロシージャを呼び出すことを望む
時には、元のコンポーネントの名前が、オプションの第３パラメータとして指定
される。

【０３０２】 ＰＲＶＥＸＴマクロは、プライベート・プロシージャまたはプライベート・ラ
ベルへの外部参照を宣言する。パラメータは、ｎａｍｅ、ｓｃｏｐｅキーワード
、ｖｅｒｓｉｏｎ、およびオプションのパラメータの属性キーワード、ａｌｔｎ
ａｍｅ、およびａｌｔｖｅｒｓｉｏｎである。ｎａｍｅパラメータは、ピリオド
によって区切られた、クラス名、０個以上のサブクラス名、および実際のエント
リ・ポイント名からなる。ｓｃｏｐｅパラメータは、キーワードＮＥＡＲまたは
ＦＡＲからなる。ｖｅｒｓｉｏｎパラメータは、上で説明したＰＵＢＬＩＣ＿Ｐ
ＲＯＣマクロのｖｅｒｓｉｏｎパラメータと同一であるか、キーワードＮＯ＿Ｖ
ＥＲである。バージョンは、ラベルが、共有ファイルまたはオーバーライドなど
、コンポーネントの外部で定義される場合に限って指定される。オプションの第
４パラメータがキーワードＯＰＴＩＯＮＡＬある時には、指定されたラベルが存
在しない場合に、ラベルへの参照が除去される。オプションの第４パラメータが
キーワードＳＵＢＳＴＩＴＵＴＥである時には、指定されたラベルが存在しない
場合に、１６進数値ＦＦＦＦＦＦＦＦ（ｆａｒ）またはＦＦＦＦ（ｎｅａｒ）が
使用される。オプションの第４パラメータがキーワードＡＬＴＥＲＮＡＴＥであ
る時には、第５パラメータが、名前が定義されない場合に使用されるａｌｔｎａ
ｍｅであり、第６パラメータが、ａｌｔｎａｍｅプロシージャのバージョン番号
である。

【０３０３】 ＥＸＴＣＡＬＬマクロは、パブリック・プロシージャまたはプライベート・プ
ロシージャを呼び出すのに使用され、先行するＰＵＢＥＸＴマクロまたはＰＲＶ
ＥＸＴマクロと共に使用されなければならない。パラメータは、ｎａｍｅ、オプ
ションのコードテキスト文字列、およびオプションのコンポーネント名である。
ｎａｍｅパラメータは、ピリオドによって区切られた、クラス名、０個以上のサ
ブクラス名、および実際のプロシージャ名からなる。オプションのコードテキス
ト文字列には、呼出しがリターンした後に実行される命令が含まれる。プロシー
ジャへの呼出しが、オプションのＩＮＴＥＲＣＥＰＴパラメータを有するＰＵＢ
ＬＩＣ＿ＰＲＯＣとして定義された第２のプロシージャによってインターセプト
され、このプロシージャが元のプロシージャを呼び出すことを望む時には、元の
コンポーネントの名前がオプションの第３パラメータとして指定される。

【０３０４】 ＥＸＴＪＭＰマクロは、パブリック・プロシージャまたはプライベート・プロ
シージャにジャンプし、先行するＰＵＢＥＸＴマクロまたはＰＲＶＥＸＴマクロ
と共に使用されなければならない。パラメータは、ｎａｍｅ、オプションのレジ
スタ名、オプションのコードテキスト文字列、およびオプションのコンポーネン
ト名である。ｎａｍｅパラメータは、ピリオドによって区切られた、クラス名、
０個以上のサブクラス名、および実際のプロシージャ名からなる。オプションの
レジスタ名はリターン・アドレスを保持する１６ビット・レジスタを指定する。
オプションのコードテキスト文字列には、呼出しがリターンした後に実行される
命令が含まれる。プロシージャへの呼出しが、オプションのＩＮＴＥＲＣＥＰＴ
パラメータを有するＰＵＢＬＩＣ＿ＰＲＯＣとして定義された第２のプロシージ
ャによってインターセプトされ、このプロシージャが元のプロシージャを呼び出
すことを望む時には、元のコンポーネントの名前が、オプションの第４パラメー
タとして指定される。

【０３０５】 ＥＸＴＰＴＲマクロは、プロシージャまたはラベルへのポインタを割り振り、
先行するＰＵＢＥＸＴマクロまたはＰＲＶＥＸＴマクロと共に使用されなければ
ならない。パラメータはｎａｍｅおよびオプションのコンポーネント名である。
ｎａｍｅパラメータは、ピリオドによって区切られた、クラス名、０個以上のサ
ブクラス名、および実際のプロシージャ名からなる。プロシージャへの呼出しが
、オプションのＩＮＴＥＲＣＥＰＴパラメータを有するＰＵＢＬＩＣ＿ＰＲＯＣ
として定義された第２のプロシージャによってインターセプトされ、このプロシ
ージャが元のプロシージャをポイントすることを望む時には、元のコンポーネン
トの名前が、オプションの第２パラメータとして指定される。

【０３０６】 ＬＯＡＤＡＤＤＲマクロは、プロシージャまたはラベルのアドレスをレジスタ
にロードし、先行するＰＵＢＥＸＴマクロまたはＰＲＶＥＸＴマクロと共に使用
されなければならない。パラメータは、ｎａｍｅ、オプションのｓｅｇｍｅｎｔ
ｒｅｇ、オプションのｏｆｆｓｅｔｒｅｇ、およびオプションのコンポーネント
名である。ｎａｍｅパラメータは、ピリオドによって区切られた、クラス名、０
個以上のサブクラス名、および実際のプロシージャ名からなる。オプションのｓ
ｅｇｍｅｎｔｒｅｇパラメータは、アドレスのセグメント部分を保持する１６ビ
ット・レジスタを指定する（デフォルトはＥＳである）。オプションのｏｆｆｓ
ｅｔｒｅｇパラメータは、アドレスのオフセット部分を保持する１６ビット・レ
ジスタを指定する（デフォルトはＤＩである）。プロシージャへの呼出しが、オ
プションのＩＮＴＥＲＣＥＰＴパラメータを有するＰＵＢＬＩＣ＿ＰＲＯＣとし
て定義された第２のプロシージャによってインターセプトされ、このプロシージ
ャが元のプロシージャのアドレスをロードすることを望む時には、元のコンポー
ネントの名前が、オプションの第４パラメータとして指定される。

【０３０７】 ＬＯＡＤＯＦＦマクロは、パブリック・ラベルまたはプライベート・ラベルの
オフセットを１６ビット・レジスタにロードし、先行するＰＵＢＥＸＴマクロま
たはＰＲＶＥＸＴマクロと共に使用されなければならない。パラメータは、ｏｆ
ｆｓｅｔｒｅｇ、ｎａｍｅ、およびオプションのコンポーネント名である。ｏｆ
ｆｓｅｔｒｅｇパラメータは、オフセットを保持する１６ビット・レジスタの名
前を指定する（デフォルトはＤＩ）。ｎａｍｅパラメータは、ピリオドによって
区切られた、クラス名、０個以上のサブクラス名、および実際のプロシージャ名
からなる。プロシージャへの呼出しが、オプションのＩＮＴＥＲＣＥＰＴパラメ
ータを有するＰＵＢＬＩＣ＿ＰＲＯＣとして定義された第２のプロシージャによ
ってインターセプトされ、このプロシージャが元のプロシージャのアドレスをロ
ードすることを望む時には、元のコンポーネントの名前がオプションの第４パラ
メータとして指定される。

【０３０８】 ＬＯＡＤＳＥＧマクロは、パブリック・ラベルまたはプライベート・ラベルの
セグメントを１６ビット・レジスタにロードし、先行するＰＵＢＥＸＴマクロま
たはＰＲＶＥＸＴマクロと共に使用されなければならない。パラメータは、ｓｅ
ｇｍｅｎｔｒｅｇ、ｎａｍｅ、およびオプションのコンポーネント名である。ｓ
ｅｇｍｅｎｔｒｅｇパラメータは、セグメントを保持する１６ビット・レジスタ
の名前を指定する（デフォルトはＤＩ）。ｎａｍｅパラメータは、ピリオドによ
って区切られた、クラス名、０個以上のサブクラス名、および実際のプロシージ
ャ名からなる。プロシージャへの呼出しが、オプションのＩＮＴＥＲＣＥＰＴパ
ラメータを有するＰＵＢＬＩＣ＿ＰＲＯＣとして定義された第２のプロシージャ
によってインターセプトされ、このプロシージャが元のプロシージャをアドレス
をロードすることを望む時には、元のコンポーネントの名前が、オプションの第
４パラメータとして指定される。

【０３０９】 ＥＸＴＲＥＦマクロは、パブリック・ラベルまたはプライベート・ラベルのア
ドレスを含むように構造体メンバをフィックスアップするのに使用され、先行す
るＰＵＢＥＸＴマクロまたはＰＲＶＥＸＴマクロと共に使用されなければならな
い。パラメータは、ｎａｍｅ、オプションのｓｔｒｕｃＭｅｍ ｎａｍｅ、オプ
ションのコンポーネント名、およびオプションのＦＯＲＷＡＲＤ＿ＲＥＦＥＲＥ
ＮＣＥキーワードである。ｎａｍｅパラメータは、ピリオドによって区切られた
、クラス名、０個以上のサブクラス名、および実際のプロシージャ名からなる。
オプションのｓｔｒｕｃＭｅｍ ｎａｍｅは、フィックスアップがｆａｒである
場合に、フィックスアップされる構造体メンバを識別する。プロシージャへの呼
出しが、オプションのＩＮＴＥＲＣＥＰＴパラメータを有するＰＵＢＬＩＣ＿Ｐ
ＲＯＣとして定義された第２のプロシージャによってインターセプトされ、この
プロシージャが元のプロシージャをアドレスをフィクスアップすることを望む時
には、元のコンポーネントの名前が、オプションの第３パラメータとして指定さ
れる。オプションのＦＯＲＷＡＲＤ＿ＲＥＦＥＲＥＮＣＥキーワードは、マクロ
に、オフセットを計算するのに前方参照匿名ラベルを使用させる。

【０３１０】 ＥＶＡＬＲＥＦマクロ、ラベルのアドレスを命令内で使用できるようにする。
パラメータは、ｏｐｃｏｄｅ、ｄｅｓｔｉｎａｔｉｏｎ、およびｓｏｕｒｃｅで
ある。ｏｐｃｏｄｅパラメータは生成される命令の名前である。ｄｅｓｔｉｎａ
ｔｉｏｎパラメータは、レジスタ、ラベル、またはプロシージャを指定し、ｓｏ
ｕｒｃｅパラメータは、レジスタ、即値、プロシージャ、またはラベルを指定す
る。ｄｅｓｔｉｎａｔｉｏｎパラメータまたはｓｏｕｒｃｅパラメータのプロシ
ージャまたはラベルは、ＥＶＡＬＲＥＦマクロと同一の行でかぎ括弧（＜＞）に
囲まれたＥＸＴＲＥＦマクロを使用して定義されなけばならない。

【０３１１】 インクルード・ファイル宣言マクロは、ＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿ＳＴ
ＡＲＴ、ＰＲＩＶＡＴＥ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴ、ＰＲＶＩＮＣ、および
ＰＵＢＩＮＣである。

【０３１２】 ＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴマクロは、他のコンポーネントが
使用することのできるインクルード・ファイルの先頭を宣言する。パラメータは
、ｃｌａｓｓｈｅｉｒａｒｃｈｙおよびｖｅｒｓｉｏｎである。ｃｌａｓｓｈｅ
ｉｒａｒｃｈｙパラメータは、ピリオドによって区切られた、クラス名および０
個以上のサブクラス名である。ｖｅｒｓｉｏｎパラメータは、ピリオドによって
区切られた、インクルード・ファイルによって定義されるインターフェースのメ
ジャー・バージョン番号およびマイナー・バージョン番号である。

【０３１３】 ＰＲＩＶＡＴＥ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴマクロは、現在のコンポーネン
ト内でのみ使用することができるインクルード・ファイルの先頭を宣言する。パ
ラメータは、ｃｌａｓｓｈｅｉｒａｒｃｈｙおよびオプションのｖｅｒｓｉｏｎ
である。ｃｌａｓｓｈｅｉｒａｒｃｈｙパラメータは、ピリオドによって区切ら
れた、クラス名および０個以上のサブクラス名である。ｖｅｒｓｉｏｎパラメー
タは、ピリオドによって区切られた、インクルード・ファイルによって定義され
るインターフェースのメジャー・バージョン番号およびマイナー・バージョン番
号であり、インクルード・ファイルが、共有インクルード・ファイルなどのコン
ポーネントの外部にある場合に限って使用される。

【０３１４】 ＰＲＶＩＮＣマクロは、プライベート・インクルード・ファイルをインクルー
ドする。パラメータは、ｃｌａｓｓｈｅｉｒａｒｃｈｙ、ｆｉｌｅｎａｍｅ、お
よびオプションのｖｅｒｓｉｏｎである。ｃｌａｓｓｈｅｉｒａｒｃｈｙパラメ
ータは、ピリオドによって区切られた、クラス名および０個以上のサブクラス名
である。ｆｉｌｅｎａｍｅパラメータはインクルード・ファイルの名前である。
ｖｅｒｓｉｏｎパラメータは、ピリオドによって区切られた、インクルード・フ
ァイルによって定義されるインターフェースのメジャー・バージョン番号および
マイナー・バージョン番号であり、インクルード・ファイルが共有インクルード
・ファイルなどのコンポーネントの外部にある場合に限って使用される。

【０３１５】 ＰＵＢＩＮＣマクロは、パブリック・インクルード・ファイルをインクルード
する。パラメータは、ｃｌａｓｓｈｅｉｒａｒｃｈｙ、ｆｉｌｅｎａｍｅ、およ
びｖｅｒｓｉｏｎである。ｃｌａｓｓｈｅｉｒａｒｃｈｙパラメータは、ピリオ
ドによって区切られた、クラス名および０個以上のサブクラス名である。ｆｉｌ
ｅｎａｍｅパラメータは、インクルード・ファイルの名前である。ｖｅｒｓｉｏ
ｎパラメータは、ピリオドによって区切られた、インクルード・ファイルによっ
て定義されるインターフェースのメジャー・バージョン番号およびマイナー・バ
ージョン番号である。

【０３１６】 プロシージャ・ヘッダ・マクロは、ＤＥＳＣＲＩＰＴＩＯＮ、ＩＮＰＵＴ：、
ＯＵＴＰＵＴ：、ＭＯＤＩＦＩＥＤ：、ＭＥＭ、ＲＥＧ、ＮＯＮＥ、およびＯＥ
Ｍ＿ＨＯＯＫである。これらのマクロのどれもが、コードを全く生成せず、これ
らのマクロの目的は、ソース・ファイルがスキャンされる時に、先行するＰＵＢ
ＬＩＣ＿ＰＲＯＣマクロまたはＰＲＩＶＡＴＥ＿ＰＲＯＣマクロによって定義さ
れたプロシージャを記述する情報の位置およびタイプを識別することである。

【０３１７】 セグメント・マクロは、ＣＯＤＥ＿ＳＥＧＭＥＮＴ＿ＯＰＥＮ、ＤＡＴＡ＿Ｓ
ＥＧＭＥＮＴ＿ＯＰＥＮ、ＡＳＳＵＭＥ＿ＣＯＤＥ＿ＳＥＧＭＥＮＴ、ＡＳＳＵ
ＭＥ＿ＤＡＴＡ＿ＳＥＧＭＥＮＴ、およびＳＥＧＭＥＮＴ＿ＣＬＯＳＥである。

【０３１８】 ＣＯＤＥ＿ＳＥＧＭＥＮＴ＿ＯＰＥＮマクロは、ＳＥＧＭＥＮＴ＿ＣＬＯＳＥ
マクロを使用してクローズされなければならないコード・セグメントの冒頭をマ
ークする。パラメータは、それに続くコードの配置および「寿命」を決定するプ
ラス（＋）を使用して組み合わされた属性キーワードの式である。

【０３１９】 ＤＡＴＡ＿ＳＥＧＭＥＮＴ＿ＯＰＥＮマクロは、ＳＥＧＭＥＮＴ＿ＣＬＯＳＥ
マクロを使用してクローズされなければならないデータ・セグメントの冒頭をマ
ークする。パラメータは、それに続くデータの配置および「寿命」を決定するプ
ラス（＋）を使用して組み合わされた属性キーワードの式である。

【０３２０】 ＡＳＳＵＭＥ＿ＣＯＤＥ＿ＳＥＧＭＥＮＴマクロは、指定されたセグメント・
レジスタが、指定された属性を含むコード・セグメントをポイントするとアセン
ブラに仮定させる。パラメータは、仮定を行うセグメント・レジスタと、属性を
指定するプラス（＋）を使用して組み合わされた属性キーワードの式である。

【０３２１】 ＡＳＳＵＭＥ＿ＤＡＴＡ＿ＳＥＧＭＥＮＴマクロは、指定されたセグメント・
レジスタが、指定された属性を含むデータ・セグメントをポイントするとアセン
ブラに仮定させる。パラメータは、仮定を行うセグメント・レジスタと、属性を
指定するプラス（＋）を使用して組み合わされた属性キーワードの式である。

【０３２２】 ＳＥＧＭＥＮＴ＿ＣＬＯＳＥマクロは、先行するＣＯＤＥ＿ＳＥＧＭＥＮＴ＿
ＯＰＥＮマクロまたはＤＡＴＡ＿ＳＥＧＭＥＮＴ＿ＯＰＥＮマクロによってオー
プンされなければならないコード・セグメントまたはデータ・セグメントの終り
をマークする。

【０３２３】 オプション・マクロは、ＯＰＴＥＸＴ、ＯＰＴＣＨＫ、ＬＯＡＤＯＰＴ、ＤＢ
＿ＯＰＴ、ＤＷ＿ＯＰＴ、およびＤＤ＿ＯＰＴである。

【０３２４】 ＯＰＴＥＸＴマクロは、コンポーネントまたは機能の情報ファイルで宣言され
た、別のコンポーネントまたは機能からのオプションへの参照を宣言する。パラ
メータは、ｎａｍｅとオプションのコンポーネント名である。ｎａｍｅパラメー
タは、ピリオドによって区切られた、クラス名、０個以上のサブクラス名、およ
び実際のオプション名からなる。プロシージャへの呼出しが、オプションのＩＮ
ＴＥＲＣＥＰＴパラメータを有するＰＵＢＬＩＣ＿ＰＲＯＣとして定義された第
２のプロシージャによってインターセプトされ、このプロシージャが元のコンポ
ーネントまたは機能のオプションを参照することを望む時には、元のコンポーネ
ントの名前が、オプションの第２パラメータとして指定される。

【０３２５】 ＯＰＴＣＨＫマクロは、指定された条件および値を用いて、指定されたオプシ
ョン（先行するＯＰＴＥＸＴマクロによって宣言されていなければならない）を
テストする。真である場合に、ｔｒｕｅｃｏｄｅｔｅｘｔが実行され、そうでな
い場合には、ｆａｌｓｅｃｏｄｅｔｅｘｔが実行される。パラメータは、ｏｐｔ
ｉｏｎｎａｍｅ、条件キーワード、ｖａｌｕｅ、ｔｒｕｅｃｏｄｅｔｅｘｔ、お
よびオプションのｆａｌｓｅｃｏｄｅｔｅｘｔである。ｏｐｔｉｏｎｎａｍｅパ
ラメータは、ピリオドによって区切られた、クラス名、０個以上のサブクラス名
、および実際のオプション名からなる。条件キーワードは、通常の通例の意味を
有する、ＬＥ、ＬＴ、ＧＥ、ＧＴ、ＮＥ、またはＥＱの１つである。ｖａｌｕｅ
パラメータは定数である。ｔｒｕｅｃｏｄｅｔｅｘｔパラメータには、条件が真
の場合に実行されるコードが含まれ、オプションのｆａｌｓｅｃｏｄｅｔｅｘｔ
パラメータには、条件が偽の場合に実行されるコードが含まれる。

【０３２６】 ＬＯＡＤＯＰＴマクロは、指定されたｄｅｓｔｉｎａｔｉｏｎに指定されたオ
プションの値をロードする。オプションは前にＯＰＴＥＸＴマクロを用いて宣言
されていなければならない。パラメータはｄｅｓｔｉｎａｔｉｏｎおよびｏｐｔ
ｉｏｎｎａｍｅである。ｄｅｓｔｉｎａｔｉｏｎパラメータは、オプション値を
保持するメモリ位置またはレジスタを指定し、オプション・サイズ以下でなけれ
ばならない。ｏｐｔｉｏｎｎａｍｅパラメータは、ピリオドによって区切られた
、クラス名、０個以上のサブクラス名、および実際のオプション名からなる。

【０３２７】 ＤＢ＿ＯＰＴマクロ、ＤＷ＿ＯＰＴマクロ、およびＤＤ＿ＯＰＴマクロは、そ
れぞれ、前にＯＰＴＥＸＴマクロを用いて宣言されていなければならない指定さ
れたオプションの値を含むバイト、ワード、またはダブル・ワードを、現在のセ
グメントに置く。オプションのｎａｍｅパラメータは、ピリオドによって区切ら
れた、クラス名、０個以上のサブクラス名、および実際のオプション名からなる
。

【０３２８】 マクロの行単位の説明 以下の本発明の好ましい実施形態でのマクロの説明中のマクロ、マクロ・パラ
メータ、およびマクロ変数に命名する識別子は、大文字（ＡからＺ）または小文
字（ａからｚ）または疑問符（？）から始まり、０個以上の文字、数字（０から
９）、アンダースコア（＿）、または疑問符文字が続く。３つの疑問符（？？？
）から始まるマクロ変数名は、マクロ内でのみ定義され参照される変数を区別す
る。マクロ・ステートメント内で参照されるマクロ変数は、通常は、現在の内容
に置換される。マクロ・ステートメントがパーセント（％）から始まる時には、
マクロ変数が、普通に現在の値に置換され、その後、置換の後に、残っているマ
クロ変数に命名する識別子のすべてが現在の値に置換される。

【０３２９】 文字列は、未満（＜）記号および超（＞）記号によって区切られる。

【０３３０】 ＩＦステートメントは、真である場合に、一致するＥＬＳＥステートメントま
たはＥＮＤＩＦステートメントまでのマクロ・ステートメントを評価させる条件
を示す。ＥＬＳＥステートメントは、先行するＩＦステートメントが偽である場
合に、一致するＥＮＤＩＦステートメントまでのマクロ・ステートメントを評価
させる。ＥＬＳＥステートメントをＩＦと組み合わせて、先行するＩＦステート
メントが偽であり、ＥＬＳＥＩＦステートメントが真である場合に、一致するＥ
ＮＤＩＦステートメントまでのマクロ・ステートメントが評価されることを示す
ことができる。Ｉｆステートメントの一部が、ＩＦＥ式 − 式が０と等しい場
合、ＩＦＮＢ ＜文字列＞ −−−−− 文字列が空白でない場合、ＩＦＤＥＦ
変数 − 変数が定義されている場合、ＩＦ式 − 式が真である場合、ＩＦＩ
ＤＮ ＜文字列１＞、＜文字列２＞− 文字列１が文字列２と同一である場合、
およびＩＦＤＩＦ ＜文字列１＞、＜文字列２＞ − 文字列１が文字列２と異
なる場合、である。

【０３３１】 １．エグジット・マクロ エグジット・マクロは、ここで説明するＥＸＴＣＡＬＬおよびＥＸＴＪＭＰと
、節４で説明するＲＯＭＣＡＬＬである。エグジット・マクロは、制御のフロー
が現在のプロシージャから出、エグジット・マクロによって識別されるプロシー
ジャに進み、その後リターンする点を識別する。

【０３３２】 DEFINE_PREFIX TEXTEQU <D_> PROC_PREFIX TEXTEQU <P_> これらの２つのテキスト式は、これに続くマクロで使用される文字列プレフィ
ックスを含むグローバル・マクロ変数を定義する。

【０３３３】 １．１ ＥＸＴＣＡＬＬマクロ ＥＸＴＣＡＬＬマクロは、本発明によって、異なるコンポーネント内のパブリ
ック・プロシージャまたは現在のコンポーネント内のプライベート・プロシージ
ャを呼び出すのに使用される。ＥＸＴＣＡＬＬマクロによって生成されるコード
は、本発明によってスキャンされるｐｒｏｃｅｄｕｒｅＮａｍｅに関するエグジ
ット宣言マクロおよびエントリ定義マクロに依存する。本発明によって作られ、
かつ各ソース・コード・ファイルにインクルードされるコードがある場合にどの
コードを生成しなければならないのかを示す機能インクルード・ファイル内で、
ｐｒｏｃｅｄｕｒｅＮａｍｅ用のグローバル・マクロ変数を生成するのに上記し
たマクロからの情報が使用される。

【０３３４】 EXTCALL MACRO procedureName:REQ, optionalCode, component BRANCH_HANDLER procedureName, call, <optionalCode>,, <component> ENDM ＥＸＴＣＡＬＬマクロは、呼出し命令、ビルド用のフィックスアップ・データ
、および、供給される場合にオプションのコードを生成する。使用法：「ＥＸＴ
ＣＡＬＬ ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ， ＜ｊｃ ｅｘｉｔ＞」。パラメー
タは次の通りである。 ｐｒｏｃｅｄｕｒｅＮａｍｅ（必須） − ドット表記の呼び出されるプロシ
ージャの名前、たとえば“ｃｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ
”。 ｏｐｔｉｏｎａｌＣｏｄｅ − アセンブルされるオプションのコード、通常
は、プロシージャによってセットされるキャリー・フラグに基づくジャンプ。 ｃｏｍｐｏｎｅｎｔ − 複数のコンポーネントが同一のｐｒｏｃｅｄｕｒｅ
Ｎａｍｅを定義する時に、このプロシージャが定義されるコンポーネントの名前
を指定するのに使用することができる。

【０３３５】 ＥＸＴＣＡＬＬマクロは、適切なパラメータを用いてＢＲＡＮＣＨ＿ＨＡＮＤ
ＬＥＲマクロを呼び出すことによって実施される。ＢＲＡＮＣＨ＿ＨＡＮＤＬＥ
Ｒマクロの第４パラメータが、故意に省略されていることに留意されたい。

【０３３６】 １．２ ＥＸＴＪＭＰマクロ ＥＸＴＪＭＰマクロは、本発明によって、異なるコンポーネント内のパブリッ
ク・プロシージャまたは現在のコンポーネント内のプライベート・プロシージャ
を呼び出すのに使用される。ＥＸＴＪＭＰマクロによって生成されるコードは、
本発明によってスキャンされるｐｒｏｃｅｄｕｒｅＮａｍｅに関するエグジット
宣言マクロおよびエントリ定義マクロに依存する。これらのマクロからの情報は
、本発明によって作られ、かつコードがある場合にどのコードを生成しなければ
ならないのかを示す各ソース・コード・ファイルにインクルードされる機能イン
クルード・ファイル内で、ｐｒｏｃｅｄｕｒｅＮａｍｅ用のグローバル・マクロ
変数を生成するのに使用される。

【０３３７】 EXTJMP MACRO procedureName:REQ, register, optionalCode, component BRANCH_HANDLER procedureName, jmp, <optionalCode>, <register>, <component> ENDM ＥＸＴＪＭＰマクロは、パブリック・プロシージャまたはプライベート・プロ
シージャを呼び出すのに使用される。このマクロは、ジャンプ命令、ビルド用の
フィックスアップ・データ、および供給される場合にオプションのコードを生成
する。使用法：「ＥＸＴＪＭＰ ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ， ＜ｊｃ ｅ
ｘｉｔ＞」。パラメータは次の通りである。 ｐｒｏｃｅｄｕｒｅＮａｍｅ（必須） − ドット表記の呼び出されるプロシ
ージャの名前、たとえば“ｃｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ
”。 ｒｅｇｉｓｔｅｒ − リターン・アドレスを保持する、オプションのレジス
タ。 ｏｐｔｉｏｎａｌＣｏｄｅ − アセンブルされるオプションのコード、通常
は、プロシージャによってセットされるキャリー・フラグに基づくジャンプ。 ｃｏｍｐｏｎｅｎｔ − 複数のコンポーネントが同一のｐｒｏｃｅｄｕｒｅ
Ｎａｍｅを定義する時に、このプロシージャが定義されるコンポーネントの名前
を指定するのに使用することができる。

【０３３８】 ＥＸＴＪＭＰマクロは、適切なパラメータを用いてＢＲＡＮＣＨ＿ＨＡＮＤＬ
ＥＲマクロを呼び出すことによって実施される。

【０３３９】 １．３ ＢＲＡＮＣＨ＿ＨＡＮＤＬＥＲマクロ ＢＲＡＮＣＨ＿ＨＡＮＤＬＥＲマクロは、必要な関数を本発明に提供し、ソー
ス・コード・ファイルによって直接には絶対に呼び出されない内部マクロである
。

【０３４０】 BRANCH_HANDLER MACRO externName:REQ, branchInstruction:REQ, ＼ optionalCode, register, component ＢＲＡＮＣＨ＿ＨＡＮＤＬＥＲマクロは、パブリック・プロシージャまたはプ
ライベート・プロシージャを呼び出すのに使用される。最初の行の末尾のバック
スラッシュ（＼）は、行継続を指定する。パラメータは、次の通りである。 ｅｘｔｅｒｎＮａｍｅ（必須） − ドット表記の、呼び出される外部プロシ
ージャの名前、たとえば「ｃｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ
」。 ｂｒａｎｃｈＩｎｓｔｒｕｃｔｉｏｎ（必須） − ｃａｌｌまたはｊｍｐ。 ｏｐｔｉｏｎａｌＣｏｄｅ − アセンブルされるオプションのコード、通常
は、呼び出されるプロシージャによってセットされるキャリー・フラグに基づく
ジャンプ。 ｒｅｇｉｓｔｅｒ − リターン・アドレス・オフセットを含むレジスタ。 ｃｏｍｐｏｎｅｎｔ − 複数のコンポーネントが同一のｐｒｏｃｅｄｕｒｅ
Ｎａｍｅを定義する時に、このプロシージャが定義されるコンポーネントの名前
を指定するのに使用することができる。

【０３４１】 LOCAL ???addr LOCAL ???retAddr LOCAL ???defineName LOCAL ???procedureName LOCAL ???extern これらは、このマクロによって使用されるローカル変数である。

【０３４２】 GET_SYMBOL_NAME <externName>, <component> ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡＭＥマクロは、グローバル変数？？？ｓｙｍｂｏ
ｌに、ドット（．）をアンダーバー（＿）に置換されたｅｘｔｅｒｎＮａｍｅ（
指定される場合にはｃｏｍｐｏｎｅｎｔ．ｅｘｔｅｒｎＮａｍｅ）を返す。たと
えば、＜ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ＞は、ｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔと
して返される。

【０３４３】 ???defineName CATSTR DEFINE_PREFIX, ???symbol ???procedureName CATSTR PROC_PREFIX, ???symbol ｅｘｔｅｒｎＮａｍｅがｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔである場合には、？？
？ｄｅｆｉｎｅＮａｍｅが、Ｄ＿ｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔになり、？？？
ｐｒｏｃｅｄｕｒｅＮａｍｅが、Ｐ＿ｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔになる。

【０３４４】 IFNB <component> IFNB <optionalCode> .ERR <BRANCH_HANDLER: Cannot specify optionalCode with ＼ component> ENDIF ENDIF ｃｏｍｐｏｎｅｎｔパラメータとｏｐｔｉｏｎａｌＣｏｄｅパラメータの両方
が指定された場合に、エラーを生成する。

【０３４５】 %IFDEF ???defineName % IF ((???defineName EQ TRUE) OR (???defineName EQ FALSE)) % .ERR <BRANCH_HANDLER: The name !'externName!' has not ＼ been PUBEXT or PRVEXT> ENDIF ｅｘｔｅｒｎＮａｍｅ（ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ）が、ＰＵＢＥＸＴマ
クロまたはＰＲＶＥＸＴマクロを使用して宣言されていることを検証する。これ
は、システムに、グローバル変数（Ｄ＿ｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔ）を定義
させ、そのタイプを示す、ＴＲＵＥでもＦＡＬＳＥでもない値を与えさせる。各
行の先頭のパーセント記号（％）は、ＩＦステートメントに、？？？ｄｅｆｉｎ
ｅＮａｍｅによって指定されるグローバル変数の値を参照させる。

【０３４６】 % IFE ???defineName AND TYPE_SUBSTITUTE ローカル変数？？？ｄｅｆｉｎｅＮａｍｅによって指定されるグローバル変数
の値が、ＴＹＰＥ＿ＳＵＢＳＴＩＴＵＴＥビットをセットされていない場合には
、ｅｘｔｅｒｎＮａｍｅが、ＳＵＢＳＴＩＴＵＴＥ属性を用いて宣言されておら
ず、コードを生成することができない。

【０３４７】 % IFE ???defineName AND TYPE_NOT_INSTALLED ＴＹＰＥ＿ＮＯＴ＿ＩＮＳＴＡＬＬＥＤビットがセットされていない場合には
、ｅｘｔｅｒｎＮａｍｅの定義を含むコンポーネントまたは機能が、ビルドに含
まれ、コードを生成することができる。

【０３４８】 IFNB <register> mov register, ???retAddr ENDIF レジスタが指定された場合に、そのレジスタにリターン・アドレス・オフセッ
トをロードする。

【０３４９】 % IF ???defineName AND TYPE_NEAR % GET_SYMBOL_NAME ???procedureName % ???extern CATSTR <???symbol> % branchInstruction ???extern ＴＹＰＥ＿ＮＥＡＲビットがセットされている場合には、ｎｅａｒ分岐として
ｂｒａｎｃｈＩｎｓｔｒｕｃｔｉｏｎ（ｃａｌｌまたはｊｍｐ）を生成する。ｎ
ａｍｅパラメータが、ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔである場合には、？？？ｐ
ｒｏｃｅｄｕｒｅＮａｍｅに、このプロシージャの名前を含む、ＰＵＢＥＸＴマ
クロによって定義されたグローバル変数の名前であるＰ＿ｐｃｉ＿ｏｐｒｏｍ＿
ｉｎｉｔが含まれる。ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡＭＥマクロは、このグローバ
ル変数の値（通常はｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ）を渡され、したがって、Ｐ
ＵＢＥＸＴマクロが、必要な時に代替プロシージャ名を使用することができる。
ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡＭＥマクロは、ドット（．）をアンダーバー（＿）
に置換された？？？ｐｒｏｃｅｄｕｒｅＮａｍｅを、グローバル変数？？？ｓｙ
ｍｂｏｌで返す。たとえば、ＰＵＢＬＩＣ＿ＰＲＯＣマクロによって定義された
プロシージャの名前である＜ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ＞は、ｐｃｉ＿ｏｐ
ｒｏｍ＿ｉｎｉｔとして返される。

【０３５０】 ELSE IFIDNI <branchInstruction>, <call> DB 09Ah ; far callのオペコード ELSEIFIDNI <branchInstruction>, <jmp> DB 0EAh ; far jumpのオペコード ELSE % .ERR <BRANCH_HANDLER: Unknown branch ＼ instruction !'branchInstruction!'> ENDIF ???addr EQU $ DW $ DW $ プロシージャ・アドレスが後にフィックス・アップされる、ｆａｒ ｃａｌｌ
（またはｊｍｐ）コードを生成する。ｂｒａｎｃｈＩｎｓｔｒｕｃｔｉｏｎパラ
メータに期待されるものが含まれない場合に、エラーが生成される。フィックス
アップ位置の物理アドレス（？？？ａｄｄｒ）が、フィックスアップ位置自体に
格納されることに留意されたい。ビルド・ツールは、格納されたフィックスアッ
プ・アドレス（それ自体を参照する）を、健全性検査として使用する。

【０３５１】 % SAVE_EXT_FIXUP_DATA ???procedureName, TYPE_EXT_FAR, ???addr, , component ENDIF ＳＡＶＥ＿ＥＸＴ＿ＦＩＸＵＰ＿ＤＡＴＡマクロを呼び出して、この外部参照
のフィックスアップ・データを保存する（下を参照されたい）。行の先頭のパー
セント記号（％）が、？？？ｐｒｏｃｅｄｕｒｅＮａｍｅによって指定されるグ
ローバル変数（Ｐ＿ｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔ）に格納されたプロシージャ
名（ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ）を、分岐のターゲットとして保管させる。

【０３５２】 ???retAddr EQU $ 上でレジスタにロードされたリターン・アドレスを定義する。

【０３５３】 IFNB <optionalCode> optionalCode ENDIF ENDIF ｏｐｔｉｏｎａｌＣｏｄｅが存在する場合に、それを生成する。

【０３５４】 ELSE .ERR <BRANCH_HANDLER: Cannot use the SUBSTITUTE attribute with calls/jumps> ENDIF ＴＹＰＥ＿ＳＵＢＳＴＩＴＵＴＥビットがセットされた場合に、エラーを生成
する。

【０３５５】 ELSE % .ERR <BRANCH_HANDLER: !'externName!' is not defined> ENDIF ？？？ｄｅｆｉｎｅＮａｍｅによって定義されるグローバル変数（Ｄ＿ｐｃｉ
＿ｏｐｒｏｍ＿ｉｎｉｔ）が定義されていない場合に、エラーを生成する。

【０３５６】 ENDM マクロを終了し、呼出し元にリターンする。

【０３５７】 １．４ ＳＡＶＥ＿ＥＸＴ＿ＦＩＸＵＰ＿ＤＡＴＡマクロ ＳＡＶＥ＿ＥＸＴ＿ＦＩＸＵＰ＿ＤＡＴＡマクロは、必要な機能を本発明に提
供し、ソース・コード・ファイルによって直接には絶対に呼び出されない内部マ
クロである。

【０３５８】 SAVE_EXT_FIXUP_DATA MACRO callProcedure:REQ, fixupType:REQ, addr:REQ, ＼ addrOffset, component ＳＡＶＥ＿ＥＸＴ＿ＦＩＸＵＰ＿ＤＡＴＡマクロは、特別な名前のセグメント
に、パラメータによって指定されるフィックスアップ・データを保存するのに使
用される内部マクロである。パラメータは次の通りである。 ｃａｌｌＰｒｏｃｅｄｕｒｅ（必須） − プロシージャ名。 ｆｉｘｕｐＴｙｐｅ（必須） − フィックスアップ・タイプ、たとえば、Ｔ
ＹＰＥ＿ＥＸＴ＿ＦＡＲ。 ａｄｄｒ（必須） − フィックスアップのアドレス。 ａｄｄｒＯｆｆｓｅｔ − オフセット・フィックスアップがセグメント・フ
ィックスアップから分離される場合のオフセットのアドレス。 ｃｏｍｐｏｎｅｎｔ − 複数のコンポーネントが同一のｐｒｏｃｅｄｕｒｅ
Ｎａｍｅを定義する時に、このプロシージャが定義されるコンポーネントの名前
を指定するのに使用することができる。

【０３５９】 このマクロは、下記の構造体を生成する： DB procedure name DB 0 DB component name DB 0 DB fixup type DW offset of offset fixup DW offset of segment fixup DW segment for fixups externSegment SEGMENT DB '&callProcedure' ; プロシージャ文字列 DB 0 ; 文字列をヌル終端する IFNB <component> DB '&component' ; 解決されるコンポーネント ENDIF DB 0 ; 文字列をヌル終端する DB fixupType ; フィックスアップ・タイプ IFNB <addrOffset> DW OFFSET addrOffset ; オフセット・フィックスアップ ; のオフセット ELSE DW OFFSET addr ENDIF IFB <addrOffset> DW OFFSET addr + 2 ; セグメント・フィックスアップ ; のオフセット ELSE DW OFFSET addr ENDIF DW SEG addr ; フィックスアップのセグメント externSegment ENDS ENDM

【０３６０】 外部フィックスアップ・データを含む構造体は特別なセグメントに置かれる。
ｃａｌｌＰｒｏｃｅｄｕｒｅは、ヌル終端文字列として格納される。ｃｏｍｐｏ
ｎｅｎｔパラメータがブランクでない場合には、これもヌル終端文字列として格
納される。ｃｏｍｐｏｎｅｎｔパラメータがブランクである場合には、ヌル終端
子だけを格納する。ヌル終端子は、０の値を有するＡＳＣＩＩ文字ＮＵＬであり
、文字列の終りを示すのに使用される。ａｄｄｒＯｆｆｓｅｔパラメータがブラ
ンクの場合には、フィックス・アップされるオフセットおよびセグメントが、隣
接するワード、それぞれａｄｄｒおよびａｄｄｒ＋２に保管され、そうでない場
合には、ａｄｄｒＯｆｆｓｅｔが、フィックス・アップされるオフセットのアド
レスを指定し、ａｄｄｒが、フィックス・アップされるセグメントのアドレスを
指定する。

【０３６１】 このマクロへの呼出しのそれぞれによって生成されるフィックスアップ・デー
タは、その呼出しを含むソース・コード・ファイルが、コンパイルされ、リンク
され、製品コンポーネント・リンカによって処理される時に、単一のｅｘｔｅｒ
ｎＳｅｇｍｅｎｔにマージされる。各オブジェクト・ファイル内のｅｘｔｅｒｎ
Ｓｅｇｍｅｎｔは、オブジェクト・ファイルがリンクされてコンポーネント．Ｅ
ＸＥファイルを形成する時に、単一のｅｘｔｅｒｎＳｅｇｍｅｎｔにマージされ
る。各コンポーネント．ＥＸＥファイルのｅｘｔｅｒｎＳｅｇｍｅｎｔ内のフィ
ックスアップ・データは、ＢＩＯＳコンポーネント・リンカによって、外部参照
のセグメントおよびオフセットをフィックスアップするのに使用される。

【０３６２】 ２．エグジット宣言マクロ ２．１ ＰＵＢＥＸＴマクロ ＰＵＢＥＸＴマクロは、本発明によって、エグジット・マクロによって参照さ
れるパブリック・プロシージャの名前を宣言するのに使用される。ＰＵＢＥＸＴ
マクロ名およびそのパラメータは、本発明によってソース・ファイルからスキャ
ンされる。このマクロおよびエントリ定義マクロからの情報は、本発明によって
作られ、かつコードがある場合にどのコードをエグジット・マクロが生成しなけ
ればならないかを示す各ソース・コード・ファイルにインクルードされる機能イ
ンクルード・ファイル内で、プロシージャ名用のグローバル・マクロ変数を生成
するのに使用される。

【０３６３】 PUBEXT MACRO name, version, attribute, altName, altVersion ＰＵＢＥＸＴマクロは、パブリック・プロシージャまたはパブリック・ラベル
への外部参照を宣言するのに使用される。使用法：「ＰＵＢＥＸＴ ｍｅｍｃｔ
ｒｌ．ｓｈａｄｏｗ．ｓｅｔ， １．０， ＯＰＴＩＯＮＡＬ」。パラメータは
次の通りである。 ｎａｍｅ − ドット表記のプロシージャまたはラベルの名前、たとえば「ｃ
ｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ」。 ｖｅｒｓｉｏｎ − 外部インターフェースのメジャー．マイナー・バージョ
ン。 属性 − ＯＰＴＩＯＮＡＬ -> パブリック・プロシージャまたはパブリック・ラベ
ルが存在する場合に限ってコードを生成する。 ＡＬＴＥＲＮＡＴＥ -> パブリック・プロシージャまたはパブリック・ラ
ベルが存在しない場合に、代替参照を使用する。 ＳＵＢＳＴＩＴＵＴＥ -> パブリック・ラベルが未定義の場合に、０ＦＦ
ＦＦｈを格納する ｃｏｍｐｏｎｅｎｔ -> 複数のコンポーネントが同一のｐｒｏｃｅｄｕｒ
ｅＮａｍｅを定義する時に、このプロシージャが定義されるコンポーネントの名
前を指定するのに使用することができる。 ａｌｔＮａｍｅ − 代替のパブリック・プロシージャまたはパブリック・ラ
ベルの名前。 ａｌｔＶｅｒｓｉｏｎ − 代替インターフェースのメジャー．マイナー・バ
ージョン。

【０３６４】 LOCAL ???defineName LOCAL ???attrib LOCAL ???component これらは、このマクロによって使用されるローカル変数である。

【０３６５】 ???attrib CATSTR <attribute> ???component TEXTEQU <> オーバーロードされる属性パラメータには、属性キーワードまたはコンポーネ
ント名が含まれる。この２つのローカル変数は、ａｔｔｒｉｂｕｔｅパラメータ
によって指定される属性キーワードおよびコンポーネント名を保持するのに使用
される。パラメータがオーバーロードされるので、一方または他方がブランクに
なる。当初は、？？？ａｔｔｒｉｂに属性キーワードが含まれると仮定し、した
がって、？？？ｃｏｍｐｏｎｅｎがブランクであると仮定する。

【０３６６】 IFNB <attribute> IFDIF <attribute>, <OPTIONAL> IFDIF <attribute>, <ALTERNATE> IFDIF <attribute>, <SUBSTITUTE> ???component CATSTR <attribute> ???attrib TEXTEQU <> ENDIF ENDIF ENDIF ENDIF オーバーロードされるａｔｔｒｉｂｕｔｅパラメータが、実際にコンポーネン
ト名であるかどうかを検査する。そうである場合には、？？？ｃｏｍｐｏｎｅｎ
ｔに、コンポーネント名が含まれ、？？？ａｔｔｒｉｂはブランクである。

【０３６７】 NAME_VER_CHECKER <name>, <version> %ATTRIB_CHECKER ???attrib, <altName>, <altVersion> ＮＡＭＥ＿ＶＥＲ＿ＣＨＥＣＫＥＲマクロは、ｎａｍｅパラメータとｖｅｒｓ
ｉｏｎパラメータの両方が指定されたことを検証する。ＡＴＴＲＩＢ＿ＣＨＥＣ
ＫＥＲマクロは、ＡＬＴＥＲＮＡＴＥ属性が指定された場合に、ａｌｔＮａｍｅ
パラメータとａｌｔＶｅｒｓｉｏｎパラメータの両方も指定されたことを検証し
、ＡＬＴＥＲＮＡＴＥ属性が指定されない場合に、ａｌｔＮａｍｅパラメータと
ａｌｔＶｅｒｓｉｏｎパラメータの両方が存在しないことを検証する。この２つ
のマクロ呼出しは、名前のそれぞれが対応するメジャー．マイナー・バージョン
番号を有しない場合にエラーになる。それ以外の場合に、バージョン番号は、生
成されるコードによって無視される。

【０３６８】 ＰＵＢＥＸＴマクロの呼出しのそれぞれからのすべてのパラメータがソース・
ファイルからスキャンされ、データベースに入力される。これによって、ＢＩＯ
Ｓ開発システムが、プロシージャ定義によって使用される実際のプロシージャ・
インターフェースのバージョンを、ＰＵＢＥＸＴマクロで宣言され、マクロ呼出
しを含むソース・コード・ファイル内で使用されるプロシージャ・インターフェ
ースのバージョンと比較できるようになる。プロシージャ宣言およびプロシージ
ャ定義の両方ののバージョン番号が、データベースに格納されるので、システム
は、コンパイルの前にバージョン番号を比較することによって、インターフェー
スに互換性があるかどうかを判定することができる。

【０３６９】 %GET_EXT_NAME name, ???attrib, altName, ???component ？？？ｄｅｆｉｎｅＮａｍｅによって指定されるグローバル変数のビットをセ
ットして、パブリック・プロシージャまたはパブリック・ラベルがＰＵＢＥＸＴ
マクロ呼出しによって宣言され、定義されているか、指定された属性に従って処
理されることを示す。下の説明を参照されたい。

【０３７０】 GET_SYMBOL_NAME name ???defineName CATSTR DEFINE_PREFIX, ???symbol ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡＭＥマクロは、グローバル変数？？？ｓｙｍｂｏ
ｌに、ドット（．）をアンダーバー（＿）に置換された名前を返す。たとえば、
＜ｍｅｍｃｔｒｌ．ｓｈａｄｏｗ．ｓｅｔ＞は、ｍｅｍｃｔｒｌ＿ｓｈａｄｏｗ
＿ｓｅｔとして返される。名前がｍｅｍｃｔｒｌ．ｓｈａｄｏｗ．ｓｅｔである
場合に、？？？ｄｅｆｉｎｅＮａｍｅは、Ｄ＿ｍｅｍｃｔｒｌ＿ｓｈａｄｏｗ＿
ｓｅｔになる。

【０３７１】 %IFDEF ???defineName % ???defineName = ???defineName OR TYPE_PUBLIC ENDIF このプロシージャのさまざまなタイプ・ビットを含むグローバル変数が定義さ
れている場合に、ＴＹＰＥ＿ＰＵＢＬＩＣビットをセットして、それがパブリッ
ク・プロシージャであることを示す。

【０３７２】 ＢＩＯＳ開発システムは、ソース・ライブラリに含まれる各ソース・コード・
ファイルによってインクルードされる機能インクルード・ファイルを生成する。
このファイルでは、ＰＵＢＥＸＴマクロによって宣言されたプロシージャごとに
、さまざまなタイプ・ビットを含むグローバル変数？？？ｄｅｆｉｎｅＮａｍｅ
、たとえばＤ＿ｍｅｍｃｔｒｌ＿ｓｈａｄｏｗ＿ｓｅｔを定義する。たとえば、
プロシージャがＯＰＴＩＯＮＡＬとして宣言され、プロシージャ定義がビルドに
含まれない場合に、システムは、その呼出しに関してコードが生成されないこと
を示すＴＹＰＥ＿ＮＯＴ＿ＩＮＳＴＡＬＬＥＤビットを有するグローバル変数を
定義する（上のＢＲＡＮＣＨ＿ＨＡＮＤＬＥＲマクロを参照されたい）。

【０３７３】 ENDM マクロを終了し、呼出し元にリターンする。

【０３７４】 ２．２ ＧＥＴ＿ＥＸＴ＿ＮＡＭＥマクロ ＧＥＴ＿ＥＸＴ＿ＮＡＭＥマクロは、必要な機能を本発明に提供し、ソース・
コード・ファイルによって直接には絶対に呼び出されない内部マクロである。

【０３７５】 GET_EXT_NAME MACRO name:REQ, attribute, altName, component ＧＥＴ＿ＥＸＴ＿ＮＡＭＥマクロは、ＰＵＢＥＸＴマクロ呼出しによって宣言
されたグローバル変数の名前を判定し、その中の、パブリック・プロシージャま
たはパブリック・ラベルが宣言されており、定義されるか、指定された属性に従
って処理されることを示すビットをセットする。パラメータは次の通りである。 ｎａｍｅ（必須） − ドット表記のプロシージャまたはラベルの名前、たと
えば「ｃｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ」 属性 − ＯＰＴＩＯＮＡＬ -> パブリック・プロシージャまたはパブリック・ラベ
ルが存在する場合に限ってコードを生成する。 ＡＬＴＥＲＮＡＴＥ -> パブリック・プロシージャまたはパブリック・ラ
ベルが存在しない場合に、代替参照を使用する。 ＳＵＢＳＴＩＴＵＴＥ -> パブリック・ラベルが未定義の場合に、０ＦＦ
ＦＦｈを格納する。 ａｌｔＮａｍｅ − 代替のパブリック・プロシージャまたはパブリック・ラ
ベルの名前。 ｃｏｍｐｏｎｅｎｔ -> 複数のコンポーネントが同一のｐｒｏｃｅｄｕｒｅ
Ｎａｍｅを定義する時に、このプロシージャが定義されるコンポーネントの名前
を指定するのに使用することができる。

【０３７６】 LOCAL ???defineName LOCAL ???publicName LOCAL ???tempDefineName これらは、このマクロによって使用されるローカル変数である。

【０３７７】 IFNB <attribute> IFDIF <attribute>, <OPTIONAL> IFDIF <attribute>, <ALTERNATE> IFDIF <attribute>, <SUBSTITUTE> .ERR <GET_EXT_NAME: Invalid ! attribute supplied> ENDIF ENDIF ENDIF ENDIF ブランクでない場合にａｔｔｒｉｂｕｔｅパラメータを検証する。

【０３７８】 GET_SYMBOL_NAME <name>, <component> ???defineName CATSTR DEFINE_PREFIX, ???symbol ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡＭＥマクロは、グローバル変数？？？ｓｙｍｂｏ
ｌで、ドット（．）をアンダーバー（＿）に置換されたｅｘｔｅｒｎＮａｍｅ（
または、指定される場合にｃｏｍｐｏｎｅｎｔ．ｅｘｔｅｒｎＮａｍｅ）を返す
。たとえば、＜ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ＞は、ｐｃｉ＿ｏｐｒｏｍ＿ｉｎ
ｉｔとして返される。ｎａｍｅがｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔである場合には
、？？？ｄｅｆｉｎｅＮａｍｅがＤ＿ｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔになる。

【０３７９】 %IFDEF ???defineName その名前が？？？ｄｅｆｉｎｅＮａｍｅによって指定されるグローバル変数が
、ビルド・ツールによって定義される場合に、グローバル変数の、宣言されるプ
ロシージャのタイプを指定するビットをセットする。

【０３８０】 % IF ???defineName EQ TRUE その名前が？？？ｄｅｆｉｎｅＮａｍｅによって指定されるグローバル変数が
、値ＴＲＵＥを有する場合に、プロシージャは、ビルドに含まれ、呼び出すこと
ができる。

【０３８１】 ???publicName CATSTR PROC_PREFIX, ???symbol % ???publicName TEXTEQU <name> % ???defineName = ???defineName OR TYPE_TRUE 呼び出されるプロシージャの名前を含むグローバル変数の名前を構成し、文字
列＜ｎａｍｅ＞をその中に格納する。ｎａｍｅがｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ
である場合に、？？？ｐｕｂｌｉｃＮａｍｅは、Ｐ＿ｐｃｉ＿ｏｐｒｏｍ＿ｉｎ
ｉｔになり、これに、文字列＜ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ＞が含まれる。そ
の名前が？？？ｄｅｆｉｎｅＮａｍｅによって指定されるグローバル変数のＴＹ
ＰＥ＿ＴＲＵＥビットをセットする。

【０３８２】 % ELSEIF ???defineName EQ FALSE その名前が？？？ｄｅｆｉｎｅＮａｍｅによって指定されるグローバル変数が
値ＦＡＬＳＥを有する場合に、プロシージャはビルドに含まれず、そのタイプは
それが宣言された時の属性によって決定される。

【０３８３】 IFIDN <attribute>, <SUBSTITUTE> % ???defineName = ???defineName OR TYPE_SUBSTITUTE ELSEIFIDN <attribute>, <OPTIONAL> % ???defineName = ???defineName OR TYPE_NOT_INSTALLED OR TYPE_OPTIONAL ＳＵＢＳＴＩＴＵＴＥ属性またはＯＰＴＩＯＮＡＬ属性が指定された場合に、
適切なビットをセットする。

【０３８４】 ELSEIFIDN <attribute>, <ALTERNATE> ???publicName CATSTR PROC_PREFIX, ???symbol GET_SYMBOL_NAME altName ???tempDefineName CATSTR DEFINE_PREFIX, ???symbol ＡＬＴＥＲＮＡＴＥ属性が指定された場合に、呼び出されるプロシージャの名
前を含むグローバル変数の名前を構成する。ａｌｔＮａｍｅのタイプ・ビットを
含むグローバル変数の名前を構成する。

【０３８５】 % IFDEF ???tempDefineName % IFE ???tempDefineName AND TYPE_RESERVED_TRUE .ERR <GET_EXT_NAME: !'altName!' is not in the build> ENDIF ELSE .ERR <GET_EXT_NAME: !'altName!' is not defined> ENDIF ａｌｔＮａｍｅのタイプ・ビットを含むグローバル変数が定義されていないか
、定義されているがＴＹＰＥ＿ＲＥＳＥＲＶＥＤ＿ＴＲＵＥビットがセットされ
ていない場合に、エラーを生じる。

【０３８６】 % ???publicName CATSTR <altName> % ???defineName = ???defineName OR TYPE_ALTERNATE ENDIF 呼び出されるプロシージャの名前を＜ａｌｔＮａｍｅ＞にセットし、タイプ・
ビットを含むグローバル変数のＴＹＰＥ＿ＡＬＴＥＲＮＡＴＥビットをセットす
る。

【０３８７】 % ELSE % .ERR <GET_EXT_NAME: !'name!' was already qualified with PUBEXT or PRVEXT> ENDIF タイプ・ビットを含むグローバル変数が、値ＴＲＵＥまたはＦＡＬＳＥを有し
なかったので、エラーを生成する。

【０３８８】 ELSE .ERR <GET_EXT_NAME: !'name!' was not picked up by the build ＼
tools> ENDIF タイプ・ビットを含むグローバル変数が、定義されておらず、したがって、エ
ラーを生成する。

【０３８９】 ENDM マクロを終了し、呼出し元にリターンする。

【０３９０】 ３．エントリ定義マクロ ３．１ ＰＵＢＬＩＣ＿ＰＲＯＣマクロ ＰＵＢＬＩＣ＿ＰＲＯＣマクロは、本発明によって、エグジット・マクロによ
って参照されるパブリック・プロシージャを定義するＰＲＯＣステートメントを
生成するのに使用される。ＰＵＢＬＩＣ＿ＰＲＯＣマクロ名およびそのパラメー
タは、本発明によってソース・ファイルからスキャンされる。このマクロおよび
エグジット宣言マクロからの情報は、本発明によって作られ、かつコードが存在
する場合にエグジット・マクロが生成しなければならないコードを指定する各ソ
ース・コード・ファイルにインクルードされる機能インクルード・ファイル内の
プロシージャ名用のグローバル・マクロ変数を生成するのに使用される。

【０３９１】 PUBLIC_PROC MACRO procedureName:REQ, version := <MISSING>, attrib ＰＵＢＬＩＣ＿ＰＲＯＣマクロは、他のコンポーネントから呼び出すことがで
きるプロシージャを定義する。使用法：「ＰＵＢＬＩＣ＿ＰＲＯＣ ｐｃｉ．ｏ
ｐｒｏｍ．ｉｎｉｔ， １．３」。パラメータは次の通りである。 ｐｒｏｃｅｄｕｒｅＮａｍｅ（必須） − ドット表記のプロシージャの名前
、たとえば「ｃｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ」。 ｖｅｒｓｉｏｎ − メジャー．マイナー・プロシージャ・インターフェース
・バージョン番号、デフォルトで値＜ＭＩＳＳＩＮＧ＞を与えられ、その結果、
欠けているバージョン番号を検出できるようになる。 ａｔｔｒｉｂ − ＩＮＴＥＲＣＥＰＴ、構成に同一のｐｒｏｃｅｄｕｒｅＮ
ａｍｅの複数の定義がある場合に、ＢＩＯＳ開発システムにこのプロシージャを
呼び出すように指示する。

【０３９２】 このマクロは、プロシージャの名前を含むグローバル変数？？？ｐｒｏｃｅｄ
ｕｒｅＮａｍｅを残す。

【０３９３】 LOCAL ???addr LOCAL ???procName LOCAL ???error LOCAL ???procType これらは、このマクロによって使用されるローカル変数である。

【０３９４】 ???error = FALSE IFDEF ???procedureName IFNB ???procedureName % .ERR <PUBLIC_PROC: The procedure ???procedureName is open> ???error = TRUE ENDIF ENDIF 既存のプロシージャがクローズされていない場合に、エラーを生成する。当初
はＦＡＬＳＥをセットされるローカル変数？？？ｅｒｒｏｒを使用して、追加の
より曖昧なエラーを引き起こすもう１つのＰＲＯＣステートメントの生成を防ぐ
ために、既存のプロシージャがクローズされていないことを示す。

【０３９５】 IFIDNI <version>, <MISSING> .ERR <PUBLIC_PROC: !Version information missing> ENDIF IFNB <attrib> IFDIF <attrib>, <INTERCEPT> % .ERR <PUBLIC_PROC: !'attrib!' is an invalid attribute> ENDIF ENDIF ｖｅｒｓｉｏｎパラメータが指定されたことを検証し、属性パラメータを検証
する。

【０３９６】 IFE ???error エラーが検出されない場合には、プロシージャを定義する。

【０３９７】 GET_SYMBOL_NAME procedureName ???procedureName CATSTR ???symbol ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡＭＥマクロは、グローバル変数？？？ｓｙｍｂｏ
ｌに、ドット（．）をアンダーバー（＿）に置換されたｐｒｏｃｅｄｕｒｅＮａ
ｍｅを返す。たとえば、＜ｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔ＞は、ｐｃｉ＿ｏｐｒ
ｏｍ＿ｉｎｉｔとして返される。グローバル変数？？？ｐｒｏｃｅｄｕｒｅＮａ
ｍｅに、アセンブラが解決するプロシージャ名をセットする。ｐｒｏｃｅｄｕｒ
ｅＮａｍｅがｐｃｉ．ｏｐｒｏｍ．ｉｎｉｔである場合に、？？？ｐｒｏｃｅｄ
ｕｒｅＮａｍｅはｐｃｉ＿ｏｐｒｏｍ＿ｉｎｉｔになる。

【０３９８】 % ???procedureName PROC FAR PRIVATE ???addr EQU $ パブリック・プロシージャを作成し、その位置を得、したがって、他のコンポ
ーネントからの呼出しをフィックス・アップできるようにする。

【０３９９】 IFIDN <attrib>, <INTERCEPT> ???procType TEXTEQU <TYPE_PUBLIC_INT_PROC> ELSE ???procType TEXTEQU <TYPE_PUBLIC_PROC> ENDIF これが普通のパブリック（コンポーネント間）プロシージャまたは同一の名前
の普通のプロシージャへの呼出しをインターセプトする特別なプロシージャのど
ちらであるかをフィックスアップ・データが示すように？？？ｐｒｏｃＴｙｐｅ
をセットアップする。

【０４００】 % SAVE_PUBLIC_FIXUP_DATA procedureName, ???procType, ???addr ＳＡＶＥ＿ＰＵＢＬＩＣ＿ＦＩＸＵＰ＿ＤＡＴＡマクロ（下で説明する）を呼
び出して、フィックスアップ・データを保存する。

【０４０１】 ENDIF ENDM マクロを終了し、呼出し元にリターンする。

【０４０２】 ３．２ ＳＡＶＥ＿ＰＵＢＬＩＣ＿ＦＩＸＵＰ＿ＤＡＴＡマクロ ＳＡＶＥ＿ＰＵＢＬＩＣ＿ＦＩＸＵＰ＿ＤＡＴＡマクロは、必要な機能を本発
明に提供し、ソース・コード・ファイルによって直接には絶対に呼び出されない
内部マクロである。

【０４０３】 SAVE_PUBLIC_FIXUP_DATA MACRO publicLabel, publicType, addr ＳＡＶＥ＿ＰＵＢＬＩＣ＿ＦＩＸＵＰ＿ＤＡＴＡマクロは、そのパラメータに
よって指定されるフィックスアップ・データを特別な名前のセグメントに保存す
るのに使用される内部マクロである。パラメータは次の通りである。 ｐｕｂｌｉｃＬａｂｅｌ − ドット表記のパブリック・シンボル名、たとえ
ば「ｃｌａｓｓ．ｓｕｂｃｌａｓｓ．ｐｒｏｃｅｄｕｒｅ」。 ｐｕｂｌｉｃＴｙｐｅ − パブリック・シンボル・タイプ（列挙される式）
。 ａｄｄｒ − パブリック・シンボルのアドレス。

【０４０４】 publicSegment SEGMENT DB '&publicLabel' ; パブリック文字列 DB 0 ; 文字列をヌル終端する DB publicType ; パブリック・タイプ DW OFFSET addr ; フィックスアップ・オフセット DW SEG addr ; フィックスアップ・セグメント publicSegment ENDS このマクロへの呼出しのそれぞれによって生成されるフィックスアップ・デー
タは、その呼出しを含むソース・コード・ファイルが、コンパイルされ、リンク
され、製品コンポーネント・リンカによって処理される時に、単一のｐｕｂｌｉ
ｃＳｅｇｍｅｎｔにマージされる。各オブジェクト・ファイル内のｐｕｂｌｉｃ
Ｓｅｇｍｅｎｔは、オブジェクト・ファイルがリンクされてコンポーネント．Ｅ
ＸＥファイルを形成する時に、単一のｐｕｂｌｉｃＳｅｇｍｅｎｔにマージされ
る。各コンポーネント．ＥＸＥファイルのｐｕｂｌｉｃＳｅｇｍｅｎｔ内のフィ
ックスアップ・データは、ＢＩＯＳコンポーネント・リンカによって、各外部参
照のセグメントおよびオフセットをフィックスアップするのに使用される。

【０４０５】 ENDM マクロを終了し、呼出し元にリターンする。

【０４０６】 ３．３ ＥＮＤ＿ＰＲＯＣマクロ ＥＮＤ＿ＰＲＯＣマクロは、本発明によって、アセンブラが必要とするＥＮＤ
Ｐディレクティブ（すなわちコマンド）を有する先行するＰＵＢＬＩＣ＿ＰＲＯ
Ｃマクロによって開始されたプロシージャの終りをマークする前に、あるエラー
検査を行うのに使用される。

【０４０７】 END_PROC MACRO ＥＮＤ＿ＰＲＯＣマクロは、パブリック・プロシージャの終りを定義する。

【０４０８】 IFNDEF ???procedureName .ERR <PROC_END: No procedure defined> ELSE .ERRB ???procedureName, <END_PROC: No procedure currently open> グローバル変数？？？ｐｒｏｃｅｄｕｒｅＮａｍｅに、現在のプロシージャの
名前が格納される。プロシージャが定義されていないか、プロシージャが現在オ
ープンされていない場合に、エラーを生成する。

【０４０９】 IFNB ???procedureName % ???procedureName ENDP ???procedureName TEXTEQU<> ENDIF プロシージャが現在オープンされている場合に、そのプロシージャのＥＮＤＰ
ステートメントを生成し、グローバル変数？？？ｐｒｏｃｅｄｕｒｅＮａｍｅに
ヌル文字列をセットする。

【０４１０】 ENDIF ENDM マクロを終了し、呼出し元にリターンする。

【０４１１】 ４．ＲＯＭスタック・マクロ ４．１ ＣＲＥＡＴＥ＿ＲＯＭ＿ＳＴＡＣＫマクロ ＣＲＥＡＴＥ＿ＲＯＭ＿ＳＴＡＣＫマクロは、本発明によって、ＲＯＭスタッ
クを作成するのに使用される。ＲＯＭスタックは、メモリに対する影響を最小に
しながら、異なるセグメント内の呼出し元にリターンする機構である。これは、
メモリが初期化されるまでリターン・アドレスを格納するのに使用可能なランダ
ム・アクセス・メモリがないので、プロセッサが最初に電源を投入される時に実
行されるコードで使用することができる。

【０４１２】 CREATE_ROM_STACK MACRO ＣＲＥＡＴＥ＿ＲＯＭ＿ＳＴＡＣＫマクロは、ＲＯＭスタックを作成し、呼出
し元にリターンする小さいディスパッチャを提供する。レジスタＢＰが、リター
ンする先のオフセットとして使用される。

【０４１３】 LOCAL returnDispatcher LOCAL romStackLabel これらは、このマクロによって使用されるローカル変数である。

【０４１４】 %romStackLabel CATSTR <romStack>, <???currSegmentName> 文字列＜ｒｏｍＳｔａｃｋ＞および現在のセグメント名からｒｏｍＳｔａｃｋ
Ｌａｂｅｌの名前を作成する。

【０４１５】 % PUBLIC romStackLabel %romStackLabel LABEL BYTE DW OFFSET returnDispatcher DW SEG returnDispatcher 現在のコード・セグメント内で、ｒｅｔｕｒｎＤｉｓｐａｔｃｈｅｒのｆａｒ
アドレスを含む外部から可視の名前としてｒｏｍＳｔａｃｋＬａｂｅｌの名前を
定義する。

【０４１６】 returnDispatcher: % mov sp, OFFSET romStackLabel jmp bp ｒｅｔｕｒｎＤｉｓｐａｔｃｈｅｒは、ＲＯＭスタックの最上部をポイントす
るようにスタック・ポインタ・レジスタをリセットし、ＢＰレジスタに格納され
たリターン・アドレス・オフセットに分岐する。

【０４１７】 ENDM ＲＯＭスタックは、メモリに対する影響を最小にしながら、異なるセグメント
内の呼出し元にリターンする機構である。これは、メモリが初期化されるまでリ
ターン・アドレスを格納するのに使用可能なランダム・アクセス・メモリがない
ので、プロセッサが最初に電源を投入される時に実行されるコードで使用するこ
とができる。

【０４１８】 ＣＲＥＡＴＥ＿ＲＯＭ＿ＳＴＡＣＫマクロは、現在のコード・セグメント内に
ＲＯＭスタックを作成するために呼び出される。ＩＮＩＴ＿ＲＯＭ＿ＳＴＡＣＫ
マクロを呼び出して、スタック・レジスタＳＳおよびＳＰを、現在のコード・セ
グメント内のＲＯＭスタックをポイントするように初期化する。ＲＯＭＣＡＬＬ
マクロは、現在のコード・セグメント内のリターン・アドレスのオフセットをＢ
Ｐレジスタに保存した後に、ｆａｒ ｊｍｐ命令を生成する。

【０４１９】 呼び出されるプロシージャは、ＢＰレジスタを保存し、通常のｆａｒ ｒｅｔ
ｕｒｎ命令を用いてリターンし、このｆａｒ ｒｅｔｕｒｎ命令は、ＲＯＭスタ
ックのｒｅｔｕｒｎＤｉｓｐａｔｃｈｅｒのアドレスをポップし、したがって、
現在のコード・セグメントにリターンする。ｒｅｔｕｒｎＤｉｓｐａｔｃｈｅｒ
コードは、スタック・ポインタをリセットし、ＢＰレジスタを使用して、呼出し
元にリターンする。

【０４２０】 ４．２ ＩＮＩＴ＿ＲＯＭ＿ＳＴＡＣＫマクロ ＩＮＩＴ＿ＲＯＭ＿ＳＴＡＣＫマクロは、本発明によって、現在のコード・セ
グメント内のＲＯＭスタックをポイントするようにスタック・レジスタを初期化
するのに使用される。ＲＯＭスタックは、メモリに対する影響を最小にしながら
、異なるセグメント内の呼出し元にリターンする機構である。これは、メモリが
初期化されるまでリターン・アドレスを格納するのに使用可能なランダム・アク
セス・メモリがないので、プロセッサが最初に電源を投入される時に実行される
コードで使用することができる。

【０４２１】 INIT_ROM_STACK MACRO ＩＮＩＴ＿ＲＯＭ＿ＳＴＡＣＫマクロは、現在のコード・セグメント内のＲＯ
Ｍスタックをポイントするようにスタック・レジスタＳＳおよびＳＰを初期化す
る。

【０４２２】 LOCAL romStackLabel これは、このマクロによって使用されるローカル変数である。

【０４２３】 %romStackLabel CATSTR <romStack>, <???currSegmentName> 文字列＜ｒｏｍＳｔａｃｋ＞および現在のセグメント名からｒｏｍＳｔａｃｋ
Ｌａｂｅｌの名前を作成する。

【０４２４】 % EXTERNDEF romStackLabel:NEAR % mov sp, SEG romStackLabel mov ss, sp % mov sp, OFFSET romStackLabel ENDM 現在のコード・セグメント内のＲＯＭスタックの名前を外部として宣言し、そ
れをポイントするようにスタック・レジスタを初期化する。

【０４２５】 ４．３ ＲＯＭＣＡＬＬマクロ ＲＯＭＣＡＬＬマクロは、本発明によって、ＲＯＭスタックを使用して異なる
コンポーネント内のパブリック・プロシージャを呼び出すのに使用される。ＲＯ
ＭＣＡＬＬマクロによって生成されるコードは、本発明によってスキャンされる
ｐｒｏｃｅｄｕｒｅＮａｍｅに関するエグジット宣言マクロおよびエントリ定義
マクロに依存する。これらのマクロからの情報が、本発明によって作られ、コー
ドがある場合にどのコードを生成しなければならないのかを示す各ソース・コー
ド・ファイルにインクルードされる、機能インクルード・ファイル内で、ｐｒｏ
ｃｅｄｕｒｅＮａｍｅ用のグローバル・マクロ変数を生成するのに使用される。

【０４２６】 ROMCALL MACRO jRoutineName, codeText, jComponent EXTJMP jRoutineName, bp, codeText, jComponent ENDM ＲＯＭＣＡＬＬマクロは、ＲＯＭスタックを使用して、ｆａｒルーチンｊＲｏ
ｕｔｉｎｅＮａｍｅを呼び出す。ＲＯＭＣＡＬＬマクロは、ＥＸＴＪＭＰマクロ
を使用して、リターン・アドレスのオフセットをＢＰレジスタに保存した後に、
ｆａｒ ｊｍｐ命令を生成する。

【０４２７】 ５．リスト・マクロ リストは、リスト名によって参照される、ソートされた同一サイズのデータ構
造体（リスト・エントリと称する）の配列である。あるコンポーネント（リスト
・オーナーと称する）が、リストを作成し、名前を与え、フォーマットし、リス
トがＲＯＭイメージ内で配置されるセグメントを割り当てる。他のコンポーネン
ト（リスト・オーナーを含む）は、リスト名を使用してリスト・エントリをリス
トに追加することができる。ＢＩＯＳコンポーネント・リンカは、すべてのリス
トおよびリスト・エントリを収集し、リスト名によってそれらをグループ化し、
ソートし、ＲＯＭイメージに書き出す。ＢＩＯＳコンポーネント・リンカは、リ
ストおよびリスト・エントリへの参照もフィックス・アップする。

【０４２８】 ５．１ ＬＩＳＴ＿ＣＲＥＡＴＥマクロ ＬＩＳＴ＿ＣＲＥＡＴＥマクロは、本発明によって、リストを作成するのに使
用される。このマクロは、リストを作成する、本発明のＢＩＯＳコンポーネント
・リンカ部分によって選択されるリストを識別する情報を生成する。ＬＩＳＴ＿
ＣＲＥＡＴＥマクロおよびそのパラメータは、本発明によってスキャンされ、し
たがって、これらを、リストのエントリを定義するＬＩＳＴ＿ＳＴＡＲＴマクロ
のパラメータと比較することができる。

【０４２９】 LIST_CREATE MACRO listName, listVersion, listSize, listAttribute ＬＩＳＴ＿ＣＲＥＡＴＥマクロは、リストを作成する。パラメータは次の通り
である。 ｌｉｓｔＮａｍｅ − このリストを表す一意の名前。 ｌｉｓｔＶｅｒｓｉｏｎ − リストのメジャー．マイナー・バージョン番号
。 ｌｉｓｔＳｉｚｅ − リスト・エントリのサイズ、バイト数、限定型（ｑｕ
ａｌｉｆｉｅｄ ｔｙｐｅ）の名前（ＢＹＴＥ、ＷＯＲＤなど）、または構造体
名とすることができる。 ｌｉｓｔＡｔｔｒｉｂｕｔｅ − ＰＵＢＬＩＣキーワード。 使用法：「ＬＩＳＴ＿ＣＲＥＡＴＥ ｐｏｓｔＬｉｓｔ， １．０， ｐｏｓ
ｔＴａｓｋＳｔｒｕｃ」。

【０４３０】 LOCAL ???entrySize LOCAL ???listAttr これらは、このマクロによって使用されるローカル変数である。

【０４３１】 ???entrySize = 0 IFNB <listAttribute> IFIDN <listAttribute>, <PUBLIC> ???listAttr = 1 ELSE ???listAttr = 0 % .ERR <LIST_CREATE: The attribute !'listAttribute!' is ＼ illegal> ENDIF ELSE ???listAttr = 0 ENDIF ？？？ｅｎｔｒｙＳｉｚｅを初期化する。ｌｉｓｔＡｔｔｒｉｂｕｔｅが指定
された場合にそれを検証し、１（ＰＵＢＬＩＣ属性）または０（属性なし）に変
換する。

【０４３２】 IFNB <listSize> IF OPATTR listSize EQ 24h ｌｉｓｔＳｉｚｅが、構造体、限定型（ＢＹＴＥ、ＷＯＲＤ、ＤＷＯＲＤなど
）、または即値であることを保証する。そうでない場合には、ＥＬＳＥステート
メントでエラーを生成する。

【０４３３】 IF TYPE listSize NE 0 ???entrySize = SIZEOF (listSize) ELSE ???entrySize = listSize ENDIF ELSE % .ERR <LIST_CREATE: !'listSize!' is not a structure, qualified type, or immediate value> ENDIF ENDIF ｌｉｓｔＳｉｚｅが型である場合に、ｌｉｓｔＳｉｚｅは、構造体または限定
型である。ＳＩＺＥＯＦ関数が、そのサイズを返す。そうでない場合には、ｌｉ
ｓｔＳｉｚｅが即値（数）であり、特別な処理は不要である。

【０４３４】 IFNB <listName> IFNB <listVersion> IFNB <listSize> % SAVE_LIST_CREATE_DATA listName, ???currSegmentName, ???entrySize, listVersion, ???listAttr ELSE .ERR <LIST_CREATE: Size of list entry is missing> ENDIF ELSE .ERR <LIST_CREATE: List version is missing> ENDIF ELSE .ERR <LIST_CREATE: List name is missing> ENDIF ｌｉｓｔＮａｍｅ、ｌｉｓｔＶｅｒｓｉｏｎ、およびｌｉｓｔＳｉｚｅのすべ
てが指定されていることを検証する。下で説明するＳＡＶＥ＿ＬＩＳＴ＿ＣＲＥ
ＡＴＥ＿ＤＡＴＡマクロを呼び出して、リスト作成データを保存する。グローバ
ル変数？？？ｃｕｒｒＳｅｇｍｅｎｔＮａｍｅに、現在のセグメントの名前が含
まれる。

【０４３５】 ENDM マクロを終了し、呼出し元にリターンする。

【０４３６】 ５．２ ＳＡＶＥ＿ＬＩＳＴ＿ＣＲＥＡＴＥ＿ＤＡＴＡマクロ ＳＡＶＥ＿ＬＩＳＴ＿ＣＲＥＡＴＥ＿ＤＡＴＡは、必要な機能を本発明に提供
し、ソース・コード・ファイルによって直接には絶対に呼び出されない内部マク
ロである。

【０４３７】 SAVE_LIST_CREATE_DATA MACRO listName:REQ,listSegment:REQ, ＼ entrySize:REQ, listVersion:REQ, listAttr:REQ ＳＡＶＥ＿ＬＩＳＴ＿ＣＲＥＡＴＥ＿ＤＡＴＡマクロは、そのパラメータによ
って指定されるリストを特別な名前のセグメント内で作成するのに必要なデータ
を保存するのに使用される内部マクロである。パラメータは次の通りである。 ｌｉｓｔＮａｍｅ（必須） − リストの名前。 ｌｉｓｔＳｅｇｍｅｎｔ（必須） − リストが存在するセグメント名。 ｅｎｔｒｙＳｉｚｅ（必須） − リスト・エントリのサイズ。 ｌｉｓｔＶｅｒｓｉｏｎ（必須） − リストのバージョン番号。 ｌｉｓｔＡｔｔｒ（必須） − １（ＰＵＢＬＩＣ属性）または０（属性なし
）。

【０４３８】 listDeclarationSegment SEGMENT DB '&listName' ; リスト名 DB 0 ; 文字列をヌル終端する DB '&listSegment' DB 0 ; 文字列をヌル終端する DW entrySize ; リスト・エントリのサイズ DB '&listVersion' ; バージョン番号 DB 0 ; 文字列をヌル終端する DB listAttr ; リスト属性 listDeclarationSegment ENDS ENDM このマクロへの呼出しのそれぞれによって生成されるリスト作成データは、そ
の呼出しを含むコード・ファイルが、コンパイルされ、リンクされ、製品コンポ
ーネント・リンカによって処理される時に、単一のｌｉｓｔＤｅｃｌａｒａｔｉ
ｏｎＳｅｇｍｅｎｔにマージされる。各オブジェクト・ファイル内のｌｉｓｔＤ
ｅｃｌａｒａｔｉｏｎＳｅｇｍｅｎｔは、オブジェクト・ファイルがリンクされ
てコンポーネント．ＥＸＥファイルを形成する時に、単一のｌｉｓｔＤｅｃｌａ
ｒａｔｉｏｎＳｅｇｍｅｎｔにマージされる。各コンポーネント．ＥＸＥファイ
ルのｌｉｓｔＤｅｃｌａｒａｔｉｏｎＳｅｇｍｅｎｔ内のリスト作成データは、
ＢＩＯＳコンポーネント・リンカによって、リスト・ヘッダを生成するのに使用
される。ｌｉｓｔＮａｍｅは、（ＰＵＢＬＩＣ）ラベルになり、最終的なＲＯＭ
イメージの指定されたセグメント内のリスト・ヘッダをポイントする。

【０４３９】 ５．３ ＬＩＳＴ＿ＳＴＡＲＴマクロ ＬＩＳＴ＿ＳＴＡＲＴマクロは、本発明によって、エントリが追加されるリス
トを識別するのに使用される。ＬＩＳＴ＿ＳＴＡＲＴマクロおよびそのパラメー
タは、本発明によってスキャンされ、したがって、これらを、リストを作成した
ＬＩＳＴ＿ＣＲＥＡＴＥマクロのパラメータと比較することができる。

【０４４０】 LIST_START MACRO listName, listVersion, listType, lOverridePriority ＬＩＳＴ＿ＳＴＡＲＴマクロは、指定されたリストの指定されたバージョンへ
のエントリの追加を開始する。このマクロは、エントリを定義する１つまたは複
数のＬＩＳＴ＿ＥＮＴＲＹマクロ、ＬＩＳＴ＿ＤＡＴＡマクロ、および／または
ＬＩＳＴ＿ＳＯＲＴマクロと、エントリを終了する対になるＬＩＳＴ＿ＥＮＤマ
クロと共に使用される。パラメータは次の通りである。 ｌｉｓｔＮａｍｅ − ＬＩＳＴ＿ＣＲＥＡＴＥマクロ呼出しによって宣言さ
れた一意の名前。 ｌｉｓｔＶｅｒｓｉｏｎ − リストのメジャー．マイナー・バージョン番号
。 ｌｉｓｔＴｙｐｅ − リスト・エントリのデータ型、限定型の名前（ＢＹＴ
Ｅ、ＷＯＲＤなど）または構造体名とすることができる。 ｌＯｖｅｒｒｉｄｅＰｒｉｏｒｉｔｙ − リスト・エントリ優先順位（ＣＯ
ＲＥキーワード、ＰＲＯＤＵＣＴキーワード、またはＰＬＡＴＦＯＲＭキーワー
ド）。これによって、これに続くリスト・エントリが、同一の名前を有するがよ
り低いオーバーライド優先順位を有する既存のリスト・エントリを置換すること
が指定される。ＰＬＡＴＦＯＲＭはＰＲＯＤＵＣＴを置換し、ＰＲＯＤＵＣＴは
ＣＯＲＥを置換し、ＣＯＲＥはデフォルトを置換する。このマクロは、次のグロ
ーバル変数を初期化する。 ？？？ｌｉｓｔＮａｍｅ − ｌｉｓｔＮａｍｅ。 ？？？ｌｉｓｔＴｙｐｅ − ｌｉｓｔＴｙｐｅ。 ？？？ｌｉｓｔＯｖｅｒｒｉｄｅ − リスト・エントリ優先順位。 その後、特別な名前のセグメントをオープンする。

【０４４１】 IFNDEF ???listName ???listName CATSTR <LIST_UNDEFINED> ENDIF IFDIFI ???listName, <LIST_UNDEFINED> % .ERR <LIST_START: List !'&???listName!' is already open> ELSE IFB <listName> .ERR <LIST_START: List name is missing> ELSEIFB <listVersion> .ERR <LIST_START: List version is missing> ELSEIFB <listType> .ERR <LIST_START: List type is missing> ELSE 必要な場合にグローバル変数？？？ｌｉｓｔＮａｍｅを初期化し、いくつかの
基本的なエラー検査を実行する。

【０４４２】 ???listName CATSTR <listName> ???listType CATSTR <listType> IFNB <lOverridePriority> IFIDN <lOverridePriority>, <CORE> ???listOverride CATSTR <0F0h> ELSEIFIDN <lOverridePriority>, <PRODUCT> ???listOverride CATSTR <80h> ELSEIFIDN <lOverridePriority>, <PLATFORM> ???listOverride CATSTR <010h> ELSE % .ERR <LIST_START: Override priority type !'lOverridePriority!' is invalid> ???listOverride CATSTR <0F0h> ENDIF ELSE ???listOverride CATSTR <0FFh> ENDIF ここまででエラーは見つかっていない。すべてのグローバル変数を初期化し、
オーバーライド優先順位を数値に変換する。ビルド内で同一の名前を有する２つ
のリスト・エントリが見つかった時に、この値によって、ＢＩＯＳコンポーネン
ト・リンカが１つのリストを選択できるようになる。ＣＯＲＥが最低の優先順位
、ＰＲＯＤＵＣＴがより高い優先順位、ＰＬＡＴＦＯＲＭが最高の優先順位を有
する。

【０４４３】 IF (OPATTR listType) NE 24h % .ERR <LIST_START: List type !'listType!' is not a structure or qualified type> ???listType CATSTR <ERROR> ELSEIF TYPE listType EQ 0 % .ERR <LIST_START: List type !'listType!' is an immediate value - not a structure or qualified type> ???listType CATSTR <ERROR> ELSE listEntrySegment SEGMENT ENDIF ENDIF ENDIF ENDM ｌｉｓｔＴｙｐｅが有効な構造体または限定型であることを検証し、セグメン
トｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔをオープンする。

【０４４４】 ５．４ ＬＩＳＴ＿ＥＮＤマクロ ＬＩＳＴ＿ＥＮＤマクロは、本発明によって、エントリが追加されたリストを
終了するのに使用される。

【０４４５】 LIST_END MACRO ＬＩＳＴ＿ＥＮＤマクロは、リストのエントリを終了する。

【０４４６】 IFDEF ???listName IFIDNI ???listName, <LIST_UNDEFINED> .ERR <LIST_END: The open list has already been closed with ＼
LIST_END> ELSE listEntrySegment ENDS ???listName CATSTR <LIST_UNDEFINED> ENDIF ELSE .ERR <LIST_END: A list has not been opened with LIST_START> ENDIF ENDM グローバル変数？？？ｌｉｓｔＮａｍｅがオープンされているリストを指定す
ることを検証する。セグメントｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔをクローズし
、クローズされたリストを示すように？？？ｌｉｓｔＮａｍｅをセットする。

【０４４７】 このｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔに含まれるリスト・エントリ・データ
は、これらのセグメント宣言を含むソース・コード・ファイルがコンパイルされ
、リンクされ、製品コンポーネント・リンカによって処理される時に、単一のｌ
ｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔにマージされる。各オブジェクト・ファイルの
ｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔは、オブジェクト・ファイルがリンクされて
コンポーネント．ＥＸＥファイルを形成する時に、単一のｌｉｓｔＥｎｔｒｙＳ
ｅｇｍｅｎｔにマージされる。各コンポーネント．ＥＸＥファイルのｌｉｓｔＥ
ｎｔｒｙＳｅｇｍｅｎｔは、ＢＩＯＳコンポーネント・リンカによって、マージ
され、ソートされて、リストを作成したＬＩＳＴ＿ＣＲＥＡＴＥマクロによって
指定されたリスト・ヘッダを有する、最終的なＲＯＭイメージ内のソートされた
リストが生成される。

【０４４８】 ５．５ ＬＩＳＴ＿ＥＮＴＲＹマクロ ＬＩＳＴ＿ＥＮＴＲＹマクロは、本発明によって、リストに追加されるエント
リを定義するのに使用される。

【０４４９】 LIST_ENTRY MACRO entryName, entryData, ePriority := <8000h>, eSortKey, listAttribute ＬＩＳＴ＿ＥＮＴＲＹマクロは、リストに現れるデータと、エントリをソート
するのに必要な情報を指定することによって、リスト・エントリを作成する。Ｌ
ＩＳＴ＿ＥＮＴＲＹマクロは、ＬＩＳＴ＿ＳＴＡＲＴマクロ呼出しの後に、ＬＩ
ＳＴ＿ＥＮＤマクロ呼出しの前に現れなければならない。パラメータは次の通り
である。 ｅｎｔｒｙＮａｍｅ − 個々のリスト・エントリの名前。リスト内で一意で
なければならない。 ｅｎｔｒｙＤａｔａ − ＲＯＭイメージに現れる、（＜）と（＞）中のデー
タ。構造体データは、追加の中括弧（｛）および（｝）の中に含まれなければな
らない。 ｅＰｒｉｏｒｉｔｙ − 同一のソート・キーを有するリスト・エントリをソ
ートするのに使用される数。小さい数が、大きい数の前に配置される。最小値は
０、最大値は６５５３５（０ＦＦＦＦｈ）、デフォルトは３２７６８（８０００
ｈ）である。 ｅＳｏｒｔＫｅｙ − リスト・エントリをマスタ参照リストと突き合わせる
のに使用される文字列。ｅｎｔｒｙＮａｍｅはデフォルト・ソート・キーである
。 ｌｉｓｔＡｔｔｒｉｂｕｔｅ − ＬＡＢＥＬおよび／またはＰＵＢＬＩＣ。

【０４５０】 このマクロは、先行するＳＴＡＲＴ＿ＬＩＳＴマクロ呼出しによって提供され
る３つのグローバル変数の値も使用する。 ？？？ｌｉｓｔＮａｍｅ − オープンされているリストの名前。 ？？？ｌｉｓｔＴｙｐｅ − エントリの型。 ？？？ｌｉｓｔＯｖｅｒｒｉｄｅ − オーバーライド優先順位数（ＣＯＲＥ
、ＰＲＯＤＵＣＴ、ＰＬＡＴＦＯＲＭ、またはなし）。 使用法：「ＬＩＳＴ＿ＥＮＴＲＹ ｖｇａＤａｔａ， ＜２４ｈ， ４５ｈ＞
」。

【０４５１】 LOCAL ???qualifiedType LOCAL ???dataSize LOCAL ???eData LOCAL ???eSortKey LOCAL ???rawData LOCAL ???listAttr これらは、このマクロによって使用されるローカル変数である。

【０４５２】 IFNB <listAttribute> IFIDN <listAttribute>, <PUBLIC> ???listAttr = 1 ELSEIFIDN <listAttribute>, <LABEL> ???listAttr = 2 ELSEIFIDN <listAttribute>, <LABEL OR PUBLIC> ???listAttr = 3 ELSEIFIDN <listAttribute>, <PUBLIC OR LABEL> ???listAttr = 3 ELSE ???listAttr = 0 % .ERR <LIST_ENTRY: The attribute !'listAttribute!' is illegal> ENDIF ELSE ???listAttr = 0 ENDIF ｌｉｓｔＡｔｔｒｉｂｕｔｅパラメータを構文解析し、数値に変換する。ＰＵ
ＢＬＩＣキーワードは、ｅｎｔｒｙＮａｍｅを、ｅｎｔｒｙＤａｔａを参照する
パブリック・ラベルとして定義させる。ＬＡＢＥＬキーワードは、ｅｎｔｒｙＮ
ａｍｅを、リスト・エントリを実際に生成せずにリスト内のラベル（両方のキー
ワードが指定された場合にはＰＵＢＬＩＣ ＬＡＢＥＬ）として定義させる。こ
の属性は、リストがオプションのエントリからなる時に、リストへのインデック
スが必要な場合に有用である。

【０４５３】 IFB <eSortKey> ???eSortKey CATSTR <entryName> ELSE ???eSortKey CATSTR <eSortKey> ENDIF ｅＳｏｒｔＫｅｙパラメータがブランクの場合には、デフォルト・ソート・キ
ーとしてｅｎｔｒｙＮａｍｅパラメータを使用する。

【０４５４】 IFB <entryName> .ERR <LIST_ENTRY: Entry name for list data is missing> ELSEIFB <entryData> .ERR <LIST_ENTRY: List data is missing> ELSEIFNDEF ???listName .ERR <LIST_ENTRY: A list has not been started with LIST_START> ELSEIFIDNI ???listName, <LIST_UNDEFINED> .ERR <LIST_ENTRY: The open list has already been closed with ＼
LIST_END> ELSEIFIDNI ???listType, <ERROR> ELSE 入力データに対する健全性検査を実行する。

【０４５５】 % ???dataSize = SIZEOF ???listType ???qualifiedType = TRUE IFIDNI ???listType, <BYTE> ELSEIFIDNI ???listType, <WORD> ELSEIFIDNI ???listType, <DWORD> ELSEIFIDNI ???listType, <FWORD> ELSEIFIDNI ???listType, <QWORD> ELSEIFIDNI ???listType, <TBYTE> ELSE ???qualifiedType = FALSE ENDIF ここに来た場合には、エラーがない。リスト型のサイズと、それが構造体また
は限定型であるかどうかを判定する。

【０４５６】 IFE ???qualifiedType ???eData CATSTR ???listType, <!<>, <entryData>, <!>> ???rawData CATSTR <!<>, <entryData>, <!>> ELSE ???eData CATSTR ???listType, <>, <entryData> ???rawData CATSTR <entryData> ENDIF データが、限定型でない場合には、式「ｓｔｒｕｃｔｕｒｅＮａｍｅ ＜ｓｔ
ｒｕｃｔｕｒｅＤａｔａ＞」を作成し、そうでない場合には「ｄａｔａＴｙｐｅ ｄａｔａ」（たとえばＢＹＴＥデータ）を作成する。

【０４５７】 % SAVE_LIST_ENTRY_DATA ???listName, entryName, ???eSortKey, ePriority,＼ ???listOverride, ???listAttr, ???dataSize, <???eData>, <???rawData> ENDIF ENDM ＳＡＶＥ＿ＬＩＳＴ＿ＥＮＴＲＹ＿ＤＡＴＡマクロを呼び出して、リスト・エ
ントリを保存し、呼出し元にリターンする。

【０４５８】 ５．６ ＳＡＶＥ＿ＬＩＳＴ＿ＥＮＴＲＹ＿ＤＡＴＡマクロ ＳＡＶＥ＿ＬＩＳＴ＿ＥＮＴＲＹ＿ＤＡＴＡマクロは、必要な機能を本発明に
提供し、ソース・コード・ファイルによって直接には絶対に呼び出されない内部
マクロである。

【０４５９】 SAVE_LIST_ENTRY_DATA MACRO listName, entryName, ＼ sortKey, sortPriority, overridePriority, ＼ listAttr, dataSize, listData, listTextData ＳＡＶＥ＿ＬＩＳＴ＿ＥＮＴＲＹ＿ＤＡＴＡマクロは、そのパラメータによっ
て指定されるリスト・エントリ・データを、ＬＩＳＴ＿ＳＴＡＲＴマクロによっ
てオープンされたセグメントｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔに保存する。

【０４６０】 DB '&listName' ; リスト名 DB 0 ; 文字列をヌル終端する DB LISTMGR_ENTRY_TYPE ; エントリ型 DB '&entryName' ; リスト・エントリ名 DB 0 ; 文字列をヌル終端する DB '&sortKey' ; リスト・ソート・キー DB 0 ; 文字列をヌル終端する DW sortPriority ; ソート優先順位（複数エントリ） DB overridePriority ; ソート・オーバーライド ; （ＣＯＲＥ、ＰＬＡＴＦＯＲＭなど） DB overridePriority ; データ・オーバーライド ; （ＣＯＲＥ、ＰＬＡＴＦＯＲＭなど） DB listAttr ; リスト属性 DW dataSize ; データのサイズ @@: listData ; データを生成する DB 「"&listTextData"] ; 生のリスト・エントリ・データ DB 0 ; 文字列をヌル終端する ENDM ローカル・ラベル（＠＠：）によって、エントリ・データの値が書き込まれる
位置が定義される。

【０４６１】 ５．７ ＬＩＳＴ＿ＤＡＴＡマクロ ＬＩＳＴ＿ＤＡＴＡマクロは、本発明によって、リスト・エントリのデータを
オーバーライドするのに使用される。

【０４６２】 LIST_DATA MACRO entryName, entryData, eAttributes ＬＩＳＴ＿ＤＡＴＡマクロは、ＬＩＳＴ＿ＳＴＡＲＴマクロ呼出しの後、ＬＩ
ＳＴ＿ＥＮＤマクロ呼出しの前に現れなければならない。パラメータは次の通り
である。 ｅｎｔｒｙＮａｍｅ − そのｅｎｔｒｙＤａｔａを変更されるリスト・エン
トリの名前。 ｅｎｔｒｙＤａｔａ − リスト・エントリの新しいデータ。 ｅＡｔｔｒｉｂｕｔｅｓ − ＬＡＢＥＬおよび／またはＰＵＢＬＩＣ。

【０４６３】 このマクロは、先行するＳＴＡＲＴ＿ＬＩＳＴマクロ呼出しによって提供され
る３つのグローバル変数の値も使用する。 ？？？ｌｉｓｔＮａｍｅ − オープンされているリストの名前。 ？？？ｌｉｓｔＴｙｐｅ − エントリの型。 ？？？ｌｉｓｔＯｖｅｒｒｉｄｅ − オーバーライド優先順位数（ＣＯＲＥ
、ＰＲＯＤＵＣＴ、ＰＬＡＴＦＯＲＭ、またはなし）。

【０４６４】 LOCAL ???dataSize LOCAL ???qualifiedType LOCAL ???eData LOCAL ???rawData LOCAL ???listAttr これらは、このマクロによって使用されるローカル変数である。

【０４６５】 IFNB <eAttributes> IFIDN <eAttributes>, <PUBLIC> ???listAttr = 1 ELSEIFIDN <eAttributes>, <LABEL> ???listAttr = 2 ELSEIFIDN <eAttributes>, <LABEL OR PUBLIC> ???listAttr = 3 ELSEIFIDN <eAttributes>, <PUBLIC OR LABEL> ???listAttr = 3 ELSE ???listAttr = 0 % .ERR <LIST_DATA: The attribute !'eAttributes!' is illegal> ENDIF ELSE ???listAttr = 0 ENDIF ｅＡｔｔｒｉｂｕｔｅｓパラメータを構文解析し、数値に変換する。ＰＵＢＬ
ＩＣキーワードは、ｅｎｔｒｙＮａｍｅを、ｅｎｔｒｙＤａｔａを参照するパブ
リック・ラベルとして定義させる。ＬＡＢＥＬキーワードは、ｅｎｔｒｙＮａｍ
ｅを、リスト・エントリを実際に生成せずにリスト内のラベル（両方のキーワー
ドが指定された場合にはＰＵＢＬＩＣ ＬＡＢＥＬ）として定義させる。この属
性は、リストがオプションのエントリからなる時に、リストへのインデックスが
必要な場合に有用である。

【０４６６】 IFB <entryName> .ERR <LIST_DATA: The list entry name is missing> ELSEIFB <entryData> .ERR <LIST_DATA: The list entry data is missing> ELSEIFNDEF ???listName .ERR <LIST_DATA: A list has not been started with LIST_START> ELSEIFIDNI ???listName, <LIST_UNDEFINED> .ERR <LIST_DATA: The open list has already been closed with ＼
LIST_END> ELSEIFIDNI ???listType, <ERROR> ELSE % ???dataSize = SIZEOF ???listType オープンされたリストが存在することと、すべての必要なパラメータが存在す
ることを検証する。リスト・エントリのサイズを判定する。

【０４６７】 ???qualifiedType = TRUE IFIDNI ???listType, <BYTE> ELSEIFIDNI ???listType, <WORD> ELSEIFIDNI ???listType, <DWORD> ELSEIFIDNI ???listType, <FWORD> ELSEIFIDNI ???listType, <QWORD> ELSEIFIDNI ???listType, <TBYTE> ELSE ???qualifiedType = FALSE ENDIF リストの型が構造体または限定型であるかどうかを判定する。

【０４６８】 IFE ???qualifiedType ???eData CATSTR ???listType, < !<>, <entryData>, <!>> ???rawData CATSTR <!<>, <entryData>, <!>> ELSE ???eData CATSTR ???listType, <>, <entryData> ???rawData CATSTR <entryData> ENDIF データが、限定型でない場合には、式「ｓｔｒｕｃｔｕｒｅＮａｍｅ ＜ｓｔ
ｒｕｃｔｕｒｅＤａｔａ＞」を作成し、そうでない場合には「ｄａｔａＴｙｐｅ ｄａｔａ」（たとえばＢＹＴＥデータ）を作成する。

【０４６９】 % SAVE_LIST_OVERRIDE_DATA ???listName, entryName, ???dataSize, ＼ <???eData>, <???rawData>, ???listOverride, ???listAttr ENDIF ENDM ＳＡＶＥ＿ＬＩＳＴ＿ＯＶＥＲＲＩＤＥ＿ＤＡＴＡマクロを呼び出して、リス
ト・オーバーライド・データを保存し、呼出し元にリターンする。

【０４７０】 ５．８ ＳＡＶＥ＿ＬＩＳＴ＿ＯＶＥＲＲＩＤＥ＿ＤＡＴＡマクロ ＳＡＶＥ＿ＬＩＳＴ＿ＯＶＥＲＲＩＤＥ＿ＤＡＴＡマクロは、必要な機能を本
発明に提供し、ソース・コード・ファイルによって直接には絶対に呼び出されな
い内部マクロである。

【０４７１】 SAVE_LIST_OVERRIDE_DATA MACRO listName, entryName, dataSize, ＼ listData,＼ listTextData, overridePriority, attributes ＳＡＶＥ＿ＬＩＳＴ＿ＯＶＥＲＲＩＤＥ＿ＤＡＴＡマクロは、パラメータによ
って指定されるリスト・オーバーライド・データを、ＬＩＳＴ＿ＳＴＡＲＴマク
ロによってオープンされたセグメントｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔに保存
する。

【０４７２】 DB '&listName' ; リスト名 DB 0 ; 文字列をヌル終端する DB LISTMGR_OVERRIDE_TYPE ; オーバーライド・タイプ DB '&entryName' ; リスト・エントリ名 DB 0 ; 文字列をヌル終端する DB overridePriority ; オーバーライド優先順位 DB attributes ; リスト属性 DW dataSize ; データのサイズ @@: listData ; データを生成する DB 「"&listTextData"」 ; 生のリスト・エントリ・データ DB 0 ; 文字列をヌル終端する ENDM ローカル・ラベル（＠＠：）によって、エントリ・データの値が書き込まれる
位置が定義される。

【０４７３】 ５．９ ＬＩＳＴ＿ＳＯＲＴマクロ ＬＩＳＴ＿ＳＯＲＴマクロは、本発明によって、リスト・エントリのソート判
断基準を変更するのに使用される。

【０４７４】 LIST_SORT MACRO entryName, ePriority := <8000h>, eSortKey ＬＩＳＴ＿ＳＯＲＴマクロは、ＬＩＳＴ＿ＳＴＡＲＴマクロ呼出しの後、ＬＩ
ＳＴ＿ＥＮＤマクロ呼出しの前に現れなければならない。パラメータは次の通り
である。 ｅｎｔｒｙＮａｍｅ − ソート順序を変更されるリスト・エントリの名前。 ｅＰｒｉｏｒｉｔｙ − 同一のソート・キーを有するリスト・エントリをソ
ートするのに使用される数。小さい数が、大きい数の前に配置される。最小値は
０、最大値は６５５３５（０ＦＦＦＦｈ）、デフォルトは３２７６８（８０００
ｈ）である。 ｅＳｏｒｔＫｅｙ − リスト・エントリをマスタ参照リストと突き合わせる
のに使用される文字列。ｅｎｔｒｙＮａｍｅが、デフォルト・ソート・キーであ
る。

【０４７５】 このマクロは、先行するＳＴＡＲＴ＿ＬＩＳＴマクロ呼出しによって提供され
る３つのグローバル変数の値も使用する。 ？？？ｌｉｓｔＮａｍｅ − オープンされているリストの名前。 ？？？ｌｉｓｔＴｙｐｅ − エントリの型。 ？？？ｌｉｓｔＯｖｅｒｒｉｄｅ − オーバーライド優先順位数（ＣＯＲＥ
、ＰＲＯＤＵＣＴ、ＰＬＡＴＦＯＲＭ、またはなし）。

【０４７６】 LOCAL ???eSortKey このマクロによって使用されるローカル変数。

【０４７７】 IFB <eSortKey> ???eSortKey CATSTR <entryName> ELSE ???eSortKey CATSTR <eSortKey> ENDIF ｅＳｏｒｔＫｅｙパラメータがブランクの場合には、デフォルト・ソート・キ
ーとしてｅｎｔｒｙＮａｍｅパラメータを使用する。

【０４７８】 IFB <entryName> .ERR <LIST_SORT: Entry name for list data is missing> ELSEIFNDEF ???listName .ERR <LIST_SORT: A list has not been started with LIST_START> ELSEIFIDNI ???listName, <LIST_UNDEFINED> .ERR <LIST_SORT: The open list has already been closed with ＼
LIST_END> ELSEIFIDNI ???listType, <ERROR> ELSE % SAVE_LIST_SORT_DATA ???listName, entryName, ???eSortKey, ＼ ePriority, ???listOverride ENDIF ENDM いくつかの健全性検査を行い、すべてが合格する場合に、新しいソート・デー
タを保存する。

【０４７９】 ５．１０ ＳＡＶＥ＿ＬＩＳＴ＿ＳＯＲＴ＿ＤＡＴＡマクロ ＳＡＶＥ＿ＬＩＳＴ＿ＳＯＲＴ＿ＤＡＴＡマクロは、必要な機能を本発明に提
供し、ソース・コード・ファイルによって直接には絶対に呼び出されない内部マ
クロである。

【０４８０】 SAVE_LIST_SORT_DATA MACRO listName, entryName, sortKey, ＼ sortPriority, overridePriority ＳＡＶＥ＿ＬＩＳＴ＿ＳＯＲＴ＿ＤＡＴＡマクロは、パラメータによって指定
されるリスト・ソート・データを、ＬＩＳＴ＿ＳＴＡＲＴマクロによってオープ
ンされたセグメントｌｉｓｔＥｎｔｒｙＳｅｇｍｅｎｔに保存する。 DB '&listName' ; リスト名 DB 0 ; 文字列をヌル終端する DB LISTMGR_SORT_TYPE ; ソート・タイプ DB '&entryName' ; リスト・エントリ名 DB 0 ; 文字列をヌル終端する DB overridePriority ; 使用される最後のエントリ DB '&sortKey' ; リスト・ソート・キー DB 0 ; 文字列をヌル終端する DW sortPriority ; ソート優先順位（複数エントリ） ENDM

【０４８１】 ５．１１ ＭＡＳＴＥＲ＿ＳＴＡＲＴマクロ ＭＡＳＴＥＲ＿ＳＴＡＲＴマクロは、本発明によって、マスタ・インデックス
の定義を開始するのに使用される。

【０４８２】 本発明のＢＩＯＳコンポーネント・リンカ部分は、マスタ・インデックスのソ
ート・キーの順序に従ってリスト・エントリをソートする。リストごとに、多く
とも１つのマスタ・インデックスがある。マスタ・インデックスは、通常はリス
トを所有するコンポーネント内で見つかるが、オーバーライドを容易にするため
に別のアセンブリ・ソース・ファイル内にある。マスタ・インデックスは、３つ
のマクロ、ＭＡＳＴＥＲ＿ＳＴＡＲＴ、ＭＡＳＴＥＲ＿ＥＮＴＲＹ、およびＭＡ
ＳＴＥＲ＿ＥＮＤを用いて作成される。

【０４８３】 MASTER_START MACRO listName, attrib ＭＡＳＴＥＲ＿ＳＴＡＲＴマクロは、ＭＡＳＴＥＲ＿ＥＮＴＲＹマクロまたは
ＭＡＳＴＥＲ＿ＥＮＤマクロを呼び出す前に呼び出されなければならない。パラ
メータは次の通りである。 ｌｉｓｔＮａｍｅ − このマスタ・インデックスに関連する完全修飾リスト
名（コンポーネント・パスを含む）。 ａｔｔｒｉｂ − ＬＯＣＫＥＤキーワード。ＬＯＣＫＥＤの場合に、これが
ロックド・インデックス（Ｌｏｃｋｅｄ Ｉｎｄｅｘ）になり、そうでない場合
に、マスタ・インデックスになる。

【０４８４】 ロックド・インデックスは、マスタ・インデックスの特別な形である。ソート
・キーを使用してリスト・エントリの最終的な順序付けを決定するのではなく、
ロックド・インデックスでは、リスト・エントリ名を使用する。ＭＡＳＴＥＲ＿
ＳＴＡＲＴマクロは、グローバル変数 ？？？ｍａｓｔｅｒＮａｍｅ − ｌｉｓｔＮａｍｅ。 ？？？ｍａｓｔｅｒＡｔｔｒｉｂｓ − マスタ・インデックスまたはロック
ド・インデックス。 を初期化し、特別な名前のセグメントをオープンし、これらのグローバル変数の
値をこのセグメントに保存する。

【０４８５】 IFNDEF ???masterName ???masterName CATSTR <MASTER_LIST_CLOSED> ENDIF IFIDN ???masterName, <MASTER_LIST_CLOSED> masterIndexSegment SEGMENT 必要であれば、グローバル変数？？？ｍａｓｔｅｒＮａｍｅを初期化し、いく
つかの一貫性検査を実行し、セグメントｍａｓｔｅｒＩｎｄｅｘＳｅｇｍｅｎｔ
をオープンする。

【０４８６】 IFNB <attrib> ???masterAttribs = 1 IFDIF <attrib>, <LOCKED> % .ERR <MASTER_START: !'attrib!' is an invalid attribute> ENDIF ELSE ???masterAttribs = 0 ENDIF ａｔｔｒｉｂパラメータを数値に変換し、マスタ・インデックスまたはロック
ド・インデックスのどちらが指定されたかを示すように、グローバル変数？？？
ｍａｓｔｅｒＡｔｔｒｉｂｓをセットする。

【０４８７】 IFNB <listName> ???masterName CATSTR <listName> ELSE .ERR <MASTER_START: The list name is missing> ???masterName CATSTR <> ENDIF % SAVE_MASTER_INFO_START ???masterName, ???masterAttribs ELSE % .ERR <MASTER_START: Master index list !'&???masterName!' is ＼
already open> ENDIF ENDM ｌｉｓｔＮａｍｅをグローバル変数に格納し、ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮ
ＦＯ＿ＳＴＡＲＴを呼び出して、グローバル変数の値を保存する。パラメータま
たはグローバル変数に一貫性がない場合には、エラーを生成する。

【０４８８】 ５．１２ ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮＦＯ＿ＳＴＡＲＴマクロ ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮＦＯ＿ＳＴＡＲＴマクロは、必要な機能を本発
明に提供し、ソース・コード・ファイルによって直接には絶対に呼び出されない
内部マクロである。

【０４８９】 SAVE_MASTER_INFO_START MACRO masterListName, attributes DB '&masterListName' ; マスタ・リスト名 DB 0 ; 文字列をヌル終端する DW attributes ; リスト属性 ENDM ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮＦＯ＿ＳＴＡＲＴマクロは、そのパラメータの
値を、ＭＡＳＴＥＲ＿ＳＴＡＲＴマクロによってオープンされたセグメントに保
存する。

【０４９０】 ５．１３ ＭＡＳＴＥＲ＿ＥＮＤマクロ ＭＡＳＴＥＲ＿ＥＮＤマクロは、本発明によって、マスタ・インデックスの定
義を終了するのに使用される。

【０４９１】 MASTER_END MACRO ＭＡＳＴＥＲ＿ＥＮＤマクロは、マスタ・インデックスの定義を終了する。Ｍ
ＡＳＴＥＲ＿ＥＮＤマクロは、ＭＡＳＴＥＲ＿ＳＴＡＲＴマクロ呼出しの後に現
れなければならない。

【０４９２】 IFNDEF ???masterName .ERR <MASTER_END: A master index was not started with ＼ MASTER_START> ELSEIFIDNI ???masterName, <MASTER_LIST_CLOSED> .ERR <MASTER_END: The master index was already closed with ＼ MASTER_END> ELSE SAVE_MASTER_INFO 0 masterIndexSegment ENDS ???masterName CATSTR <MASTER_LIST_CLOSED> ENDIF ENDM マスタ・リストがオープンされていることを検証する。ヌルのマスタ・リスト
・エントリを保存して、リストの終りをマークする。マスタ・インデックス・セ
グメントをクローズし、？？？ｍａｓｔｅｒＮａｍｅをＭＡＳＴＥＲ＿ＬＩＳＴ
＿ＣＬＯＳＥＤとしてマークする。

【０４９３】 ５．１４ ＭＡＳＴＥＲ＿ＥＮＴＲＹマクロ ＭＡＳＴＥＲ＿ＥＮＴＲＹマクロは、本発明によって、リスト・エントリをマ
スタ・インデックスに挿入するのに使用される。

【０４９４】 MASTER_ENTRY MACRO keyName ＭＡＳＴＥＲ＿ＥＮＴＲＹマクロは、ＭＡＳＴＥＲ＿ＳＴＡＲＴマクロ呼出し
の後、ＭＡＳＴＥＲ＿ＥＮＤマクロ呼出しの前でなければならない。パラメータ
は次の通り。 ｋｅｙＮａｍｅ − 特定のリスト・エントリとこのマスタ・インデックス位
置との間の関連を作成するのに使用される名前。これは、ソート・キー（マスタ
・インデックス）またはリスト・エントリ名（ロックド・インデックス）のいず
れかでなければならない。

【０４９５】 IFNDEF ???masterName .ERR <MASTER_ENTRY: A master index list has not been opened ＼
with MASTER_START> ELSE IFDIF ???masterName, <MASTER_LIST_CLOSED> % SAVE_MASTER_INFO keyName ELSE % .ERR <MASTER_ENTRY: The master index list has already ＼ been closed with MASTER_END> ENDIF ENDIF ENDM マスタ・リストが開始されていることを検査する。ＳＡＶＥ＿ＭＡＳＴＥＲ＿
ＩＮＦＯマクロを呼び出して、ソート・キーまたはリスト・エントリ名を保管す
る。

【０４９６】 ５．１５ ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮＦＯマクロ ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮＦＯマクロは、必要な機能を本発明に提供し、
ソース・コード・ファイルによって直接には絶対に呼び出されない内部マクロで
ある。

【０４９７】 SAVE_MASTER_INFO MACRO keyName IFDIF <keyName>, <0> DB '&keyName' ; インデックス名 ENDIF DB 0 ; 文字列をヌル終端する ENDM ＳＡＶＥ＿ＭＡＳＴＥＲ＿ＩＮＦＯマクロは、パラメータによって指定された
ｋｅｙＮａｍｅを、先行するＭＡＳＴＥＲ＿ＳＴＡＲＴマクロ呼出しによってオ
ープンされた特別なセグメントに保存する。

【０４９８】 ６．インクルード・マクロ ６．１ ＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴマクロ ＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴマクロは、本発明によって、パブ
リック・インクルード・ファイルを識別するのに使用される。ＰＵＢＬＩＣ＿Ｉ
ＮＣＬＵＤＥ＿ＳＴＡＲＴマクロおよびそのパラメータは、本発明によってスキ
ャンされ、したがって、これらを、そのファイルをインクルードするＰＵＢＩＮ
Ｃマクロのパラメータと比較することができる。

【０４９９】 インクルード・ファイルは、その中の定義を論理的に「所有」するコンポーネ
ント内に常駐する。定義が、他のディレクトリ内の他のコンポーネントによって
使用される場合には、インクルード・ファイルで、ＰＵＢＬＩＣ＿ＩＮＣＬＵＤ
Ｅ＿ＳＴＡＲＴマクロを使用することによってそれ自体をパブリックとして宣言
しなければならない。外部コンポーネントは、ＰＵＢＩＮＣマクロによって指定
されたクラス／サブクラスおよびファイル名を使用してインクルード・ファイル
を参照する。使用されるインクルード・ファイルの物理位置は、ビルド処理によ
って判定される。

【０５００】 インターフェースと同様に、パブリック・インクルード・ファイルの使用法に
、ファイルに関して期待される、「インターフェース」のメジャー・バージョン
およびマイナー・バージョン（ファイル・バージョンではなく）が含まれる。

【０５０１】 PUBLIC_INCLUDE_START MACRO classPath, version ＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴマクロは、他のディレクトリ内の
他のコンポーネントによって使用することができるパブリック・インクルード・
ファイルの先頭をマークする。パラメータは次の通りである。 ｃｌａｓｓＰａｔｈ − ピリオド（．）によって区切られた、クラス名と０
個以上のサブクラス名。 ｖｅｒｓｉｏｎ − ファイルに関して期待されるインターフェースのメジャ
ー．マイナー・バージョン番号。

【０５０２】 IFB <version> .ERR<PUBLIC_INCLUDE_START: !Version number for public include ＼
missing> ENDIF IFB <classPath> .ERR<PUBLIC_INCLUDE_START: Class path information is missing> ENDIF ENDM ｃｌａｓｓＰａｔｈパラメータおよびｖｅｒｓｉｏｎパラメータの両方が指定
されていることを検証する。

【０５０３】 各ＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿ＳＴＡＲＴマクロ呼出しのパラメータは、
インクルード・ファイルからスキャンされ、インクルード・ファイル名およびデ
ィレクトリ・パスと共にデータベースに入力される。これによって、ＢＩＯＳ開
発システムが、コンパイルの前に、インクルード・ファイルからスキャンしたイ
ンターフェース情報を、それをインクルードしたソース・ファイルからのインタ
ーフェース情報とマージできるようになる。

【０５０４】 ６．２ ＰＵＢＩＮＣマクロ ＰＵＢＩＮＣマクロは、本発明によって、異なるコンポーネント内で定義され
たパブリック・インクルード・ファイルをインクルードするのに使用される。Ｐ
ＵＢＩＮＣマクロおよびそのパラメータは、本発明によってスキャンされ、した
がって、これらを、そのファイルを定義するＰＵＢＬＩＣ＿ＩＮＣＬＵＤＥ＿Ｓ
ＴＡＲＴマクロのパラメータと比較することができる。

【０５０５】 PUBINC MACRO classPath, fileName, version ＰＵＢＩＮＣマクロは、外部インクルード・ファイルをビルドに含める。外部
インクルード・ファイルは、現在のディレクトリおよびコンポーネントの外にあ
る。パラメータは次の通りである。 ｃｌａｓｓＰａｔｈ − ピリオド（．）によって区切られた、クラス名と０
個以上のサブクラス名。 ｆｉｌｅＮａｍｅ − インクルード・ファイルの名前。 ｖｅｒｓｉｏｎ − ファイルに関して期待されるインターフェースのメジャ
ー．マイナー・バージョン番号。 使用法：「ＰＵＢＩＮＣ ｐｏｓｔ．ｄｉｓｐａｔｃｈｅｒ， ｐｏｓｔｄｉ
ｓｐ．ｉｎｃ， １．０」。

【０５０６】 LOCAL ???incPath このマクロによって使用されるローカル変数。

【０５０７】 IFNB <classPath> IFNB <fileName> GET_SYMBOL_NAME classPath ???incPath CATSTR <I_>, ???symbol % INCLUDE???incPath＼＼fileName IFB <version> .ERR<PUBINC: The include file !version is missing> ENDIF ELSE .ERR<PUBINC: The include file name is missing> ENDIF ELSE .ERR<PUBINC: The include file feature path is missing> ENDIF ENDM すべてのパラメータが存在することを検証する。ＧＥＴ＿ＳＹＭＢＯＬ＿ＮＡ
ＭＥマクロを呼び出して、各ピリオド（．）をアンダースコア（＿）に置換され
たｃｌａｓｓＰａｔｈを含むグローバル変数？？？ｓｙｍｂｏｌを返す。？？？
ｓｙｍｂｏｌの値にＩ＿を前置することによって、インクルード・ファイルのデ
ィレクトリ・パスを含むグローバル変数の名前を形成する。ｃｌａｓｓＰａｔｈ
がｐｏｓｔ．ｄｉｓｐａｔｃｈｅｒである場合に、？？？ｉｎｃＰａｔｈは、Ｉ
＿ｐｏｓｔ＿ｄｉｓｐａｔｃｈｅｒになる。グローバル変数のディレクトリ・パ
スを使用するＩＮＣＬＵＤＥディレクティブ（すなわちコマンド）を用いてファ
イルをインクルードする。

【０５０８】 ＢＩＯＳ開発システムは、ソース・コード・ライブラリの各ソース・コード・
ファイルにインクルードされる機能インクルード・ファイル「ｆｅａｔｕｒｅ．
ｉｎｃ」を生成する。ＢＩＯＳ開発システムは、インクルード・ファイルのディ
レクトリ・パス、たとえばＩ＿ｐｏｓｔ＿ｄｉｓｐａｔｃｈｅｒ ＴＥＸＴＥＱ
Ｕ ＜＠Ｅｎｖｉｒｏｎ（ＭＡＮＴＩＣＯＲＥ）￥ｐｏｓｔ￥ｄｉｓｐａｔｃｈ
ｅｒ＞を含むＰＵＢＩＮＣマクロ呼出しによって、宣言されるパブリック・イン
クルード・ファイルごとにグローバル変数を定義する。

【０５０９】 付録Ａ：ＰｌａｔｆｏｒｍＴｙｐｅデスクトップのソース・ライブラリ Directory of c:＼BIOS＼core 4-26-99 1:23p 11,645 bda.inc 7-23-99 7:42a 795 beep.obj 7-23-99 7:42a 453 chksum.obj 7-23-99 7:42a 559 compat.obj 7-23-99 7:42a 18,564 compnent.exe 7-28-99 9:48p 1,110 compnent.inf 7-23-99 7:42a 803 compnent.map 7-23-99 7:42a 2,261 dispinit.obj 7-23-99 7:42a 1,423 dispintf.obj 7-23-99 7:42a 871 disputil.obj 7-23-99 7:42a 4,274 exe.obj 7-23-99 7:42a 675 fillint.obj 7-23-99 7:42a 577 getnext.obj 7-22-99 10:44a 3,988 makefile 7-23-99 7:42a 3,080 module.obj 7-23-99 7:42a 1,529 service.obj Directory of c:＼BIOS＼core＼beep 4-26-99 2:15p 4,448 beep.asm 4-26-99 1:20p 1,375 feature.inc 5-24-99 10:19a 1,058 feature.inf Directory of c:＼BIOS＼devref\intel＼440bx 7-22-99 2:49p 143,245 binlink.out 7-22-99 2:49p 262,144 bios.rom 6-29-99 9:15a 1,503 bios.scr 6-03-99 12:14p 44,823 devutils.asm 7-22-99 2:49p 313 dispat~1.out 6-25-99 8:25a 4,865 dmainit.asm 7-29-99 7:20a 245 hook.asm 7-28-99 12:06p 5,809 init.asm 7-22-99 9:01a 3,514 makefile 7-22-99 2:49p 34,650 modules.out 7-29-99 1:12p 245 myfile.asm 8-12-99 4:38p 113 platform.cfg 8-12-99 4:38p 113 platform.old 6-16-99 3:39p 4,142 register.asm 7-22-99 2:49p 2,401 stackl~1.out 7-22-99 2:49p 1,651 tasklist.out

【０５１０】 付録Ｂ：リスト・マネージャ・コンポーネント １．概要 多数のコンポーネントが、ＢＩＯＳの複数のコンポーネントからの関係するデ
ータ構造体のリストを作成し、管理する能力を必要とする。リストの例が、セッ
トアップ、ＰＯＳＴタスク、プラグ・アンド・プレイ・デバイス・ノード、ＳＭ
Ｉハンドラなどにみられる。この文書では、Ｍａｎｔｉｃｏｒｅのリスト管理に
関連する設計、マクロ、および機能を説明する。 ２．関連する文書

【表１】 ３．使用される用語 下は、この文書で使用される用語のリストである。 リスト リスト名によって参照される、ソートされた同一サイズのデータ構造体
（リスト・エントリ）の配列。 リスト・データ ＲＯＭイメージに配置される実際のデータ。キー、名前、また
は優先順位を含まない。 リスト・エントリ 関連する名前、キー、および優先順位と共に、リストを構成
する個々のデータ構造体。 リスト・ヘッダ 最終的なＲＯＭイメージ内のリストの前に配置される、エント
リの数および各エントリのサイズを含む小さい構造体。 リスト名 リストを識別する一意の名前。 リスト・オーナー リストを作成するコンポーネント。 リスト・マネージャ リストへのアクセスを制御し、共通のユーティリティ機能
を提供するコンポーネント。 マスタ・インデックス 特定のリストの、可能なすべてのリスト・エントリ・キ
ーのリスト。すべてのリストがマスタ・インデックスを有するわけではない。リ
スト・エントリは、このファイル内のキーの位置に従ってソートされる。あるリ
ストのすべての可能なキーが、マスタ・インデックスに現れなければならない。
ロックド・インデックス リスト・エントリの正確な順序を保証するのに使用さ
れる、マスタ・インデックスの特別な形式。リスト・エントリは、このファイル
内のリスト・エントリ名（ソート・キーではなく）の位置に従ってソートされる
。 ４．設計 リストは、リスト名によって参照される、ソートされた同一サイズのデータ構
造体（リスト・エントリと呼ばれる）の配列である。あるコンポーネント（リス
ト・オーナーと呼ばれる）が、リストを作成し、名前を与え、フォーマットし、
リストがＢＩＯＳ実行中に存在する場所を割り当てる。他のコンポーネント（リ
スト・オーナーを含む）は、リスト名を使用することによってリストにリスト・
エントリを追加することができる。バイナリ・リンカが、すべてのリストおよび
リスト・エントリを収集し、リスト名によってグループ化し、ソートし、ＢＩＯ
Ｓに書き出す。バイナリ・リンカは、リストおよびリスト・エントリへの参照も
フィックス・アップする。 （付録Ｂの図１の翻訳 List Record #2: リスト・レコード＃２ Module 1: モジュール１ List Record #3: リスト・レコード＃３ Module 2: モジュール２ List Record #1: リスト・レコード＃１ Module 3: モジュール３ List Definition: リスト定義 Module 4: モジュール４ BUILT UTILITY: ビルド・ユーティリティ Ascii File Output to OEM listing sorted list entries: ソートされたリス
ト・エントリをリストする、ＯＥＭに出力されるＡＳＣＩＩファイル List Header: リスト・ヘッダ List Record #1: リスト・レコード＃１ List Record #2: リスト・レコード＃２ List Record #3: リスト・レコード＃３ Figure 1: List Collection: 図１：リスト収集） バイナリ・リンカ・ユーティリティは、ソートされたリスト・データをＲＯＭ
イメージに置く。配置は、リスト宣言で見つかるセグメント属性に依存する。バ
イナリ・リンカは、リスト・データの前に、リスト・エントリの数を含むリスト
・ヘッダを置く。

【表２】 リストの先頭は、必ずパラグラフ整列される。リスト名から作成されるパブリ
ック・ラベルは、リスト・ヘッダをポイントする。リスト・ヘッダのサイズは、
保証されず、将来のリビジョンで変更される可能性がある。 ４．１ リストの作成 各リストは、所有するコンポーネント／機能によって、ＬＩＳＴ＿ＣＲＥＡＴ
Ｅマクロ（１０ページ）を使用して、１回だけ作成されなければならない。リス
トが、マスタ・インデックスを使用してソートされる場合には、マスタ・インデ
ックス・ファイルも、所有するコンポーネントの一部である。同一の名前を有す
る２つのリストが作成される場合には、バイナリ・リンカが、エラーを生成する
。 LIST_CREATE devnodes, 1.0, devNodeListStruct リストは、３つのものすなわち、名前、バージョン番号、およびエントリサイ
ズを有しなければならない。名前は、他のリストまたはプロシージャと衝突して
はならない。 リストのバージョン番号は、リストの構造体または関数の変更を示す。バージ
ョン番号は、ピリオド！！によって区切られた２つの部分すなわち、メジャー・
バージョンおよびマイナー・バージョンからなる。より大きい数字が、後のリビ
ジョンを意味する。メージャー・バージョン番号が変更される時に、より小さい
かより大きいメジャー・バージョンを有するリスト・エントリは、バイナリ・リ
ンカにエラーを生成させる。マイナー・バージョンが変更される時に、より大き
いマイナー・バージョンを有するリスト・エントリは、バイナリ・リンカにエラ
ーを生成させる。 エントリ・サイズは、各リスト・エントリについてリスト・データのサイズを
指定する、数、限定型（ＢＹＴＥ、ＷＯＲＤなど）、または構造体名である。こ
のサイズは、リスト・ヘッダの第２フィールドに置かれる。 ４．２ エントリの作成 コンポーネントまたは機能は、ＬＩＳＴ＿ＳＴＡＲＴ（１３ページ)、ＬＩＳ
Ｔ＿ＥＮＤ（１１ページ）、およびＬＩＳＴ＿ＥＮＴＲＹ（１ページ）マクロを
使用して、リストにリスト・エントリを追加することができる。 LIST_START pnp.devnodes, 1.0, devNodeListStruct LIST_ENTRY pnpDEVNodeName, <(...)> LIST_END ４．２．１ ＬＩＳＴ＿ＳＴＡＲＴの使用法 ＬＩＳＴ＿ＳＴＡＲＴは、リスト・エントリのブロックを開始し、リスト名、
リスト・バージョン番号、リスト・エントリ・サイズ、およびリスト・エントリ
・オーバーライド優先順位を含む、すべてに共通する情報を与える。 LIST_START listName, listVersion, entrySize, overridePriority リスト名は、リスト・オーナーと、その後のリスト名（関数名のように）を与
える。バイナリ・リンカは、存在しないリストについてリスト・エントリが作成
される場合に、警告を生成する。 リスト・バージョン番号は、それに続くリスト・エントリが、リストの指定さ
れたバージョンのために設計されていることを示す。バージョン番号は、２つの
部分すなわち、メジャー・バージョンおよびマイナー・バージョンに分解される
。より大きい数が、より後のリビジョンを意味する。リスト・エントリのメジャ
ー・バージョンが、リストのメジャー・バージョンと等しくない時に、バイナリ
・リンカがエラーを生成する。リスト・エントリのマイナー・バージョンが、リ
ストのマイナー・バージョンより大きい時に、バイナリ・リンカがエラーを生成
する。 リスト・エントリ・サイズは、各リスト・エントリについてリスト・データが
何バイトを要するかを指定する。これは、ＭＡＳＭの限定型（すなわち、ＢＹＴ
Ｅ、ＷＯＲＤなど）または構造体名でなければならない。 追加のオプションであるリスト・エントリ・オーバーライド優先順位は、それ
に続くリスト・エントリが、同一の名前を有するがより低いオーバーライド優先
順位を有する既存のリスト・エントリを置換するかどうかを指定する。このフィ
ールドについて、現在は３つの事前定義の値すなわち、ＣＯＲＥ（コア・コード
用）、ＰＲＯＤＵＣＴ（製品ライン・コード用）、ＰＬＡＴＦＯＲＭ（プラット
フォーム・コード用）がある。指定されない場合のデフォルト値は、ＣＯＲＥで
ある。 たとえば、コアは、オーバーライド優先順位「ＣＯＲＥ」を使用して、ＰＯＳ
Ｔタスクｘが、テスト・ポイント５０で発生することを指定することができる。
しかし、顧客は、すべてのプラットフォームでＰＯＳＴタスクｘがテスト・ポイ
ント９０に再配置される製品ラインｙを有する。したがって、顧客は、ＯＥＭ「
製品ライン」コンポーネント内にもう１つのリスト・エントリを作成し、オーバ
ーライド優先順位「ＰＲＯＤＵＣＴ」を使用する。最後に、製品ラインｙで、型
を破り、ＰＯＳＴタスクｘをテスト・ポイント３３に移動することを求める単一
のプラットフォームがある。したがって、顧客は、ＯＥＭ「プラットフォーム」
コンポーネント内にもう１つのリスト・エントリを作成し、オーバーライド優先
順位「ＰＬＡＴＦＯＲＭ」を使用する。 バイナリ・リンカは、同一の名前を有するが異なるオーバーライド優先順位を
有する複数のリスト・エントリを見た時に、ＰｒｏｄｕｃｔよりもＰｌａｔｆｏ
ｒｍ、ＣｏｒｅよりもＰｒｏｄｕｃｔを選択する。 ４．２．２ ＬＩＳＴ＿ＥＮＴＲＹ使用法 ＬＩＳＴ＿ＥＮＴＲＹでは、名前、リスト・データ、ソート・キー、およびソ
ート優先順位を含む、単一のリスト・エントリに関する情報を記述する。 LIST_ENTRY entryName, <listData>, sortPriority, sortKey リスト・エントリ名（リスト・エントリ・オーバーライド優先順位と共に）に
よって、リスト内でエントリが一意に識別される。リスト・エントリ名は、リス
ト・データをポイントするラベルとして使用することができる。リスト・エント
リ名は、ソートおよびオーバーライドにも使用される。同一のオーバーライド優
先順位を有するもう１つのリスト・エントリが見つかる場合には、バイナリ・リ
ンカが、エラーを生成する。 リスト・データには、かぎ括弧内で、リスト・タイプ（ＬＩＳＴ＿ＳＴＡＲＴ
から）の後に配置される正確なデータが含まれる。構造体は、追加の中括弧「｛
」および「｝」に含まれなければならない。これは、ＲＯＭイメージ内に実際に
現れるデータである。 ソート・キーおよびソート優先順位によって、リスト内のリスト・エントリの
順序付けが決定される。ソート・キーは、標準の名前または空である。順序付け
の挙動は、下の表に示されているように、ソート・キーと、マスタ・インデック
スまたはロックド・インデックスの存在に依存する。

【表３】 ４．２．３ ＬＩＳＴ＿ＥＮＤ使用法 ＬＩＳＴ＿ＥＮＤは、リスト・エントリのブロックの末尾をマークする。 ４．３ リストの使い方 リスト・マネージャ（ｌｉｓｔｍｇｒ）は、リストのアクセスに関するユーテ
ィリティ関数を提供する。関数の完全なリストについては、パブリック関数（１
４ページ）を参照されたい。この節では、リスト・マネージャを使用する一般的
な作業のガイドラインを提供する。 ４．３．１ リストの先頭を見つける リストの先頭を見つけるには、２つのステップがある。 １．リストを作成する（ＬＩＳＴ＿ＣＲＥＡＴＥ、１０ページ）か、外部と宣
言する（ＰＵＢＥＸＴ）。 ２．ＬＯＡＤＡＤＤＲを使用して、リストのアドレスをロードする。 たとえば、 PUBEXT posttask, 1.0, SUBSTITUTE LOADADDR posttask ; GS:DI - リスト・ヘッダ ＳＵＢＳＴＩＴＵＴＥ属性が、ＰＵＢＥＸＴと共に使用され、その結果、リス
トがエントリを有しない場合に、ＧＳおよびＤＩに０ｘＦＦＦＦが含まれるよう
になる。リスト・マネージャは、この値についてＤＩを検査することによって、
空のリストを検出する。ＯＰＴＩＯＮＡＬが使用される（ＳＵＢＳＴＩＴＵＴＥ
の代わりに）場合には、リストが空の場合に、ＬＯＡＤＡＤＤＲがコードを生成
しない。ＳＵＢＳＴＩＴＵＴＥまたはＯＰＴＩＯＮＡＬがないと、リストが空の
場合に、ＬＯＡＤＡＤＤＲが、バイナリ・リンカにエラーを生成させる。 ４．３．２ リストを介するループ リストのすべてのエントリを処理するために、リスト・マネージャが、ｇｅｔ
Ｎｅｘｔ関数を提供する。 たとえば、 EXTINC listMgr, listmgr.inc, 1.0 ; リスト・マネージャ・ マクロを有する PUBEXT posttask, 1.0, SUBSTITUTE PUBEXT listMgr.getNext, 1.0 LOADADDR posttask ; GS:DI = リスト・ヘッダ
loop1: EXTCALL listMgr.getNext ; GS:DI = 最初のエントリ jc exitLoop1 ; リストの終り ...ユーザ・コード... jmp loop1 exitLoop1: ４．４ マスタ・インデックス バイナリ・リンカは、マスタ・インデックスを使用して、ソート・キーを有す
るリスト・エントリをソートする。リストごとに、多くとも１つのマスタ・イン
デックスがある。マスタ・インデックスは、普通はリストを所有するコンポーネ
ント内で見つかる．ＡＳＭファイルであるが、オーバーライドを容易にするため
に別のファイルになっている。マスタ・インデックスは、３つのマクロ、ＭＡＳ
ＴＥＲ＿ＳＴＡＲＴ、ＭＡＳＴＥＲ＿ＥＮＴＲＹ、およびＭＡＳＴＥＲ＿ＥＮＤ
を使用して作成される。 たとえば、 MASTER_START post.postTask MASTER_ENTRY TpVerifyRealMode ; 第1POSTタスク MASTER_ENTRY TpChipsetInit ; 第2POSTタスク MASTER_ENTRY TpVideoInit ; 第3POSTタスク . . . MASTER_END ＭＡＳＴＥＲ＿ＳＴＡＲＴに続く名前は、リストの名前である（ＬＩＳＴ＿Ｃ
ＲＥＡＴＥによる）。ＭＡＳＴＥＲ＿ＥＮＴＲＹに続く名前は、リスト・エント
リでみられるソート・キーである。 バイナリ・リンカは、マスタ・インデックスのソート・キーの順序に従ってリ
スト・エントリをソートする。バイナリ・リンカは、 １．リスト・エントリがソート・キーを有するが、そのリストに関してマスタ
・インデックスが指定されていない。 ２．リスト・エントリのソート・キーが、マスタ・インデックスで見つからな
い。 ３．マスタ・インデックスが見つかったが、対応するリストがない。 場合にエラーを生成する。 マスタ・インデックス・ファイルは、普通にオーバーライドすることができる
。 ４．５ リスト出力 バイナリ・リンカは、リストの最終的な内容を、名前ｌｉｓｔｎａｍｅ．ｏｕ
ｔを有するアセンブル可能ファイルに出力する。このｌｉｓｔｎａｍｅは、リス
トへの完全修飾コンポーネント・パスである。たとえば、リストｐｏｓｔ．ｐｏ
ｓｔＴａｓｋｓの内容は、ｐｏｓｔ．ｐｏｓｔＴａｓｋｓ．ｏｕｔに出力される
。 リスト出力ファイルは、明確に定義されたフォーマットを有し、２つのセクシ
ョンすなわちコメントおよびコードに分解される。コメント・セクションには、
リスト・エントリごとに生成された実際のバイナリ・データを含む、最終的なリ
スト内容に関する人間（およびデバッガ）可読情報が含まれる。コード・セクシ
ョンには、ビルドのリスト・エントリの正確な順序を記述するロックド・インデ
ックスが含まれる。リスト出力ファイルは、ロックド・インデックス・ファイル
として使用することができる。詳細については、ロックド・インデックス（７ペ
ージ）を参照されたい。 ４．５．１ コメント・セクション コメント・セクションは、最初の非ホワイトスペース文字としてタグ「；＄＄
ＣＯＭＭＥＮＴＳＴＡＲＴ＄＄」を有する新しい行から開始される。コメント・
セクションは、最初の非ホワイトスペース文字としてタグ「；＄＄ＣＯＭＭＥＮ
ＴＥＮＤ＄＄」を有する新しい行で終わる。コメント・セクション内のすべての
行が、最初の非ホワイトスペース文字としての「；」から始まらなければならな
い。 他のコメント・セクション・ステートメントが現れる前に、キーワード「Ｃｏ
ｍｍｅｎｔＶｅｒｓｉｏｎ（ｘ．ｘ）」が現れなければならず、このｘ．ｘは、
コメント・セクション・フォーマットのメジャー・バージョン番号およびマイナ
ー・バージョン番号である。メジャー番号は、後方互換でない変更を意味する。
マイナー番号は、後方互換の変更を意味する。 以下に示すのは、すべてのリスト宣言ステートメントが単一の．ＡＳＭファイ
ル内で行われたかのように（オーバーライドされるバージョンを含む）、リスト
を記述するＬＩＳＴ＿ＣＲＥＡＴＥマクロ、ＬＩＳＴ＿ＳＴＡＲＴマクロ、およ
びＬＩＳＴ＿ＥＮＴＲＹマクロである。２つの相違がある。まず、すべての行に
、「；」が前置される。第２に、ＬＩＳＴ＿ＥＮＴＲＹマクロによって生成され
る実際の１６進データが、行内でＬＩＳＴ＿ＥＮＴＲＹマクロの直後に現れる（
１行あたり１６バイト）。 たとえば、 ;$$COMMENTSTART$$ ;CommentVersion(1.0) ; ;LIST_CREATE postTask, 1.0, postTaskStruct ;LIST_START postTask, 1.0, postTaskStruct ;* LIST_ENTRY postEntry1, <(...), TpPostEntry1, 0x8000 ; ; 8000F00869 ; LIST_ENTRY postEntry1, <(...)>, TpPostEntry2, 0x4000, SORT_KEY+SORT
_PRIORITY ; ; 8000F00973 ; LIST_ENTRY postEntry2, , (...)., TpPostEntry2, 0x8000 ; 8000F00A90 ; ... ;LIST_END ; $$COMMENTEND$$ ４．５．２ コード・セクション コード・セクションには、ロックド・インデックスの形の正確なリスト順序付
けが含まれる。詳細に関しては７ページを参照されたい。 ４．６ ロックド・インデックス ロックド・インデックスは、マスタ・インデックスの特別な形態であり、リス
ト内のリスト・エントリの順序付けを固定するために、ＯＥＭによって使用され
る。リスト・エントリの最終的な順序付けを決定するのにソート・キーを使用す
るのではなく、ロックド・インデックスでは、リスト・エントリ名を使用する。
リストごとに、多くとも１つのロックド・インデックスを設けることができる。
ほとんどの場合に、ロックド・インデックスは、リスト出力ファイルの名前を変
更したバージョンである（ページ６を参照されたい）。 ロックド・インデックスは、ＭＡＳＴＥＲ＿ＳＴＡＲＴが第２パラメータとし
て属性ＬＯＣＫＥＤを指定されることを除いて、マスタ・インデックスと同一の
マクロを使用することによって作成される。詳細については、ＭＡＳＴＥＲ＿Ｓ
ＴＡＲＴ（１４ページ）を参照されたい。 バイナリ・リンカは、 １．ロックド・インデックスがリストについて見つかるが、リストがＬＩＳＴ
＿ＣＲＥＡＴＥを用いて作成されていない。 ２．リスト・エントリ名が、ロックド・インデックスで見つからない。 ３．対応するリスト・エントリのないエントリが、ロックド・インデックスに
現れる。 場合にエラーを生成する。 ４．７ バイナリ・リンカ情報 説明したマクロのそれぞれが、バイナリ・リンカによって使用されるコンポー
ネントのイメージ内に情報を配置しなければならない。これらのデータ構造体を
、下で詳細に示す。

【表４】

【０５１１】 付録Ｃ

【表５】

【０５１２】 付録Ｄ

【表６】

【表７】

【０５１３】 付録Ｅ プラットフォーム・タイプ階層 本発明で記述される際に、ソース・コード・ライブラリのすべての部分／ディ
レクトリが、プラットフォーム／製品タイプに基づくビルド包含トリガ特性を宣
言する。たとえば、ＢＩＯＳでは、複数プロセッサ・サポートが、サーバに関す
る推奨デフォルト機能であるが、他の製品タイプについては明示的にインストー
ル可能であるに過ぎない。新しいプラットフォーム・タイプが作られる時に、そ
のタイプを宣言するためにソース・コード・ライブラリのすべての機能を変更す
ることは望ましくない。したがって、製品タイプは、階層内で宣言され、新しい
タイプを別のタイプから派生させることができる。親と異なるトリガを必要とす
る機能だけを変更すればよい。下記は、システムの製品タイプを宣言するファイ
ルと、BIOSに関するそれらの派生階層の例である。 Basic PC ; 基本製品タイプ Desktop99 ; Basic PCから派生 Desktop2000 ; desktopから派生 Laptop2000 ; desktop2000から派生 Laptop99 ; やはりDesktop99から派生 下記は、所与の機能のトリガを選択する再帰アルゴリズムである。 １）PLATFORM.CFGで宣言されたプラットフォーム・タイプが、INFトリガを宣
言されている場合には、機能についてそのトリガを仮定し、終了する。 ２）親が宣言されていない場合には、トリガを'Explicit'と仮定し、終了する
。 ３）親プラットフォーム・タイプの宣言を検査する。宣言されている場合には
、機能について親のタイプのトリガを仮定し、終了する。 ４）２に進む。

【０５１４】 付録Ｆ トリガ・ルール この図で、コード・ツリーに関する無効なトリガの組合せを定義する。コード
・ツリー内の無効なトリガの組合せは、複数のコンポーネントまたは機能に同一
のクラス・パス定義が含まれる時に、未確定のトリガをもたらす。 定義： コレクティブ・トリガ（Ｃｏｌｌｅｃｔｉｖｅ Ｔｒｉｇｇｅｒ）：機能の祖
先を考慮に入れたコンポーネントまたは機能のトリガ。コレクティブ・トリガは
、アルゴリズムの一部として判定される。 トリガの説明： Ｒ＝Ｒｅｃｏｍｍｅｎｄｅｄ Ｏ＝Ｏｎｄｅｍａｎｄ Ｏ＋Ｅ＝ＯｎｄｅｍａｎｄとＥｘｔｅｒｎａｌ Ｔｒｉｇｇｅｒの組合せ Ｘ＝Ｅｘｐｌｉｃｉｔ コレクティブ・トリガの説明 Ｒ＝Ｒｅｃｏｍｍｅｎｄｅｄ Ｒｏｏｔ＝類似するクラスの有効性検査のルートの再確立 Ｉ＝未確定 静的なツリー判定 ツリーを検証するには： １．状態テーブルＡをツリーに適用し ２．状態テーブルＢをツリーに適用し ３．状態が変化しなくなるまでステップ１および２を繰り返す。 類似するクラス名のコンポーネント／機能および同一のルートの下の関数につ
いて、下のテーブルは、無効なトリガ組合せの条件を示す。

【表８】

【表９】

【表１０】

【０５１５】 付録Ｇ コード・セグメント化アクセス違反 関数への呼出しのアクセス特権は、呼出し元および呼び出される側のセグメン
トの属性によって検証される。呼び出される側は、最小限のサブセットとして呼
出し元の属性を有しなければならず、さもなければ、グラフィカル製品ビューで
エラーが注記される。下の例では、ＸがＳＭＩの属性を有しないので、ＹがＸを
呼び出すことはできない。論法は、ＳＭＩからＹを呼び出すことができるならば
、Ｙが呼び出す関数を、ＳＭＩから実行できると仮定しなければならないという
ことである。構成処理は、呼び出される側に対して呼出し元のこれらの属性を検
証し、適切なエラーを与える。これらのエラーによって、呼び出される時に、リ
ンクされたコードがもはや使用可能でない時の実行時デバッグの数時間を防ぐこ
とができる。 セグメント・アクセス違反の例 OPEN_CODE_SEGMENT RUNTIME + PRERAM ; コード・セグメント ; を宣言する PUBLIC_PROC X ; プロシージャXを宣言する ENDP ; Xの宣言を終了する CLOSE_SEGMENT ; コード・セグメント宣言を終了する OPEN_CODE_SEGMENT RUNTIME + PRERAM + SMI ; コード・セグメント ; を宣言する PUBLIC_PROC Y ; プロシージャYを宣言する CALL X ; Xへの呼出し元 - エラーが生成される ENDP ; プロシージャの終り CLOSE_SEGMENT ; コード・セグメント宣言を終了する

【０５１６】 付録Ｈ 構成のカスタマイズ技法の例 ステップ1) ユーザが、INFファイルで定義されたデフォルトからオプション値を
変更する。グラフィカルには、これは、ポイント・アンド・クリック・オペレー
ションである。新しい値は、ソース・コード内で強調表示されて可視になる。 ステップ2)ユーザ・インターフェースが、構成を呼び出して、新しいオプション
値をPLATFORM.CFGファイルに書き込む。 ステップ3)ビルドの準備をする時に、コンパイラに対するオプションの値を定義
した動的に作成されたプリプロセッサ・ファイルFEATURE.INCで式を定義する。
新しい値が、デフォルト値と置換される。 ステップ4)コンパイルで、新しい値が使用される。 オプション値のカスタマイズ ファイル・オーバーライドによるカスタマイズ ステップ1)ユーザが、ソース・ライブラリ・ファイルを右クリックし、"overrid
e"を選択する。 ステップ2)ユーザ・インターフェースが、オーバーライド・ファイルを配置する
カスタム・ディレクトリについてユーザにプロンプトを出す。 ステップ3)ユーザ・インターフェースが、構成を呼び出して、ファイル名および
フォルダをPLATFORM.CFGに置く。 ステップ4)ユーザ・インターフェースが、カスタム・アイコンと共に、元のファ
イルの代わりにオーバーライド・ファイルを表示する。 ステップ5)ビルド準備処理が、ビルド・スクリプトで元のファイルの代わりにオ
ーバーライド・ファイルを使用する。 カスタム・ファイルを機能に追加することによるカスタマイズ。 ステップ1)ユーザが、機能を右クリックし、"add custom file"を選択する。 ステップ2)ユーザ・インターフェースが、カスタム・ファイルのカスタム・ディ
レクトリについてユーザにプロンプトを出す。 ステップ3)ユーザ・インターフェースが、構成を呼び出して、ファイル名および
フォルダをPLATFORM.CFGに置く。 ステップ4)ユーザ・インターフェースが、カスタム・アイコンと共に、機能ファ
イル・リストにカスタム・ファイルを表示する。 ステップ5)ビルド準備処理が、機能/コンポーネントのビルド・スクリプトにカ
スタム・ファイルを追加する。

【０５１７】 付録Ｉ データベース・アーカイブ 開発環境には、２つのマスタ・コンポーネント・データベースがある。コア・
マスタ・コンポーネント・データベースは、コア・サーバに常駐し、これには、
コア・ソース・ファイルに関する情報が含まれる。ローカル・マスタ・コンポー
ネント・データベースは、開発者のワークステーションに常駐し、これには、ロ
ーカル開発ツリーに関する情報が含まれる。すべてのデータベースが、データ・
アクセスＡＰＩを介してのみアクセスされる。下の図に、これらの関係をグラフ
ィカルに示す。 （図の翻訳 Deveropment Workstation: 開発ワークステーション Developer' GUI: 開発者のＧＵＩ (32 bit Console App.): （３２ビット・コンソール・アプリケーション） Data Access API: データ・アクセスＡＰＩ Configuration API: 構成ＡＰＩ Local Master Database: ローカル・マスタ・データベース Local BIOS Tree: ローカルＢＩＯＳツリー OEM Config. Options: ＯＥＭ構成オプション CORE SERVER: コア・サーバ Event Driven DBUpdate: イベント・ドリブンＤＢＵｐｄａｔｅ Periodic DBUpdate(T=24 hours): 周期的ＤＢＵｐｄａｔｅ（Ｔ＝２４時間） Core Master Component Database: コア・マスタ・コンポーネント・データベ
ース Tips Master Database: チップス・マスタ・データベース Core Label Archived Database: コア・ラベル・アーカイブド・データベース
Component Archived Database: コンポーネント・アーカイブド・データベース
BIOS Core: ＢＩＯＳコア） コア・マスタ・コンポーネント・データベースは、３つのサブパート、「チッ
プ・データベース」、「コンポーネント・アーカイブ・データベース」、および
「コア・ラベル・アーカイブ・データベース」を有する。これらのデータベース
のそれぞれが、異なるタイプのサポートを提供する。 ・チップ・データベースは、最新のコンポーネント・ファイルおよび機能ファ
イルのチップで参照されるファイルからの情報からなる。ディレクトリ内のファ
イルのセットに対する変更が、チップ・データベースに対する更新にトリガをか
けるイベントを生成する。このデータベースは、最新の使用可能なコア情報への
アクセスのために、ＧＵＩおよび他のツールによって使用される。 ・コンポーネント・アーカイブ・データベースは、保存される新しいコンポー
ネント・ラベルごとに作成される。このアーカイブ・データベースは、チップ・
データベースとほぼ同一であるが、これには、特定のコンポーネント・ラベルに
関する情報が含まれる。コンポーネント・ラベルに対する変更は、コンポーネン
ト・アーカイブの更新にトリガをかける、サーバ上のイベントを生成する。コン
ポーネント・アーカイブ・データは、コア・ラベル・アーカイブ・データの構築
のみに使用される。 ・コア・ラベル・アーカイブ・データベースは、保存される新しいコア・ラベ
ルごとに作成される。このアーカイブ・データベースは、コンポーネント・アー
カイブとほぼ同一である。このアーカイブの情報は、コア・ラベルで参照される
コア・コンポーネント・ラベルごとにコンポーネント・アーカイブから吸収され
たデータに基づく。コア・ラベルに対する変更が、コア・ラベル・アーカイブの
更新にトリガをかける、サーバ上のイベントを生成する。コア・ラベル・アーカ
イブ・データは、ＧＵＩによって、より古いコア・ラベルに関する情報を提示す
るのに使用される。これは、開始するファイルを一致させるために、コアからロ
ーカル開発ツリーに特定のコンポーネントをダウンロードする必要があるファイ
ルを判定するのに役立つ可能性がある。 ローカル・マスタ・コンポーネント・データベースは、チップ・データベース
と同一のデータベース構造を有する。このデータベースの相違は、その情報源に
ある。ローカル・データベースには、ローカル・ディレクトリ・ツリーから得ら
れた情報が含まれる。したがって、この情報には、作業コード・ベースでの変更
が含まれる。

【０５１８】 付録Ｊ コンポーネント／機能トリガ・アルゴリズム 下のアルゴリズムで、システムが製品に含まれるコンポーネントおよび機能を
判定する機構を説明する。状態テーブルの参照を、下に示す。 アルゴリズム： １）状態テーブルＡを適用する。 ２）状態テーブルＢを適用する。 ３）状態テーブルＣを適用する。 ４）状態テーブルＤを適用する。 ５）状態テーブルＥを適用する。 ６）いずれかの機能の状態がステップ３から５で変化した場合には、２に進む
。 ７）アクティブな機能の依存性を解決する。未解決の依存性を記録する。下記
のルールに注意： ａ．許容されるスコープ内のリゾルバだけが、依存性解決について検討され
る。プライベート／シールド・プライベートによってスコープが制限される。 ｂ．ハード依存性だけが、未解決としてリストされる。オプションまたは代
替の依存性は、リストされない。 ８）未解決の依存性がない場合には、１１に進む。 ９）状態テーブルＦを適用する。 １０）いずれかの項目の状態がステップ９で変化した場合には、２に進む。 １１）状態テーブルＧを適用する。 状態テーブルを適用するための定義： トリガ: Ｒ＝Ｒｅｃｏｍｍｅｎｄｅｄ Ｏ＝Ｏｎ Ｄｅｍａｎｄ Ｅ＝Ｅｘｔｅｒｎａｌ Ｔｒｉｇｇｅｒ Ｘ＝Ｅｘｐｌｉｃｉｔ Ｔｒｉｇｇｅｒ Ｏ＋Ｅ＝ＯｎＤｅｍａｎｄ ＴｒｉｇｇｅｒとＥｘｔｅｒｎａｌ Ｔｒｉ
ｇｇｅｒの両方 その他： Ｄｃ＝ドントケア Ａ− アクティブ − 製品に含まれる ＩＡ− インアクティブ − 製品に含まれない ＵＤ− 未確定状態 ＵＤＯ− 未決定だが、参照を解決するために含まれる可能性がある。 ツリーのルートは、プラットフォームが定義される場合に、必ずアクティ
ブとみなされる。 親は、当該の機能の１レベル上と定義される。トリガは、この構成のプラ
ットフォーム・タイプに適用されるfeature.inf内で定義される。

【表１１】

【表１２】

【表１３】

【表１４】

【表１５】

【表１６】

【表１７】

【０５１９】 付録Ｋ 動的ツリー検証決定 ユーザが動的にコンポーネント／機能をフォース・インまたはフォース・アウ
トする時に構成が決定的であることを検証するために、下記のアルゴリズムを適
用する。この検証は、ユーザがコンポーネントおよび機能をビルドにフォース・
インまたはフォース・アウトする時に、構成エンジンによって適用される。 １．ツリーに状態テーブルＣを適用する。 ２．ツリーに状態テーブルＡを適用する。 ３．ツリーに状態テーブルＢを適用する。 ４．状態が変化しなくなるまでステップ２および３を繰り返す。 同一のルートの下の類似するクラス名のコンポーネント／機能について、下の
テーブルが、無効なトリガ組合せの条件を示す。

【表１８】

【表１９】

【表２０】

【０５２０】 付録Ｌ コード・フロー情報 製品構成で関数呼出しをコンパイルし、取り込む前にコードベースをスキャン
することによって、データの異なるビューから、ユーザに価値のある情報を提供
することができる。このデータは、製品デバッグおよび焦点を合わせた回帰テス
トを支援する。下記は、同一のデータベースおよび構成情報から生成された、２
つの異なるレポートの非常に単純化された例である。 Code flow starting at Function X Function X Calls Function Y Calls Function Z Calls Function W Calls Function Q Calls Function Z Functions to test if changes are made to Function Z Z is called by Function Y and X Called by Function X この分析に加えて、呼出しおよび参照の情報から、デッド・コードまたは未解
決のコード（任意選択で参照される場合でも）を含めて、ソース・コード・ライ
ブラリの問題を報告することができる。ソース・コード・ライブラリ内の参照さ
れない関数のすべてが、おそらくはデッド・コードとして報告される。ソース・
コード・ライブラリ内で解決されない参照のすべてが、無用な参照として報告さ
れる。これらの報告を、カスタム・コードに対してフィルタリングし、開発者が
、ライブラリ更新の後に、自分のカスタマイズがまだ参照されるか、既存のコー
ドを参照することを検証できるようになる。

【図面の簡単な説明】

【図１】 さまざまなソフトウェア要素の間の関係が強調されている、本発明の教示に従
って設計されたプログラム開発システム１００の概要ブロック図である。

【図２】 ユーザ実行可能関数をリストし、表示関数もリストする、ビジュアル・ユーザ
・インターフェース・システムの概要要約を示す図である。

【図３】 ユーザが開始したコマンドを実行するルーチンを示すブロック図である。

【図４】 データベース更新ルーチンのブロック図である。

【図５】 ファイルを修正し、データベースを更新し、改訂された製品構成を判定し、新
たに改訂された構成をユーザまたはシステム開発者に表示する処理を示す流れ図
（Ａ）とすべてのファイルのスキャン、データベースの更新、構成の改訂（必要
な場合に）、すべての構成リビジョンのシステム開発者への表示、および完成し
た製品のビルドの処理を示す流れ図（Ｂ）である。

【図６】 データベース・アクセス・ルーチンのブロック図である。

【図７】 構成ルーチンのブロック図である。

【図８】 製品メイク・プロシージャの概要を示す流れ図である。

【図９Ａ】 機能ごとに「ｆｅａｔｕｒｅ．ｉｎｃ」ファイルを作成するビルド準備ルーチ
ンの流れ図である。

【図９Ｂ】 コンポーネント・メイクファイルを作成し、「ｆｅａｔｕｒｅ．ｉｎｃ」ファ
イルを作成するために図９Ａのルーチンに頼る、ビルド準備ルーチンの流れ図で
ある。

【図１０】 ソース・コード選択、修正、コンパイル、アセンブル、リンク、および製品コ
ンポーネント・リンカによる最終コンポーネント・リンクを引き起こす、製品メ
イクファイルおよびコンポーネント・メイクファイルを実行する時にメイク・ユ
ーティリティによって実行されるステップの流れ図である。

【図１１】 本発明のデータ・フロー形態が強調された、プログラム開発システム１００の
概要を示す流れ図である。

【図１２】 コンポーネント・ソース・コード・ライブラリ（図１１の１２００）の内容の
概要を示す図である。

【図１３】 図１１に示されたコンポーネント・ソース・コード・ライブラリ１２００を占
める通常のＩＢＭ ＰＣ互換アセンブリ言語ソース・コード・ファイル１３００
の内容を示す図である。

【図１４】 図１１に示されたコンポーネント・ソース・コード・ライブラリ１２００を占
めるコンポーネント情報ファイル「ｃｏｍｐｎｅｎｔ．ｉｎｆ」１４００の内容
を示す図である。

【図１５】 コンポーネント情報ファイルに配置することができるものの例を示す図である
。

【図１６】 図１１に示されたコンポーネント・ソース・コード・ライブラリ１２００を占
める通常の機能情報ファイル「ｆｅａｔｕｒｅ．ｉｎｆ」１６００の内容を示す
図である。

【図１７】 機能情報ファイルに配置することができるものの例を示す図である。

【図１８】 図１１に示されたコンポーネント・データベース１８００の内容の概要を示す
図である。

【図１９】 図１１に示された構成状態データ１９００の内容の概要を示す図である。

【図２０】 図１９に示されたデータのうちで、完成した製品のビルドを管理するために、
選択され、図８および３４に示された製品メイク・ルーチン９００に供給される
部分の概要を示す図である。

【図２１】 図１１に示された製品構成データ・ファイル「ｐｌａｔｆｏｒｍ．ｃｆｇ」２
１００に含まれる製品構成コマンドの例示的な組を示す図である。

【図２２】 この「ｐｌａｔｆｏｒｍ．ｃｆｇ」ファイルに配置することができるものの概
要を示す図である。

【図２３】 例示的な機能インクルード・ファイル「ｆｅａｔｕｒｅ．ｉｎｃ」２３００（
図１１）の内容（製品メイク・ルーチン９００（図１１）によって自動的に生成
され、より具体的には、ビルド機能インクルード・ファイル・ルーチン９５０（
図９Ａおよび３５）によって生成される）を示す図である。

【図２４】 製品メイク・ルーチン８００（図８および３４）によって自動的に生成され、
より具体的にはコンポーネント・ビルド準備ルーチン９００（図９Ｂおよび３４
）によって生成される、例示的なコンポーネント・メイクファイル２４００（図
１１）の内容を示す図である。

【図２５】 製品メイク・ルーチン８００（図８および３４）によって自動的に生成される
例示的な製品メイクファイル２５００（図１１）の内容を示す図である。

【図２６】 図４にも示されている、データベース更新ルーチン４００のブロック図である
。

【図２７】 図２６に示された機能およびコンポーネント・ファイル・スキャン・ルーチン
２７００（図４、１１、および２６のステップによって呼び出される）の詳細を
示すブロック図である。

【図２８】 図１１に示され、図７にも示された、コンフィギュレータ・プロシージャ２８
００のブロック図である。

【図２９】 コンフィギュレータ・プロシージャ２８００（図２８）の初期活動化ルーチン
２９００部分のブロック図である。

【図３０】 コンフィギュレータ・プロシージャ２８００（図２８）の製品構成ルーチン３
０００部分のブロック図である。

【図３１】 コンフィギュレータ・プロシージャ２８００（図２８）の製品構成ルーチン３
０００（図３０）内の外部参照解決ルーチン３１００のブロック図である。

【図３２】 ＲＡＭベース製品構成データ１９００（図１１、図１９にも図示）の内部構造
を示す図である。

【図３３Ａ】 製品の論理ビューと特定のファイルのウィンドウ化されたビューを含む、本発
明のグラフィカル・ユーザ・インターフェースのシステム設計者ビューを示す図
である。

【図３３Ｂ】 エラーをユーザ・インターフェースでシステム設計者に示す方法を示す図であ
る。

【図３３Ｃ】 システム設計者がソース・コード・ファイルのオープン、除去、またはオーバ
ーライドを行うか、グラフィカル・ユーザ・インターフェースからそのプロパテ
ィを習得する方法を示す図である。

【図３３Ｄ】 システム設計者がグラフィカル・ユーザ・インターフェース内でコンポーネン
トをオープンし、選択または選択解除を行う方法を示す図である。

【図３３Ｅ】 システム設計者がグラフィカル・ユーザ・インターフェースを使用してオプシ
ョンを調整する方法を示す図である。

【図３３Ｆ】 アイコンとグラフィカル・ユーザ・インターフェース内でアイコンが意味する
ものを示す図である。

【図３４】 図８にも示された、製品メイク・ルーチン８００（図１１）の概要ブロック図
である。

【図３５】 図９Ａにも示された、ビルド機能インクルード・ファイル・ルーチン９５０の
ブロック図である。

【図３６】 製品コンポーネント・リンカ・ルーチン３６００（図１１）の概要のブロック
図である。

【図３７】 リスト作成および管理処理３７００の概要のブロック図である。

【図３８】 ソフトウェア開発過程を案内するためのシステム１００を介する制御情報の流
れを示すブロック図である。

【図３９】 不揮発性ＲＡＭの割振りおよび管理を示すブロック図である。

【図４０】 文字列の割振りおよび管理を示すブロック図である。

【図４１】 本発明のパブリック、プライベート、および「ＳｈｉｅｌｄＰｒｉｖａｔｅｓ
」依存性アクセス機能を示すブロック図である。

【図４２】 テーブルからとられた単一の項目をカスタマイズするための製品コンポーネン
ト・リンカ３６００の使用を示すブロック図である。

【手続補正書】

【提出日】平成１４年１２月２４日（２００２．１２．２４）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】０２０１

【補正方法】変更

【補正の内容】

【０２０１】 コンフィギュレータ・プロシージャ２８００の初期活動化２９００は、製品構
成データ２１００からプラットフォーム・タイプ２１０２を取り出すことによっ
て開始される。その後、データベース１８００から、指定されたプラットフォー
ム・タイプで許容されるか必須であるコンポーネントに関するすべてのコンポー
ネント情報を読み取り２９０４、製品コンフィギュレータ状態データ１９００を
ランダム・アクセス・メモリ内に作成する。製品コンフィギュレータ状態データ
１９００には、各機能のソース・ファイルと、これらのソース・ファイル内のＰ
ＵＢＬＩＣ＿ＰＲＯＣマクロおよびＰＵＢＥＸＴマクロのそれぞれのパラメータ
が含まれる。製品構成ルーチン３０００による各機能の活動化（３００４、３０
０８、３０１０、３０１４）の際に、各ＰＵＢＥＸＴマクロによってそのソース
・ファイル内で参照されるプロシージャが未解決の参照のリストに追加される。
製品構成ルーチン３０００は、フォース・アウトを指定された（３３３４、２２
０４、２２１０、２２０８）オブジェクトを活動化しないように注意して３００
２、以下のステップに進む。

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０２０２

【補正方法】変更

【補正の内容】

【０２０２】 ステップＡ３００４で、フォース・アウトを指定された（３３３４、２２０４
、２２１０、２２０８）すべてのオブジェクト（コンポーネントまたは機能）お
よびその親を製品コンフィギュレータ状態データ１９００内でアクティブ状態に
設定する。ステップＢ３００６で、すべての推奨されるコンポーネント・オブジ
ェクト（１５１０、１５１４、１５１６）を製品コンフィギュレータ状態データ
１９００内でアクティブ状態に設定する。ステップＣ３００８で、製品コンフィ
ギュレータ状態データ１９００内のすべてのアクティブ・オブジェクトについて
、すべての推奨される子（１７１０、１７１４、１７１６）をアクティブ状態に
設定し、繰り返す。ステップＤ３０１０で、外部トリガとしてクラスを指定され
た（１５１８、１７１８）、コンポーネント・オブジェクトまたはアクティブ・
オブジェクトの子のそれぞれについて、そのクラスのオブジェクトが製品コンフ
ィギュレータ状態データ１９００でアクティブである場合に、外部トリガされる
オブジェクトをアクティブ状態に設定する。ステップＥ３１００で、外部参照を
解決し（図３１）、未解決の参照および解決された参照の一致しないバージョン
のリストを維持する。ステップＦ３０１４で、アクティブに設定できるオブジェ
クトがなくなり、未解決のままの参照がなくなるまで、ある機能が未解決の参照
を解決し、オン・デマンドであり（１７１６）、すべての親オブジェクトがアク
ティブまたはオン・デマンドである（１５１６、１７１６）場合に、そのオブジ
ェクトおよび製品コンフィギュレータ状態データ１９００内のすべての親オブジ
ェクトをアクティブ状態に設定し、ステップＣ、Ｄ、およびＥを繰り返す。

【手続補正３】

【補正対象書類名】明細書

【補正対象項目名】０２８５

【補正方法】変更

【補正の内容】

【０２８５】 さまざまな統計情報が、データベースから使用可能である。この情報には、下
記が含まれる。１）未使用のインターフェース、ラベル、または変数の判定。２
）コード・フロー分析。３）あるプロシージャについて宣言されたパブリック・
インターフェースおよびプライベート・インターフェースの数。４）コンポーネ
ントまたは機能のクラスその他に基づく最小機能インターフェース要件を満たさ
ないコンポーネントおよび機能の報告。

【手続補正４】

【補正対象書類名】図面

【補正対象項目名】図３３Ｃ

【補正方法】変更

【補正の内容】

【図３３Ｃ】

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ， ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，Ｉ Ｓ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ， ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，Ｐ Ｔ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ， ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ルシンスキー，ロバート・デニス アメリカ合衆国・92870・カリフォルニア 州・プレイセンティア・イースト ホーコ ム プレイス・1449 (72)発明者 ルイス，ティモシィ・アンドリュー アメリカ合衆国・94555・カリフォルニア 州・フリーモント・シャロウ コート・ 33775 (72)発明者 サンダスキィ，マーク・シェイン アメリカ合衆国・92565・カリフォルニア 州・アリソ ビエジョ・グリーンボロウ コート・７ Ｆターム(参考） 5B076 AB10 AC07 DB04 DD05

Claims (73)

【特許請求の範囲】
1. 【請求項１】 完成した製品を開発するソフトウェア開発システムであって
   、 完成した製品を定義する製品構成データと、 インターフェースおよび依存性を含む１つまたは複数のオブジェクトを定義す
   るソース・コードを含む少なくとも１つのソース・コード・ライブラリと、 前記オブジェクトの性質を定義するディレクティブと、 前記製品構成データと、前記ディレクティブと、前記ソース・コード・ライブ
   ラリから得られるデータとから構成状態データを展開するコンフィギュレータと
   、 完成した製品と、欠けているか選択されているか選択解除されているオブジェ
   クトおよびオプションとを表す構成状態データの視覚的論理表現を提示するグラ
   フィカル・ユーザ・インターフェースであって、完成した製品を調整するコマン
   ドを受け入れるグラフィカル・ユーザ・インターフェースと、 前記構成状態データの制御の下で前記ソース・コードから完成した製品を生成
   するルーチンと を含むソフトウェア開発システム。
2. 【請求項２】 前記オブジェクトが少なくとも１つのソース・コード要素と
   前記ディレクティブを含むオブジェクト情報データ・セットとを含む請求項１に
   記載のソフトウェア開発システム。
3. 【請求項３】 前記ディレクティブが、ビルド・ディレクティブを含む請求
   項２に記載のソフトウェア開発システム。
4. 【請求項４】 前記オブジェクトが、機能である少なくとも１つのオブジェ
   クトを含む少なくとも１つのコンポーネントを含む請求項１に記載のソフトウェ
   ア開発システム。
5. 【請求項５】 前記コンポーネントおよび機能のそれぞれが、少なくとも１
   つのソース・コードと、対応するコンポーネントまたは機能に関するディレクテ
   ィブを含むオブジェクト情報データ・セットとを含む請求項４に記載のソフトウ
   ェア開発システム。
6. 【請求項６】 前記インターフェースおよび依存性の少なくともいくつかが
   、完成した製品の展開の前に正しい絶対アドレスを用いて置換される両方のクラ
   ス指定を有する請求項１に記載のソフトウェア開発システム。
7. 【請求項７】 完成した製品を生成する前記ルーチンが、少なくともいくつ
   かの依存性およびインターフェースがソース・コード要素を修正する時に、前記
   少なくともいくつかの依存性およびインターフェースの参照を名前およびライブ
   ラリ参照に変換し、命名する請求項６に記載のソフトウェア開発システム。
8. 【請求項８】 前記インターフェースおよび依存性の少なくともいくつかが
   、バージョン表示を有し、前記インターフェースおよび依存性の少なくともいく
   つかが、完成した製品の展開の前に絶対アドレスに置換される名前およびクラス
   指定の両方を有する請求項１に記載のソフトウェア開発システム。
9. 【請求項９】 前記グラフィカル・ユーザ・インターフェースが、突き合わ
   されたおよび依存性の非互換のバージョン番号について警告する請求項８に記載
   のソフトウェア開発システム。
10. 【請求項１０】 さらに、少なくともいくつかの依存性に関連するデータの
    一部として、オブジェクト指定データを含み、オブジェクト指定データが、対応
    するものを、同一の識別子を有する他のインターフェースに優先して、指定され
    たものに含まれるソース・コード要素内のインターフェースにリンクさせる請求
    項１に記載のソフトウェア開発システム。
11. 【請求項１１】 前記インターフェースおよび依存性の少なくともいくつか
    が、完成した製品の展開の前に正しい絶対アドレスに置換される名前およびクラ
    ス指定の両方を有する請求項１０に記載のソフトウェア開発システム。
12. 【請求項１２】 少なくともいくつかのクラス指定が、複数のオブジェクト
    を含み、前記オブジェクトが、機能を含むコンポーネントを含み、少なくともい
    くつかの指定が、複数の機能のインターフェースおよび依存性に関する請求項１
    １に記載のソフトウェア開発システム。
13. 【請求項１３】 前記インターフェースおよび依存性の少なくともいくつか
    が、バージョン表示を有する請求項１０に記載のソフトウェア開発システム。
14. 【請求項１４】 前記グラフィカル・ユーザ・インターフェースが、突き合
    わされたインターフェースおよび依存性の非互換のバージョン番号について警告
    する請求項１３に記載のソフトウェア開発システム。
15. 【請求項１５】 ＲＡＭフリー環境で走るように指定されたソース・コード
    要素を含み、完成した製品を生成するルーチンが、ＲＡＭベースのサブルーチン
    ・スタックを必要としないサブルーチン・ジャンプおよびリターンをエミュレー
    トする呼出しまたはジャンプ依存性挿入コードで、前記ソース・コード要素を修
    正する請求項１に記載のソフトウェア開発システム。
16. 【請求項１６】 呼出しまたはジャンプおよびリターンの依存性で挿入され
    たコードが、リターンに続くレジスタ分岐を実行するダミー・リターン・スタッ
    クをセット・アップし、呼出しまたはジャンプの点で、前記レジスタに即値アド
    レスをロードし、指定されたインターフェースへのジャンプを作るコードを生成
    し、挿入する請求項１５に記載のソフトウェア開発システム。
17. 【請求項１７】 呼出しまたはジャンプおよびリターンの依存性で挿入され
    たコードが、リターン・アドレスまたはリターン・アドレスの位置を示すインデ
    ックスを指定されたレジスタに保存し、呼出し側プログラムの適切な点へのリタ
    ーンを実行するのにそのレジスタを使用する請求項１５に記載のソフトウェア開
    発システム。
18. 【請求項１８】 コンフィギュレータが、対応するインターフェースに関す
    る選択されていないオブジェクトの存在に依存する依存性に出会った時に、完成
    した製品に含めるために前記オブジェクトを自動的に選択する請求項１に記載の
    ソフトウェア開発システム。
19. 【請求項１９】 前記インターフェースおよび依存性の少なくともいくつか
    が、完成した製品の展開の前に正しい絶対アドレスに置換される名前およびクラ
    ス指定の両方を有する請求項１８に記載のソフトウェア開発システム。
20. 【請求項２０】 前記クラス指定の少なくともいくつかが複数のオブジェク
    トを含み、前記オブジェクトが機能を含むコンポーネントを含み、前記クラス指
    定の少なくともいくつかが複数の機能のインターフェースおよび依存性に関する
    請求項１９に記載のソフトウェア開発システム。
21. 【請求項２１】 いくつかのインターフェースが任意選択としてインターセ
    プト指定を含むことができ、前記コンフィギュレータが他の同一の名前を有する
    インターフェースに優先してインターセプト指定を有するインターフェースに依
    存性を関連付ける請求項１に記載のソフトウェア開発システム。
22. 【請求項２２】 前記インターフェースおよび依存性の少なくともいくつか
    がバージョンを有する請求項２１に記載のソフトウェア開発システム。
23. 【請求項２３】 前記オブジェクトが、機能である少なくとも１つのオブジ
    ェクトを含む少なくとも１つのコンポーネントを含む請求項２１に記載のソフト
    ウェア開発システム。
24. 【請求項２４】 完成した製品を生成する前記ルーチンが、オブジェクトの
    非選択に起因して対応するインターフェースがない少なくともいくつかの依存性
    に直面した時に、これがエラー状態でない場合に、依存性を含むソース・コード
    要素から依存性を除去することによってソース・コード要素を修正する請求項１
    に記載のソフトウェア開発システム。
25. 【請求項２５】 前記インターフェースおよび依存性の少なくともいくつか
    がバージョン表示を有する請求項２４に記載のソフトウェア開発システム。
26. 【請求項２６】 マクロ・プログラムが依存性を識別するのに使用され、前
    記マクロ・プログラムが前記コンフィギュレータによって設定される制御してい
    る引数への参照を含み、前記制御している引数が、対応するインターフェースを
    含むオブジェクトが選択されていない時に、コンフィギュレータの選択で依存性
    を除去できるようにする請求項２４に記載のソフトウェア開発システム。
27. 【請求項２７】 前記グラフィカル・ユーザ・インターフェースが対応する
    インターフェースを含み、対応するオブジェクトの選択または非選択のコマンド
    を受け入れるオブジェクトの非選択に起因して除去されなければならない依存性
    を示す請求項２４に記載のソフトウェア開発システム。
28. 【請求項２８】 前記コンフィギュレータが、グラフィカル・ユーザ・イン
    ターフェースに、インターフェースがない少なくともいくつかの依存性に関する
    視覚的エラー表示を与えさせる請求項１に記載のソフトウェア開発システム。
29. 【請求項２９】 前記インターフェースおよび依存性の少なくともいくつか
    がバージョン表示を含む請求項２８に記載のソフトウェア開発システム。
30. 【請求項３０】 前記オブジェクトの性質を定義するデータが、少なくとも
    いくつかの場合に、あるオブジェクトの選択が別のオブジェクトの選択によって
    トリガされることの表示を含み、前記コンフィギュレータが、そのようなデータ
    に出会った時に、前記あるオブジェクトも選択されている時に、必ず前記もう１
    つのオブジェクトを選択する請求項１に記載のソフトウェア開発システム。
31. 【請求項３１】 前記ディレクティブが、ビルド・ディレクティブを含む請
    求項３０に記載のソフトウェア開発システム。
32. 【請求項３２】 前記インターフェースおよび依存性の少なくともいくつか
    が、完成した製品の展開の前に絶対アドレスに置換される名前およびクラス指定
    の両方を有し、前記インターフェースおよび依存性の少なくともいくつかがバー
    ジョン表示を有する請求項３０に記載のソフトウェア開発システム。
33. 【請求項３３】 前記ソース・コード要素の少なくともいくつかがリスト要
    素を含み、前記ルーチンが製品コンポーネント・リンカを含み、前記製品コンポ
    ーネント・リンカがこれらのリスト要素を一緒にし、それらを指定された点で完
    成した製品に挿入し、リスト項目参照へのリンクを確立することによって、ソー
    ス・コードを修正する請求項１に記載のソフトウェア開発システム。
34. 【請求項３４】 前記リスト要素がソート優先順位指定を含む請求項３３に
    記載のソフトウェア開発システム。
35. 【請求項３５】 前記リスト要素がソート・キー指定を含む請求項３３に記
    載のソフトウェア開発システム。
36. 【請求項３６】 前記リスト要素がリスト・エントリを含む請求項３３に記
    載のソフトウェア開発システム。
37. 【請求項３７】 複数のリストを定義することができ、各リスト・エントリ
    が、リストの要素の識別および収集を容易にするために、リスト名を割り当てら
    れる請求項３３に記載のソフトウェア開発システム。
38. 【請求項３８】 前記リスト要素が、その少なくともいくつかがソート優先
    順位ならびにソート・キーを指定するリスト・エントリを含む請求項３７に記載
    のソフトウェア開発システム。
39. 【請求項３９】 前記インターフェースの少なくともいくつかがパブリック
    と宣言され、かつすべてのオブジェクト内のすべての依存性によってアクセス可
    能であるか、あるいは、プライベートと宣言され、同一のオブジェクト内の依存
    性によってのみアクセス可能である請求項１に記載のソフトウェア開発システム
    。
40. 【請求項４０】 前記オブジェクトが少なくとも１つの機能を含む少なくと
    も１つのコンポーネントを含み、少なくともいくつかのインターフェースがパブ
    リックと宣言され、すべてのオブジェクト内のすべての依存性によってアクセス
    可能であり、いくつかのインターフェースがプライベートと宣言され、同一のコ
    ンポーネント内の依存性によってのみアクセス可能であり、いくつかのインター
    フェースがシールデッドと宣言され、同一の機能内の依存性によってのみアクセ
    ス可能である請求項１に記載のソフトウェア開発システム。
41. 【請求項４１】 前記ソース・コード要素の少なくともいくつかが、および
    文字列の言語を定義する文字列要素を含み、完成した製品を生成する前記ルーチ
    ンが、不揮発性メモリに保管された値によって正しい言語文字列を選択できるよ
    うにするコードを挿入する請求項１に記載のソフトウェア開発システム。
42. 【請求項４２】 前記製品構成データが、ビルドされるプラットフォームの
    タイプを定義するデータを含む請求項１に記載のソフトウェア開発システム。
43. 【請求項４３】 ビルドされるプラットフォームのタイプを定義する前記デ
    ータが、デスクトップ、ポータブル、およびサーバからなる群から選択されるタ
    イプのプラットフォームを指定することができる請求項４２に記載のソフトウェ
    ア開発システム。
44. 【請求項４４】 完成した製品を生成する前記ルーチンが、データ・テーブ
    ル内のデータのいくつかの項目を置換するためのオーバーライド・データの提供
    を可能にする製品コンポーネント・リンカを含む請求項１に記載のソフトウェア
    開発システム。
45. 【請求項４５】 完成した製品を生成する前記ルーチンが、別々にコンパイ
    ルされリンクされた実行可能コードのブロックの間のセグメント内リンクを確立
    する製品コンポーネント・リンカを含む請求項１に記載のソフトウェア開発シス
    テム。
46. 【請求項４６】 前記ソース・コード・ライブラリ内のコード要素を不揮発
    性メモリに常駐するものとして指定することができ、完成した製品を生成する前
    記ルーチンが製品コンポーネント・リンカを含み、前記製品コンポーネント・リ
    ンカが、そのような要素の記憶のために不揮発性メモリを割り振り、システム設
    計者が不揮発性メモリの性質に関心を持つ必要がない形で、プログラムに不揮発
    性メモリ内のそのような変数へのアクセスを与えるのに必要なコードを、完成し
    た製品に挿入する請求項１に記載のソフトウェア開発システム。
47. 【請求項４７】 前記ソース・コード要素の少なくともいくつかが、テキス
    トおよび文字列の言語を定義する文字列要素を含み、完成した製品を生成する前
    記ルーチンが、不揮発性メモリに格納された値によって正しい言語文字列を選択
    できるようにするコードを挿入する請求項４６に記載のソフトウェア開発システ
    ム。
48. 【請求項４８】 前記グラフィカル・ユーザ・インターフェースがオブジェ
    クトのソース・コード要素を表示し、修正するためのエディタを含む請求項１に
    記載のソフトウェア開発システム。
49. 【請求項４９】 構成状態データの前記視覚的論理表現内の要素の１つをク
    リックすることによって、前記グラフィカル・ユーザ・インターフェース内で編
    集ウィンドウを開くことができる請求項４８に記載のソフトウェア開発システム
    。
50. 【請求項５０】 マクロ・ディレクティブが、前記インターフェースおよび
    依存性をマークするのに使用され、コード修正が、標準的なアセンブラ、コンパ
    イラ、およびリンカをソフトウェア開発システムの実施に使用できるように、前
    記コンフィギュレータによって展開される構成状態データによって駆動され、制
    御されるマクロ・プログラムによって実行される請求項１に記載のソフトウェア
    開発システム。
51. 【請求項５１】 前記構成状態データが製品メイク・ルーチンに供給され、
    前記製品メイク・ルーチンが機能インクルード・ファイルおよびメイクファイル
    を生成し、その後、製品ビルド・ルーチンが、前記メイクファイルによって制御
    されるコンパイラおよびリンカに、前記ソース・コード・ライブラリおよび前記
    機能インクルード・ファイルからとられるソース・コード要素を、完成した製品
    を定義するビルドされた製品コンポーネントに組み合わせることを行わせる請求
    項５０に記載のソフトウェア開発システム。
52. 【請求項５２】 前記メイクファイルがコンポーネント・メイクファイルお
    よび製品メイクファイルを含む請求項５１に記載のソフトウェア開発システム。
53. 【請求項５３】 製品コンポーネント・リンカが、前記ビルドされた製品コ
    ンポーネントを前記完成した製品に変換する請求項５１に記載のソフトウェア開
    発システム。
54. 【請求項５４】 完成した製品を開発する方法であって、 完成した製品を定義する製品構成データを作ることと、 インターフェースおよび依存性を含む１つまたは複数のオブジェクトを定義す
    るソース・コード要素を含む少なくとも１つのソース・コード・ライブラリを提
    供することと、 前記オブジェクトの性質を定義するディレクティブを提供することと、 前記製品構成データと、前記ディレクティブと、前記ソース・コード・ライブ
    ラリから得られるデータとから構成状態データを展開することと、 グラフィカル・ユーザ・インターフェースを使用し、完成した製品と、欠けて
    いるか選択されたか選択解除されたオブジェクトおよびオプションとを表す構成
    状態データの視覚的論理表現を検査し、完成した製品を調整するコマンドを提供
    することと、 前記構成状態データの制御の下で前記ソース・コード要素から完成した製品を
    生成することと を含む方法。
55. 【請求項５５】 前記オブジェクトに関して少なくとも１つのソース・コー
    ド要素と前記ディレクティブを含むオブジェクト情報データ・セットとを提供す
    ることを含む請求項５４に記載の方法。
56. 【請求項５６】 機能である少なくとも１つのオブジェクトを含むコンポー
    ネントである少なくとも１つのオブジェクトを提供することを含む請求項５４に
    記載の方法。
57. 【請求項５７】 前記インターフェースおよび依存性の少なくともいくつか
    に名前およびクラス指定の両方を割り当てることと、完成した製品の展開の前に
    それらを正しい絶対アドレスに置換することとを含む請求項５４に記載の方法。
58. 【請求項５８】 少なくともいくつかの依存性に関連するデータの一部とし
    て、オブジェクト指定データを割り当てることと、その後、オブジェクト指定デ
    ータに案内されて、同一の識別子を有する他のインターフェースに優先して指定
    されたオブジェクトと共に含まれるソース・コード要素内のインターフェースに
    対応する依存性をリンクすることとを含む請求項５４に記載の方法。
59. 【請求項５９】 ソース・コード要素をＲＡＭフリー環境で走るように指定
    することと、ＲＡＭベースのサブルーチン・スタックの必要なしにサブルーチン
    ・ジャンプおよびリターンをエミュレートする、呼出しまたはジャンプ依存性で
    の修正されたソース・コード要素を生成することとを含む請求項５４に記載の方
    法。
60. 【請求項６０】 対応するインターフェースと共に選択されていないオブジ
    ェクトの存在に依存する依存性に出会った時に、完成した製品に含めるために前
    記オブジェクトを自動的に選択することを含む請求項５４に記載の方法。
61. 【請求項６１】 少なくともいくつかのインターフェースについてインター
    セプト指定を追加することと、他の同一の名前を有するインターフェースに優先
    してインターセプト指定を有するインターフェースに依存性を関連付けることと
    を含む請求項５４に記載の方法。
62. 【請求項６２】 オブジェクトの非選択に起因して対応するインターフェー
    スがない依存性に直面した時に、これがエラー状態でない場合に、ソース・コー
    ド要素から依存性を除去することによってソース・コード要素を修正することを
    含む請求項５４に記載の方法。
63. 【請求項６３】 インターフェースがない依存性に関する視覚的エラー表示
    を、グラフィカル・ユーザ・インターフェースによって知らせることを含む請求
    項５４に記載の方法。
64. 【請求項６４】 別のオブジェクトの選択によってトリガされるあるオブジ
    ェクトの選択を指定することと、別のオブジェクトが選択された時に必ずあるオ
    ブジェクトを選択することとを含む請求項５４に記載の方法。
65. 【請求項６５】 前記ソース・コード要素の少なくともいくつかでリスト要
    素を提供することと、その後、これらのリスト要素を一緒にし、それらを指定さ
    れた点で完成した製品に挿入し、リスト項目参照へのリンクを確立することによ
    って、ソース・コード要素を修正することとを含む請求項５４に記載の方法。
66. 【請求項６６】 いくつかのインターフェースをパブリックであると宣言し
    、すべてのオブジェクトのすべての依存性によってアクセス可能にすることと、
    他のインターフェースをプライベートであると宣言し、同一オブジェクト内の依
    存性によってのみアクセス可能にすることとを含む請求項５４に記載の方法。
67. 【請求項６７】 少なくともいくつかの文字列要素を前記ソース・コード要
    素の少なくともいくつかに追加することと、テキストおよび文字列の言語を定義
    することと、不揮発性メモリに配置される値によって正しい言語文字列を選択で
    きるようにするコードを挿入することとを含む請求項５４に記載の方法。
68. 【請求項６８】 前記製品構成データに、ビルドされるプラットフォームの
    タイプを定義するデータを追加することを含む請求項５４に記載の方法。
69. 【請求項６９】 少なくともいくつかのオーバーライド・データを提供する
    ことと、前記オーバーライド・データに、データ・テーブル内のデータのいくつ
    かの項目を置換させることとを含む請求項５４に記載の方法。
70. 【請求項７０】 アセンブルまたはコンパイルの後に、実行可能コードの別
    々にコンパイルされリンクされたブロックの間でのセグメント内リンクを確立す
    ることを含む請求項５４に記載の方法。
71. 【請求項７１】 前記ソース・コード・ライブラリ内のいくつかのコード要
    素を不揮発性メモリに常駐する予定として指定することと、その後、そのような
    要素の格納のために不揮発性メモリを割り振ることと、システム設計者が不揮発
    性メモリの性質に関心を持つ必要がない形で、プログラムに不揮発性メモリ内の
    そのような変数へのアクセスを与えるのに必要なコードを完成した製品に挿入す
    ることとを含む請求項５４に記載の方法。
72. 【請求項７２】 オブジェクトのソース・コード要素を表示し、修正するの
    に前記グラフィカル・ユーザ・インターフェースを使用することを含む請求項５
    ４に記載の方法。
73. 【請求項７３】 マクロ・ディレクティブを用いてインターフェースおよび
    依存性を識別することと、その後、構成状態データの制御の下でマクロ・プログ
    ラムを実行することによってコード修正を実行することと、ソース・コード要素
    をアセンブルまたはコンパイルし、リンクするのに、標準的なアセンブル、コン
    パイラ、およびリンカを使用することとを含む請求項５４に記載の方法。