oleviewdotnet | net OLE/COM viewer and inspector to merge functionality

There are entire books on the subject, but here's a very simplified story. There are basically 3 "categories" of COM interfaces:

Interfaces deriving from IUnknown

• aliases for programming against: early binding, (custom) vtable binding
• the simplest way to implement a COM "server"
• it's only a binary contract (methods layout, method signature, parameters behavior like in/out for cross-apartment/process support, ...)
• you need to somewhow tell your callers what is this binary contract you support (you can use .idl, .tlb or anything that your caller can understand)
• there are some official ways of documenting your IUnknown-derived interfaces: .idl -> .h and .tlb is the most standard one
• only supported by a certain class of languages (for example C/C++, .NET, Delphi), those who understand .tlb (or .idl, or equivalent .h), or those who allow redefining layout manually (like .NET). You can perfectly define a language that can do that w/o ever using .tlb. That's the beauty of COM, it's just a binary contract.
• if your language doesn't support it, you just can't use it, you'll have to write or use a wrapper with a language that supports it and exposes it in a way your language supports. Powershell for example doesn't support IUnknown-derived interfaces (I'm not 100% sure) but supports .NET so it can use .NET as a "super wrapper".

IDispatch interface

• only requires one IUnknown well-known interface implementation: IDispatch
• aliases for programming against: late binding, OLE automation, COM automation, or simply Automation (not to confuse with UI Automation)
• invented for higher level languages (VB/VBA first, ActiveScripting a bit later)
• only supported by a certain class of language, and the way it's supported varies (for example it's supported in C++ of course but it's not super easy w/o wrappers or tooling like Visual Studio's C++ #import directive). JScript and VBScript don't exactly support the same set of features with regards to Automation.
• you're supposed to use only a predefined list of types "Automation-Compatible types":
• these types where initially very related to VB/VBA (VARIANT, SAFEARRAY, BSTR which means "Basic String"...)
• from the higher level language, it really makes COM much transparent and easier as that was the whole point (and can make it harder from the lower level ones...), it also allows "syntactic sugar" niceties
• note the IDispatch implementation can be very dynamic and really late-bound at runtime (get id of name -> invoke) but most available programming tooling quite freezes the list of ids/names at compile time (ex: .NET) because they support Dual interfaces.

Dual interfaces:

• interfaces that implement a custom IDispatch-derived interface and implement IDispatch itself to match the custom interface (both implementations supposedly being "equivalent" of course). Have a look at the link below, it has nice images.
• because of IDispatch, you're supposed to use only Automation compatible data types in the IDispatch-derived method.
• it's more work to implement (so it's usually done by programming tools, for ex: ATL)
• a bit easier for native (C/C++, etc.) callers (no need to use IDispatch wrappers) but you still have to digest automation data types

IMHO, one of the best 1-page introduction to COM is here: Introduction to COM