JP4601665B2 - 条件付で実行可能モジュールを縮小するシステムおよび方法 - Google Patents

Description

本発明の実施例は、概ねコードイメージファイルのフォーマット化に関し、詳しくは、イメージをフラッシュメモリ内に格納する前に、共通のヘッダにおける不要なフィールドを削除することにより、フラッシュメモリに格納されるコードイメージファイルの長さを削減する（縮小する）ことに関する。

バイナリコードイメージを記憶装置に格納する目的でフォーマットしかつ圧縮する様々なマシンが存在する。この場合、バイナリコードイメージは、一般的に、実行ファイルイメージであるか、または、パソコンやファームウエア、あるいは、タスクを実行するためにコンピュータプログラムが用いられる処理システムなどにおいて実行できるイメージである。プロセッサで実行されるイメージは、標準形式でなければならない。それによって、ターゲットプロセッサファームウエアは、そのイメージがフラッシュメモリから実行できるか、メモリにロードできるか、または、他のやり方で実行できることを認識する。実行ファイルイメージに使用される既存のパソコンシステムにおける共通基準は、ポータブルで実行可能な共通のオブジェクトファイルフォーマット（ＰＥ／ＣＯＦＦ）スペックであり、Microsoft Portable Executable and Common Object File Format Specification、 Revision 6.0、という１９９９年２月にマイクロソフト社から出されたものである。これは、ワールドワイド・ウェブhttp://www.microsoft.com/whdc/hwdev/hardware/PECOFF.mspxで確認することもできる。このフォーマットがポータブルなのは、フォーマット化されたファイルが異なるターゲットで実行できるように意図されて作られているからである。例えば、ＰＥ／ＣＯＦＦイメージは、ウィンドウズＸＰ環境とＷＩＮ／ＣＥ環境とのどちらでも実行可能であろう。ターゲットプロセッサは、ＰＥ／ＣＯＦＦフォーマットを認識しさえすれば、ＰＥ／ＣＯＦＦフォーマット化されたイメージを実行することができる。

異なるプラットフォームで実行するためには、ＰＥ／ＣＯＦＦイメージは、使用する可能性のあるターゲットプラットフォームおよびオペレーティングシステムに関する特定の情報を含んでいなくてはならない。そして、ＰＥ／ＣＯＦＦイメージ内の情報すべてが、使用する可能性のあるターゲットプラットフォームに関連するとも限らない。すべてのフィールドがすべてのプラットフォームに適用できるわけではない。

例えば、ＰＥ／ＣＯＦＦイメージは、デバイスドライバであるかもしれない。デバイスドライバは、フラッシュメモリの中にある場合もある。記憶装置の有効スペースを節約するためには、フラッシュメモリ内のデバイスドライバのサイズは縮小されることが望ましい。既存のシステムでのスペース節約方法は、イメージ内容の圧縮に限定されている場合が多い。あるケースでは、ヘッダを含むイメージファイル全体が圧縮される。

デバイスドライバイメージは、通常、多数のコンピューティングプラットフォームで利用可能であるように開発される。実行可能ファイルは、ベンダの構成および開発／維持コストを削減する。そのイメージのヘッダは、おそらくポインタまたは仮想アドレスがあれば、別々のモジュール、または、ルーチンが異なるプラットフォームでも利用できることを示すことができるだろう。実行可能ファイルの中には、フラッシュメモリの実アドレスから実行されなければならないものもある。例えば、これらの実行ファイルは、ＸＩＰ(eXecute In Place)と称し、移動させることはできない。他に、メモリに移動させることができる実行ファイルもある。この情報は、ＰＥ／ＣＯＦＦイメージ自体に含まれていてよい。

既存のシステムでは、ＰＥ／ＣＯＦＦイメージは、多数のプラットフォームに送られ、ターゲットプラットフォームのフラッシュメモリ内にロードされる。イメージのタイプがＸＩＰの場合、そのイメージはフラッシュメモリから実行されるべきなので、フラッシュメモリ上では圧縮できない。したがって、フラッシュメモリにある情報は、直接実行可能な命令とならなければならない。フラッシュメモリにロードされる前に圧縮されるイメージもある。関連技術の中には、フラッシュメモリに書き込む前に実行可能なイメージを圧縮する様々な既知の方法がある。
なお、本出願に対応する外国の特許出願においては下記の文献が発見または提出されている。
米国特許第４３８９７０６号明細書 米国特許第５１１３４９４号明細書 米国特許第５８４１９７９号明細書 米国特許第５８８９９６１号明細書 米国特許第５９２３８７８号明細書 米国特許第６２７２２５２号明細書 米国特許第６３８５５６７号明細書 米国特許第６６５４９５４号明細書 米国特許第６８４５１３０号明細書 米国特許第７１９７７１１号明細書 米国特許出願公開第２００１／０００８０２３号明細書 米国特許出願公開第２００３／０００９７４７号明細書 米国特許出願公開第２００２／００３４１０５号明細書 米国特許出願公開第２００２／００６９３４２号明細書 米国特許出願公開第２００３／０２２３４９１号明細書 米国特許出願公開第２００４／００８８７０１号明細書 米国特許出願公開第２００４／０２２６００４号明細書 米国特許出願公開第２００５／０１３２３５６号明細書 Knowledgerush-Bitmask. [oneline]. Retrieved from the Internet: <URL: http://www.knowledgerush.com/kr/encyclopedia/Bitmask>. Peter Johnson. How to detect the types of executable files (3pages). [online]. [Posted at http://www.delphidabbler.com/ on August 29, 2003]. Retrieved from the Internet: <http://www.delphidabbler.com/>

