Accessing Windows Contacts (pre Win10) from JScript (or any ActiveScripting)
See the question and my original answer on StackOverflowThere 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 supportDual
interfaces.
Dual
interfaces:
- interfaces that implement a custom
IDispatch-derived
interface and implementIDispatch
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 theIDispatch
-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