ABIは、XPCOMコンポーネントのバイナリインターフェースです。Xなど)を越えて動作させられますが、コンパイルが必要な言語(C++など)で書かれたコンポーネントの場合、異なるプラットフォームで動かすためには再コンパイルが必要です。コンパイルされたXPCOMコンポーネントは多くの場合、「バイナリ」や「ネイティブ」などと呼ばれます。一つのバイナリXPCOMコンポーネントは、すべてのプラットフォームで利用できる.xptファイルと、特定のプラットフォーム用で且つ特定のABIを持ったDLL(Windowsでは.dll、Linuxでは.so)から成ります。このABIを利用するアプリケーションだけが、このXPCOMコンポーネントを利用することができます。簡単に言えば、特定のABI用にビルドされたXPCOMコンポーネントは、同じABI用にビルドされたFirefox、Thunderbird、その他のXULRunnerアプリケーションに対してのみ互換性があります。ABIのネーミング各々のABIは、以下の形式の[TARGET_XPCOM_ABI]文字列によって名付けられています。ABI文字列は、nsIXULRuntimeを使うことによってプログラムから取得できます。ABI文字列を持たず、それを取得しようと試みた際にはNS_ERROR_NOT_AVAILABLEというエラーを起こすでしょう。それは特徴的なABIだと思われますが、しかし私たちはそれに対して付ける名前を持っていません。Platformsこれは利用可能なCPUアーキテクチャやコンパイラのABIの完全なリストではありません。最新の情報は常に、ビルドシステムの中を探索することで見つけられるでしょう。ABIを保持している変数はTARGET_XPCOM_ABIです。(これは内部の詳細情報で、拡張機能の開発者にとっては無関係です。Installationアプリケーション(例:Firefox)がサポートするABIの名前は、ビルド時に埋め込まれます。その後、アプリケーションはサードパーティ製のバイナリXPCOMコンポーネントの互換性を調べるためにその値を使います。互換性チェックとの共通点は、拡張機能のインストールの間にあります。ABIが宣言されているべきです。拡張機能の作者は、XPCOMコンポーネントをサポートしているマシンすべてのためにそれぞれビルド(コンパイル)して、プラットフォームごとのサブディレクトリに入れ、すべてのビルドを一つのXPIの中にパッケージングすることができます。拡張機能がインストールされる時、アプリケーションはそれ自身のABIに最も適したコンポーネントのビルドを選択します。適合するビルドが見つからなければ、その拡張機能は互換性がないと見なされ、アプリケーションはインストールを中断するでしょう。ABIを付けずに)使うべきです。inbox.現在、ニュースレターは英語でのみ提供されています。従って私の個人情報を扱うことに同意します。