本発明の実施例に従う、ＰＥ／ＣＯＦＦイメージを表わし、かつ、イメージヘッダを縮小する典型的な方法を示すブロック図である。

本発明の実施例に従う、部分的に縮小または最適化されたＰＥ／ＣＯＦＦセクションヘッダを表わすブロック図である。

図２のセクションヘッダはそれらのデフォルト形式かまたは最適化されているかを示す表である。

本発明の実施例を用いて節約されたスペースを示す。

本発明の実施例に従う、縮小または最適化されたＰＥ／ＣＯＦＦイメージを用いる典型的な方法を示すフローチャートである。

本発明の実施例に従う、プルーニングされたコードイメージファイルを再構築するための典型的なシステムを示すブロック図である。

本発明の特徴及び利点は、以下の詳細な説明から明らかになるであろう。

本発明の実施例は、実行可能なイメージを縮小または最適化することに関連し、その結果、記憶空間の節約をもたらすシステムおよび方法を含む。少なくとも１つの実施例において、本発明は、ターゲットプラットフォームのフラッシュメモリに格納する前に、不要なフィールドまたは情報を実行可能なイメージヘッダから削除することを目的とする。ターゲットプラットフォームにとって無関係な情報を削除することにより、実行ファイルがフラッシュメモリ内で占めるスペースを少なくすることができる。イメージは、ロードされるとき、最適化されたヘッダ情報に基づき変換される。一実施例では、イメージは、さらに既知の方法で圧縮されることにより、スペースをとらないようにされる。

本発明において、明細書中の「１つの実施例」または「一実施例」は、実施例に関連して記載された特定の機能、構造、または、特徴が、本発明の少なくとも１つの実施例に含まれることを意味する。したがって、明細書中を通じて随所に見られる「一実施例では」という言い回しは、必ずしも同じ実施例を指すものではない。

実行可能なイメージのサイズを縮小するための方法には様々なものがある。説明を簡単にする目的で、以下の実施例ではＰＥ／ＣＯＦＦイメージを例にとって述べる。ここに記載するシステムおよび方法は、ＥＬＦイメージまたはＭａｃｈ−Ｏ形式のイメージなど、他のイメージ形式でも用いられることは、当業者にとっては明らかである。ＥＬＦ（Executable and Linking Format）は、Ｌｉｎｕｘオペレーティングシステムで利用でき、元々はユニックス・システムズ・ラボラトリーズで開発されたものである。ＥＬＦについてのさらなる情報は、Ｌｉｎｕｘマニュアル参照ページhttp://www.gsp.com/cgi-in/man.cgi?section=5&topic=elf.で確認することができる。Mach-Ｏ形式は、アップルコンピュータのオペレーティングシステムで用いられている。Mach-Ｏ形式のさらなる情報は、Ｍａｃｈ−Ｏランタイムアーキテクチャ、第３章、ォーマットリファレンス、アップルコンピュータ、２００３年８月７日
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/).
で確認することができる。

本発明および方法の実施例は、実行可能なイメージを効率的にプルーニングすることにより、イメージサイズを縮小することができる。本発明の実施例は、圧縮されたアイテムを元の状態に復元するといった圧縮とは異なる。縮小される実行ファイルは、カスタマイズされたやり方で縮小され、ターゲットプラットフォームとは無関係ないくつかのデータまたはフィールドが削除される。プルーニングされた後のイメージは、さらに既知の方法を用いて圧縮されることもできる。

本発明の実施例は、フラッシュメモリにロードする前に、実行可能なイメージからイメージ内容を削除することができる。不要なデータが削除され、利用可能なイメージのサブセットがターゲットプラットフォームの基準として定義される。定義されたサブセットは、イメージを圧縮しかつロードするために用いられる。その結果、イメージが小さくなり、記憶装置のスペースの節約につながる。開示されたシステムおよび方法の実施例は、既存の圧縮技術に追加することもできる。さらに、開示されたシステムおよび方法は、すでに圧縮されたイメージに適用することもできる。

