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](

[To see links please register here]

).

In JScript I did:
```javascript
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](

[To see links please register here]

) 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"](

[To see links please register here]

)*. Thank you.

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][1]":
* 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][2]


[1]:

[To see links please register here]

[2]:

[To see links please register here]