(57)【要約】本明細書に記載されているのは、ネイティブコンピューティングプラットフォーム内での非ネイティブプログラムモジュールの動作を実現する技術である。この技術によって、データ構造のパラメータを必要に応じて整列（アライメント、位置あわせ、境界整列ともいう）し、その結果、異なるパラダイムのプログラムモジュールまたはオペレーティングシステムがそれらを使用できるようにする機構が提供される。データ構造のパラメータのデータは、ネイティブパラダイムと一致するように整列される。通常、そのようなデータ構造は、非ネイティブプログラムモジュールおよびネイティブオペレーティングシステム（または他のプログラムモジュール）によって共有される。そのようなデータ構造が、整列され、その結果、そうでなければ整列されず、性能を妨げるデータが、ネイティブプラットフォームによってすばやく簡単にアクセス可能になる。この要約自体は、本特許の範囲を制限することを意図されたものではない。本発明の範囲は、請求項で指摘される。
2005507114.tif 000002
【特許請求の範囲】
【請求項１】
非ネイティブプログラムモジュール用のエミュレータであって、
非ネイティブプログラムモジュールからの呼出しをインターセプトするように構成されたインターセプタと、
パラメータを渡すための非ネイティブプログラムモジュールの非ネイティブパラダイムを、パラメータを渡すためのネイティブ環境のネイティブパラダイムに変換するように構成されたトランスレータと、
前記ネイティブ環境のネイティブパラダイムに従ってパラメータのフォーマットを整列（アライメント）するように構成されたデータアライナと
を含むことを特徴とするエミュレータ。
【請求項２】
前記データアライナが整列するように構成される前記パラメータは、前記ネイティブ環境および前記非ネイティブプログラムモジュールによって共有されるデータ構造の一部であることを特徴とする請求項１に記載のエミュレータ。
【請求項３】
前記トランスレータは、さらに、アドレスを非ネイティブ長さからネイティブ長さに変換するように構成されることを特徴とする請求項１に記載のエミュレータ。
【請求項４】
前記ネイティブ環境の前記ネイティブパラダイムのワードサイズは、非ネイティブプログラムモジュールの非ネイティブパラダイムのワードサイズと異なることを特徴とする請求項１に記載のエミュレータ。
【請求項５】
コンピュータ可読媒体上のオペレーティングシステムであって、
ネイティブプログラムモジュールからの呼出しを受け取るように構成されたネイティブカーネルと、
非ネイティブプログラムモジュールからの呼出しを受け取るように構成された、請求項１に記載のカーネルエミュレータと
を含むことを特徴とするオペレーティングシステム。
【請求項６】
非ネイティブプログラムモジュールおよびネイティブ環境の相互運用性および互換性を促進するデータ整列システムであって、
データ構造のパラメータを検査し、該パラメータがネイティブ環境向けに整列されているかどうかを判定するように構成されたパラメータイグザミナと、
そうでなければ整列されていないパラメータのデータを保持するためのバッファを割り当て、そのパラメータのデータがネイティブ環境向けに整列されるようにするために、そのパラメータのデータをその割り当てられたバッファにコピーするように構成されたパラメータアライナと
含むことを特徴とするシステム。
【請求項７】
前記パラメータは、前記ネイティブ環境および非ネイティブプログラムモジュールによって共有されるデータ構造の一部であることを特徴とする請求項６に記載のシステム。
【請求項８】
データ構造の前記パラメータは、非ネイティブパラダイムからネイティブパラダイムに変換される時に整列されない可能性があるパラメータであることを特徴とする請求項６に記載のシステム。
【請求項９】
前記パラメータアライナは、さらに、
そうでなければ整列されていないパラメータへの呼出しを前記割り当てられたバッファにリダイレクトし、
前記割り当てられたバッファからのデータによって元のパラメータのデータを置換する
ように構成されることを特徴とする請求項６に記載のシステム。
【請求項１０】
非ネイティブプログラムモジュールおよびネイティブ環境の相互運用性および互換性を促進する方法であって、
データ構造のパラメータを検査することと、
そのパラメータがネイティブ環境向けに整列されているかどうかを判定することと、
そのパラメータがそのように整列されていないとの判定に応答して、
そうでなければ整列されていないパラメータのデータを保持するためのバッファを割り当て、
前記データがネイティブ環境向けに整列されるようにするために、前記割り当てられたバッファにそのパラメータのデータをコピーする
ことを行うことと
を含むことを特徴とする方法。
【請求項１１】
前記パラメータが整列されていないとの判定に応答して、さらに、
そうでなければ整列されていないパラメータへの呼出しを前記割り当てられたバッファにリダイレクトすることと、
前記割り当てられたバッファからのデータによって元のパラメータのデータを置換することと
を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記パラメータは、前記ネイティブ環境および非ネイティブプログラムモジュールによって共有されるデータ構造の一部であることを特徴とする請求項１０に記載の方法。
【請求項１３】
データ構造の前記パラメータは、非ネイティブパラダイムからネイティブパラダイムに変換される時に整列されない可能性があるパラメータであることを特徴とする請求項１０に記載の方法。
【請求項１４】
コンピュータによって実行される時に、請求項１０に記載の方法を実行するコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体を含むことを特徴とするコンピュータ。
【請求項１５】
コンピュータによって実行される時に、請求項１０に記載の方法を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項１６】
コンピュータによって実行される時に、請求項１０に記載の方法を実行するコンピュータ実行可能命令を有するコンピュータ可読媒体上で実施されることを特徴とするオペレーティングシステム。
【請求項１７】
コンピュータによって実行される時に、非ネイティブプログラムモジュールおよびネイティブ環境の相互運用性および互換性を促進する方法を実行するコンピュータ実行可能命令を有するコンピュータ可読媒体であって、前記方法が、
データ構造のパラメータを検査することと、
そのパラメータがネイティブ環境向けに整列されているかどうかを判定することと、
そのパラメータがそのように整列されていないとの判定に応答して、
そうでなければ整列されていないパラメータのデータを保持するためのバッファを割り当て、
前記データがネイティブ環境向けに整列されるようにするために、前記割り当てられたバッファにそのパラメータのデータをコピーする
ことを行うことと
を含むことを特徴とするコンピュータ可読媒体。
【請求項１８】
前記方法が、さらに、
そうでなければ整列されていないパラメータへの呼出しを前記割り当てられたバッファにリダイレクトすることと、
前記割り当てられたバッファからのデータによって元のパラメータのデータを置換することと
を含むことを特徴とする請求項１７に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には、ネイティブコンピューティングプラットフォーム内での非ネイティブプログラムコンポーネントの動作を実現する技術に関する。
【背景技術】
【０００２】
特定のコンピューティングプラットフォームで実行されるように設計されたアプリケーションは、異なるコンピューティングプラットフォームで動作しない。一般に、ソフトウェアは、そこで動作するように設計された特定のコンピューティングプラットフォームに、解けないようにリンクされる。たとえば、Ｕｎｉｘ（登録商標）オペレーティングシステムの特定の実施手段が動作するミニコンピュータで動作するように記述され、コンパイルされたソフトウェアは、独自オペレーティングシステムを使用するハンドヘルドコンピュータでは機能しない。
【０００３】
コンピューティングプラットフォームに、通常は、オペレーティングシステム（ＯＳ）およびコンピューティングハードウェアアーキテクチャが含まれる。ＯＳの例には、下記のＭｉｃｒｏｓｏｆｔ（登録商標）社のオペレーティングシステムが含まれる：ＭＳ−ＤＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ、Ｗｉｎｄｏｗｓ（登録商標）２０００、Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）４．０、Ｗｉｎｄｏｗｓ（登録商標）ＭＥ、Ｗｉｎｄｏｗｓ（登録商標）９８、およびＷｉｎｄｏｗｓ（登録商標）９５。コンピューティングハードウェアアーキテクチャの例には、下記のＩｎｔｅｌ（登録商標）社のマイクロプロセッサに関連するハードウェアアーキテクチャが含まれる：８０２８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）ＩＩ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩＩ、およびＩｔａｎｉｕｍ（商標）。
【０００４】
コンピューティングプラットフォームの例に、１６ビットプラットフォーム（Ｍｉｃｒｏｓｏｆｔ（登録商標）ＭＳ−ＤＯＳ（登録商標）およびＩｎｔｅｌ（登録商標）８０２８６など）、３２ビットプラットフォーム（Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）ＮＴ（登録商標）およびＩｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（登録商標）ＩＩなど）、および６４ビットプラットフォーム（Ｉｎｔｅｌ（登録商標）Ｉｔａｎｉｕｍ（商標）など、および、たとえば、Ｗｉｎｄｏｗｓ（登録商標）ＸＰ  ６４−ｂｉｔ  Ｅｄｉｔｉｏｎ）が含まれる。コンピューティングプラットフォームを、プラットフォーム、コンピューティング環境、または環境と呼ぶ場合もある。
【０００５】
アプリケーションの特定のバージョンは、特定のプラットフォームで動作するように設計される。これらのアプリケーションを、その特定のプラットフォームで実行される時に、「ネイティブ」と呼ぶことができる。たとえば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ  ２０００は、３２ビットプラットフォームで動作するように設計されたアプリケーションである。言い換えると、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ（登録商標）２０００は、その３２ビットプラットフォームに関するネイティブアプリケーションである。しかし、この３２ビットアプリケーションを、６４ビットプラットフォームなど、異なるプラットフォームで実行される時に、「非ネイティブ」と呼ぶことができる。
【０００６】
プログラムモジュールターゲットプラットフォーム（または単に「ターゲットプラットフォーム」）の例が、実行可能プログラム（たとえば、プログラムモジュール、アプリケーション、プログラム）が動作することをターゲットにされたプラットフォームである。プログラムモジュールにとって、そのターゲットプラットフォームが、そのネイティブプラットフォームである。たとえば、Ｗｉｎｄｏｗｓ（登録商標）２０００  ３２ビット  Ｘ８６  ＯＳ環境で動作するＭｉｃｒｏｓｏｆｔ（登録商標）Ｏｆｆｉｃｅ（登録商標）アプリケーションをビルドする場合に、そのイメージにとって、ターゲットプラットフォームは３２ビット  Ｘ８６になる。
【０００７】
アプリケーションプログラムは、本明細書で使用される用語「プログラムモジュール」の主要な例である。しかし、用語「プログラムモジュール」には、アプリケーションと分類することができない他の実行可能ソフトウェアが含まれる。
【０００８】
通常のコンピュータアーキテクチャ
通常のコンピュータアーキテクチャは、マルチレイヤ式である。最下部から言うと、コンピュータアーキテクチャには、ハードウェアレイヤ、オペレーティングシステム（ＯＳ）レイヤ、およびアプリケーションレイヤが含まれる。その代わりに、これらのレイヤを、ハードウェアレイヤ、カーネルモードレイヤ、およびユーザモードレイヤとして説明することができる。
【０００９】
図１に、通常のコンピュータアーキテクチャ１００のレイヤを示す。このアーキテクチャの最上部が、ユーザモード１１０である。これには、アプリケーション１１２ａ〜ｅなどのアプリケーションが含まれる。これらのアプリケーションは、ＡＰＩ１２０のセットと通信する。通常、このＡＰＩセットは、ＯＳの一部とみなされ、したがって、コンピューティングプラットフォームの一部である。
【００１０】
このアーキテクチャの次のレイヤが、カーネルモード１３０である。これを、一般にＯＳの「カーネル」と呼ぶことができる。これはＯＳの一部なので、コンピューティングプラットフォームの一部である。
【００１１】
ＯＳのカーネルは、ＯＳの特権部分（privileged part）すなわち、ＯＳの最も信頼されている部分である。これは、コードの内側のレイヤである。カーネルは、通常は、入出力１３２、セキュリティ１３４、ディスプレイ制御（すなわち、スクリーンへのアクセス）１３６、メモリ管理１３８、および他の特権機能１３９を動作させる。カーネルは、デバイスドライバ１４２および他のハードウェアインターフェース１４４を介するハードウェアレイヤ１５０内のハードウェアへの唯一のアクセスを有する。
【００１２】
カーネルＡＰＩ１４０は、カーネル内で、カーネル機能へのアクセスを調整するＡＰＩである。アプリケーションは、通常は、カーネルを直接には呼び出さない。その代わりに、アプリケーションは、ＡＰＩ１２０を呼び出し、ＡＰＩが、カーネル（特にカーネルＡＰＩ１４０）を呼び出す。
【００１３】
図１には、カーネルモード１３０のコンポーネント１３２〜１４４が、その間の接続なしで図示されているが、これらのコンポーネントは、必要に応じて接続される。図を単純明瞭にするために、接続線を図から省略した。
【００１４】
カーネルモード１３０の下に、ハードウェアレイヤ１５０がある。このレイヤには、実際のコンピュータのハードウェアのすべてが含まれる。これには、プロセッサ、メモリ、ディスク入出力、および他の入出力が含まれる。プラットフォームには、ハードウェアレイヤも含まれる。
【００１５】
したがって、コンピューティングプラットフォームには、ハードウェアレイヤ、カーネルレイヤ、および通常はユーザモードＡＰＩ１２０が含まれる。
【００１６】
相互運用性および互換性
アプリケーション互換性は、コンピューティングプラットフォームが進化し始めて以来、長い間主要な問題であった。人々は、あるべき姿として、望みのアプリケーションを自分の選んだプラットフォームで実行することを求める。しかし、現実の世界では、アプリケーションを、それが設計されたものでない異なるホストプラットフォームで実行することは、困難または不可能である。たとえば、３２ビットｘ８６アプリケーションは、６４ビットＩｔａｎｉｕｍ（ＩＡ６４）環境で動作することができない。人々が、以前に使用したものと異なるプラットフォームを有するより強力な機械を購入する時に、問題が悪化する。即座に、古いプラットフォームからのすべてのアプリケーションが、役に立たなくなるのである。
【００１７】
各プラットフォームは、そこで動作するように設計された対応する一連のネイティブアプリケーションを有する。新世代のプラットフォームが公開される時に、ソフトウェア開発者は、一般に、新世代のプラットフォームで動作するように製品をアップグレードする。ソフトウェア開発者は、マーケティング、技術、および経済を含む多数の理由からこれを行う。
【００１８】
同様の理由から、ＯＳ開発者は、製品を後方互換性にすることを好む。このようにして、旧世代のアプリケーションが、ＯＳの最新世代で（したがって、プラットフォームの最新の世代で）動作できるようになる。言い換えると、非ネイティブアプリケーションが、ネイティブプラットフォーム（新しいＯＳを含む）で動作できる場合に、ユーザは、現在のアプリケーションを捨てて新しいバージョンを購入することを強制されないので、新しいＯＳを買う気になる。これによって、ソフトウェア開発者に、アプリケーションのアップグレードを開発する時間が与えられる。
【００１９】
ここで、互換性の例が、ネイティブコンピューティング環境（たとえば、ＯＳ）内で適切に機能し、ネイティブアプリケーションと円滑に共存する非ネイティブプログラムモジュールである。
【００２０】
本明細書で使用される相互運用性の例が、ネイティブと非ネイティブの両方のプログラムモジュールが、リソースを共有すること（互いのメモリ空間または共有メモリ空間内のデータにアクセスするなど）かつ／または一緒に協力して働く能力である。
【００２１】
明瞭単純にするために、例を使用して、非ネイティブアプリケーションの非互換性およびネイティブアプリケーションと非ネイティブアプリケーションの間の非相互運用性の問題を示す。この例では、非ネイティブプログラムモジュールが、３２ビットプラットフォームで動作するように設計されているので、３２ビットアプリケーションと呼ばれる。この例では、ネイティブアプリケーションが、６４ビットであるネイティブプラットフォームで動作するように設計されているので、６４ビットアプリケーションと呼ばれる。これは、１つの例として提供されるのであって、制限ではない。当業者は、ネイティブおよび非ネイティブのアプリケーションならびにネイティブプラットフォームの他の組合せが存在することを理解し、了解している。
【００２２】
ネイティブプラットフォームでの非ネイティブアプリケーションの実行
下記を検討する：ネイティブプラットフォームでの非ネイティブアプリケーションの実行。具体的に言うと、６４ビット環境での３２ビットアプリケーションの実行の例を検討する。この例について、６４ビットプラットフォームが、既存の好評な３２ビットプラットフォーム（その上で３２ビットアプリケーションが動作するように設計される）に対するアップグレードであると仮定する。
【００２３】
コンピュータアーキテクチャで、あるビット数のプラットフォーム（たとえば、３２ビットプラットフォーム）は、通常は、プラットフォームのアドレス可能メモリのワードサイズを指す。通常、ワードは、単一の動作でストレージからプロセッサレジスタに移動されるデータの単位である。過去数十年間の最も一般的なアーキテクチャでは、ワードが、４バイトの長さまたは３２ビットであった。ＩＢＭ社のメインフレームプロセッサおよび標準ＰＣで使用されるＩｎｔｅｌ社のプロセッサの両方で、３２ビットワードが使用されてきた。Ｉｎｔｅｌ社および他社の最近のプロセッサアーキテクチャは、６４ビットワードを備える。
【００２４】
３２ビットプラットフォームに対する６４ビットプラットフォームの長所の１つが、はるかに大きいメモリ空間をアドレッシングできることである。これは、主に、メモリに対するアドレスが、３２ビットプラットフォームの通常の３２ビット長アドレスではなく、６４ビットプラットフォームでは６４ビット長とすることができるからである。
【００２５】
データの整列
整列（Alignment:アライメント、位置あわせ、境界整列ともいう）とは、データを、プラットフォームがより効率的にアクセスするアドレスで、コンピュータメモリの置くことである。通常、これは、データをメモリのワード境界で格納することによって行われる。これは、格納されるデータのサイズが１ワード未満である時には、多少メモリを浪費するという犠牲を払って行われる場合がある。しかし、整列の利益は、速度である。メモリに格納されるデータの整列によって、コンピュータプラットフォームがより効率的に利用されるので、そのようなデータのメモリアクセスが速くなる。
【００２６】
たとえば、現代のＲＩＳＣプラットフォームでは、複数バイトチャンク（multi-byte chunks）、通常は４バイト長または８バイト長でメモリから読み取り、これらのチャンクは、チャンクサイズの倍数のアドレスから始まらなければならない。整列されていないアドレスへのメモリアクセスは、複数の整列されたアクセスによってエミュレートされ、はるかに遅く、あるいは、バスエラーが生成され、プログラムが打ち切られる場合がある。他のプラットフォームでは、整列されていない（すなわちバイト整列された）メモリアクセスが、より優雅であるが、性能が低下する。
【００２７】
当業者は、データの整列と、それを行うことのコストおよび利益に精通している。
【００２８】
ネイティブおよび非ネイティブによって共有されるメモリ
相互運用性および互換性に関する問題の１つが、非ネイティブ（たとえば、３２ビット）アプリケーションとネイティブ（たとえば、６４ビット）アプリケーションの間で共有されるメモリの管理である。もう１つの問題が、非ネイティブ（たとえば、３２ビット）アプリケーションとネイティブ（たとえば、６４ビット）オペレーティングシステムの間で共有されるメモリの管理である。
【００２９】
これは、メモリアドレス整列がネイティブと非ネイティブの間で異なる時に特にそうである。たとえば、すべてのデータが、３２ビット環境で４バイト単位（increments）でメモリ内で整列され、すべてのデータが、８バイト単位で整列される。そのような状況では、非ネイティブアプリケーションのデータが、ネイティブ環境において整列されていない形で格納される可能性がある。
【００３０】
図２に、この点を示す。メモリブロック２１０は、３２ビットワードアドレッシング方式に基づくメモリ構造を表す。太い垂直の線は、ワード境界を表す。符号「Ａ１」から「Ａ８」の６４ビットのデータが、２つのワードサイズのメモリ位置２１２および２１４に格納される。符号「Ｂ１」から「Ｂ４」までの３２ビットデータが、単一のワードサイズのメモリ位置２１６に格納される。
【００３１】
図２では、メモリブロック２３０および２５０が、６４ビットワードアドレッシング方式に基づくメモリ構造であることを表す。やはり、太い垂直の線は、ワード境界を表す。
【００３２】
ブロック２１０のＡ１〜Ａ８データおよびＢ１〜Ｂ４データが、６４ビットメモリアドレッシング方式による使用のために変換される時に、これらのデータを、メモリブロック２３０で示される形で格納し、アドレッシングすることができる。もっと正確にいうと、この形は、整列されていない。しかし、同一のデータを、メモリブロック２５０の整列された形で格納することができる。
【００３３】
したがって、データを整列するかどうかの判断に直面する時に、選択肢の１つは、この問題を無視し、ハードウェアに補償させることである。上で説明し、図２のメモリブロック２３０によって示されるように、ハードウェアは、複数の連続するメモリアドレス位置からオーバーラップするデータにアクセスすることによって、補償することができる。この手法のコストは、メモリからデータにアクセスするのに必要な余分の時間である。この手法は、失われる時間（複数のアクセスの）が許容可能である場合に限って実現可能である。
【００３４】
メモリ内で整列されていないデータについて補償することによって浪費される時間が許容不能になる場合にはどうすればよいのか。
【００３５】
もう１つの問題は、必ず整列を強制する必要があるのかどうかである。時には、整列が自然に行われる。
【発明の開示】
【発明が解決しようとする課題】
【００３６】
本明細書で説明するのは、ネイティブコンピューティングプラットフォーム内での非ネイティブプログラムコンポーネントの動作を実現する技術である。
【課題を解決するための手段】
【００３７】
この技術によって、データ構造のパラメータを必要に応じて整列し、その結果、異なるパラダイムのプログラムモジュールまたはオペレーティングシステムがそれを使用できるようにする機構が提供される。データ構造のパラメータのデータは、ネイティブパラダイムに一致するように整列される。通常、そのようなデータ構造は、非ネイティブプログラムモジュールおよびネイティブオペレーティングシステム（または他のプログラムモジュール）によって共有される。そのようなデータ構造は、整列され、その結果、そうでなければ整列されず、性能を妨げるデータが、ネイティブプラットフォームによってすばやく簡単にアクセス可能になる。
【００３８】
この要約自体は、この特許の範囲を制限することを意図されたものではない。本発明のよりよい理解のために、以下の詳細な説明および請求項を、添付図面と共に参照されたい。本発明の範囲は、請求項で指摘する。
【発明を実施するための最良の形態】
【００３９】
同一の符号は、図面全体を通じて類似する要素および特徴を指すのに使用される。
【００４０】
以下の記述では、本発明の十分な理解を提供するために、説明目的で特定の数、材料、および構成を示している。しかし、本発明を、特定の模範的な詳細説明なしで実践できることは、当業者に明白であろう。他の場合に、本発明の模範的な実施形態の説明を明瞭にし、これによって本発明をよりよく説明するために、周知の特徴を省略し、または単純化する。さらに、理解しやすくするために、ある方法ステップを、別々のステップとして表すが、これらの別々に表されたステップを、その実行に依存する必須の順序と解釈してはならない。
【００４１】
以下の説明では、ネイティブと非ネイティブの共有データ構造体の間のデータ整列の１つまたは複数の典型的実施形態を示す。発明人は、この典型的実施形態を例とすることを意図している。発明人は、この典型的実施形態を、請求される発明の範囲を制限するものとして意図してはいない。そうではなく、発明人は、請求される発明を、他の形で、現在のまたは将来の他の技術と共に実施し、実装することもできることを企図している。
【００４２】
ネイティブと非ネイティブの共有データ構造体の間のデータ整列の実施形態の例を、「典型的なデータアライナ（data  aligner）」と呼ぶことができる。
【００４３】
参照による組込み
米国特許出願書第０９／８４７５３号明細書が、参照によって本明細書に組み込まれる。
【００４４】
序説
本明細書で説明する、典型的なデータアライナの１つまたは複数の典型的実施形態は、ネイティブ／非ネイティブフォーマット変換システム４００および／または図６に示されたものに類似するコンピューティング環境によって（全体的にまたは部分的に）実施することができる。
【００４５】
本明細書に記載の典型的なデータアライナによって、非ネイティブアプリケーションをネイティブプラットフォーム上で透過的かつ効率的に実行できる機構が提供される。たとえば、３２ビットアプリケーションを、典型的なカーネルエミュレータを使用することによって、６４ビットプラットフォームで実行することができる。具体的に言うと、本明細書に記載の典型的なデータアライナによって、異なるプラットフォームのアプリケーションおよび／またはオペレーティングシステム（たとえば、ネイティブおよび非ネイティブ）によって共有されるデータ構造体を必要に応じて整列する機構が提供される。
【００４６】
カーネルエミュレーションの概要
本明細書に記載の典型的なデータアライナは、（たとえば、）カーネルエミュレーション（たとえば、米国特許出願書第０９／８４７５３号明細書参照）の一部として実施することができる。
【００４７】
そのようなカーネルエミュレーション内で、非ネイティブアプリケーションが、その非ネイティブカーネルを有するオペレーティングシステム（ＯＳ）で動作しているかのように振る舞う。その非ネイティブカーネルは、エミュレートされている。非ネイティブカーネルエミュレータによって、非ネイティブアプリケーションによって行われるカーネル呼出しがインターセプトされ、ネイティブカーネル呼出しに変換される。
【００４８】
適切なコンピュータアーキテクチャの例
図３に、典型的なデータアライナを実施するのに適切なコンピュータアーキテクチャ３００の例を示す。当業者は、実施形態に適切である可能性がある他の可能なコンピュータアーキテクチャを理解し、了解している。
【００４９】
このアーキテクチャには、ネイティブプラットフォームが含まれ、このネイティブプラットフォームには、ハードウェア３５０、カーネルモード３３０、およびユーザモード３１０のネイティブＡＰＩ３２０のセットが含まれる。アーキテクチャ３００の最上部が、ユーザモード３１０である。ユーザモード３１０には、アプリケーションが含まれる。具体的に言うと、ユーザモード３１０には、ネイティブアプリケーション（アプリケーション３１２ａ〜ｃなど）および非ネイティブアプリケーション（アプリケーション３１４ａおよび３１４ｂなど）が含まれる。
【００５０】
ネイティブアプリケーションは、ネイティブＡＰＩ３２０のセットと通信する。通常、このネイティブＡＰＩセット３２０は、ネイティブＯＳの一部とみなされ、したがって、ネイティブコンピューティングプラットフォームの一部とみなされる。非ネイティブアプリケーションは、非ネイティブＡＰＩ３２２のセットと通信する。通常、この非ネイティブＡＰＩセット３２２は、非ネイティブＯＳの一部とみなされ、したがって、このセットは、ネイティブコンピューティングプラットフォームの一部ではない。
【００５１】
アーキテクチャ３００の次のレイヤが、ネイティブカーネルモード３３０である。これを、一般に、ネイティブＯＳのネイティブ「カーネル」と呼ぶことができる。これは、ネイティブＯＳの一部なので、ネイティブコンピューティングプラットフォームの一部である。
【００５２】
このネイティブカーネル３３０には、ネイティブカーネルＡＰＩ３４０ならびに、入出力、セキュリティ、ディスプレイ制御（すなわち、スクリーンへのアクセス）、メモリ管理、および他の特権機能などのさまざまなカーネル機能３３３が含まれる。ネイティブカーネル３３０は、デバイスドライバ３４２および他のハードウェアインターフェース３４４を介するハードウェアレイヤ３５０内のハードウェアアへの唯一のアクセスを有する。ネイティブカーネルＡＰＩ３４０は、カーネル内の、カーネル機能へのアクセスを調整するＡＰＩである。
【００５３】
カーネルモード３３０の下に、ハードウェアレイヤ３５０がある。このレイヤには、実際のコンピュータのハードウェアのすべてが含まれる。これには、プロセッサ、メモリ、ディスク入出力、他の入出力などが含まれる。ネイティブプラットフォームには、ハードウェアレイヤも含まれる。
【００５４】
したがって、ネイティブコンピューティングプラットフォームには、ハードウェアレイヤ３５０、カーネルレイヤ３３０、および通常はユーザモードネイティブＡＰＩ３２０が含まれる。ネイティブプラットフォームには、非ネイティブＡＰＩ３２２または非ネイティブカーネルエミュレータ４００は含まれない。
【００５５】
カーネルエミュレータの例
図４に、非ネイティブカーネルエミュレータ４００を示すが、これは、典型的なデータアライナの実施形態を使用することができる典型的なカーネルエミュレータの実施形態である。これには、非ネイティブカーネルＡＰＩのエミュレータ４１０が含まれ、このエミュレータを、非ネイティブＣＰＵシミュレータ（または単に「ＣＰＵシミュレータ」）と呼ぶ場合もある。用語に関する混乱を避けるために、これをＣＰＵシミュレータ４１０と呼ぶ。
【００５６】
ＣＰＵシミュレータ４１０には、非ネイティブＣＰＵ命令セットをネイティブＣＰＵ命令セットに変換するトランスレータ（translator）４１２、非ネイティブワードサイズをネイティブワードサイズに変換するコンバータ４１４、および非ネイティブアプリケーションからアクセス可能なメモリをそのようなアプリケーションがアドレッシングできるメモリに制限するメモリコンストレイナ（memory  constrainer）４１６が含まれる。
【００５７】
非ネイティブアプリケーションによるカーネルへの呼出し
ＣＰＵシミュレータ４１０によって、非ネイティブアプリケーションからのカーネル呼出しが受け取られる。具体的に言うと、ＣＰＵシミュレータ４１０によって、非ネイティブＡＰＩからのカーネル呼出しが受け取られる。
【００５８】
カーネルエミュレータ４００は、カーネルの機能を実行しない。もっと正確に言えば、カーネルエミュレータ４００によって、非ネイティブ呼出しが、その非ネイティブフォーマットからネイティブフォーマットに変換される。次に、カーネルエミュレータ４００によって、変換された呼出しがネイティブカーネルに渡されて、ネイティブカーネルによって、その呼出しがネイティブアプリケーションからのものであるかのように処理される。しかし、これを行うことに、単純な言語の変換以上のものが含まれる可能性がある。これには、非ネイティブプラットフォームとネイティブプラットフォームの間のパラダイム（paradigms）の変換が含まれる場合がある。
【００５９】
トランスレータ４１２によって、命令エミュレーションが実行される。トランスレータ４１２によって、非ネイティブプロセッサの命令セットのエミュレーションが処理される。
【００６０】
コンバータ４１４によって、引数フォーマットおよびワードサイズの両方が管理される。コンバータ４１４によって、引数フォーマットが、非ネイティブからネイティブに変更され、ワードサイズが、非ネイティブからネイティブに変更される。
【００６１】
一緒に、トランスレータ４１２およびコンバータ４１４によって、３２ビットプラットフォームのスタック経由の引数渡しの規約(convention)から６４ビットプラットフォームのレジスタ経由の引数渡しの規約(の変更)が管理される。これは、引数値を渡す方法でのパラダイム変更の例である。ＣＰＵシミュレータ４１０は、トランスレータ４１２によるＣＰＵ命令セットの変換と共に、この変更の原因となる。
【００６２】
もう１つの例では、３２ビットプラットフォームで、ワードサイズが３２ビット長である。したがって、アドレスおよびデータは、通常は、メモリ内の３２ビットサイズのワードに書き込まれる。６４ビットプラットフォームでは、ワードサイズが６４ビット長である。したがって、アドレスおよびデータは、通常は、メモリ内の６４ビットサイズのワードに書き込まれる。
【００６３】
パラメータ（すなわち引数）は、通常は１ワード長である。したがって、６４ビットカーネルＡＰＩのパラメータは、３２ビットカーネルＡＰＩの３２ビット長ではなく、６４ビット長である。
【００６４】
コンバータによって、非ネイティブアプリケーション（およびＡＰＩ）によって渡される３２ビット引数が、３２ビットから６４ビットに引き延ばされる。これを行う方法の例の１つが、引数に３２個の先行０をパディング（padding:つけ足し、詰め込み）することである。典型的な実施形態では、コンバータ４１４が、主にユーザレイヤ内で動作する。
【００６５】
上で述べたように、異なるプラットフォームは、通常は異なるワードサイズを有する。その結果、アドレス可能メモリ空間のサイズも異なる。したがって、コンバータ４１４によって、そのワード変換の一部として、アドレス（具体的にはポインタ）が変換される。
【００６６】
たとえば、３２ビットプラットフォームのメモリアドレスは、３２ビット長までとすることができ、したがって、最大のアドレス可能なメモリは、約４ＧＢである（ビットの１つが予約されている場合には、最大値は約２ＧＢになる）。６４ビットプラットフォームのメモリアドレスは、６４ビット長までとすることができ、したがって、最大のアドレス可能なメモリは、テラバイト単位で評価される。したがって、アドレス可能メモリのサイズが、３２ビットプラットフォームと６４ビットプラットフォームの間で異なる。
【００６７】
ネイティブと非ネイティブの間で共有されるデータ構造体
相互運用性および互換性に関する問題の１つが、非ネイティブ（たとえば、３２ビット）アプリケーションとネイティブ（たとえば、６４ビット）アプリケーションまたはネイティブ（たとえば、６４ビット）オペレーティングシステムの間で共有されるメモリの管理である。具体的に言うと、データ構造体（そのようなメモリに格納される）が、非ネイティブアプリケーションとネイティブアプリケーションまたはネイティブオペレーティングシステムの間で共有される時に、問題がある。
【００６８】
整列
データの整列（アライメント）が、共有データ構造体が問題になる１つの方法である。共有データ構造体のデータが、非ネイティブフォーマットからネイティブフォーマットに変換される時には、メモリ内でデータをコピーし移動するのではなく、ワード境界を再定義することが望ましい。そのようなデータのコピーおよび移動によって、貴重な時間とリソースが消費されるからである。
【００６９】
時々、ネイティブと非ネイティブの間のワードサイズの差が、他方の倍数になる。たとえば、６４ビットワードプラットフォームは、３２ビットワードプラットフォームの倍数である。その結果、ワード境界（単語の境界、語境界）が再定義される時に、そのような境界が、既にそのような倍数である（たとえば、６４ビット長データ）データの間に自然におさまる場合がある。
【００７０】
メモリブロック２１０および２５０とそれに含まれるデータを見れば、読者は、何をそのような自然なワード境界再定義の例とみなすことができるかを理解することができる。言い換えると、ブロック２１０のワード境界（データ構造２１２および２１４ならびにデータＡ１〜Ａ８を含む）が再マッピングされる場合には、これらが、メモリブロック２５０のデータ構造２５２として見えるであろう。そのデータ構造２５２に、整列されたデータ２６２が含まれる。この例では、メモリ境界が、自然に、データが整列されているように収まる。
【００７１】
非整列
逆に言えば、ワード境界が再定義される時に、そのような境界が、データ内に自然に収まる場合には、したがって、データは整列されないままとなる。メモリブロック２１０および２３０とそれに含まれるデータを見ることによって、読者は、どの例を、データが整列されないままのそのような自然なワード境界再定義とみなすことができるかがわかる。言い換えると、ブロック２１０のワード境界（データ構造２１２および２１４とデータＡ１〜Ａ８を含む）が再マッピングされる場合に、これらは、メモリブロック２３０のブロック２３２および２３４にまたがって見えるであろう。このブロック２３２および２３４に、整列されていないデータ２４２が含まれる。この例では、このデータが整列されていないように、メモリ境界が自然に収まる。
【００７２】
整列の動機づけ
したがって、データを整列するかどうかの決断に直面した時に、選択肢の１つは、この問題を無視し、ハードウェアに補償させることである。いくつかの場合に、ハードウェアは、複数の連続するメモリアドレス位置から、オーバーラップするデータにアクセスすることによって補償する。この手法のコストは、メモリからデータにアクセスするのに必要な余分な時間である。この手法は、失われる時間（複数アクセスの）が許容可能である場合に限って実現可能である。
【００７３】
許容可能な非整列コストの例が、Ｉｎｔｅｌ（登録商標）ｘ８６プロセッサの場合である。整列されたデータにアクセスするコストは、１単位の時間（１サイクルなど）であるが、非整列データ（アライメントされていないデータ）にアクセスするコストは、約３単位の時間であった。その結果、Ｉｎｔｅｌ（登録商標）ｘ８６プラットフォーム用に設計されたソフトウェアのプログラマは、性能ヒットが全般的に許容可能なので、データの非整列をなくす動機を与えられなかった。
【００７４】
しかし、整列されたデータのアクセスに高度に最適化されたプラットフォームが存在する。従って、そのプロセスは、非整列データへのアクセスを試みる時に、かなりストール（stall:機能停止）する可能性がある。これは、クラッシュに見える場合がある。そのような場合に、非整列コストは容認し得ないものとなる。
【００７５】
共有不能な非整列コストの例が、Ｉｎｔｅｌ（登録商標）ＩＡ６４プロセッサの場合である。整列されたデータにアクセスするコストは、１単位の時間（１サイクルなど）であるが、非整列データにアクセスするコストは、約１万単位以上の時間である。その結果、Ｉｎｔｅｌ（登録商標）ＩＡ６４プラットフォーム用に設計されるソフトウェアのプログラマが、データの非整列をなくすことができない場合に、完全に許容不能な性能低下が生じる可能性がある。
【００７６】
少なくとも１つの態様で、この典型的なデータアライナによって、ネイティブおよび非ネイティブの両方のアプリケーションおよび／またはオペレーティングシステムによって見られるメモリに格納されるデータの整列が強制される。
【００７７】
データ整列サブシステム
図４からわかるように、非ネイティブカーネルエミュレータ４００には、ネイティブアプリケーションと非ネイティブアプリケーションの間（または非ネイティブアプリケーションとネイティブオペレーティングシステムの間）のデータ整列を調整するデータ整列サブシステム４６０が含まれる。典型的な実施形態で、データ整列サブシステム４６０を、典型的なデータアライナの実施形態とすることができる。
【００７８】
上で述べたように、コンバータ４１４によって、必要に応じてデータ構造のサイズが変更されて、非ネイティブフォーマットからネイティブフォーマットへ（およびその逆へ）変換される。たとえば、ブロック２１０のブロック２１６に、データＢ１〜Ｂ４が含まれる。コンバータによって、これをブロック２５０のブロック２５４に拡大して、データ２６４へ含めることができる。
【００７９】
コンバータ４１４によって、成功裡にデータのサイズを変更することができるが、そのデータが整列されていない場合がある。そのようなデータ構造体（たとえば、ＬＡＲＧＥ＿ＩＮＴＥＧＥＲ）は、ネイティブ環境のために正しいサイズにされる（たとえば、６４ビット）が、ネイティブ環境向けに正しく整列されていない場合がある。その例を、図２のブロック２１０および２３０に示す。整列を強制する選択肢の１つが、データ構造体を新しい位置にコピー（転写）し、整列することである。コピーは、コピーなしよりかなり時間がかかり、データ構造体が、正しく整列されている場合があるので、コピーの前に、データ構造体が整列されているかどうかを判定する方法があった方が望ましい。
【００８０】
データ整列サブシステム４６０によって、データ構造体の特定の事前に識別される型が検査されて、それが整列されているかどうかが判定される。
【００８１】
整列されていない場合に、データ整列サブシステム４６０によって、データ構造体が整列されたメモリブロックにコピーされ、ネイティブ環境では、そのコピーへポイント（指す）される。その共有データ構造体に作用する関数が呼び出された後に、ブロック内のデータが、元の非整列空間にコピーされる。
【００８２】
しかし、データ構造体が整列されている場合には、ネイティブ環境で、オリジナルへポイントされる。
【００８３】
データ整列サブシステム４６０を用いると、データ構造体のタイプが、（ネイティブ環境について）正しいサイズにされるが、整列されていない可能性があると判断される。そのようなデータ構造体の例が、ＬＡＲＧＥ＿ＩＮＴＥＧＥＲである。
【００８４】
典型的データアライナの方法論的実施形態
図５に、カーネルエミュレータ４００（またはその一部）によって実行される典型的なデータアライナの方法論的実施形態を示す。この方法論的実施形態は、ソフトウェア、ハードウェア、またはその組合せで実施することができる。
【００８５】
図５の５１０で、データ整列サブシステム４６０によって、整列されていない可能性があるパラメータを含む特定の事前に識別された型のデータ構造体が監視される。５１２で、サブシステムによって、パラメータが検査されて、そのパラメータが整列されているかどうかが判定される。そうである場合には、処理はブロック５３０に進み、整列は実行されない。整列されていない場合には、処理はブロック５１４に進む。
【００８６】
図５の５１４で、データ整列サブシステム４６０によって、そのパラメータを保持するバッファが再割り当てされる。５１６で、サブシステムによって、パラメータ（およびおそらくはデータ構造体全体）が、整列されたメモリブロックにコピーされる。５１８で、ネイティブ環境は、割り当てられたバッファ内のコピーへポイントされる。共有データ構造体（および、したがって、パラメータ）を使用する可能性がある関数が呼び出された後に、ブロック内のデーが、元の非整列空間にコピーされる（５２０）。この処理は、５２２で終了する。
【００８７】
しかし、データ構造体のパラメータが整列されている場合には、ネイティブ環境は、元のデータへポイントされる（ブロック５３０に示されているように）。
【００８８】
補足的詳細
一般に、カーネルエミュレータ（または同等物）は、非ネイティブアプリケーション（たとえば、３２ビットアプリケーション）が、ディスク上のファイル情報、セキュリティ情報、イベント通知などのアクセスなどのサポートについてネイティブＯＳと通信する必要がある間の実行プロセスを調整する中間レイヤである。その中間レイヤによって、非ネイティブアプリケーション（たとえば、３２ビットアプリケーション）とネイティブＯＳ（たとえば、６４ビットＯＳ）の間でやり取りされる情報を監視することができる。
【００８９】
コールバックフックの問題の処理
時々、非ネイティブアプリケーションによって、システム全体の安定性に影響する可能性があるＯＳ−アプリケーションコールバック（しばしば「フック」と称する）がインストールされる場合がある。フックは、非ネイティブプログラムモジュール内の命令とすることができる。これらの非ネイティブ命令は、ネイティブコードに適用可能でない異なる情報構造（たとえば、関数ポインタ）を有する場合がある。これらは、ネイティブ実行パスから呼び出されるが、ネイティブモジュールは、非ネイティブフックへの呼出しを行っていることを知らない。
【００９０】
非ネイティブフック呼出し内のデータ整列の問題を解決するために、フックが、そのフックが特定のタイプの非ネイティブアプリケーションのためにセットされたことを識別する属性を用いてマーク（印付け）される。この属性は、後に、実行パスによってそのフックを実行できるかどうかを判定するのに使用される（すなわち、フックチェーン（連鎖）が、セットされた属性に基づいてフィルタ処理される）。この形で、非互換の実行パスによって、ある種のフックが処理できなくなる。
【００９１】
時々、エミュレートされた命令によって、カーネル内のネイティブコードが呼び出される場合がある。この呼出しを行っている間に、エミュレートされた命令が、リターンする場所の情報を含むコールバック構造体にも書き込まれる。これらの構造体は、ネイティブ環境およびエミュレートされる環境の間で共有され、非整列データがアクセスされる可能性がある。サンクレイヤ（thunk layer）で、データ整列サブシステム４６０によって、カーネル呼出しを行う前に構造体を再パッチ(repatch)することができる。
【００９２】
共有データ構造体
ネイティブＯＳと実行中のエミュレートされるアプリケーションの間で共有される情報がある場合がある。ネイティブＯＳが、そのような情報があるフォーマットであることを必要とする場合がある。たとえば、その注目情報に、ＯＳが操作する前に８バイトで整列されなければならない関数ポインタが含まれる場合がある。しかし、実行中のアプリケーションはかまわない。というのは、非ネイティブアプリケーション（たとえば、３２ビットアプリケーション）には４バイト整列で十分であるからである。そのシナリオでは、データ整列サブシステム４６０によって、そのような構造体が識別され、ＡＰＩがこの情報をやり取りする時に、これらの共有情報のサンク（thunk）が自動的に生成される。
【００９３】
整列の問題
整列を必要とするデータ型の例が、ＬＡＲＧＥ＿ＩＮＴＥＧＥＲなどのデータ型、メンバとして６４ビット整数を有する共用体(union)、およびユーザモードとＯＳによって共有される共有可能６４ビットポインタである。そのようなデータが正しく整列されていない場合に、性能ペナルティ(performance penalty)に起因して、ＯＳがそのデータを許容しない場合がある。ＯＳは、実行を継続しないことを選択する場合がある。あるいは、より悪い場合に、ＯＳがクラッシュする場合がある。
【００９４】
カーネルエミュレータ側で、データ整列サブシステム４６０が、これらのデータ型を有するか、あるいは構造体のメンバである可能性があるパラメータを監視する。データ整列サブシステム４６０によって、そのような型が見つけられた場合に、整列が検査される。整列されていない場合には、データ整列サブシステム４６０によって、そのパラメータを保持するバッファ（すなわち、割り当てられたバッファ）が再割り当てされ、ＡＰＩ呼出しを行うために渡された最初のバッファを渡すのではなく、再割り当てされたバッファを使用してＯＳ  ＡＰＩ呼出しが行われる。ＯＳ  ＡＰＩが成功裡にリターンする時に、データ整列サブシステム４６０によって、割り当てられたバッファからアプリケーションバッファに出力がコピーされる。
【００９５】
上のシナリオでは、アプリケーションは、ＯＳが構造体へのポインタと解釈できるバッファへのポインタとしてパラメータを渡す場合に、パラメータパッチが機能しない場合がある。その場合には、カーネルエミュレータが、特に、どのＡＰＩがその型のデータを渡すのかを知る必要がある。いくつかの場合に、ＯＳが、ＡＰＩで渡される他のパラメータに依存して、そのバッファをある構造体へのポインタと解釈する場合がある。データ整列サブシステム４６０によって、カーネルエミュレータ内での整列のフィックスアップ（fix-up：世話）を必要とする任意のＡＰＩまたは特定のＡＰＩに適用可能とすることができるあるルールに基づいて、中間命令を生成することができる。
【００９６】
ＬＡＲＧＥ＿ＩＮＴＥＧＥＲの個々のデータに関するルール
データタイプを再整列する方法を示すために、ＬＡＲＧＥ＿ＩＮＴＥＧＥＲの例を示す。このテンプレートから生成される命令は、ネイティブセクションにあり、このテンプレートは、ＬＡＲＧＥ＿ＩＮＴＥＧＥＲを渡すすべてのＡＰＩに適用される。非ネイティブコードは、４バイト整列されたＬＡＲＧＥ＿ＩＮＴＥＧＥＲを渡すことができる。ネイティブセクション内で、データ整列サブシステム４６０によって、そのデータ型のコピーが保たれ、ネイティブ呼出しを行う間は、そのデータ型が渡される。出る途中で、データ整列サブシステム４６０によって、その結果がクライアント空間に戻してコピーされる。
【００９７】
2005507114.tif 000003
【００９８】
いくつかの他のタイプのルール
データの整列されていないコピーを、特定のシナリオについて最適化することができる。たとえば、非ネイティブアプリケーション（たとえば、３２ビットアプリケーション）によって、ＬＡＲＧＥ＿ＩＮＴＥＧＥＲなどの一部のラージデータについて４バイト整列されたデータを有することを保証することができる。８バイト整列位置を必要とするネイティブＯＳ（たとえば、６４ビットＯＳ）でそれをエミュレートする間に、実行に８命令を要する可能性がある未整列部分全体のコピーを行うのではなく、データ整列サブシステム４６０が、下記のように、下記のテンプレートでも使用される２つの命令によってそれを行うことができる。
【００９９】
2005507114.tif 000004
2005507114.tif 000005
【０１００】
ＡＰＩのルール
この例では、ＡＰＩが、別のパラメータによって定義される異なる構造体へのポインタを有することができる。この拡張部子を用いると、型を決定する別のパラメータに基づいてこれらの構造体のサンク処理を行えるようになる。
2005507114.tif 000006
【０１０１】
メンバコピーのルール
構造体をコピーする間に、データ整列サブシステム４６０によって、非整列タグが追加され、その結果、コンパイラによって、正しいコードを生成できるようになり、そのコードは、実行中に、整列フォールト（faults:失敗、誤り）を引き起こさない。
2005507114.tif 000007
【０１０２】
典型的なコンピューティングシステムおよび環境
図６に、本明細書に記載の典型的なデータアライナをその中で実施できる（完全にまたは部分的にのいずれか）適切なコンピューティング環境９００の例を示す。コンピューティング環境９００を、本明細書に記載のコンピュータアーキテクチャおよびネットワークアーキテクチャで使用することができる。
【０１０３】
典型的なコンピューティング環境９００は、コンピューティング環境の１つの例にすぎず、コンピュータアーキテクチャおよびネットワークアーキテクチャの使用または機能性の範囲に関する制限を提案することを意図されたものではない。コンピューティング環境９００を、典型的なコンピューティング環境９００に示されたコンポーネントのいずれか１つまたはその組合せに関する依存性または要件を有すると解釈してもならない。
【０１０４】
典型的なデータアライナは、多数の他の汎用または特殊目的のコンピューティングシステム環境または構成と共に実施することができる。使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例に、パーソナルコンピュータ、サーバコンピュータ、シンクライアント、シッククライアント、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限はされない。
【０１０５】
典型的なデータアライナを、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。典型的なデータアライナは、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境でも実践することができる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置することができる。
【０１０６】
コンピューティング環境９００に、コンピュータ９０２の形の汎用コンピューティングデバイスが含まれる。コンピュータ９０２のコンポーネントに、１つまたは複数のプロセッサまたは処理ユニット９０４、システムメモリ９０６、およびプロセッサ９０４を含むさまざまなシステムコンポーネントをシステムメモリ９０６に結合するシステムバス９０８を含めることができるが、これに制限はされない。
【０１０７】
システムバス９０８は、メモリバスまたはメモリコントローラ、周辺バス、アクセラテテッド・グラフィックス・ポート（accelerated  graphics  port）、およびさまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む、さまざまなタイプのバス構造のいずれかの１つまたは複数を表す。たとえば、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ（ＰＣＩ）バスを含めることができる。
【０１０８】
コンピュータ９０２に、通常は、さまざまなコンピュータ可読媒体が含まれる。そのような媒体は、コンピュータ９０２によってアクセス可能な使用可能な任意の媒体とすることができ、揮発性および不揮発性、取外し可能および取外し不能の両方の媒体が含まれる。
【０１０９】
システムメモリ９０６には、ランダムアクセスメモリ（ＲＡＭ）９１０などの揮発性メモリ、および／または読取専用メモリ（ＲＯＭ）９１２などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。起動中などにコンピュータ９０２内の要素の間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）９１４が、ＲＯＭ９１２に格納される。ＲＡＭ９１０には、通常は、処理ユニット９０４から即座にアクセス可能かつ／または処理ユニット９０４によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。
【０１１０】
コンピュータ９０２に、他の取外し可能／取外し不能の揮発性／不揮発性のコンピュータ記憶媒体を含めることもできる。たとえば、図６に、取外し不能不揮発性磁気媒体（図示せず）から読み取り、それに書き込むハードディスクドライブ９１６、取外し可能不揮発性磁気ディスク９２０（たとえば、「フロッピディスク」）から読み取り、それに書き込む磁気ディスクドライブ９１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光学媒体などの取外し可能不揮発性光ディスク９２４から読み取り、それに書き込む光ディスクドライブ９２２を示す。ハードディスクドライブ９１６、磁気ディスクドライブ９１８、および光ディスクドライブ９２２は、それぞれ、１つまたは複数のデータ媒体インターフェース９２６を介してシステムバス９０８に接続される。代替案では、ハードディスクドライブ９１６、磁気ディスクドライブ９１８、および光ディスクドライブ９２２を、１つまたは複数のインターフェース（図示せず）によってシステムバス９０８に接続することができる。
【０１１１】
ディスクドライブおよびそれに関連するコンピュータ可読媒体によって、コンピュータ９０２のコンピュータ可読命令、データ構造体、プログラムモジュール、および他のデータの不揮発性ストレージがもたらされる。この例には、ハードディスク９１６、取外し可能磁気ディスク９２０、および取外し可能光ディスク９２４が図示されているが、磁気カセットまたは他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、電気的消去可能読取専用メモリ（ＥＥＰＲＯＭ）、および類似物など、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ可読媒体も、典型的なコンピューティングシステムおよび環境の実施に使用できることを了解されたい。
【０１１２】
たとえば、オペレーティングシステム９２６、１つまたは複数のアプリケーションプログラム９２８、他のプログラムモジュール９３０、およびプログラムデータ９３２を含む、任意の個数のプログラムモジュールを、ハードディスク９１６、磁気ディスク９２０、光ディスク９２４、ＲＯＭ９１２、および／またはＲＡＭ９１０に格納することができる。そのようなオペレーティングシステム９２６、１つまたは複数のアプリケーションプログラム９２８、他のプログラムモジュール９３０、およびプログラムデータ９３２のそれぞれ（またはこれらの組合せ）に、インターセプタ、呼出しコンバータ、引数コンバータ、トランスレータ、共有メモリマネージャ、命令トランスレータ、アドレストランスレータ、データアライナ、およびターゲットプラットホームデターミナ（ｔａｒｇｅｔ−ｐｌａｔｆｏｒｍ  ｄｅｔｅｒｍｉｎｅｒ）の実施形態を含めることができる。
【０１１３】
ユーザは、キーボード９３４およびポインティングデバイス９３６（たとえば、「マウス」）などの入力デバイスを介してコンピュータ９０２にコマンドおよび情報を入力することができる。他の入力デバイス９３８（具体的には図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、シリアルポート、スキャナ、および／または類似物を含めることができる。上記および他の入力デバイスは、システムバス９０８に結合された入出力インターフェース９４０を介して処理ユニット９０４に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。
【０１１４】
モニタ９４２または他のタイプのディスプレイデバイスも、ビデオアダプタ９４４などのインターフェースを介してシステムバス９０８に接続することができる。モニタ９４２の他に、他の出力周辺デバイスに、入出力インターフェース９４０を介してコンピュータ９０２に接続できるスピーカ（図示せず）およびプリンタ９４６などのコンポーネントを含めることができる。
【０１１５】
コンピュータ９０２は、リモートコンピューティングデバイス９４８などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。たとえば、リモートコンピューティングデバイス９４８は、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイスまたは他の一般的なネットワークノード、および類似物とすることができる。リモートコンピューティングデバイス９４８は、コンピュータ９０２に関して本明細書で説明した要素および特徴の多くまたはすべてを含めることができるポータブルコンピュータとして図示されている。
【０１１６】
コンピュータ９０２とリモートコンピュータ９４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）９５０および一般的なワイドエリアネットワーク（ＷＡＮ）９５２として図示されている。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【０１１７】
ＬＡＮネットワーキング環境で実施される場合に、コンピュータ９０２は、ネットワークインターフェースまたはネットワークアダプタ９５４を介してローカルネットワーク９５０に接続される。ＷＡＮネットワーキング環境で実施される場合に、コンピュータ９０２に、通常は、ワイドネットワーク９５２を介する通信を確立する、モデム９５６または他の手段が含まれる。モデム９５６は、コンピュータ９０２の内蔵または外付けとすることができるが、入出力インターフェース９４０または他の適切な機構を介してシステムバス９０８に接続することができる。図示のネットワーク接続が、典型的であり、コンピュータ９０２と９４８の間で通信リンクを確立する他の手段を使用できることを了解されたい。
【０１１８】
コンピューティング環境９００によって示されるものなどのネットワーク化された環境では、コンピュータ９０２に関して示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに格納することができる。たとえば、リモートアプリケーションプログラム９５８が、リモートコンピュータ９４８のメモリデバイスに常駐する。例示のために、アプリケーションプログラムおよびオペレーティングシステムなどの他の実行可能プログラムコンポーネントが、図では別個のブロックとして示されているが、そのようなプログラムおよびコンポーネントが、さまざまな時にコンピューティングデバイス９０２の異なる記憶コンポーネントに常駐し、コンピュータのデータプロセッサによって実行されることを了解されたい。
【０１１９】
コンピュータ実行可能命令
典型的なデータアライナの実施形態を、プログラムモジュールなど、１つまたは複数のコンピュータまたは他のデバイスによって実行されるコンピュータ実行可能命令の全体的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などが含まれる。通常、プログラムモジュールの機能性は、さまざまな実施形態で望みに応じて組み合わせるか分散することができる。
【０１２０】
典型的なオペレーティング環境
図６に、典型的なデータアライナを実施できる適切なコンピューティング環境９００の例を示す。具体的に言うと、本明細書に記載の典型的なデータアライナは、（全体的にまたは部分的に）図６のプログラムモジュール９２８〜９３０および／またはオペレーティングシステム９２６あるいはその一部によって実施することができる。
【０１２１】
オペレーティング環境は、適切なオペレーティング環境の例にすぎず、本明細書に記載の典型的なデータアライナの機能性の範囲または使用に関する制限を提案することを意図されたものではない。使用に適切である他の周知のコンピューティングシステム、環境、および／または構成に、パーソナルコンピュータ（ＰＣ）、サーバコンピュータ、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブル家庭電化製品、無線電話機、無線機器、汎用機器、特殊目的機器、特定用途向け集積回路（ＡＳＩＣ）、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限はされない。
【０１２２】
コンピュータ可読媒体
典型的なデータアライナ（データ整列ソフト）の実施形態を、ある形のコンピュータ可読媒体に格納するか、それによって送信することができる。コンピュータ可読媒体は、コンピュータによってアクセスできるすべての使用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体に、「コンピュータ記憶媒体」および「通信媒体」が含まれる。
【０１２３】
「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージの方法または技術で実施された、揮発性および不揮発性の、取外し可能および取り外し不能の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは、所望の情報を格納でき、コンピュータによってアクセス可能な他のすべての媒体が含まれるが、これに制限はされない。
【０１２４】
「通信媒体」によって、通常は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが、搬送波または他のトランスポート機構などの変調されたデータ信号で実施される。通信媒体に、情報配布媒体も含まれる。
【０１２５】
用語「変調されたデータ信号」は、信号内で情報をエンコードする形でその特性の１つまたは複数をセットされるか変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれる。
【０１２６】
結論
構造的特徴および／または方法ステップに言葉依存で本発明を説明したが、請求項で定義される発明が、説明された特定の特徴またはステップに必ずしも制限されないことを理解されたい。そうではなく、特定の特徴およびステップは、請求される発明を実施する好ましい形態として開示されたものである。
【図面の簡単な説明】
【０１２７】
【図１】コンピューティングアーキテクチャを示す概略ブロック図である。
【図２】ネイティブと非ネイティブのメモリブロックを示す図である。
【図３】本明細書に記載の実施形態に適するコンピューティングアーキテクチャを示す概略ブロック図である。
【図４】本明細書に記載の実施形態に適するカーネルエミュレータを示す概略ブロック図である。
【図５】本明細書に記載の方法実施形態を示す流れ図である。
【図６】本明細書に記載の実施形態を実施する（全体的にまたは部分的に）ことができるコンピューティングオペレーティング環境の例を示す図である。
【図１】
2005507114.tif 000008
【図２】
2005507114.tif 000009
【図３】
2005507114.tif 000010
【図４】
2005507114.tif 000011
【図５】
2005507114.tif 000012
【図６】
2005507114.tif 000013
【国際公開パンフレット】
2005507114.tif 000014
2005507114.tif 000015
2005507114.tif 000016
2005507114.tif 000017
2005507114.tif 000018
2005507114.tif 000019
2005507114.tif 000020
2005507114.tif 000021
2005507114.tif 000022
2005507114.tif 000023
2005507114.tif 000024
2005507114.tif 000025
2005507114.tif 000026
2005507114.tif 000027
2005507114.tif 000028
2005507114.tif 000029
2005507114.tif 000030
2005507114.tif 000031
2005507114.tif 000032
2005507114.tif 000033
2005507114.tif 000034
2005507114.tif 000035
2005507114.tif 000036
2005507114.tif 000037
2005507114.tif 000038
2005507114.tif 000039
2005507114.tif 000040
2005507114.tif 000041
2005507114.tif 000042
2005507114.tif 000043
2005507114.tif 000044
2005507114.tif 000045
2005507114.tif 000046
2005507114.tif 000047
2005507114.tif 000048
2005507114.tif 000049
2005507114.tif 000050
2005507114.tif 000051
2005507114.tif 000052
2005507114.tif 000053
2005507114.tif 000054
2005507114.tif 000055
2005507114.tif 000056
2005507114.tif 000057
【国際調査報告】
2005507114.tif 000058
2005507114.tif 000059
2005507114.tif 000060