Hack#12: Create smaller .EXE files ($SetPEFlags)

No, this post is not about so-called EXE-compressors - I don't believe in using them. And it is not a pure hack in the sense that we're breaking any rules - its just about documenting an undocumented and unknown feature of the Delphi 2006 Win32 compiler (it is not implemented in D7 - I don't know about D2005 yet as I don't have it installed on this laptop anymore).

Background info
When you compile a DLL (or a package which is a Delphi-specific DLL in disguise), the linker includes what is known as a relocation table. This table includes information about what addresses must be fixed up by the OS loader in the (likely) event that the DLL must be loaded at a different address than its intended-at-compile/link-time base address. You see all DLLs come with a base address that is the "ideal" loading address of that module. The OS will try to load the DLL at this address to avoid the overhead of runtime rebasing (patching the in-memory pages of the DLL forces it to be paged in from disk and prevents cross-process sharing of the DLL pages). That's why you should set the Image base option in the Linker page of the project options of DLL and package projects. The default Image base that Delphi uses is $00400000 for both applications, DLLs and packages - and thus by default all DLLs and packages will need to be rebased - as that address is reserved for the process' EXE file.

The implication is that an EXE file will always be loaded at the fixed virtual address $00400000 and that it will never need to be rebased. Alas, it doesn't really need its relocation table and we can safely remove it, shrinking the size of the .EXE without affecting its behavior or performance. It is basically a free lunch!

Up until now Delphi users have had to resort to external stripping tools like Jordan Russell's excellent StripReloc tool. It basically takes the name of an .EXE file as a parameter and removes the relocation table from it. I normally don't bother to strip the reloc table during development, but I do run Jordan's tool before deploying our application. This strips a hefty 350 kB from our 7 MB EXE file - a nice, free 5% reduction right there.

As far as I know, most Microsoft tools produces reloc-free EXE files, while Delphi always includes it for both DLLs and EXEs. Up until now. Delphi 2006 actually has a unknown, undocumented compiler directive feature that allows you to turn off the relocation table for EXE files.

To test it out I first opened the ResXplor project from the Demos\DelphiWin32\VCLWin32\ResXplor folder (a pretty neat application, btw). I compiled it as-is. Project | Information told me that the size of the EXE file was 614400 bytes (and Windows Explorer agreed). Then I added the following line to the top of the project file:

{$SetPEFlags 1}

(We'll look at the source of the mysterious value 1 in a moment).

Then I recompiled the project (there is no need to rebuild it, as the unit files does not need to be recompiled - only the linker must be reinvoked). And the size of the EXE file had shrunk to 577536 bytes - that is a reduction of 36864 bytes or 6 %. Not bad for a one-liner, eh? ;).

The Delphi 2006 help file has the following to say about the $SetPEFlags compiler directive:

"Type: Flag
Syntax: {$SetPEFlags <integer expression>} {$SetPEOptFlags <integer expression>}
Scope: Local

Microsoft relies on PE (portable executable) header flags to allow an application to indicate compatiblity with OS services or request advanced OS services. These directives provide powerful options for tuning your applications on high-end NT systems.

These directives allow you to set flag bits in the PE file header Characteristics field and PE file optional header DLLCharacteristics field, respectively. Most of the Characteristics flags, set using $SetPEFlags, are specifically for object files and libraries. DLLCharacteristics, set using $SetPEOptFlags, are flags that describe when to call a DLL's entry point.

The <integer expression> in these directives can include Delphi constant identifiers, such as the IMAGE_FILE_xxxx constants defined in Windows.pas. Multiple constants should be OR'd together."

So it (and the related SetOptPEFlags directive) is a way of informing the OS about the certain aspects of the application. For instance, it can be used to tell the OS that it is ready and compatible with getting access to virtual memory addresses above the 2 GB boundary. Lets look at the IMAGE_FILE constants defined in the Windows.pas unit.