図面、特に図１は、ＰＥ／ＣＯＦＦイメージを表わす。ＰＥ／ＣＯＦＦイメージは、ＣＯＦＦヘッダ１１０、ＰＥヘッダ１２０、セクションヘッダ１６０、および、イメージ内容１８０を表わす。一実施例では、ＣＯＦＦヘッダ１１０は、ｍａｃｈｉｎｅ １１１、ＮｕｍｂｅｒｏｆＳｅｃｔｉｏｎｓ １１２、ＴｉｍｅＤａｔｅＳｔａｍｐ １１３、ＰｔｒＴｏＳｙｍｂｏｌ １１４、ＮｕｍＳｙｍｂｏｌｓ １１５、ＳｉｚｅＰＥＨｄｒ １１６、および、Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ １１７の７つのフィールド（２０バイト）を有する。以下の表１は、ＰＥ／ＣＯＦＦスペックに従うＣＯＦＦヘッダにおける各フィールドのオフセットおよび長さを示す。２０バイトの７つのフィールドでは、ターゲットプラットフォームは、８バイトのみを用いるｍａｃｈｉｎｅ １１１、ＮｕｍｂｅｒｏｆＳｅｃｔｉｏｎｓ １１２、ＳｉｚｅＰＥＨｄｒ １１６、および、Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ １１７へのアクセスだけを必要とする場合もある。ＰＥヘッダ１２０の最後のアドレスオフセットは、ＰＥヘッダのサイズを特定するＣＯＦＦヘッダ１１０における値、すなわち、オフセット１６のＳｉｚｅＰＥＨｄｒ１１６により決定される。セクションヘッダ１６０のサイズは、ＣＯＦＦヘッダのオフセット２の１６ビット値（すなわちＮｕｍｂｅｒｏｆＳｅｃｔｉｏｎｓ１１２）であり得るセクション数をそれらのセクションの長さで乗じることにより決定されることができる。この例では、デフォルトセクションは、４０バイト長である。

この例では、ＰＥヘッダ１２０は、以下のフールドを含む：Ｓｉｇｎａｔｕｒｅ１２１、ＭａｊｏｒＶｅｒｓｉｏｎ１２２、ＭｉｎｏｒＶｅｒｓｉｏｎ１２３、ＳｉｚｅＯｆＣｏｄｅ１２４、ＳｉｚｅＯｆＩｎｉｔｄＤａｔａ１２５、ＳｉｚｅＯｆＵｎＩｎｉｔｄＤａｔａ１２６、ＥｎｔｒｙＰｏｉｎｔ１２７、ＢａｓｅＯｆＣｏｄｅ１２８、ＢａｓｅＯｆＤａｔａ１２９、ＩｍａｇｅＢａｓｅ１３０、ＳｅｃｔｉｏｎＡｌｉｇｎｍｅｎｔ１３１、ＦｉｌｅＡｌｉｇｎｍｅｎｔ１３２、ＭａｊｏｒＯＳＶｅｒｓｉｏｎ１３３、ＭｉｎｏｒＯＳＶｅｒｓｉｏｎ１３４、ＭａｊｏｒＩｍａｇｅＶｅｒｓｉｏｎ１３５、ＭｉｎｏｒＩｍａｇｅＶｅｒｓｉｏｎ１３６、ＭａｊｏｒＳｕｂＶｅｒｓｉｏｎ１３７、ＭｉｎｏｒＳｕｂＶｅｒｓｉｏｎ１３８、Ｗｉｎ３２Ｖｅｒｓｉｏｎ１３９、ＩｍａｇｅＳｉｚｅ１４０、ＨｅａｄｅｒＳｉｚｅ１４１、ＣｈｅｃｋＳｕｍ１４２、Ｓｕｂｓｙｓｔｅｍ１４３、ＤｌｌＣｈａｒ１４４、ＳｔａｃｋＲｅｓｅｒｖｅＳｚ１４５、ＳｔａｃｋＣｏｍｍｉｔＳｚ１４６、ＨｅａｐＲｅｓｅｒｖｅＳｚ１４７、ＨｅａｐＣｏｍｍｉｔＳｚ１４８、ＬｏａｄｅｒＦｌａｇｓ１４９、および、ＮｕｍｂｅｒＯｆＲＶＡＳｚ１５０。この例では、ＰＥヘッダ１２０は、１０８バイトを含む。いくつかのプラットフォームでは、ＰＥヘッダ１２０の、Ｓｉｇｎａｔｕｒｅ１２１、ＳｉｚｅＯｆＣｏｄｅ１２４、ＥｎｔｒｙＰｏｉｎｔ１２７、ＢａｓｅＯｆＣｏｄｅ１２８、ＩｍａｇｅＢａｓｅ１３０、および、Ｓｕｂｓｙｓｔｅｍ１４３の２２バイトのみが必要とされる。したがって、ＰＥヘッダは、８６バイトから２２バイトに減らすことができる。

