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

Abstract

【課題】本発明の実施例は、実行可能な画像を縮小または最適化することに関するシステムおよび方法が結果として記憶空間の節約をもたらすことである。
【解決手段】少なくとも１つの実施例において、本発明は、実行可能な画像をターゲットプラットフォームのフラッシュメモリに格納する前に、該画像から不要なフィールドまたは情報を削除する。
ターゲットプラットフォームには関係ない情報を削除することにより、実行可能な画像がフラッシュメモリ上でとるスペースを少なくできる。画像はロード時に最適化されたヘッダ情報に基づき翻訳される。一実施例では、画像がさらに既知の方法で圧縮されることにより、さらなるスペースの節約をもたらす。他の実施例も記載され、クレームされる。
【選択図】図１

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)と称し、移動させることはできない。他に、メモリに移動させることができる実行ファイルもある。この情報は、ＰＥ／ＣＯＦＦ画像自体に含まれていてよい。

既存のシステムでは、ＰＥ／ＣＯＦＦ画像は、多数のプラットフォームに送られ、ターゲットプラットフォームのフラッシュメモリ内にロードされる。画像のタイプがＸＩＰの場合、その画像はフラッシュメモリから実行されるべきなので、フラッシュメモリ上では圧縮できない。したがって、フラッシュメモリにある情報は、直接実行可能な命令とならなければならない。フラッシュメモリにロードされる前に圧縮される画像もある。関連技術の中には、フラッシュメモリに書き込む前に実行可能な画像を圧縮する様々な既知の方法がある。

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

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

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

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

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

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

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

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

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

実行可能な画像のサイズを縮小するための方法には様々なものがある。説明を簡単にする目的で、以下の実施例ではＰＥ／ＣＯＦＦ画像を例にとって述べる。ここに記載するシステムおよび方法は、ＥＬＦ画像またはＭａｃｈ−Ｏ形式の画像など、他の画像形式でも用いられることは、当業者にとっては明らかである。ＥＬＦ（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 (21)

1. 画像をロードする方法であって、
   十分なサイズのメモリバッファを割り当てることにより、実行可能な画像ファイルを保持する段階と、
   前記画像ファイルがプルーニングされているかどうかを決定する段階と、
   前記画像を実行すべく前記メモリバッファにロードする段階と、
   を含む、方法。
2. 前記画像ファイルをロードする段階は、
   該画像ファイルに対応する各セクションヘッダに対し、
   前記画像ファイルがプルーニングされていた場合、
   現在のセクションヘッダがプルーニングされているかどうかを決定することと、もしされてされていれば、前記プルーニングされた現在のセクションヘッダから現在の標準フォーマットセクションヘッダを再構築し、かつ、該再構築されたセクションヘッダを前記メモリバッフにロードすることと、 前記現在のセクションヘッダがプルーニングされていない場合、 前記現在のセクションヘッダを前記メモリバッファにロードすることと、
   前記画像ファイルがプルーニングされていない場合、前記各セクションヘッダを前記メモリバッファにロードすることと、
   をさらに含む、請求項１に記載の方法。
3. 前記画像ファイルがプルーニングされているかどうかを決定する段階は、
   ビットマスクを取り出すことと、
   前記画像ファイルに対応する複数のセクションヘッダを識別し、かつ、前記ビットマスクを用いて前記各識別されたセクションヘッダがプルーニングされているかどうかを決定することと、
   をさらに含む、請求項１に記載の方法。
4. 前記ビットマスクは、前記画像ファイルに対応する前記複数のセクションヘッダの第１のセクションヘッダのネームフィールドに配置される、請求項３に記載の方法。
5. 前記画像ファイルをロードする段階は、
   前記メモリバッファに複数のセクションヘッダをロードすることと、
   前記メモリバッファに前記画像の内容をロードすることと、
   をさらに含む、請求項１に記載の方法。