const
  { Relocation info stripped from file. }
  IMAGE_FILE_RELOCS_STRIPPED               = $0001;
  { File is executable  (i.e. no unresolved externel references)}
  IMAGE_FILE_EXECUTABLE_IMAGE              = $0002;
  { Line nunbers stripped from file. }
  IMAGE_FILE_LINE_NUMS_STRIPPED            = $0004;
  { Local symbols stripped from file. }
  IMAGE_FILE_LOCAL_SYMS_STRIPPED           = $0008;
  { Agressively trim working set }
  IMAGE_FILE_AGGRESIVE_WS_TRIM             = $0010;
  { App can handle >2gb addresses }
  IMAGE_FILE_LARGE_ADDRESS_AWARE           = $0020;
  { Bytes of machine word are reversed. }
  IMAGE_FILE_BYTES_REVERSED_LO             = $0080;
  { 32 bit word machine. }
  IMAGE_FILE_32BIT_MACHINE                 = $0100;
  { Debugging info stripped from file in .DBG file }
  IMAGE_FILE_DEBUG_STRIPPED                = $0200;
  { If Image is on removable media, copy and run from the swap file}
  IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP       = $0400;
  { If Image is on Net, copy and run from the swap file. }
  IMAGE_FILE_NET_RUN_FROM_SWAP             = $0800;
  { System File. }
  IMAGE_FILE_SYSTEM                        = $1000;
  { File is a DLL. }
  IMAGE_FILE_DLL                           = $2000;
  { File should only be run on a UP machine }
  IMAGE_FILE_UP_SYSTEM_ONLY                = $4000;
  { Bytes of machine word are reversed. }
  IMAGE_FILE_BYTES_REVERSED_HI             = $8000;

That's a lot of values, but for the purposes of this article, we're really only interested in the first one.

const
  { Relocation info stripped from file. }
  IMAGE_FILE_RELOCS_STRIPPED               = $0001;

That's where our magic number 1 comes from. If we add Windows to the project uses clause, and move the SetPEFlags directive below the uses clause, we can use this more self-documenting directive.

{$SetPEFlags IMAGE_FILE_RELOCS_STRIPPED}

So this tells the OS that the file does not contain any relocation information, and thus it cannot be rebased at runtime. In addition, the Delphi compiler now also picks up on this information and uses it as an instruction to do as you say - leaving out reloc information from the generated EXE file!

Note: The compiler allows using the same directive to remove reloc info from packages and DLLs, but this is not a recommended practice. It will generate slightly smaller DLLs, but the DLL will fail to load unless it can be loaded at its given base address.

Score: Delphi 7 vs. Delphi 2006: 0 - 1 ;)

ODC#2: 1st Oslo Delphi Club event was great!

Unbelievable, but true - only two weeks after the Oslo Delphi Club was created we have 48 members and counting! And on Wednesday September 20th we gathered not less than 21 members to the first ever meeting at the local Peppe's Pizza joint to share good food, beverages, background stories and enthusiasm of Delphi, DevCo and the Oslo Delphi Club.

The room I had booked was packed to the last seat. After getting our first cold glass in hand, we took turns telling about ourselves, our Delphi/ Turbo/Borland Pascal background, our employers/companies, our projects and our ideas, hopes and possible contribution to the future our new-founded club.

Members varied greatly in age, experience and project types, but in common we all had the love in a product and phenomena as splendid as Delphi. We raved about the ingeniousness of a development tool that has followers who will select a product based on the language (read: Delphi) in which it is programmed.

I think that this enthusiasm caters well for the future of Delphi in general and the Oslo Delphi Club in general. If you haven't already, and you're close to Oslo, Norway - be sure to sign up as a member here.

ODC#1: First ever Oslo Delphi Club meeting!

The Oslo Delphi Meetup group has now been created and the first meeting is scheduled to be Wednesday September 20th, at a local pizza place. If you are a Delphi programmer situated in or close to Oslo, make sure you join the group and signup for the meeting.

 

PS. IMO, the Oslo Delphi group hasn't finalized its name yet. The archetypical English name that meetup.com uses is The Oslo Delphi Meetup Group. The current Norwegian name is the awkward "Brukergruppen for Delphi i Oslo" (literally "The user group for Delphi in Oslo) and I'm not satisfied with it. Perhaps "Oslo Delphi Club" could be a swifter, more natural name - it works in both Norwegian and English. We'll probably discuss it at the first meeting - be there if you can!

DN4DP#2: Protecting your privates

This post continues the series of The Delphi Language Chapter teasers from Jon Shemitz’ .NET 2.0 for Delphi Programmers book. Last time we learned about the new kinds of class members that have become available; class fields, class static methods, class properties and class constructors. This time we will look at the new class member visibility specifiers that are available, abstract classes and final methods.

Note that I do not get any royalties from the book and I highly recommend that you get your own copy – for instance at Amazon.

"Protecting your privates

Native Delphi already had four class member visibility levels; private, protected, public and published[1]. One quirk with these is that private and protected members are fully visible to all the code in the unit they are declared in[2], not just the class they are part of (almost like an implicit version of the C++ friend concept). To match .NET's concept of truly private and protected, two new access levels named strict private and strict protected, were introduced. The AppendixDfn\PrivateParts project demonstrates this