この例では、セクションヘッダ１６０は、各セクションごとに１つずつ、以下の多くのフィールドのセットを含む：Ｎａｍｅ１６１、Ｖｉｒｔｓｉｚｅ１６２、ＶｉｒＡｄｄｒ１６３、ＲａｗＤａｔａＳｚ１６４、ＰｏｉｎｔｅｒｔｏＲａｗＤａｔａ１６５、ＰｏｉｎｔｅｒｔｏＲｅｌｏｃａｔｉｏｎｓ１６６、ＰｏｉｎｔｅｒｔｏＬｉｎｅＮｕｍｓ１６７、ＮｕｍｏｆＲｅｌｏｃｓ１６８、ＮｕｍｏｆＬｉｎｅＮｕｍｓ１６９、および、Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ１７０（合計４０バイト）。いくつかのプラットフォームでは、Ｎａｍｅ１６１、ＲａｗＤａｔａＳｚ１６４、ＰｏｉｎｔｅｒｔｏＲａｗＤａｔａ１６５、ＰｏｉｎｔｅｒｔｏＲｅｌｏｃａｔｉｏｎｓ１６６、および、ＮｕｍｏｆＲｅｌｏｃｓ１６８の合計２１バイトのフィールドのみが使用される。フィールド名は、３２セクション、すなわち１つのオーバーヘッドバイトおよびデータの３２ビットを考慮して予め割り当てられてられることもできる。したがって、未使用のフィールドを削除すると、セクションあたり１９バイト節約できることになる。

一実施例では、第１番目のセクションヘッダは、常にネームフィールドである。多くのケースでは、第１番目のセクションは、０値になる（通常は無効な）第１のバイトを示し、残りの４バイトは、３２ビットマスクとなり、そのセクションは、そうでないセクションと比べ最適化／縮小される。また、第１番目のセクションを最適化しないこともできる。その場合、第１番目のセクションは、０である第１のバイトを持たない。言い換えれば、ネームフィールドは、ＰＥ／ＣＯＦＦスペックに適合し、その中に何らかの実際のネームをもつ８バイトのフィールドである。この状況では、最適化される次のセクションヘッダは、残りのセクションの状態を表わす指標となり、次のセクションヘッダは、ネームフィールド（５バイト）を有するようになる。この場合、第１番目のｎセクションヘッダは最適化されず、ｎ＋１のセクションヘッダは、ネームフィールドにビットマスクを有するようになる。ネームフィールドのセクションヘッダに一旦マスクが現れると、次に最適化されるセクションヘッダにネームフィールドを有している必要はもはやない。いくつかの実施例では、すべてのセクションヘッダで一貫したネームフィールドを用いることもできる。本明細書においては、使用されるバイト、および、必要なフィールドは、例示目的のみで用いられている。他のシステムでは、ヘッダの異なる形式を使用するか、または、異なるフィールドを必要とする場合もある。

図２は、４つのセクション２１０、２２０、２３０、および、２４０を有するイメージにおける不要なフィールドを削除するべく縮小されるＰＥ／ＣＯＦＦセクションヘッダを示す。この例では、セクションヘッダ１、３、および、４（２１０、２３０、および、２４０）は最適化されるかまたは縮小される。セクションヘッダ２は、フォーマット基準により定義されたデフォルトフィールドを使用する。図２に示すように、セクション１（２１０）は、ネームフィールド１６１を含むが、セクション３および４（２３０および２４０）は、ネームフィールド１６１を含まない。最適化されたセクションヘッダのそれぞれは、さらに、図１で示したような４つのフィールド１６４、１６５、１６６、および、１６８を含む。ネームフィールド１６１は、以下により詳細に説明するような特別に重要な意味をもつ。

一実施例では、ネームフィールド１６１は、第１のセクションヘッダ２１０で使用される。そして、どのセクションヘッダが最適化され、また、そのセクションヘッダが完全なデフォルトフォーマットを使用するかを識別する。図３は、以降のセクションを最適化するかまたは縮小するか、あるいは、デフォルトフォーマットを使用するかを定義する表３００を示す。例えば、一実施例では、イメージは、１−ｎのｎ個のセクションを有する。第１のセクション３０１は、最適化される。第２のセクション３０３は、デフォルトフォーマットを使用する。第３および第４のセクション（３０５および３０７）は、最適化され、その結果、第ｎのセクション３０９もうまく最適化する。いくつかの実施例では、この表は、マスクワードで実行することもでき、１ビット（１ｂ）は、セクションが最適化されることを示し、かつ、０ビット（０ｂ）は、セクションがデフォルトフォーマットを使用することを示す。このマスクまたはヘッダは、イメージファイルにプリペンドされているか、または、イメージ内の既知の他の予め決められたオフセットに配置されていてもよい。例えば、イメージ内の未使用のフィールド、すなわち、ネームフィールド１６１に配置してもよい。この例では、図３に示すようなセクション１−４は、１０１１ｂで表わされ、ここでは、第１のセクション３０１に対して最下位ビットが用いられる。

「最適化」という用語は、イメージがロードされるプラットフォームによって決まる特定の意味をもつ。イメージを処理した後、それをメモリにロードするエージェントまたはリコンストラクタがあってもよい。エージェントは、このビットマスクに基づき、セクションを翻訳する。したがって、セクションが最適化されると、エージェントは、バイトがいくつあってどのフィールドがセクションで使用されるのかがわかるようになる。一実施例では、セクション１（３０１）のネームフィールド１６１は、図３の表を格納するためのビットマップとして用いられる。その結果、エージェントは、イメージファイルにさらにオーバヘッドをかけることなく、デフォルトセクションおよび最適化されるセクションを識別することができる。例えば、ゼロバイトから始まるネームフィールド１６１は、最適化表を格納するために使用されたネームフィールドとして翻訳されてもよい。第１のバイトが０でない場合、エージェントは、イメージをデフォルト／レガシーフォーマットとして読み込む。

