Tuesday, August 15, 2006

Extended Interface RTTI

To support the most basic mechanisms of its SOAP architecture, Delphi has supported extended interface RTTI since version 7. As we saw in the previous article, all interfaces support basic RTTI information such as the name of the interface, its GUID, unit, parent interface and number of methods.

To enable extended RTTI on an interface, compile it with {$M+}, {$TYPINFO ON} or {$METHODINFO ON} defined. Alternatively, you can have your interface inherit from IInvokable (defined in System with $M+ enabled). This will extend the generated RTTI for the interface with information about each method’s signature.

Both the client and server side support code for SOAP in Delphi uses the extended interface RTTI structures. Some of the most basic routines can be found in the IntfInfo unit (source is shipped with D2005 and D2006, but not in D7, it seems), for instance take a look at the FillMethodArray and GetIntfMetaData routines.

There is also code to generate WSDL (Web Service Description Language) from the list of registered interfaces in a web service (see WSDLPub.pas) and to dynamically generate an interface method table (IVT) with pointers to dynamically generated thunks that will eventually call TRIO.Generic. This method is responsible for packing up the client-side method call including parameters into an XML formatted SOAP message, execute it by sending it to the server and waiting for the return information, decoding the XML formatted SOAP reply message and updating out and var parameters (in OPToSOAPDomConv’s TOPToSoapDomConvert.ProcessSuccess method) and the result value. Pretty advanced stuff! Note that TRIO does not support the register calling convention for remoted interface calls – the recommendation is to use stdcall.

That was the background information about how the extended interface information is used and where you can find the implementation code that utilizes it. While there are low-level access routines in the IntfInfo unit (exported when DEVELOPERS is defined), we want to get our hands dirty and implement this ourselves from first principles.

As usual the RTTI structures for interface methods contain numerous packed shortstrings – meaning it is impossible to write correct Pascal declarations for them. By digging around in Borland’s extended interface RTTI consuming SOAP code, stepping through the code in the debugger and dumping out raw RTTI memory contents as an array of characters and deducing the (dynamic) field lengths I was able to reverse engineer and write some pseudo Pascal structures to map into the RTTI information. For example here is an ASCII dump from a single interface method’s RTTI that I manually tagged with probable field declarations:

