Answering my own questions:
On Thursday, 2 November 2017 at 14:22:56 UTC, Guillaume Piolat
wrote:
Question 1. Is it mandatory to inherit from
core.sys.windows.unknwn.IUnknown, or just having an interface
named "IUnknown" validate it for being a COM interface?
Deriving from an interface named "IUnknown", in whatever module,
with whatever actual methods, make the compiler consider it a
"COM interface", which applies semantic restrictions.
The actual layout is _separated_ from the compiler considering it
as a "COM interface", and one can achieve the exact desired
layout with a IUnknown-like interface named in other way. One can
test this with `delete interfaceInstance`.
The only layout effect of having the compiler consider it like
COM interface, is that derived class will become "COM classes"
whose only effects seems to be extern(System) as default linkage
type.
So: you don't need the compiler to follow COM ABI, it just makes
it easier.
Question 2. If this fails, may I emulate COM vtable layout with
extern(C++) class? I wonder what the exact differences are
anyway between extern(C++) and the special IUnknown.
extern(C++) is indeed very flexible, with no virtual methods,
whereas COM objects will have at least 8.
However this doesn't seem needed.
Question 3. It seems I can inherit both from A D object and a
COM interface. What will be the choosen layout?
Should not be a problem.
The problem I had was my inability to override a base class
methods since I forgot extern(D). This problem is talked about in
the spec: https://dlang.org/spec/interface.html#com-interfaces
