Share via

データ形式と転送メディア

  • [アーティクル]

Windows を含むほとんどのプラットフォームでは、クリップボードと呼ばれる一連の関数に基づいて、アプリケーション間でデータを転送するための標準プロトコルを定義します。 これらの関数を使用するアプリケーションは、ネイティブ データ形式が大きく異なる場合でも、データを共有できます。 一般に、これらのクリップボードには、COM が克服した 2 つの重要な欠点があります。

最初に、データの説明では、Windows の単一の 16 ビット クリップボード形式識別子などの形式識別子のみが使用されます。つまり、クリップボードはデータの構造、つまりビットの順序のみを記述できます。 "ビットマップがある" または "テキストがある" と報告できますが、データが構成されているターゲット デバイス、データが提供できるビューや側面、または転送に最適なストレージ メディアを指定することはできません。 たとえば、"グローバル メモリに格納され、画面またはプリンターでプレゼンテーション用に書式設定されたテキストの文字列がある" や "100 dpi ドット マトリックス プリンター用にサムネイル スケッチ ビットマップがレンダリングされ、ディスク ファイルとして保存されている" と報告することはできません。

次に、クリップボードを使用するすべてのデータ転送は、通常、グローバル メモリを介して行われます。 グローバル メモリの使用は、少量のデータでは合理的に効率的ですが、20 MB (メガバイト)マルチメディア オブジェクトなど、大量の場合は恐ろしく非効率的です。 大きなデータ オブジェクトの場合、グローバル メモリの速度が低下します。そのサイズでは、ディスク上の仮想メモリにかなりのスワップが必要です。 交換されるデータがディスク上にほとんど存在する場合、この仮想メモリのボトルネックを介してデータを強制することは非常に非効率的です。 より良い方法は、グローバルメモリを完全にスキップし、データをディスクに直接転送するだけです。

これらの問題を軽減するために、COM には FORMATETC と STGMEDIUM の 2 つのデータ構造が用意されています。 詳細については、次のトピックを参照してください。

データ転送