COMを学ぼうと思っているのですが、マイクロソフトがCOMの代替として.NETを立ち上げたと聞きました。では、COM を学ぶ価値はありますか? 実際に、UMDF デバイス ドライバー用の COM の学習を開始しました。COM 以外に UMDF で作業する別の方法はありますか?
4 に答える
COMは古く、退屈でイライラします。COMでの作業を楽しんだ人はいないと思います。したがって、一般的に、本当に説得力のある理由がない限り、それを学ぶことはお勧めしません。使用する必要のあるCOMライブラリがある場合は、代わりにCOM相互運用機能を使用して使用する方法を学習します。これにより、.NETからCOMを操作できるようになります。
明確にするために言うと、.NET は COM の代わりになることを非常に意図していました。そしてそれはうまくいきました、それは非常に成功しています。しかし、COM はWindows のどこにでもあります。典型的なプログラムでスティックを振っても、どこかで COM に遭遇することはありません。それは、任意の .NET GUI プログラム [STAThread] のコードの最初の部分から始まります。
Windows には、フレンドリーな .NET ラッパーをまだ取得していないものがたくさんあります。これは常に必要なわけではありません。CLR は COM 相互運用性を優れた方法でサポートしています。[参照の追加] ダイアログからよくわかるように、[COM] タブには便利な機能がたくさんあります。しかし、そのリストに表示されているのは、どのランタイム環境からでも簡単に使用できるように特別に設計されたコンポーネントです。これらは、「OLE オートメーション」と呼ばれる COM のサブセットを実装しています。
自動化は非常に制限されたサブセットです。実際にできることは限られているため、非常にうまく機能します。ただし、そのサブセットに適合しないコードの塊があります。タイプ ライブラリが見つからない種類。タイプ ライブラリがなければ、.NET にはまってしまいます。その問題で最も目に見えるコンポーネントはシェルです。ウィンドウズ・エクスプローラ。マネージ コードでシェル拡張機能を記述するのは困難です。
問題は、COM インターフェイス宣言が元々、多重継承を実装するコンパイラで適切に機能するように設計されていることです。特にC++。COM インターフェイスが別の COM インターフェイスから派生したものである場合、.NET インターフェイス宣言はその COM インターフェイスに適切にマップされません。CLR が間違った v テーブルを生成します。これは、このMSDN マガジンの記事で触れられていますが、著者の結論はかなり間違っています。
COM インターフェイス宣言を .NET 言語で記述して実装できます。SDK からは何の助けも得られないというだけです。そして、それらを正しく理解するには、COM について十分に理解する必要があります。
UMDF もこのモデルに適合し、そのインターフェイスは IUnknown から派生しています。タイプ ライブラリはありません。私が知っている管理されたラッパーはありません。C# でコードを記述できますが、すべてのインターフェイス宣言を自分で記述する必要があります。現実的には、ここでは C++ のみが適用されます。
はい、COM を学ぶ必要があります。
UMDF は、ユーザー モード デバイス ドライバーを開発するためのフレームワークです。デバイス ドライバーの重要な要件は、読み込みが速いことだと思います。.NET フレームワークをロードして JIT する必要があるファンキーなデバイス ドライバーがあるという理由だけで、起動時間を遅らせたくありません (preJIT されていますが)。
確かに肥大化した com ライブラリを開発することもできますが、有能であればそれを避けることができます。.NET ランタイムを避けることはできません。
したがって、たとえ UMDF で .NET 開発が許可されていたとしても、現時点では、デバイス ドライバーを .NET で作成する必要はありません。
誤解しないでください。.NET が大好きです。ユーザーモードドライバーについて話しているとしても、デバイスドライバーとうまく混ざるとは思いません。
COM を見ると、COM が開発された理由を理解するのに役立つと思います。異なる環境で開発されたコンポーネント間の相互運用性を提供するためです。これは80年代にさかのぼります。人々は何年にもわたって COM について不満を漏らしてきましたが、実際にはその点で非常に成功しています。COM の配置モデル (つまり、レジストリの依存関係) にはいくつかの誤りがあり、開発者を困惑させたその他の興味深い設計上の選択がありました。ただし、COM のコア (つまり IUnknown) は依然として健全な IMO です。
COMは、複数の言語から使用できる言語に依存しないAPIを構築できるため便利でした。現在、.netはアクセスしにくいものの、おおよそのサンプル目的で使用されています。.netをプログラムする場合、多くのCOM APIは「正しく機能します」が、COMがどのように機能するかについての基本的な理解を得るのは良いことです(COMはメモリ管理にrefcountingを使用しますが、.netはガベージコレクションを使用します)。