12

The majority of my experience is with high level languages like Java and VB.NET. I do have some experience with C++ (at university).

I understand the difference between a COM DLL and a DLL produced by a .NET compiler. I don't fully understand the difference between a COM DLL and a Windows DLL generated by the C and C++ compiler.

I want to use C++ DLL in a .NET program. I have managed to get this working. My question is specifically: What is the difference between a DLL produced by C++ and a DLL produced by VB6 (COM based).

I have spent an hour Googling this and looking on MSDN. I though I would find my answer without having to ask a question, but I have not.

BrendanMcK
  • 14,252
  • 45
  • 54
w0051977
  • 15,099
  • 32
  • 152
  • 329

2 Answers2

18

There's a giant difference between the two. The list is too long to reproduce accurately in an SO post, I'll try to hit the highlights:

  • A C++ DLL must export every function or class it wants to make available to the client code. A COM DLL only exports 4 functions with well-known names and behavior
  • An application that uses a C++ DLL must describe that DLL's interface at link time, a COM server is bound at runtime
  • An application that uses a C++ DLL must allow Windows to find the DLL at startup time, usually by having the DLL in the same directory as the EXE or on the Path. A COM DLL is found without the client app specifying where it is located. The registry is used at runtime to locate the DLL
  • A COM server doesn't have to be a DLL. It can be anything, including a seperate process on the same machine or an executable located on another machine half-way around the world. The client code is oblivious to where it is located

Specific to the Automation subset of COM:

  • A COM server is usable by any language that supports COM. Which in Windows is just about any of them.

The last bullet is possibly what trips you up about thinking that you understand the difference between a COM dll and a .NET dll. They have nothing at all in common, but .NET is pretty good and inter-operating with COM servers. The Tlbimp.exe utility is quite adept at papering over the differences.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks for the explanation (+1). Are you able to provide a link to an MSDN page/tutorial that explains this. I am interested specifically in the C++ DLL. – w0051977 Oct 02 '12 at 14:15
  • You cannot directly use a C++ DLL that exports classes in a .NET program. A wrapper written in the C++/CLI language is required. Not exactly something you'll pick up from a tutorial, there are lots of books about that language. – Hans Passant Oct 02 '12 at 14:58
  • One clarification: You can, actually, directly use a C++ DLL in .NET by using pinvoke. http://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx – dss539 Nov 05 '13 at 21:29
  • Well, no, notable how the linked article never talks about C++ anywhere. Pinvoke only supports a C-style interface, it has no support for classes or anything from the standard C++ library. Programmers tend to talk about a fictional language named C/C++ when they point this out. Which is okayish, the C++ compiler is a better C compiler. You just have to deal with the name mangling applied to the exported functions. – Hans Passant Jan 10 '17 at 15:05
5

Com is a binary standard that allows applications to utilize binary modules interchangeable any language can produce com complaint library's as long as they meet the com standard. So what the diffidence is depends some com library's will be native machine code some may be manged and running through an interpreter. What com is really meant to do is bridge the usability gap between the oop style that c++ had at the source level to the prebuilt binary world.

rerun
  • 25,014
  • 6
  • 48
  • 78