プログラミング言語をOSランタイムとどのように統合するか
たとえば、Objective-C、SwiftおよびRuby（つまりRubyMotion））は、Cocoaフレームワークと統合されます。
これはリンクされたライブラリを介して行われますか？単にいくつかの共通のインターフェースを再作成するのではなく、既存のバイナリーの関数を呼び出すと思います。
多くの異なる方法で、簡単に数パラに減らすことはできません。抽象化の大まかな昇順でいくつか示します。
- OSは1つ以上の特権命令（trap、syscallなど）を実装します。コンパイラーは、特定の言語構造をそれらの命令に変換するためのコードを発行します。 [ASM]
- OSは、特定のターゲット言語の外部インターフェースと互換性のある形式でAPIを提供します（通常、個別にコンパイルされた翻訳単位を呼び出すためのメカニズムを提供するもの）。 OSへの呼び出しは、ユーザーコードへの呼び出しと区別できません。 [C]
- OSは、特定のさまざまなターゲット言語の外部インターフェイスとの互換性を目的とした形式でバインディングレイヤーを提供します。 OSの呼び出しは、ユーザーコードの呼び出しに似ています。 [C++、多く]
- OSは、さまざまな言語から呼び出すことができるように設計された形式でAPIを実装しますが、バインディングレイヤーとともにネイティブではありません。このメカニズムは、ユーザーコードの呼び出しにも使用できます。 [VB、COM]
- OSは、そのサービスに直接アクセスする代わりに、幅広い機能を備えた「フレームワーク」を提供します。コンパイラは通常、フレームワークへの特権アクセスを提供するだけでなく、ユーザーコードと区別できない呼び出しを許可します。 [C＃、Java、Objective-C *]
これらのメカニズムは階層化されていることがよくあります。上位層のコールは、舞台裏の下位層のコールに変換されます。 Objective-Cは、2つの異なるAPIメカニズムを提供するという点で奇妙なものです。
物理的な展開レベルでは、サービスは次の方法で提供できます。
- 生成されたコードはOSに直接「トラップ」し、多くの場合マクロとして提供されます。
- OSライブラリコードは静的にリンクされ（LIB）、多くの場合「ヘッダー」ファイルとして提供されます。
- OSライブラリコードは、多くの場合ヘッダーと介在する静的ライブラリ（DLL、SO）を介して、OS自体が使用するものと同様の低レベルのメカニズムを使用して動的にリンクされます。
- OSライブラリコードは、API仕様の一部であるメカニズムを使用して、仕様に固有のメカニズム（COM、.NET）を使用して動的にリンクされます。
2つの異なるテクノロジー（RubyとCocoaなど）が相互作用できる場合は常に、ツールによって、または手動で作成されたバインディングレイヤーがあります。最終的には、上記のメカニズムの1つを使用します（ただし、私は何かを逃しました）。