type
  TFoo = class
  strict private
    FCantTouchMe: integer;
    FAnyOneAndDelphiRTTI: integer;
  private
    FClassAndUnit: integer;
  strict protected
    FClassAndDescendants: integer;
  protected
    FClassDescendantsAndUnit: integer;
  public
    FAnyOne: integer;
    constructor Create(Report: boolean = True);
  published
    property AnyOneAndDelphiRTTI: integer read FAnyOneAndDelphiRTTI 
  write FAnyOneAndDelphiRTTI;
  end;

Delphi classes can now be explicitly sealed and abstract. The syntax here has the mildly surprising order class sealed and class abstract. The main reason for this is to avoid reserving more language keywords than absolutely necessary – sealed and abstract are directives that only have special meaning after the class reserved word. This means that existing code that already use these identifiers will not break. A sealed class cannot be inherited from and an abstract class cannot be instantiated (even if it does not contain any abstract methods).

Finally, a virtual method that you override can now be marked final, preventing derived classes from overriding that method.

  TAbstractClass = class abstract
  public
    procedure Bar; virtual;
  end;

  TSealedClass = class sealed(TAbstractClass)
  public
    procedure Bar; override;
  end;

  TFinalMethodClass = class(TAbstractClass)
  public
    procedure Bar; override; final;
  end;

---

[1] There is also the obsolete automated section from Delphi 2 – but that is not supported in .NET.

[2] One native Delphi trick is to declare a local descendant of a class in the current unit. Then you hard-cast an object instance into this local class. Now you have access to all the protected members of the object. This hack is so common that the .NET compiler has special logic to handle it too. It does work as long as the original class code is in the same assembly as the hacking code. This is because Delphi’s protected access maps to the .NET family or assembly access level. Similarly, Delphi’s private access maps to the .NET assembly access level, but the Delphi compiler itself enforces the cross-unit privateness."

[Note: This text differs slightly from the final printed version]

Hack#11: Get the GUID of an interface reference

Recently Randy Magruder approached me with a very interesting sounding project he is working on:

"What I'd like to do is effectively add/remove new interfaces to a class at runtime, and invoke them. I have done enough that I can use the OTAServices model in Delphi to pass in additional interfaces, add them to an internal list, and override the QueryInterface behavior to return something in a contained interface list rather than having to declare it on the object."

That really sounds like a very cool (and complicated) project! He continues:

"But if the caller to the object only knows the GUID of the interface he wants, and wants to get back the appropriate interface, and invoke a method on it by name, how would I go about doing that?  Is the extended RTTI with IInvoker the way to go? "

Well, I'm not sure how that can be solved. AFAIK there is no easy mapping from an object implementing interfaces to the typeinfo of those interfaces. One solution might be to implement a registry mapping interface GUIDs to interface typeinfos.

"Also, do you know a way to extract a GUID from an interface instance at runtime, ..."

That should be possible, albeit a little complex. You may recall the little utility routine I wrote to convert a Delphi Win32 interface reference back into the object reference that implements it. It should be possible to morph that function into another function that returns the offset in the object that contains the
interface method table pointer. Combining this with a call to TObject.GetInterfaceTable to get a PInterfaceTable that contains a TInterfaceEntry record for each implemented interface. Compare the
calculated offset with the IOffset field - when you have a match you have the GUID in the IID field.

From System.pas:

 PInterfaceEntry = ^TInterfaceEntry;
 TInterfaceEntry = packed record
   IID: TGUID;
   VTable: Pointer;
   IOffset: Integer;
   ImplGetter: Integer;
 end;
 PInterfaceTable = ^TInterfaceTable;
 TInterfaceTable = packed record
   EntryCount: Integer;
   Entries: array[0..9999] of TInterfaceEntry;
 end;
 TObject = class
   class function GetInterfaceTable: PInterfaceTable;

But that will only work for interfaces that are declared on the class at compile time, of course.

Randy continues his sentence above:

"...even if it's passed in as an IUnknown?"

Eh - you keep making it complicated, aren't you, Randy? ;) The GUID of IUnknown is fixed of course (it's {00000000-0000-0000-C000-000000000046}). And I don't think there is any trace of the interface/GUID that the IUnknown reference was converted from . OTOH, all interfaces inherit from IUnknown so if the IUnknown reference you have really is a sub-interface, it could work [it does -  as we will see in a moment].

After answering Randy's email, I took up the challenge and tried to implement my suggestion solution - getting the GUID of an interface reference. The starting point is the code for Hack#7: Interface to Object - which is able to convert an interface reference back into an object reference of the object that implements the interface (say that fast 5 times ;)).

function GetImplementingObject(const I: IInterface): TObject; 
const 
  AddByte = $04244483;  
  AddLong = $04244481;  
