值得学习COM吗？
我正在考虑学习 COM。但是我听说 Microsoft 推出了 .NET 作为 COM 的替代品。 那么值得学习COM吗？ 实际上我开始学习 UMDF 设备驱动程序的 COM。 除了 COM 之外，还有其他方法可以在 UMDF 上工作吗？
I am thinking to learn COM.But I heard that Microsoft launched .NET as an alternative to COM.
So is it worth to learn COM?
actually I started learning COM for UMDF device driver.
Is there any alternate way to work on UMDF except COM?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
需要明确的是，.NET 非常想成为 COM 的替代品。效果很好，非常成功。但是 COM 在 Windows 中无处不在，你不可能在一个典型的程序中不碰到 COM 的地方。这从任何 .NET GUI 程序中的第一段代码开始，[STAThread]。
Windows 中有很多东西还没有获得友好的 .NET 包装器。这并不总是需要的，CLR 对 COM 互操作具有出色的支持。从“添加引用”对话框中可以明显看出，COM 选项卡充满了好东西。但您在该列表中看到的是经过专门设计的组件，以便在任何运行时环境中轻松使用。他们实现了一个名为“OLE Automation”的 COM 子集。
自动化是一个非常受限制的子集，它运行得很好，因为你实际上能做的事情是有限的。然而，有一些代码不适合该子集。您找不到类型库的类型。如果没有类型库，您就会陷入 .NET 困境。存在该问题的最明显组件是 shell。 Windows 资源管理器。在托管代码中编写 shell 扩展很难。
问题是 COM 接口声明最初设计为在实现多重继承的编译器上运行良好。具体来说是C++。如果 COM 接口是从另一个 COM 接口派生的，则 .NET 接口声明不能很好地映射到 COM 接口。 CLR 生成错误的 v 表。这篇MSDN 杂志文章中谈到了这一点，尽管作者的结论是完全错误的。
您可以用 .NET 语言编写 COM 接口声明并实现它们。只是您根本无法从 SDK 获得任何帮助。并且您需要非常了解 COM 才能正确使用它们。
UMDF也适合这个模型，它的接口源自IUnknown。没有类型库。据我所知，没有托管包装器。您可以用 C# 编写代码，但必须自己编写所有接口声明。实际上，只有 C++ 适用于此。
是的，您需要学习 COM。
To be clear, .NET was very much intended to be a replacement for COM. And that worked out well, it's been very successful. But COM is everywhere in Windows, you can't shake a stick at a typical program and not run into COM somewhere. That starts with the very first bit of code in any .NET GUI program, [STAThread].
There is lots and lots of stuff in Windows that hasn't gotten the friendly .NET wrapper yet. That isn't always needed, the CLR has excellent support for COM interop. Quite visible from the Add Reference dialog, the COM tab is filled with goodies. But what you see in that list are components that were specifically engineered to be easy to use from any runtime environment. They implement a subset of COM called "OLE Automation".
Automation is a very restricted subset, it works so well because what you actually can do is limited. There are however gobs of code that don't fit that subset. The kind for which you can't find a type library. Without the type library you're screwed in .NET. The most visible component with that issue is the shell. Windows Explorer. Writing a shell extension in managed code is hard.
The issue is that COM interface declarations were originally designed to work well on a compiler that implements multiple inheritance. C++ specifically. A .NET interface declaration does not map well to a COM interface if that COM interface was derived from another COM interface. The CLR generates the wrong v-table. This is touched upon in this MSDN magazine article, albeit that the author's conclusion is quite wrong.
You can write COM interface declarations in a .NET language and implement them. It is just that you get no help at all from the SDK. And that you'll need to know COM pretty well to get them right.
UMDF fits this model too, its interfaces are derived from IUnknown. No type library. No managed wrapper that I know of. You could write your code in C# but you'll have to write all the interface declarations yourself. Realistically, only C++ applies here.
Yes, you'll need to learn COM.
UMDF 是一个开发用户模式设备驱动程序的框架。我认为设备驱动程序的一个关键要求是：加载速度快。我不想仅仅因为我有一个必须加载和 JIT .NET 框架的时髦设备驱动程序而延迟启动时间（但尽管如此）。
当然，您也可以开发臃肿的 com 库，但只要有能力，您就可以避免它。您无法避免 .NET 运行时。
因此，即使 UMDF 允许 .NET 开发，我此时也不希望用 .NET 编写设备驱动程序。
别误会我的意思。我喜欢.NET。我只是不认为它与设备驱动程序混合得很好，即使我们谈论的是用户模式驱动程序。
当查看 COM 时，我认为这有助于理解它的开发原因：提供在不同环境中开发的组件之间的互操作性。这已经是上世纪 80 年代的事了。多年来人们一直在抱怨 COM，但它实际上在这方面非常成功。 COM 的部署模型（即注册表依赖性）中存在一些错误以及其他有趣的设计选择，这些都让开发人员摸不着头脑。然而，COM 的核心（即 IUnknown）在我看来仍然是健全的。
UMDF is a framework to develop user mode device drivers. I think a key requirement for a device driver is: load fast. I don't want to delay my startup times just because I have a funky device driver that has to load and JIT the .NET framework (preJITed but nonetheless).
Sure you can develop bloated com libraries too but by being competent you can avoid it. You can't avoid .NET runtime.
So even if UMDF allowed for .NET development I at this point of time wouldn't want device drivers written in .NET.
Don't get me wrong. I love .NET. I just don't think it mixes that well with device drivers even if we are talking about usermode drivers.
When looking at COM I think it helps to understand why it was developed: to provide interopability between components developed in different environments. This was back in the '80s. Now people has complained about COM over the years but it is actually very successful at that. There were some mistakes in the deployment model of COM (ie the registry dependency) and other interesting design choices that have made developers scratch their heads. However, the core of COM (ie IUnknown) is still sound IMO.
COM 很有用，因为它允许您构建可以从多种语言使用的独立于语言的 API。现在，.net 大致用于相同的目的，尽管它不太容易访问。如果您对 .net 进行编程，许多 COM API 就“正常工作”，尽管最好了解 COM 的工作原理（例如 COM 使用引用计数进行内存管理，而 .net 使用垃圾收集）。
COM was useful because it allowed you to build a language independent API that could be consumed from multiple languages. Now .net is used for roughly the sampe purpose, although it is less accessible. If you program .net, many COM API's "just work", although it is good to get some basic understanding of how COM works (such that COM uses refcounting for memory management, whereas .net uses garbage collection).
COM 已经过时、乏味且令人沮丧。我认为没有人喜欢使用 COM 工作。所以一般来说，我建议不要学习它，除非你有一个真正令人信服的理由。如果您需要使用 COM 库，我会学习如何通过 COM 互操作来使用它，这使您能够从 .NET 使用 COM。
COM is old, tedious and frustrating. I don't think anyone has ever enjoyed working with COM. So generally, I'd recommend against learning it unless you have a really compelling reason. If there is a COM library out there that you need to use, I'd instead learn how to use it through COM interop, which enables you to work with COM from .NET.