我正在考虑学习COM。但我听说微软推出.NET作为COM的替代品。 学习COM值得吗? 实际上我开始学习UMDF设备驱动程序的COM。 除了COM之外,还有其他方法可以在UMDF上工作吗?
答案 0 :(得分:11)
答案 1 :(得分:10)
要明确的是,.NET非常希望成为COM的替代品。这很好,它非常成功。但是COM在Windows中无处不在,你不能动摇一个典型的程序而不是在某个地方遇到COM。这从任何.NET GUI程序中的第一个代码开始,[STAThread]。
Windows中有很多东西还没有得到友好的.NET包装器。这并不总是需要,CLR对COM互操作有很好的支持。从“添加引用”对话框中可以看到,COM选项卡中充满了好东西。但是,您在该列表中看到的是专门设计为易于在任何运行时环境中使用的组件。它们实现了一个名为“OLE Automation”的COM子集。
自动化是一个非常有限的子集,它运行良好,因为您实际可以做的事情是有限的。然而,有些代码不适合该子集。您找不到类型库的那种。没有类型库,你就搞砸了.NET。具有该问题的最明显的组件是shell。 Windows资源管理器。在托管代码中编写shell扩展名为 hard 。
问题是COM接口声明最初设计为在实现多继承的编译器上运行良好。特别是C ++。如果该COM接口是从另一个COM接口派生的,则.NET接口声明不能很好地映射到COM接口。 CLR生成错误的v表。虽然作者的结论是错误的,但在MSDN magazine article中已经触及了这一点。
您可以以.NET语言编写COM接口声明并实现它们。只是你从SDK获得了 no 的帮助。并且你需要很好地了解COM以使它们正确。
UMDF也适合这个模型,它的接口来自IUnknown。没有类型库。我不知道托管包装器。您可以在C#中编写代码,但您必须自己编写所有的接口声明。实际上,这里只适用C ++。
是的,你需要学习COM。
答案 2 :(得分:8)
UMDF是开发用户模式设备驱动程序的框架。我认为设备驱动程序的关键要求是:加载速度快。我不想因为我有一个时髦的设备驱动程序而需要加载和JIT .NET框架(preJITed但仍然如此)来延迟我的启动时间。
当然你也可以开发臃肿的com库,但是通过胜任你可以避免它。你无法避免.NET运行时。
因此,即使UMDF允许进行.NET开发,我此时也不希望用.NET编写设备驱动程序。
别误会我的意思。我喜欢.NET。即使我们谈论用户模式驱动程序,我也不认为它与设备驱动程序混合得很好。
在查看COM时,我认为有助于理解它的开发原因:提供在不同环境中开发的组件之间的互操作性。这是在80年代。现在人们多年来一直抱怨COM,但实际上它非常成功。 COM的部署模型中存在一些错误(即注册表依赖性)和其他有趣的设计选择,这些选择使得开发人员不顾一切。然而,COM的核心(即IUnknown)仍然是合理的IMO。
答案 3 :(得分:3)
COM非常有用,因为它允许您构建可以从多种语言中使用的独立于语言的API。现在.net用于大致的样本目的,虽然它不太容易访问。如果编写.net,许多COM API“只是工作”,虽然最好能够对COM如何工作有一些基本的了解(这样COM使用引用计数进行内存管理,而.net使用垃圾回收)。