type 
  PAdjustSelfThunk = ^TAdjustSelfThunk; 
  TAdjustSelfThunk = packed record 
    case AddInstruction: longint of 
      AddByte : (AdjustmentByte: shortint); 
      AddLong : (AdjustmentLong: longint); 
  end; 
  PInterfaceMT = ^TInterfaceMT; 
  TInterfaceMT = packed record 
    QueryInterfaceThunk: PAdjustSelfThunk; 
  end; 
  TInterfaceRef = ^PInterfaceMT; 
var 
  QueryInterfaceThunk: PAdjustSelfThunk; 
begin 
  Result := Pointer(I); 
  if Assigned(Result) then 
    try 
      QueryInterfaceThunk := TInterfaceRef(I)^. QueryInterfaceThunk; 
      case QueryInterfaceThunk.AddInstruction of 
        AddByte: Inc(PChar(Result), QueryInterfaceThunk.AdjustmentByte); 
        AddLong: Inc(PChar(Result), QueryInterfaceThunk.AdjustmentLong); 
        else     Result := nil; 
      end; 
    except 
      Result := nil; 
    end; 
end; 

It does look like a lot of gobbledygook, but most of it is actually constant and type declarations to make the code more self-documenting and clear (yeah, right!). The code peaks into the code thunks generated by the compiler to convert an the Self: IInterface call-side parameter into the expected Self: TObject callee-side parameter.

While an object reference points to the first byte of the memory block allocated to hold the object instance fields, an interface reference points inside somewhere in the middle of the object memory block. So the only difference of the two types of reference pointers is a small offset. Our task is to find that offset. As it happens the compiler must fixup the Self reference of a interface method call - and it does this simply by adding a negative offset to the Self pointer before jumping to the actual method implementation. The code above reaches out into the QueryInterface code thunk and uses the offset there to convert the interface reference to an object reference.

To achieve the goal of finding the GUID of an interface reference, we should return the actual offset instead of just using it to generate an object reference. Lets rewrite the function above to do that.

function GetPIMTOffset(const I: IInterface): integer;
// PIMT = Pointer to Interface Method Table
const
  AddByte = $04244483; // opcode for ADD DWORD PTR [ESP+4], Shortint
  AddLong = $04244481; // opcode for ADD DWORD PTR [ESP+4], Longint
type
  PAdjustSelfThunk = ^TAdjustSelfThunk;
  TAdjustSelfThunk = packed record
    case AddInstruction: longint of
      AddByte : (AdjustmentByte: shortint);
      AddLong : (AdjustmentLong: longint);
  end;
  PInterfaceMT = ^TInterfaceMT;
  TInterfaceMT = packed record
    QueryInterfaceThunk: PAdjustSelfThunk;
  end;
  TInterfaceRef = ^PInterfaceMT;
var
  QueryInterfaceThunk: PAdjustSelfThunk;
begin
  Result := -1;
  if Assigned(Pointer(I)) then
    try
      QueryInterfaceThunk := TInterfaceRef(I)^.QueryInterfaceThunk;
      case QueryInterfaceThunk.AddInstruction of
        AddByte: Result := -QueryInterfaceThunk.AdjustmentByte;
        AddLong: Result := -QueryInterfaceThunk.AdjustmentLong;
      end;
    except
      // Protect against non-Delphi or invalid interface references
    end;
end;

As you can see, this is basically the same function as above, but it returns an integer instead of a TObject. The function name is a little geeky - PIMT is short for pointer to interface method table. This is a special compiler generated "field" that is added to an object instance by the compiler when you declare that the class implements an interface. The "field" is a pointer to a kind of virtual method table for the methods declared on the interface. The function returns the offset of this field. Note that the compiler uses an ADD assembly instruction to adjust the Self parameter - but the value added is actually negative. That's why we return the negated value of the adjustment offset.

Now we can rewrite the original GetImplementingObject function in terms of this new, more basic function.

function GetImplementingObject(const I: IInterface): TObject;
var
  Offset: integer;
begin
  Offset := GetPIMTOffset(I);
  if Offset > 0 
  then Result := TObject(PChar(I) - Offset)
  else Result := nil;  
end;

A neat little function - nice to get rid of the duplication. Note that PChar is the only pointer type that allows pointer arithmetic and we cast to it to turn the interface and offset into an object reference.

We're still only the first step towards getting the interface GUID (or IID which is the formally correct name). Now we're able to get the PIMT offset, but the offset by itself isn't very useful. What makes it useful is that we can use the offset to compare it with the offsets stored as part of the InterfaceEntry records the compiler generates for all the interfaces a class implements. As indicated above, we can use the TObject class function called GetInterfaceTable to get a pointer to this table. With that knowledge, let's write a function that tries to find the InterfaceEntry of an interface reference.