{ MethodCount:1; HasMethodRTTI:1; 
Name: #3, 'F', 'o', 'o',
Kind: #0,
CallConv: #0,
ParamCount: #3,
Flags: #8,
ParamName: #4, 'S', 'e', 'l', 'f',
TypeName: #14, 'I', 'M', 'y', 'M', 'P', 'I', 'n', 't', 'e', 'r', 'f', 'a', 'c', 'e',
TypeInfo: #24, 'T', 'O', #0,
Flags: #0,
Name: #1, 'A',
TypeName: #7, 'I', 'n', 't', 'e', 'g', 'e', 'r', }

At the outermost level we start with the record that follows the IntfUnit field of the tkInterface part of the TTypeData variant record from TypInfo.

  PExtraInterfaceData = ^TExtraInterfaceData;
TExtraInterfaceData = packed record
MethodCount: Word; // #methods
HasMethodRTTI: Word; // $FFFF if no method RTTI,
// #methods again if has RTTI
Methods: packed array[0..High(Word)-1] of

For all interfaces, the MethodCount field contains the number of methods in the interface. For “normal” interfaces (compiled with $METHODINFO OFF) the HasMethodRTTI field will be $FFFF indicating that there are no more RTTI for this interface. Extended RTTI interfaces (compiled with $METHODINFO ON) the HasMethodRTTI field will equal the MethodCount field and there will be a packed array of information about each method following it.

  PInterfaceMethodRTTI = ^TInterfaceMethodRTTI;
TInterfaceMethodRTTI = packed record
Name: TPackedShortString;
Kind: TMethodKind; // mkProcedure or mkFunction
CallConv: TCallConv;
ParamCount: byte; // including Self
Parameters: packed array[0..High(byte)-1] of TInterfaceParameterRTTI;
case TMethodKind of
(Result: TInterfaceResultRTTI);

The RTTI for a single interface method contains the name of the method, the kind of method (procedure or function), the calling convention, the number of parameters (including the implicit Self parameter), and a packed array of details about each parameter. If the method is a function, the parameter array is followed about information about the result type.

  PInterfaceParameterRTTI = ^TInterfaceParameterRTTI;
TInterfaceParameterRTTI = packed record
Flags: TParamFlags;
ParamName: TPackedShortString;
TypeName: TPackedShortString;
TypeInfo: PPTypeInfo;

The record definition for a parameter contains flags (indicating var, const, out or value parameter, array parameters and references) , the parameter name, the string name of the parameter type and a pointer to a PTypeInfo with the RTTI for the parameter type (if it has RTTI).

  PInterfaceResultRTTI = ^TInterfaceResultRTTI;
TInterfaceResultRTTI = packed record
Name: TPackedShortString;
TypeInfo: PPTypeInfo;

Finally, we have the record definition for a function result.

  PInterfaceResultRTTI = ^TInterfaceResultRTTI;
TInterfaceResultRTTI = packed record
Name: TPackedShortString;
TypeInfo: PPTypeInfo;

Again we have the string name of the result type and a pointer to a PTypeInfo for the RTTI of the return type.

The TExtraInterfaceData structures above approximate the physical layout of the raw RTTI information generated by the compiler. For external code we want to translate this into some preprocessed and easier to use structures. Note that this is very similar to what we did for published methods. Both interface and published methods have signatures with parameter and return type information. So I decided to refactor out the signature related definitions and helper routines from the HVPublishedMethodParams unit into a separate HVMethodSignature unit.

unit HVMethodSignature;


uses Classes, SysUtils, TypInfo, HVVMT;

TCallConv = (ccReg, ccCdecl, ccPascal, ccStdCall, ccSafeCall);
PMethodParam = ^TMethodParam;
TMethodParam = record
Flags: TParamFlags;
ParamName: PShortString;
TypeName: PShortString;
TypeInfo: PTypeInfo;
TMethodParamList = array of TMethodParam;
PMethodSignature = ^TMethodSignature;
TMethodSignature = record
Name: PShortString;
MethodKind: TMethodKind;
CallConv: TCallConv;
ParamCount: Byte;
Parameters: TMethodParamList;
ResultTypeName: PShortString;
ResultTypeInfo: PTypeInfo;

function MethodKindString(MethodKind: TMethodKind): string;

function MethodParamString(const MethodParam: TMethodParam;
ExcoticFlags: boolean = False): string;

function MethodParametesString(const MethodSignature: TMethodSignature;
SkipSelf: boolean = True): string;

function MethodSignatureToString(const Name: string;
const MethodSignature: TMethodSignature): string; overload;

function MethodSignatureToString(
const MethodSignature: TMethodSignature): string; overload;


function MethodKindString(MethodKind: TMethodKind): string;
case MethodKind of
mkProcedure : Result := 'procedure';
mkFunction : Result := 'function';
mkConstructor : Result := 'constructor';
mkDestructor : Result := 'destructor';
mkClassProcedure: Result := 'class procedure';
mkClassFunction : Result := 'class function';

function MethodParamString(const MethodParam: TMethodParam;
ExcoticFlags: boolean = False): string;
if pfVar in MethodParam.Flags then Result := 'var '
else if pfConst in MethodParam.Flags then Result := 'const '
else if pfOut in MethodParam.Flags then Result := 'out '
else Result := '';
if ExcoticFlags then
if pfAddress in MethodParam.Flags then
Result := '{addr} ' + Result;
if pfReference in MethodParam.Flags then
Result := '{ref} ' + Result;

Result := Result + MethodParam.ParamName^ + ': ';
if pfArray in MethodParam.Flags then
Result := Result + 'array of ';
Result := Result + MethodParam.TypeName^;
if Assigned(MethodParam.TypeInfo) then
Result := Result + ' {' + MethodParam.TypeInfo.Name + '} ';

function MethodParametesString(
const MethodSignature: TMethodSignature;
SkipSelf: boolean = True): string;
i: integer;
MethodParam: PMethodParam;
Result := '';
for i := 0 to MethodSignature.ParamCount-1 do
MethodParam := @MethodSignature.Parameters[i];
// Skip the implicit Self parameter for class and interface methods
// Note that Self is not included in event types
if SkipSelf and
(i = 0) and
(MethodParam.Flags = [pfAddress]) and
(MethodParam.ParamName^ = 'Self') and
(MethodParam.TypeInfo.Kind in [tkInterface, tkClass]) then
Result := Result + MethodParamString(MethodParam^);
if i < MethodSignature.ParamCount-1 then
Result := Result + '; ';

function CallingConventionToString(CallConv: TCallConv): string;
case CallConv of
ccReg : Result := 'register';
ccCdecl : Result := 'cdecl';
ccPascal : Result := 'pascal';
ccStdCall : Result := 'stdcall';
ccSafeCall: Result := 'safecall';
else Result := 'TCallConv('+IntToStr(Ord(CallConv))+')';

function MethodSignatureToString(const Name: string;
const MethodSignature: TMethodSignature): string; overload;
Result := Format('%s %s(%s)',
if MethodSignature.MethodKind = mkFunction then
Result := Result + ': ' + MethodSignature.ResultTypeName^;
if Assigned(MethodSignature.ResultTypeInfo) then
Result := Result + ' {' + MethodSignature.ResultTypeInfo.Name + '} ';
Result := Result + ';' ;
if MethodSignature.CallConv <> ccReg then
Result := Result + ' ' +
CallingConventionToString(MethodSignature.CallConv) + ';';

function MethodSignatureToString(
const MethodSignature: TMethodSignature): string; overload;
Result := MethodSignatureToString(MethodSignature.Name^,


This code is a simple extension of the code we saw back in the article about the hack of getting published method parameters via an event. Extended interface method RTTI contains more detailed information than an event, so we have extended the structures with fields for PTypeInfo of the parameter and return types, calling convention and method name. The routines are straightforward conversions of the logical method information into their corresponding pseudo-code string representations. We covered these in the previous article.

The only piece we are missing now is the code in the middle to translate from the internal raw RTTI structure to the externally useful structures. Here is the additional code from the HVInterfaceMethods unit that also contains the RTTI structures.

unit HVInterfaceMethods;


uses TypInfo, HVMethodSignature;

// Easy-to-use fixed size structure
PInterfaceInfo = ^TInterfaceInfo;
TInterfaceInfo = record
UnitName: string;
Name: string;
Flags: TIntfFlags;
ParentInterface: PTypeInfo;
Guid: TGUID;
MethodCount: Word;
HasMethodRTTI: boolean;
Methods: array of TMethodSignature;

procedure GetInterfaceInfo(InterfaceTypeInfo: PTypeInfo;
var InterfaceInfo: TInterfaceInfo);


// … TExtraInterfaceData type definitions goes here …

function Skip(Value: PShortstring): pointer; overload;
Result := Value;
Inc(PChar(Result), SizeOf(Value^[0]) + Length(Value^));

function Skip(Value: PPackedShortString;
var NextField{: Pointer}): PShortString; overload;
Result := PShortString(Value);
Inc(PChar(NextField), SizeOf(Char) + Length(Result^)
- SizeOf(TPackedShortString));

function Skip(CurrField: pointer; FieldSize: integer)
: pointer; overload;
Result := PChar(Currfield) + FieldSize;

function Dereference(P: PPTypeInfo): PTypeInfo;
if Assigned(P)
then Result := P^
else Result := nil;

procedure GetInterfaceInfo(InterfaceTypeInfo: PTypeInfo;
var InterfaceInfo: TInterfaceInfo);
// Converts from raw RTTI structures to user-friendly Info structures
TypeData: PTypeData;
ExtraData: PExtraInterfaceData;
i, j: integer;
MethodInfo: PMethodSignature;
MethodRTTI: PInterfaceMethodRTTI;
ParameterInfo: PMethodParam;
ParameterRTTI: PInterfaceParameterRTTI;
InterfaceResultRTTI: PInterfaceResultRTTI;
Assert(InterfaceTypeInfo.Kind = tkInterface);
TypeData := GetTypeData(InterfaceTypeInfo);
ExtraData := Skip(@TypeData.IntfUnit);

// Interface
InterfaceInfo.UnitName := TypeData.IntfUnit;
InterfaceInfo.Name := InterfaceTypeInfo.Name;
InterfaceInfo.Flags := TypeData.IntfFlags;
InterfaceInfo.ParentInterface := Dereference(TypeData.IntfParent);
InterfaceInfo.Guid := TypeData.Guid;
InterfaceInfo.MethodCount := ExtraData.MethodCount;
InterfaceInfo.HasMethodRTTI :=
(ExtraData.HasMethodRTTI = ExtraData.MethodCount);
if InterfaceInfo.HasMethodRTTI
then SetLength(InterfaceInfo.Methods, InterfaceInfo.MethodCount)
else SetLength(InterfaceInfo.Methods, 0);

// Methods
MethodRTTI := @ExtraData.Methods[0];
for i := Low(InterfaceInfo.Methods) to
High(InterfaceInfo.Methods) do
MethodInfo := @InterfaceInfo.Methods[i];
MethodInfo.Name := Skip(@MethodRTTI.Name, MethodRTTI);
MethodInfo.MethodKind := MethodRTTI.Kind;
MethodInfo.CallConv := MethodRTTI.CallConv;
MethodInfo.ParamCount := MethodRTTI.ParamCount;
SetLength(MethodInfo.Parameters, MethodInfo.ParamCount);

// Parameters
ParameterRTTI := @MethodRTTI.Parameters;
for j := Low(MethodInfo.Parameters) to
High(MethodInfo.Parameters) do
ParameterInfo := @MethodInfo.Parameters[j];
ParameterInfo.Flags := ParameterRTTI.Flags;
ParameterInfo.ParamName :=
Skip(@ParameterRTTI.ParamName, ParameterRTTI);
ParameterInfo.TypeName :=
Skip(@ParameterRTTI.TypeName, ParameterRTTI);
ParameterInfo.TypeInfo :=
ParameterRTTI := Skip(@ParameterRTTI.TypeInfo, SizeOf(ParameterRTTI.TypeInfo));

// Function result
if MethodInfo.MethodKind = mkFunction then
InterfaceResultRTTI := Pointer(ParameterRTTI);
MethodInfo.ResultTypeName :=
Skip(@InterfaceResultRTTI.Name, InterfaceResultRTTI);
MethodInfo.ResultTypeInfo :=
MethodRTTI := Skip(@InterfaceResultRTTI.TypeInfo,
MethodRTTI := Pointer(ParameterRTTI);


The code is a little tricky and hard to follow because of the need to skip over the variable length shortstring fields. The low-level code in IntfInfo is different, using a ReadString, ReadByte, ReadWord , ReadLong model. I like the self-documenting aspects of pseudo-record definitions and wanted to use them in the access code as well. Note that at some points, only one field in a record structure is aligned correctly and can be read.

With all the foundations in place, now we can write a little dumping routine that will print out a pseudo source code representation of an interface.

procedure DumpInterface(InterfaceTypeInfo: PTypeInfo);
InterfaceInfo: TInterfaceInfo;
i: integer;
GetInterfaceInfo(InterfaceTypeInfo, InterfaceInfo);

writeln('unit ', InterfaceInfo.UnitName, ';');
write(' ', InterfaceInfo.Name, ' = ');
if not (ifDispInterface in InterfaceInfo.Flags) then
if Assigned(InterfaceInfo.ParentInterface) then
write(' (', InterfaceInfo.ParentInterface.Name, ')');
if ifHasGuid in InterfaceInfo.Flags then
writeln(' [''', GuidToString(InterfaceInfo.Guid), ''']');
if InterfaceInfo.HasMethodRTTI then
for i := Low(InterfaceInfo.Methods) to
High(InterfaceInfo.Methods) do
writeln(' ', MethodSignatureToString(
for i := 1 to InterfaceInfo.MethodCount do
writeln(' procedure UnknownName',i,';');
writeln(' end;');

And finally we can write some test code to try it all out.

TNumber = integer;
TNewNumber = type integer;
TIntegerArray = array of integer;
TNormalClass = class
TPersistentClass = class(TPersistent)
TSetOfByte = set of byte;
TEnum = (enOne, enTwo, enThree);
{.$M+} {.$TYPEINFO ON}
// With regards to interface RTTI, METHODINFO
// has the same effect as $M and $TYPEINFO
IMyMPInterface = interface
procedure TestRegister(A: integer; var B: string); register;
procedure TestStdCall(LongParaName: TObject;
const B: string; var C: integer; out D: byte); stdcall;
procedure TestSafeCall(out R: integer); safecall;
function Number: TNumber; cdecl;
function NewNumber: TNewNumber; cdecl;
function AsString: string; pascal;
function AsString2: string; safecall;
// Return types that are supported
procedure A2(const A: TIntegerArray);
procedure OkParam1(Value: TSetOfByte);
procedure OkParam2(Value: TSetOfByte);
procedure OkParam3(Value: Variant);
procedure OkParam4(Value: TNormalClass);
function OkReturn1: shortstring;
function OkReturn2: TObject;
function OkReturn3: IInterface;
function OkReturn4: TSetOfByte;
function OkReturn5: TNormalClass;
function OkReturn6: TEnum;
function OkReturn7: TClass;
function OkReturn8: Pointer;
function OkReturn9: PChar;
function OkReturn10: TIntegerArray;

procedure Test;

on E:Exception do

And the output is:

unit TestExtendedInterfaceRTTI;
IMyMPInterface = interface (IInterface)
procedure TestRegister(A: Integer {Integer} ; var B: String {String} );
procedure TestStdCall(LongParaName: TObject {TObject} ;
const B: String {String} ; var C: Integer {Integer} ;
out D: Byte {Byte} ); stdcall;
procedure TestSafeCall(out R: Integer {Integer} ); safecall;
function Number(): Integer {Integer} ; cdecl;
function NewNumber(): TNewNumber {TNewNumber} ; cdecl;
function AsString(): String {String} ; pascal;
function AsString2(): String {String} ; safecall;
procedure A2(const A: TIntegerArray {TIntegerArray} );
procedure OkParam1(Value: TSetOfByte {TSetOfByte} );
procedure OkParam2(Value: TSetOfByte {TSetOfByte} );
procedure OkParam3(Value: Variant {Variant} );
procedure OkParam4(Value: TNormalClass {TNormalClass} );
function OkReturn1(): ShortString {ShortString} ;
function OkReturn2(): TObject {TObject} ;
function OkReturn3(): IInterface {IInterface} ;
function OkReturn4(): TSetOfByte {TSetOfByte} ;
function OkReturn5(): TNormalClass {TNormalClass} ;
function OkReturn6(): TEnum {TEnum} ;
function OkReturn7(): TClass;
function OkReturn8(): Pointer;
function OkReturn9(): PAnsiChar;
function OkReturn10(): TIntegerArray {TIntegerArray} ;

The code including the utility units and the test code for this and most of my other RTTI articles can be found in CodeCentral here. The test code also contains some conditional code to test the support of additional parameter types. My experiments indicates that the following parameter types are not supported in interface methods with extra RTTI:

  • All pointer types

  • open array parameters (array of Type), named dynamic array is ok

  • class references (such as TClass)

  • record types (such as TRect)

  • untyped var and out parameters

If the compiler encounters one of these parameter types in a $METHODINFO ON interface method it generates a compiler time error like “[Error] : Type '%s' has no type info” at the end statement of the interface (i.e. it does not indicate what method is the culprit).

Due to my summer holidays and general laxness, this article was brought to you a litter later than originally planned. Hopefully I will be able to follow up with the next article on extended $METHODINFO ON RTTI for public and published methods of a class within a reasonable time. This technology is what the Websnap scripting is based on.

Updated (27. Oct 2007): $METHODINFO was first available in Delphi 7, not Delphi 6.


Anonymous said...

Very interesting, as always!

Anonymous said...

Nice. Do you plan to explain how to invoke instances by meta data?

Hallvards New Blog said...

> Nice. Do you plan to explain how to invoke instances by meta data?

Heh - I knew that question would pop up. As usual, I have left the hard stuff as an excercize for the reader ;).

If you look at the Delphi units I mentioned you will find code that invokes methods dynamically

You can find the required logic in the TInterfaceInvoker.Invoke in the Soap\Invoker.pas unit (available in D2005 and D2006).

Some assembly understanding needed.

Anonymous said...

{$METHODINFO ON} is not works correctly - D7 (and D2005?) compiler gives an error, if your class has more than one method with parameters. Borland has bug report on this, but... there is no solution...

Hallvards New Blog said...

> {$METHODINFO ON} is not works correctly

Hi Divi,

Note that the sample above is only using extended RTTI for an interface, not for a class - I'll discuss that later.

I think D7 should work fine with $METHODINFO ON on classes with multiple methods too. I know there are certain parameter and returntypes that cannot be used, but besides that it should work.

Do you have a specific sample that does not work? Is the issue reported in QC?

Anonymous said...

Great work!
I take a look at the sources and as far as I can see (this might not be far anyway) there is no way to call DumpInterface with an Object. In TestMorePubMethodParams.dpr there is nifty exit before an example with an object and if one delete the assertion is coming up and beat you!
Is it on purpose? It would be so nice to have it ...

Hallvards New Blog said...

Hi Ralf,

> In TestMorePubMethodParams.dpr there is nifty exit before an example with an object

I left some testing code for the upcoming article on extended method RTTI. The code is using the ObjectInvoke routine from the ObjAuto to dynamically call a method looked up by a string at runtime. Comment out the last GetIntfMetaData call (that takes IMyInterface as parameter) and it should run fine.

> no way to call DumpInterface with an Object

As we will see later, it is possible to get at rich RTTI for the methods and properties in a class (the method parameter RTTI requires METHODINFO ON).

Anonymous said...

Hi Hallvard,

thank you for your answer! It sound promising. So I will wait.

best regards

Ralf Grenzing

Anonymous said...

Hallo, Hallvard!
Again about {METHODINFO ON}
Yes, Borland has such issue on QC

The problem takes place then methods have records as parameters.

Thank you for great articles!

Best regards, DiVi

Hallvards New Blog said...

Yes, I document this restriction(among others) in the article.

I don't consider it a bug, just a as-designed restriction. Records don't have full RTTI either, so it would be rather hard to know what to pass dynamically at runtime if you encountered one of these record parameters.

Anonymous said...

Good article.
But it seems that there is a bug - at least with delphi 7 - arround the indexed properties (like property Items [index: integer]..). In that case the method count is increased by the number of such properties. This is a serious problem, especially if this interface is used as an ancestor or if the property is declared in between normal procedure. Dynamic invokation in that case is just not possible.
If you have any proposal, please tell us !

Hallvards New Blog said...

> indexed properties (like property Items [index: integer]..). In that case the method count is increased by the number of such properties.

Do you have a code example that demonstrates the issue - or have it been reported to QC?

Anonymous said...

I get an error in my previous post so i try it again:

Hi Hallvard,

In order to test the problem, just modify your TestSimpleInterfaceRTTI program by adding such property to IMyInterface:

function GetTest (Index: Integer): integer;
procedure SetTest (Index: Integer; value: Integer);
property Test [Index: Integer]: integer read GetTest write SetTest;

you will get 6 methods and in that case you have only 5 methods plus one property. Further more if you get extended RTTI (M+), you will see that the extra method is named Test and it as only one parameter (the self one) so even that is wrong. Of course, it you try to dynamically call this method, you will just get an error since it is not in the interface table (and that is normal).
Note that the Borland code provided in IntfInfo.pas report the same, so your code is correct :). I believe the bug is in the compiler.

I didn't report it to QC for two reasons. The first one is that I'm working with D7 and there is no chance to get an update.
The second is that this feature is 'undocumented' so I can't report it as is. The only way to get a chance the bug report will take attention is to create a soap object and report the bug in the soap category. Unfortunatly, I have no time to create such project.

If you need more info you can contact me by email at: jgv at flexsys belgium dot com.

Anonymous said...

To avoid the bug with indexed properties: write your own RTTI and use it along with the original one. We did that, and we're happy :)

Anonymous said...

Can you supply the code to get Property-information out of a tkInterface TypeData.

To get extra information about methods you have to point to a packed record immediately after IntfUnit. But where do we have to point to get the property record?

Copyright © 2004-2007 by Hallvard Vassbotn