Interfacing with XPCOM

[John Reimer]

As the title suggests, this post is about D interfaces, specifically as supported 
in D 1.0.  

Here's some background:

I've been working on porting the SWT Browser package to DWT (on Linux) over 
the last few months.  I'm happy to say that I've mostly succeeded despite 
some rather annoying problems.  The important issues have been ironed out. 
 What remains now is to get down to some heavy debugging sessions.

SWT implements its Browser code based on the mozilla XPCOM interface.  What 
this means is that in order to use the SWT Browser in your project, you need 
to install a mozilla package called XULRunner that provides all the components 
that make up a working browser.  XULRunner is basically the Mozilla Team's 
way of separating the internals of Mozilla Firefox into a shared package 
that serves any number of applications that want to embed browser components. 
 As of Firefox 3.0, the Mozilla Foundation has moved to this XPCOM component 
server system; it seems that they now include the XULRunner package within 
the Firefox installation instead of making it an integrated component of 
the browser.

Obviously this scheme is useful for all sorts of apps that want to embed 
a comprehensive browser.  The only requirement is that development language 
know how to interface to the Mozilla components.  So the key here is that 
a language must be compatible with XPCOM.

This is no problem for D on windows machines because D provides a mechanism 
of direct COM interface support on that platform.  XPCOM happens to be binary 
compatible with the vtable layout of the COM structure, so, on windows, all 
one has to do is alias the XPCOM's base interface nsISupports to the COM 
IUknown.  The D compiler takes care of the rest since it automatically adjusts 
the vtable when it sees a reference to the IUnknown COM type.

But how does one do this on Linux?  Can we use D to interface with XPCOM 
there?  The problem is that this will not work on Linux since COM has no 
meaningful implementation on the platform primarily because all COM components 
are declared extern(Windows) internally by the D compiler.   This would appear 
to mean that Linux is left out in the cold when it comes to interfacing with 
anything like XPCOM.  D interfaces obviously won't work because they are 
constitute a new type, independent of any relationship to any other language 
interface (D intefaces insert a vtable entry at index 0 that references RTTI).

There is, in fact, a solution for Linux:

We can use the COM interface alias technique just as we would on windows.

[code]

alias IUknown nsISupports;

[/code]

Even on linux, the D compiler will create a COM clean vtable with windows 
calling convention for the methods.  You don't actually notice that the compiler 
has done this until you try to implement some classes based on the interface, 
at which point the compiler protests loudly.  Now on linux, we need to get 
rid of the windows calling convention in order to make the interfaces XPCOM 
compatible.  The best way to do this is to directly override the compiler 
by declaring each interface method extern(C); this is something XPCOM wants 
to see.

[code]

interface IUnknown
{
    static const char[] IID_STR = NS_ISUPPORTS_IID_STR;
    static const nsIID IID = NS_ISUPPORTS_IID;

extern(System):
    nsresult QueryInterface( nsIID* uuid, void **result);
    nsrefcnt AddRef();
    nsrefcnt Release();
}

[/code]

I've used extern(System) to demonstrate a quick way to do this for the particular 
platform so the code is portable.  Now we have a simple COM interface with 
extern(C) calling convention that will interface acceptably with Linux XPCOM.

There's still a problem here, however.  Since we are using IUnknown, the 
D compiler is going to secretly force all /class/ methods that implement 
the contract methods to also use extern(Windows).  So within any class that 
implements the interface, we also have to apply the extern(System) decoration:

[code]

class A : nsISupports {
    extern(System) nsresult QueryInterface( nsIID* uuid, void **result) {} 
   
    ...
}

[/code]

But what about the class methods that don't implement the interface?  Well, 
they have to be explicitly declared extern(D) in order to keep the compiler 
from complaining again.

[code]

class A : nsISupports {
    extern(System) nsresult QueryInterface( nsIID* uuid, void **result) {} 
   
    ...
    extern(D) void handleFolderEvent( Event event );
}

[/code]

The above code worked in porting the Browser code to DWT specifically for 
D version 1.0.  But I have to admit that I remain a little uncomfortable 
implementing the fix this way.  It's a hack.  Unfortunately, it's the only 
way I know that simply and effectively solves this problem.  

Here are a couple of thoughts I have:

(1) I'm wondering if the implicit COM support (triggered by the IUnknown 
symbol only) implemented in D is such a good idea.  Would such a feature 
be more correctly supported as a Pragma wherever an interface vtable type 
is augmented in a system specific way?  pragma("COM") {} or something to 
that effect.

(2) As an alternate solution to my trick with COM on linux, there is also 
the option of using extern(C++), except that it only exists in D 2.0.  I 
think using extern(C++) might work in this situation because mozilla XPCOM 
interfaces are often represented in C++ using single inheritance C++ class 
structures.  The vtables should match unless I'm missing some important detail. 
 Porting extern(C++) to D 1.0 should not constitute a spec change, and it 
could mean simpler support for Mozilla XPCOM without ugly workarounds.  Does 
this sound reasonable?

For more information, I've also covered the same material here:

http://www.dsource.org/projects/dwt/wiki/PortingJournal

Here's a link to the Walter's discription of D 2.0 Interfaces and the addition 
of extern(C++) along with its caveats:

http://www.digitalmars.com/d/2.0/cpp_interface.html

Notice that in the above link Walter says COM only works on windows. ;)

-JJR