6. 前記メモリバッファにロードされた前記複数のセクションヘッダのそれぞれは、デフォルトフォーマットセクションヘッダおよび再構築されたセクションヘッダの１つを含む、請求項５に記載の方法。
7. 前記画像内容は、ｅＸｅｃｕｔｅ Ｉｎ Ｐｌａｃｅ(ＸＩＰ)コードとして識別される、請求項５に記載の方法。
8. 前記画像内容は圧縮される、請求項５に記載の方法。
9. 前記画像ファイルは、第１のターゲットプラットフォームの第１の予め決められたフォーマットにプルーニングされ、また、第２のターゲットプラットフォームの第２の予め決められたフォーマットにプルーニングされる、請求項１に記載の方法。
10. 画像ファイルをロードする命令を含むマシンアクセス可能な媒体であって、前記命令によりマシンは、
    十分なサイズのメモリバッファを割り当てることにより、実行可能な画像ファイルを保持することと、
    前記画像ファイルがプルーニングされているかどうかを決定することと、
    前記画像ファイルを実行すべく前記メモリバッファにロードすることと、
    を実行する、マシンアクセス可能な媒体。
11. 前記画像ファイルをロードするための命令によりマシンは、
    前記画像ファイルに対応する各セクションヘッダに対し、
    前記画像がプルーニングされている場合、
    現在のセクションヘッダがプルーニングされているかどうかを決定することと、
    そうであれば、前記プルーニングされた現在のセクションヘッダから現在の標準フォーマットセクションヘッダを再構築し、かつ、前記現在のセクションヘッダがプルーニングされていなければ、前記現在のセクションヘッダを前記メモリバッファにロードすることと、
    前記画像ファイルがプルーニングされていなければ、前記各セクションヘッダを前記メモリバッファにロードすることと、
    をさらに実行する、請求項１０に記載の媒体。
12. 前記画像ファイルがプルーニングされているかどうかを決定するための命令により、前記マシンは、
    ビットマスクを取り出すことと、
    前記画像ファイルに対応する複数のセクションヘッダを識別し、かつ、前記ビットマスクを使用して前記各識別されたセクションヘッダがプルーニングされているかどうかを決定することと、
    をさらに実行する、請求項１０に記載の媒体。
13. 前記ビットマスクは、前記画像ファイルに対応する前記複数のセクションヘッダの第１のセクションヘッダのネームフィールドに配置される、請求項１２に記載の媒体。
14. 前記画像ファイルにロードされた命令により、前記マシンは、
    前記メモリバッファに複数のセクションヘッダをロードすることと、
    前記メモリバッファに前記画像の内容をロードすることと、
    をさらに実行する、請求項１０に記載の媒体。
15. 前記メモリバッファにロードされる前記複数のセクションヘッダのそれぞれは、デフォルトフォーマットセクションヘッダ、および、再構築されたセクションヘッダの１つを含む、請求項１４に記載の媒体。
16. 前記画像内容は、ｅＸｅｃｕｔｅ Ｉｎ Ｐｌａｃｅ(ＸＩＰ)コードとして識別される、請求項１４に記載の媒体。
17. 前記画像内容は圧縮される、請求項１４に記載の媒体。
18. 画像ファイルをロードするためのシステムであって、
    ターゲットプラットフォームにおけるプロセッサであって、システムメモリを有し、かつ、フラッシュメモリデバイスと有効に結合されるプロセッサと、
    前記フラッシュメモリデバイスに格納される少なくとも１つの実行可能な画像ファイルと、
    プルーニングされた画像ファイルを再構築し、かつ、該再構築された画像ファイルをシステムメモリにロードするリコンストラクタと、
    を含むシステム。
19. 前記リコンストラクタは、前記少なくとも１つの実行可能なファイルのそれぞれがプルーニングされているかどうかを決定し、もしされていれば、該プルーニングされた実行可能ファイルに対応するセクションヘッダがプルーニングされているかを決定し、セクションヘッダがプルーニングされていれば、該プルーニングされたセクションヘッダをターゲットプラットフォームに適合するフォーマットで再構築する、請求項１８に記載のシステム。
20. 前記フラッシュメモリデバイスに格納された実行可能な画像の少なくとも１つの実行可能な画像ファイルは、前記ターゲットプラットフォームに適合するフォーマットにプルーニングされている、請求項１８に記載のシステム。
21. 再構築された画像ファイルがシステムメモリに一旦ロードされると、該画像ファイルは、オリジナル画像ファイルからプルーニングされたものではないように動作する、請求項１８に記載のシステム。

Images