既存のシステムでは、ＰＥ／ＣＯＦＦイメージ中に１６セクション以上あることはあまりない。したがって、最適化テーブルを保持するべくネームフィールド１６１を使用する実施例では、マスク情報を伝達するのには２バイトしか必要としない。ＰＥ／ＣＯＦＦスペックでは、ネームフィールドは８バイトとして定義される。一実施例では、３２セクションまでを考慮に入れて表には４バイト用意されている。したがって、ネームフィールドには５バイトだけ使用される。一実施例では、第１のバイトは、このフィールドが表として使用されるか、４バイトが表に使用されるか、ネームフィールドの残りの３バイトは他の目的でも使用できるかまたは削除されるのかを示すフラグとなる。

図４を参照すると、処理済みのＰＥ／ＣＯＦＦイメージ４００が表わされている。一実施例では、ＰＥ／ＣＯＦＦヘッダは、１２９バイト（図１参照）から３０バイト（４０１）にまで引き下げられている。セクションヘッダ領域４０３は、４０＊ｎバイトから２１＊ｎバイトにまで引き下げられている（ｎは、セクション数を示す）。一見するとスペースの節約がそう重要なこととは思われないかもしれないが、フラッシュメモリは、多数のイメージを含むことがある。フラッシュメモリにロードされる多くのイメージに対しスペースの節約が有効であれば、追加のイメージのためにより多くのスペースが利用できるようになるか、または、フラッシュカードのサイズを縮小することもできる。スペースの節約は、各プラットフォームが異なるフィールドセットを必要とするような、ターゲットプラットフォームによっても変わることがある。ＥＬＦおよびＭａｃｈ−Ｏなど、ＰＥ／ＣＯＦＦ以外のイメージフォーマットのスペースの節約も、フォーマットおよびターゲットプラットフォームによって変わる。

図５は、開示されたシステムおよび方法の実施例を用いてのスペース節約を表わすフラッシュメモリを示す。一実施例によれば、処理５１０の前と処理５２０の後に全体のフラッシュイメージが表われる。処理５１０なしのフラッシュイメージは、ＸＩＰコード専用の６５５３６バイト５１１と、非ＸＩＰコード専用の４５８７５２バイト５１３とを含む。本発明の実施例によれば、ラッシュメモリで処理されたイメージでは、ＸＩＰイメージは、圧縮されないが、プルーニングされることはできる。したがって、従来の方法は、イメージのこの領域に６５５３６バイト必要であるが、プルーニングされるかまたは最適化されたＸＩＰ領域は、６１１８０バイト５２１ですむようになる。同様に、この例では、非ＸＩＰコードは、従来のフォーマットを用いて４５８７５２バイト５１３必要である場合もあるが、プルーニング後は、４５０４０３バイト５２３だけで足りるようになる。従来の方法では、ＸＩＰコードが圧縮できないと、スペースの節約もできない点に注意すべきである。

図６を参照すると、本実施例に従う、処理されるかまたはプルーニングされたイメージをロードする典型的な方法６００を表わすフローチャートが示されている。ブートまたはシステムの電源オンと同時に、実行可能なイメージがフラッシュメモリからロードされる（ブロック６０１）。ブロック６０３において、ファームウェアモジュールがフラッシュメモリから取り出されるかどうかの決定がなされる。何も取り出されない場合、ブロック６０３においてファームウェアモジュールがフラッシュメモリから取り出されるべきかどうかの決定がなされるまで、ブロック６０５において通常のオペレーションでの処理が続けられる。

フラッシュメモリからファームウェアモジュールが取り出された場合、イメージ／モジュールを格納するため、ブロック６０７において十分な大きさのメモリバッファが割り当てられる。イメージのサイズは、そのイメージに格納されており、プルーニングがされていなければ、そのサイズがＰＥヘッダに格納される。プルーニングされていないイメージに対しては、そのイメージサイズはＰＥヘッダから決定されるか、または、デフォルトまたは最適化情報から計算される。ブロック６０９において先頭ヘッダファイルが再構築される。典型的なＰＥ／ＣＯＦＦイメージでは、オリジナルＰＥおよびＣＯＦＦヘッダがシード情報により再構築され、プルーニングされた情報のギャップを満たす。言い換えれば、イメージがメモリにあるときにオリジナルサイズのヘッダが再構築されると、そのイメージは、データが全くプルーニングされていない場合と同じだけのスペースをとる。それによって、レガシーソフトウェアは、イメージを読み取ることができる。いくつかの実施例では、ＰＥ／ＣＯＦＦ（または他のフォーマット）ヘッダは、プルーニングされるが、セクションヘッダデータは一部分だけプルーニングされるかまたは全くプルーニングされない。

