Search code examples
comactivexjscriptwshactive-script

Accessing Windows Contacts (pre Win10) from JScript (or any ActiveScripting)

I want to use the COM object with the progID Windows.Contact.1 via ActiveScripting (JScript, VBScript, Python, etc).

This COM resides in C:\Program Files (x86)\Common Files\System\wab32.dll. It seems, there is no TypeLib available for it. The COM delivers, amongst others, IContact for the "Windows Address Book" (storing contacts as XML in folders, as in Windows 7). IContact is documented here.

In JScript I did:

var co = new ActiveXObject("Windows.Contact.1");
typeof co;  // results in: unknown

Since it results in unknown, I have the suspicion, that this COM could not be usable for scripting. Somewhere I read, that everything, that inherits from IUnknown can not be used for scripting, instead it must inherit from IDispatch. But I am unsure, as to how much of this is valid, and whether there are workarounds.

I would like to ask for acknowledgement of my suspicions (since I am new to all of this and have no C++ or C# background) or to ask for a way, as to how to use Windows.Contact.1 from scripting, including a way, to find out, which methods/objects I can use, without resorting to a TypeLib.

I have access to pages like Programming Windows Contacts and related ones, but first I need to get an instance in ActiveScript (JScript, VBScript, Python, Lua will do). I also have access to applications like "MS OLE View" and "OLEView DotNet". Thank you.

Solution

  • 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