function GetInterfaceEntry(const I: IInterface): PInterfaceEntry;
var
  Offset: integer;
  Instance: TObject;
  InterfaceTable: PInterfaceTable;
  j: integer;
  CurrentClass: TClass;
begin
  Offset := GetPIMTOffset(I);
  Instance := GetImplementingObject(I);
  if (Offset >= 0) and Assigned(Instance) then
  begin
    CurrentClass := Instance.ClassType;
    while Assigned(CurrentClass) do
    begin
      InterfaceTable := CurrentClass.GetInterfaceTable;
      if Assigned(InterfaceTable) then
        for j := 0 to InterfaceTable.EntryCount-1 do
        begin
          Result := @InterfaceTable.Entries[j];
          if Result.IOffset = Offset then
            Exit;
        end;  
      CurrentClass := CurrentClass.ClassParent
    end;    
  end;
  Result := nil;  
end;

First we use the the utility functions above to get both the object instance and the offset of the PIMT field. Then we loop across this class and all parent classes looking for an InterfaceEntry that has the same offset as our PIMT field. When we find a match, we return a pointer to the InterfaceEntry record. This record contains both the PIMT offset and the IID. Let's write a simple wrapper function to extract the IID.

function GetInterfaceIID(const I: IInterface; var IID: TGUID): boolean;
var
  InterfaceEntry: PInterfaceEntry;
begin
  InterfaceEntry := GetInterfaceEntry(I);
  Result := Assigned(InterfaceEntry);
  if Result then
    IID := InterfaceEntry.IID;
end;

There - that was a no-brainer. Ok, now we have all the functions and utility punitions in place - now we just need to test that they actually work. Here is my simple test program.

program TestInterfaceGUID;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  HVInterfaceGUID in 'HVInterfaceGUID.pas';

type
  IMyInterface = interface
    ['{ABDA7685-DB67-43C1-947F-4B9535142355}']
    procedure Foo;
  end;
  TMyObject = class(TInterfacedObject, IMyInterface)
    procedure Foo;
  end;  
  
procedure TMyObject.Foo;
begin
end;

var
  MyInterface: IMyInterface;
  Unknown: IUnknown;
  Instance: TObject;
  IID: TGUID;
begin
  MyInterface := TMyObject.Create;
  Instance := GetImplementingObject(MyInterface);
  Writeln(Instance.ClassName);
  if GetInterfaceIID(MyInterface, IID) then
    writeln('MyInterface IID = ', GUIDToString(IID));
  Unknown := MyInterface;  
  if GetInterfaceIID(Unknown, IID) then
    writeln('Dereived IUnknown IID = ', GUIDToString(IID));
  Unknown := TMyObject.Create;
  if GetInterfaceIID(Unknown, IID) then
    writeln('Pure IUnknown IID = ', GUIDToString(IID));
  readln;
end.

This program declares an interface with a method Foo and a class that implements it. Then it creates an instance of the class - assigning it directly to an interface reference. First we test the GetImplementingObject function and write out the name of the implementing class. Then we call GetInterfaceIID three times and print out the resulting GUID. In the first call we use the actual interface directly - if our code is correct, this should work fine. In the second call we have transferred the interface reference into an IUnknown reference. Depending on how the compiler implements interface assignment between assignment compatible interfaces, this may or may not work. We'll see. In the final call we assign a new IUnknown reference a new instance of the class. In this case, we expect the GUID of IUnknown to be returned.

When we run the code we get the following output:

TMyObject
MyInterface IID = {ABDA7685-DB67-43C1-947F-4B9535142355}
Derived IUnknown IID = {ABDA7685-DB67-43C1-947F-4B9535142355}
Pure IUnknown IID = {00000000-0000-0000-C000-000000000046}

Looks like the code works ;). We get the expected results for the class name and the first interface IID. It is also interesting (and useful) that the second "Derived IUnknown IID" returns the IID of the original interface. Unsurprisingly the IID of IUnknown is the one defined by Microsoft. The reason the second IID is preserved is that the Unknown reference is a pure copy of the MyInterface reference. This is the assembly code the compiler generates for the assignment.

  Unknown := MyInterface;  
  mov eax,$0040a7a4
  mov edx,[MyInterface]
  call @IntfCopy

This code calls the RTL routine to copy interfaces, System._IntfCopy, which handles the reference counting of the source and destination interfaces references. So the actual reference stays the same - it only affects the reference count (by calling _AddRef). That's why we get the desirable result with the IMyInterface GUID instead of the IUnknown GUID in the second case.