一実施例では、第１のセクションヘッダは、最適化（プルーニング）マスクによりネームフィールドをオーバーロードする。ブロック６１１において、イメージがプルーニングされているかの決定がなされる。この例では、この決定は、第１のセクションのネームフィールドを見てなされる。第１のバイトがゼロの場合、イメージはプルーニングされており、マスクは、ネームフィールド内にある。 ネームフィールドの第１のバイトがゼロでない場合、イメージはデフォルトフォーマットになり、１セクションずつ従来のやり方でロードされることもできる。イメージファイルがプルーニングされていない場合、ブロック６１３において、第１のセクションヘッダは、割り当てられたメモリバッファにコピーされる。ブロック６１５で決定されたように、より多くのセクションヘッダがロードされた場合、処理はブロック６１１へと続き、ブロック６１３において、次のセクションヘッダがメモリにコピーされる。ブロック６１１においてなされた決定は、一回だけ行われ、その後フラグはセクションヘッダを通じてルーピングするべく設定され得ることは、当業者にとって明らかである。フローチャート６００におけるループ（６１１、６１３、６１５）は例示にすぎず、他の様々なやり方で実行することもできる。

ブロック６１１で示すように、イメージがプルーニングされている場合、一実施例では、次の４バイトがビットマスクとして用いられ、ブロック６１９において、各ヘッダが最適化されているか、または、デフォルトフォーマットであるかどうかが決定される。ブロック６２１では、現在のセクションヘッダがビットマスクにおいて識別された最適化ヘッダどうかが決定される。そうでない場合、ブロック６２５において、セクションヘッダは、割り当てられたメモリにコピーされ、処理は、次のセクションヘッダへと続く。

セクションヘッダは、最適化またはプルーニングされている場合には再構築されなくてはならない。完全なイメージ形式を予測するレガシープログラムと適合するべく、ブロック６２３において、セクションヘッダが再構築される。フィールドの残りは、ＰＥ／ＣＯＦＦなどのイメージ形式で定義されたオフセットに対応する位置に移動される。プルーニングまたは削除されたフィールドは、シードデータで満たされるか、または、ブランクのまま、オリジナルファイル形式のそのフィールドのオフセット位置にコピーされる。したがって、再構築されたセクションヘッダは、レガシーソフトウェアに適合すべくデフォルトフォーマットで現れるようになる。シードフィールド（前にプルーニングされている）は、ターゲットプラットフォームには必要ないと定義され、それらのフィールドのいずれのデータも無視される。すべてのセクションが割り当てられたメモリにコピーされるまで処理は続けられる。

すべてのセクションヘッダが一旦メモリにロードされると、ブロック６１７において、イメージファイルの残りがメモリにロードされる。表示され得る追加イメージをロードすべく、ブロック６０３において処理が続けられる。

イメージがＸＩＰであれば、メインメモリにはロードされず、フラッシュメモリから直接実行されなければならない。一般的に、ＸＩＰファイルはフラッシュメモリから実行されるものであるが、通常特にポータブルではないので、正確な互換性は必要とされない。大抵、それらは、システム初期化のごく早期に使用され、プラットフォームが一旦資源豊富な状態になってしまえば、すなわち、メモリが見つけられ使用されているときは、参照されない。ＸＩＰイメージをどのように扱うかは、実施形態によって特有である。

図７を参照すると、プルーニングされたコードイメージファイルを再構築する典型的なシステム７００が示されている。一実施例では、プロセッサ７０１は、システムメモリ７０３を有し、フラッシュメモリ７０５に有効に結合される。プレブート間の様々な時間において、フラッシュメモリからコードイメージファイル７１５を取り出す必要がある場合もある。一実施例では、フラッシュメモリ７０５内には、１つまたはそれ以上のコードイメージファイル７１５が存在する。コードイメージファイルは、先に述べたような方法に従いプルーニングまたは縮小されているプルーニングイメージファイル７１５ｂであってよく、あるいは、コードイメージファイルは、オリジナルコードイメージファイル７１５ａであってよい。コードイメージファイル７１５は、プルーニングの有無に関わらず、圧縮されてよい。コードイメージ７１５ｂがプルーニングされている場合、ＢＩＯＳ７１１は、プルーニングされたイメージ７１５ｂのヘッダを再構築すべく、イメージリコンストラクタ７２１に制御を移管してよい。再構築されたコードイメージ７１３は、レガシーコードで処理されることができる形式でシステムメモリ７０３内に配置される。ここでは、レガシーコードは、イメージが最初からプルーニングされていたことを必ずしもわかっていなくてよい。オリジナルイメージからプルーニングされたデータはどれもこのターゲットプラットフォームにとっては必要でないため、レガシーコードは、再構築されたイメージを処理することができる。

