core.sys.windows.com.ComObject apparently has wrongly laid out Vtable

[Carl Sturtivant]

On Wednesday, 20 March 2024 at 04:14:44 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> These are functions that alter in this case the this pointer to 
> align with what the actual function expects.
>
> https://dlang.org/spec/abi.html#classes

A useful reference! Should have factored interfaces and not just 
single inheritance into my speculation on inheritance and 
Vtables. Thanks for the detailed counterargument.

However, in the world of COM the situation can be considered 
simpler by having COM objects implement only one COM interface. 
Perhaps that cannot be reflected in how COM is represented in D 
because of the potentially more complicated possibilities for an 
object while it still represents a regular COM object.

> Without it the interface will not understand how to call the 
> class and all the pointers will be a little bit off, in this 
> case the size of a pointer aka the extra vtable entry.

So the layout is as I concretely suspected in this case, the 16 
bytes being exactly the offset mentioned abstractly here in the 
concrete case of IUnknown and ComObject. I inspected the 
reference to a ComObject from druntime and it is indeed a pointer 
offset upward by those 16 bytes from a reference cast to a 
pointer when it is first cast to IUnknown.

This being the case, how do C++ objects in D escape this 
constraint when cast to a pointer? Remember the top post? 
Redefining IUnknown and ComObject to have C++ linkage eliminated 
the 16 byte offset when casting directly and not via IUnknown, 
and the code worked.

Is there some reason why this arrangement is not used for COM 
objects in D?