If the IUnknown interface is assigned using an as-cast, the result it different.

  Unknown := MyInterface as IUnknown;  
  if GetInterfaceIID(Unknown, IID) then
    writeln('As IUnknown IID = ', GUIDToString(IID));

In this case the output is

  As IUnknown IID = {00000000-0000-0000-C000-000000000046} 

We get the IUnknown GUID, not the IMyInterface GUID. The reason is that the compiler generates the as-cast and assignment like this:

  Unknown := MyInterface as IUnknown;  
  mov eax,$0040a7a4
  mov edx,[MyInterface]
  mov ecx,$00408b0c
  call @IntfCast

This version uses System._IntfCast to do the cast and assignment - and looking at the source it uses QueryInterface to perform the conversion. QueryInterface will return another new interface reference (the PIMT field, remember) that TInterfacedObject added for the IUnknown (aka IInterface) interface. This interface has its own IID of course, so we don't get the original IID of IMyInterface that Randy wanted in his original question.

The long string of hex numbers that a GUID consists of isn't very human readable. Some interfaces (particularly COM interfaces), have their IIDs and corresponding name string registered in the registry. For instance, HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{00000000-0000-0000-C000-000000000046} = IUnknown. It is possible to lookup a GUID in the registry to try and find the name string. This is left as an exercise for the reader ;).

Oslo Delphi Meetup Group started!

We have now started the Oslo Delphi Meetup Group (or "Brukergruppen for Delphi i Oslo" as it is called in Norwegian). If you have a chance to participate in upcoming meetings in Oslo and is interested in Delphi (I assume you are - why else would you be here;)) please sign up as a member here.

Membership is free, but using the meetup.com site isn't (there is a monthly fee). For the time being DevCo's Fredrik Haglund is the Organizer (and thus the guy paying the bills) while I'm a Assistant Organizer (so I can manage parts of the site).

When we have reached a minimal membership count, we'll try to organize the first actual meeting somewhere in Oslo. Until then, sign up, answer the first Poll and feel free to start threads in the message board with comments, ideas or questions.

Extended Class RTTI

As has been mentioned earlier, Delphi (since version 7) supports extended RTTI on the methods of a class - by compiling the class with $METHODINFO ON defined. This RTTI includes the signature information of the public and published methods. Delphi uses this to implement scripting of Delphi code in the WebSnap framework - see ObjAuto and friends for the details.

I have now been able to write my own types and routines to dig down and get hold of the extended class RTTI into a format that can easily be used for external consumption. As usual my sample app simply dumps out the source code declaration of a sample class.

While writing the HVMethodInfoClasses unit I refactored some of the earlier code and structures so that I could use as much common code with HVIntefaceMethods and HVMethodSignature.

We're getting used to this RTTI digging now, so lets go through the new code quickly. First there are the additional implementation-detail structures defining the approximate layout of the RTTI the compiler generates - gleaned from the "official" source in ObjAuto.

type
  PReturnInfo = ^TReturnInfo;
  TReturnInfo = packed record
    Version: Byte; 
    CallingConvention: TCallConv;
    ReturnType: PPTypeInfo;
    ParamSize: Word;
  end;
  PParamInfo = ^TParamInfo;
  TParamInfo = packed record
    Flags: TParamFlags;
    ParamType: PPTypeInfo;
    Access: Word;
    Name: ShortString;
  end;

Exactly how to find where these structures start is a little subtle. Remember back to the Under the hood of published methods article? At the time I wrote the following (ignorant to the existence of the $MethodInfo directive and extended class RTTI):

"As you can see above the published method table now has the type PPmt. It points to a record that contains the number of published methods in this class followed by a packed array of TPublishedMethod records. Each record contains a size (used to find the start of the next record), a pointer to the address of the method and a packed shortstring containing the name of the method.
Notice that it appears that the Size field would have been unnecessary. In all my testing the value of Size has always been equal to the expression:

  Size :=  SizeOf(Size) + SizeOf(Address) + SizeOf(Name[0]) + Length(Name);

In other words, the next TPublishedMethod record starts just after the last byte of the method name. I’m not sure why Borland decided to add the Size field, but one possible reason might be to be able to extend the contents of the TPublishedMethod record in the future. One natural extension would be to include information about the parameters and calling convention of the method. Then Size would be adjusted accordingly and old code unaware of the new fields would still work fine"

It turns out that the Size field is indeed used to pack up the TReturnInfo and TParamInfo records just following the Name field of the TPublishedMethod record.

type
  PPublishedMethod = ^TPublishedMethod;
  TPublishedMethod = packed record
    Size: word;  
    Address: Pointer;
    Name: {packed} Shortstring;
  end;