ここで説明する技術は、特定のハードウェアまたはソフトウェア構成に制限されるものではなく、あらゆるコンピュータ、一般電子機器、または、処理環境においても適用性を見出すことができる。
また、ここで説明する技術は、ハードウェア、ソフトウェア、または、それらの組合せにおいても実施できる。さらに、モバイルまたはステーショナリコンピュータ、パーソナル携帯情報機器、セットトップボックス、携帯電話、ポケットベル、一般電子機器（ＤＶＤプレーヤ、パーソナル・ビデオレコーダ、パーソナル・ビデオプレーヤ、衛星受信機、ステレオレシーバ、ケーブルＴＶ受信機を含む）、および、プロセッサ、プロセッサにより読み取り可能な記憶媒体（揮発および不揮発メモリ、および／または記憶素子など）、少なくとも１つの入力デバイス、および、１つまたはそれ以上の入力デバイスを含む他の電子機器においても実施できる。プログラムコードは、入力デバイスを用いて入力されたデータに適用されることにより、記述された関数を実行し、かつ、出力情報を生成する。出力情報は、１つまたは他の出力デバイスに適用されることもできる。本発明がマルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ、個別の一般電子機器など様々なシステム構成により実施できることは当業者にとって明らかなことである。本発明はまた、通信ネットワークを介し接続される遠隔処理装置により実行できる分散コンピューティング環境においても実施可能である。

各プログラムが、高度なプロシージャまたはオブジェクト指向プログラミング言語で実行されることにより、処理システムとの通信が実現する。また、必要であれば、プログラムはアセンブリまたはマシン言語で実行することもできる。いずれの場合でも、言語はコンパイルまたは翻訳されることができる。

プログラム命令を用いることにより、命令によりプログラムされた汎用または専用処理システムは、本明細書中に記載された動作を実行することができる。一方で、動作は、それらを実行するためのハードワイヤードロジックを含む特定のハードウェアコンポーネント、または、プログラムされたコンピュータ要素とカスタムハードウェアコンポーネントとの組合せにより実行することもできる。本明細書中に記載された方法は、処理システムをプログラムするよう用いることができる命令を格納したマシンアクセス可能な媒体を含むコンピュータプログラム製品、または、方法を実行する他の電子デバイスとして提供することもできる。ここで使用した「マシンアクセス可能な媒体」という用語は、マシンで実行するための命令シーケンスを格納またはエンコードすることが可能であり、また、マシンが本明細書中に記載された方法のいずれか１つを実行できるようにする媒体を当然含む。したがって、「マシンアクセス可能な媒体」とは、固体メモリ、光磁気ディスク、および、データ信号をエンコードする搬送波も当然含むが、これに制限されるものではない。さらに、プログラム、手順、プロセス、アプリケーション、モジュール、ロジック、などいずれの形にせよ、ソフトウェアが動作を起こすまたは結果を生じさせるように説明するのは技術的に一般的なことである。このような表現は、処理システムでソフトウェアを実行することにより、プロセッサに結果を生じる動作を行わせるということを分かりやすく説明する１つの手法に過ぎない。

以上、本発明の一側面を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることができる。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

Claims (13)

1. ターゲットプラットフォームで実行可能なイメージファイルをブート時にフラッシュメモリからロードする方法であって、当該イメージファイルは、使用する可能性のあるターゲットプラットフォームに関する情報を格納可能な少なくとも１つのセクションヘッダを有しており、
   前記イメージファイルの所定のフィールドが、当該イメージファイルがプルーニングされているかどうかを示す値と、前記少なくとも１つのセクションヘッダのそれぞれがプルーニングされているかどうかを示すビットマスクとを格納し、
   前記プルーニングとは、前記イメージファイルを実行する前記ターゲットプラットフォームと無関係なデータまたはフィールドを前記セクションヘッダから削除することであり、
   前記イメージファイルを保持するために十分なサイズのメモリバッファを割り当てる段階と、
   前記イメージファイルの前記所定のフィールドに格納された前記値に基づいて、当該イメージファイルがプルーニングされているかどうかを決定する段階と、
   前記ブート時に、前記イメージファイルが有する前記セクションヘッダを前記メモリバッファにロードする段階と、
   を含み、
   前記ロードする段階は、
   前記少なくとも１つのセクションヘッダのいずれかがプルーニングされていれば、プルーニングされる前のセクションヘッダのサイズと同じスペースを確保すべく、前記ビットマスクに基づいて、前記プルーニングされたセクションヘッダを予め定められたデータで満たすかまたはブランクのままとすることにより、データが削除されたセクションヘッダを再構築し、かつ、該再構築されたセクションヘッダを前記メモリバッファにロードすることと、
   前記少なくとも１つのセクションヘッダのいずれかがプルーニングされていない場合、当該プルーニングされていないセクションヘッダを前記メモリバッファにロードすることと、を含む、方法。
2. 前記所定のフィールドは、前記少なくとも１つのセクションヘッダの第１番目のセクションヘッダの先頭のフィールドである、請求項１に記載の方法。
3. 前記ロードする段階は、
   前記メモリバッファに前記イメージファイルの内容をロードすること、
   をさらに含む、請求項１または２に記載の方法。
