0

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.

amix
  • 133
  • 1
  • 12
  • 2
    You're right, since these interfaces derive from IUnknown, you can't access them using scripting interface such as VBScript or JScript. You can use them using C/C++ or .NET, or any other language that support IUnknown-derived interfaces. – Simon Mourier Feb 16 '20 at 23:36
  • 2
    Does this answer your question? [What is the difference between IDispatch and IUnkown in COM?](https://stackoverflow.com/questions/37937360/what-is-the-difference-between-idispatch-and-iunkown-in-com) – user692942 Feb 17 '20 at 12:36
  • @Lankymart No, it doesn't, since the question was not for difference between IUnknown and IDispatch. As I (now) understand it, the IUnknown stuff gets bound at compile time, and there is no way to reproduce that at runtime. This must either be hardcoded via IDispatch into the component, or another component must be written, that mirrors the IUnknown deliveries and exposes them via IDispatch. But these are all just my own guesses, and I want(ed) clarification, so I can write off the topic. But thanks, anyway it helped finding the shape of things. As did Simon's comment. – amix Feb 17 '20 at 21:55
  • @SimonMourier If you want you could transfer your comment to an answer, so I can check it off. If you could add a remark or two, whether there is workarounds for my problem, or whether my assumptions in the comment to Lankymart are right, that would be nice and help future visitors. Thanks. – amix Feb 17 '20 at 21:57
  • @amix it doesn't matter what the question title is, [read the answer](https://stackoverflow.com/a/37952232/692942). You basically just re-wrote what is already confirmed there, no need for more clarification in the form of another question. – user692942 Feb 18 '20 at 00:05

1 Answers1

1

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

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298
  • Thanks for updating. Upon my research in the last days I have also found [this document](http://wi.wu.ac.at:8002/rgf/diplomarbeiten/2003_Helmecke_A/MasterThesis_AutomationOfWindowsApplicationsWithObjectRexx.pdf), which is using the ObjectRexx scripting language as target, but has a well layed out, generic analysis of the COM technology. – amix Feb 18 '20 at 21:27