To find and decode the method's signature we have to collect the number of extra bytes as indicated by the Size field. We'll see the code for that shortly.

First, here is the easy to use structure that will hold the decoded RTTI for a single class, including all public/published methods with all their parameters and return types.

type
  // Easy-to-use fixed size structure
  PClassInfo = ^TClassInfo;
  TClassInfo = record
    UnitName: string; 
    Name: string;
    ClassType: TClass;
    ParentClass: TClass;
    MethodCount: Word;
    Methods: array of TMethodSignature;  
  end;

That should be largely self-documenting. As you can see have have reused the same TMethodSignature record as we used for interfaces. Who said you have to write OOP to do re-use ;)? All right, now we're more or less ready to write the actual code to convert a typeinfo of a class to the TClassInfo structure above. This implies getting our hands dirty by iterating over all public/published methods and over all extra RTTI info for each method containing signature info. After a little trial-and-error and a couple of peeks into ObjAuto, I ended up with the following code.

function ClassOfTypeInfo(P: PPTypeInfo): TClass;
begin
  Result := nil;
  if Assigned(P) and (P^.Kind = tkClass) then
    Result := GetTypeData(P^).ClassType;
end;  
  
procedure GetClassInfo(ClassTypeInfo: PTypeInfo; 
  var ClassInfo: TClassInfo);
// Converts from raw RTTI structures to user-friendly Info structures
var
  TypeData: PTypeData;
  i, j: integer;
  MethodInfo: PMethodSignature;
  PublishedMethod: PPublishedMethod;
  MethodParam: PMethodParam;
  ReturnRTTI: PReturnInfo;
  ParameterRTTI: PParamInfo;
  SignatureEnd: Pointer;
begin
  Assert(Assigned(ClassTypeInfo));
  Assert(ClassTypeInfo.Kind = tkClass);
  // Class
  TypeData  := GetTypeData(ClassTypeInfo);
  ClassInfo.UnitName        := TypeData.UnitName;
  ClassInfo.ClassType       := TypeData.ClassType;
  ClassInfo.Name            := TypeData.ClassType.ClassName;
  ClassInfo.ParentClass     := ClassOfTypeInfo(TypeData.ParentInfo);  
  ClassInfo.MethodCount     := GetPublishedMethodCount(ClassInfo.ClassType);
  SetLength(ClassInfo.Methods, ClassInfo.MethodCount);
  // Methods
  PublishedMethod := GetFirstPublishedMethod(ClassInfo.ClassType);
  for i := Low(ClassInfo.Methods) to High(ClassInfo.Methods) do
  begin
    // Method
    MethodInfo := @ClassInfo.Methods[i];
    MethodInfo.Name       := PublishedMethod.Name;
    MethodInfo.Address    := PublishedMethod.Address;
    MethodInfo.MethodKind := mkProcedure; // Assume procedure by default
    
    // Return info and calling convention
    ReturnRTTI := Skip(@PublishedMethod.Name);
    SignatureEnd := Pointer(Cardinal(PublishedMethod) 
      + PublishedMethod.Size);
    if Cardinal(ReturnRTTI) >= Cardinal(SignatureEnd) then
    begin
      MethodInfo.CallConv := ccReg; // Assume register calling convention 
      MethodInfo.HasSignatureRTTI := False;
    end
    else  
    begin
      MethodInfo.ResultTypeInfo := Dereference(ReturnRTTI.ReturnType);
      if Assigned(MethodInfo.ResultTypeInfo) then 
      begin
        MethodInfo.MethodKind := mkFunction;
        MethodInfo.ResultTypeName := MethodInfo.ResultTypeInfo.Name;
      end  
      else 
        MethodInfo.MethodKind := mkProcedure;
      MethodInfo.CallConv := ReturnRTTI.CallingConvention;
      MethodInfo.HasSignatureRTTI := True;
      // Count parameters
      ParameterRTTI := Pointer(Cardinal(ReturnRTTI) + SizeOf(ReturnRTTI^));
      MethodInfo.ParamCount := 0;
      while Cardinal(ParameterRTTI) < Cardinal(SignatureEnd) do
      begin
        Inc(MethodInfo.ParamCount); // Assume less than 255 parameters ;)!
        ParameterRTTI := Skip(@ParameterRTTI.Name);
      end;  
      // Read parameter info
      ParameterRTTI := Pointer(Cardinal(ReturnRTTI) + SizeOf(ReturnRTTI^));
      SetLength(MethodInfo.Parameters, MethodInfo.ParamCount);
      for j := Low(MethodInfo.Parameters) to High(MethodInfo.Parameters) do
      begin
        MethodParam := @MethodInfo.Parameters[j];
        MethodParam.Flags      := ParameterRTTI.Flags;
        if pfResult in MethodParam.Flags 
        then MethodParam.ParamName  := 'Result'
        else MethodParam.ParamName  := ParameterRTTI.Name;
        MethodParam.TypeInfo   := Dereference(ParameterRTTI.ParamType);
        if Assigned(MethodParam.TypeInfo) then
          MethodParam.TypeName := MethodParam.TypeInfo.Name;
        MethodParam.Location   := TParamLocation(ParameterRTTI.Access);
        ParameterRTTI := Skip(@ParameterRTTI.Name);
      end;  
    end;
    PublishedMethod := GetNextPublishedMethod(ClassInfo.ClassType, 
      PublishedMethod);
  end;  