4. 前記イメージファイルの内容は、前記メモリバッファへロードされずに、前記フラッシュメモリから直接実行される、請求項１または２に記載の方法。
5. 前記イメージファイルの前記内容は圧縮される、請求項３または４に記載の方法。
6. ターゲットプラットフォームで実行可能なイメージファイルをブート時にフラッシュメモリからロードする命令を含むマシンアクセス可能なプログラムであって、当該イメージファイルは、使用する可能性のあるターゲットプラットフォームに関する情報を格納可能な少なくとも１つのセクションヘッダを有しており、
   前記イメージファイルの所定のフィールドが、当該イメージファイルがプルーニングされているかどうかを示す値と、前記少なくとも１つのセクションヘッダのそれぞれがプルーニングされているかどうかを示すビットマスクとを格納し、
   前記プルーニングとは、前記イメージファイルを実行する前記ターゲットプラットフォームと無関係なデータまたはフィールドを前記セクションヘッダから削除することであり、
   前記命令によりマシンに、
   前記イメージファイルを保持するために十分なサイズのメモリバッファを割り当てることと、
   前記イメージファイルの前記所定のフィールドに格納された前記値に基づいて、当該イメージファイルがプルーニングされているかどうかを決定することと、
   前記ブート時に、前記イメージファイルが有する前記セクションヘッダを前記メモリバッファにロードすることと、
   を実行させ、
   前記イメージファイルをロードするための命令により前記マシンに、
   前記少なくとも１つのセクションヘッダのいずれかがプルーニングされていれば、プルーニングされる前のセクションヘッダのサイズと同じスペースを確保すべく、前記ビットマスクに基づいて、前記プルーニングされたセクションヘッダを予め定められたデータで満たすか、またはブランクのままとすることをさらに実行させることにより、データが削除されたセクションヘッダを再構築し、かつ、該再構築されたセクションヘッダを前記メモリバッファにロードすること、
   前記少なくとも１つのセクションヘッダのいずれかがプルーニングされていない場合、当該プルーニングされていないセクションヘッダを前記メモリバッファにロードすること、
   をさらに実行させる、プログラム。
7. 前記所定のフィールドは、前記少なくとも１つのセクションヘッダの第１番目のセクションヘッダの先頭のフィールドである、請求項６に記載のプログラム。
8. 前記イメージファイルにロードされた命令により、前記マシンに、
   前記メモリバッファに前記イメージファイルの内容をロードすること、
   をさらに実行させる、請求項６または７に記載のプログラム。
9. 前記イメージファイルの内容は、前記メモリバッファへロードされずに、前記フラッシュメモリから直接実行される、請求項６または７に記載のプログラム。
10. 前記イメージファイルの前記内容は圧縮される、請求項８または９に記載のプログラム。
11. ターゲットプラットフォームで実行可能なイメージファイルをブート時にフラッシュメモリからロードするためのシステムであって、当該イメージファイルは、使用する可能性のあるターゲットプラットフォームに関する情報を格納可能な少なくとも１つのセクションヘッダを有しており、
    前記イメージファイルの所定のフィールドに、当該イメージファイルがプルーニングされているかどうかを示す値と、前記少なくとも１つのセクションヘッダのそれぞれがプルーニングされているかどうかを示すビットマスクと格納し、
    前記プルーニングとは、前記イメージファイルを実行する前記ターゲットプラットフォームと無関係なデータまたはフィールドを前記セクションヘッダから削除することであり、
    前記ターゲットプラットフォームにおけるプロセッサであって、システムメモリを有し、かつ、前記イメージファイルを格納するフラッシュメモリと有効に結合されるプロセッサと、
    プルーニングされたイメージファイルを再構築し、かつ、該再構築されたイメージファイルを前記システムメモリにロードするリコンストラクタと、
    を含み、
    前記リコンストラクタは、
    当該イメージファイルの前記所定のフィールドに格納された前記値に基づいて、当該イメージファイルがプルーニングされているかどうかを決定し、
    前記少なくとも１つセクションヘッダのいずれかがプルーニングされていれば、前記ビットマスクに基づいて、プルーニングされる前のセクションヘッダのサイズと同じスペースを確保すべく、前記プルーニングされたセクションヘッダを予め定められたデータで満たすかまたはブランクのままとすることにより、データが削除されたセクションヘッダを再構築し、かつ該再構築されたセクションヘッダを前記システムメモリにロードし、
    前記少なくとも１つのセクションヘッダのいずれかがプルーニングされていない場合、当該プルーニングされていないセクションヘッダを前記システムメモリにロードする、システム。
12. 前記フラッシュメモリに格納された前記イメージファイルは、前記ターゲットプラットフォームに適合するフォーマットにプルーニングされている、請求項１１に記載のシステム。
13. 前記リコンストラクタは、前記再構築されたセクションヘッダを前記システムメモリにロードする場合に、前記プルーニングされたセクションヘッダを、予め定められたデータで満たすかまたはブランクのままとし、再構築された前記セクションヘッダが前記システムメモリに一旦ロードされると、該セクションヘッダは、オリジナルのセクションヘッダからプルーニングされたものではないように動作する、請求項１１または１２に記載のシステム。

Images