end;  

As usual we test the code by defining some silly code and use RTTI to reconstruct the source of a class declaration. Here is the simplified test project.

program TestHVMethodInfoClasses;
 
{$APPTYPE CONSOLE}
 
uses
  SysUtils,
  TypInfo,
  HVMethodSignature in 'HVMethodSignature.pas',
  HVMethodInfoClasses in 'HVMethodInfoClasses.pas';

procedure DumpClass(ClassTypeInfo: PTypeInfo);
var
  ClassInfo: TClassInfo;
  i: integer;
begin
  GetClassInfo(ClassTypeInfo, ClassInfo);
  writeln('unit ', ClassInfo.UnitName, ';');
  writeln('type');
  write('  ', ClassInfo.Name, ' = '); 
    write('class');
    if Assigned(ClassInfo.ParentClass) then
      write(' (', ClassInfo.ParentClass.ClassName, ')');
    writeln;
  for i := Low(ClassInfo.Methods) to High(ClassInfo.Methods) do
    writeln('    ', MethodSignatureToString(ClassInfo.Methods[i]));
  writeln('  end;');
  writeln;
end;  

type
  {$METHODINFO OFF}
  TNormalClass = class
  end;
  TSetOfByte = set of byte;
  TEnum = (enOne, enTwo, enThree);
type
  {$METHODINFO ON}
  TMyClass = class
  public
    function Test1(const A: string): string; 
    function Test2(const A: string): byte;
    procedure Test3(R: integer);
    procedure Test4(R: TObject); 
    procedure Test5(R: TNormalClass); 
    procedure Test6(R: TSetOfByte); 
    procedure Test7(R: shortstring); 
    procedure Test8(R: openstring); 
    procedure Test9(R: TEnum); 
    function Test10: TNormalClass; 
    function Test11: integer; 
    function Test18: shortstring; 
    function Test19: TObject; 
    function Test20: IInterface; 
    function Test21: TSetOfByte; 
    function Test22: TEnum; 
  end;
 
//... Dummy implementations of TMyClass methods left out...

procedure Test;
begin
  DumpClass(TypeInfo(TMyClass));
end;

begin
  try
    Test;
  except
    on E:Exception do
      writeln(E.Message);
  end;
  readln;
end.

 And the output of the program is:

unit TestHVMethodInfoClasses;
type
  TMyClass = class (TObject)
    function Test1(A: String): String;
    function Test2(A: String): Byte;
    procedure Test3(R: Integer);
    procedure Test4(R: TObject);
    procedure Test5(R: TNormalClass);
    procedure Test6(R: TSetOfByte);
    procedure Test7(R: ShortString);
    procedure Test8(R: ShortString);
    procedure Test9(R: TEnum);
    function Test10(): TNormalClass;
    function Test11(): Integer;
    function Test18(): ShortString;
    function Test19(): TObject;
    function Test20(): IInterface;
    function Test21(): TSetOfByte;
    function Test22(): TEnum;
  end;

The full code is available at CodeCentral.

As my diligent reader, Ralf, pointed out the output of this program is not a verbatim copy of the source code. Aside from my sloppiness of not omitting the empty parens in the functions, the A: string parameters are not declared const. This is because the RTTI for those parameters does not include pfConst (duh!). I think the reason is that the method and parameter RTTI is optimized to achieve dynamic run-time calling of methods and a const modifier does not affect the caller - it only influences the code the compiler generates in the implementation of the method (omitting string ref-counting and a try-finally clause).

In fact, I've been (unsuccessfully so far) lobbying Borland DevCo CodeGear to ease up the compiler and allow having const in the implementation section and non-const in the interface. This might sound like a sloppy request, but it would allow changing the const-ness of a parameter without affecting the interface. Oh well, a story for some other time, perhaps.

[PS. This blog post was edited in Windows Live Writer - I like it, although I goofed up and posted this article too early, probably by accidentally pressing Ctrl+P = publish post ;)].

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