Friday, September 29, 2006

There is an aura of magic around Delphi packages. Packages allow you to share Delphi code at a much higher level than is possible with plain old DLLs. Writing a DLL-based library API involves writing flat non-OOP global routines and avoiding any data types more advanced than integers, doubles, static arrays, PChar and records. You cannot share or exchange classes, objects, global variables or let alone strings (unless the client is a Delphi app and both the DLL and client use ShareMem).

Delphi Package MagicEnter the magic of Delphi packages. Now you no longer have to worry about what you can share between module boundaries, because you can share everything! Packages is just a way of dividing up the logical code into physical deployment modules. Everything just works - somehow. The somehow is the (mainly undocumented) magic.

We're going to look at a small part of that magic - how global variables can be accessed across the application/package boundary. Lets start with the simplest possible case first .

Lets say we have a Unit1 that defines a GlobalVar: integer and some code in the same unit that sets it. Here is the generated assembly and machine code.

That is a single assembly instruction with no indirections or pointer access going on. Notice that both the address of the global variable and the immediate value 13 (encoded as a 16-bit shortint, $000D) is encoded directly inside the machine code instruction. When I evaluate the address of the global variable in the Ctrl+F7 evaluator, @GlobalVar, I get $409298. This is the big-endian value I have highlighted in yellow above.

Then let's look at the package magic situation. If we have a PackageA containing a Unit1 that defines a GlobalVar: integer and a DemoApplication that links to PackageA and with code that access the GlobalVar, the compiler will compile the code into something like this:

Notice the indirection there? Global variables are accessed through a pointer that is fixed up to point to the right address inside the package when the package is loaded. That is cool and a good thing. The global variable itself resides inside the package/DLL module, while the application has a magic, "invisible" global pointer variable that points to the actual package variable. This pointer is fixed up during the magic static loading of packages (it's value is probably set to the result of a GetProcAddress API call).

Global variables in standalone appsNow lets step back a little and look at another common situation. We have looked at the intra-unit situation and the inter-module situation - the two most extreme conditions. But what happens when you access a global variable between units inside the same application? Surely, then the indirection should not be needed? Lets test it.

We write a simple console application consisting of two units, Unit1 and Unit2, and the main program.

Notice the cute little hand-coded breakpoints? Debugger breakpoints are actually implemented by overwriting a byte of your code with the software breakpoint instruction (int 3) which is encoded in a machine code byte $CC. When you run this program with debugging enabled from the IDE, it will break on the two int 3 instructions. Neat, huh? ;)

The first breakpoint is inside Unit1 just above the code that modifies the global variable. This is the case we showed first above. If you run it and follow the instructions to look at the code in the CPU view, you will see that there is no indirection.

The second breakpoint is in Unit2 where we are modifying the global variable from an "external" unit (from a different unit than were the global was declared). Notice that we are still in a single EXE file here, so there should be no need for indirection, as it was in the package case. Run the code again and when it hits the second breakpoint, look at the machine code in the CPU again.

Looks like we still have indirection here...! What is going on? The reason for this (small) inefficiency is that a unit can be moved into or out of a package without being recompiled. So the compiler has to be conservative and generate the unit's code to support the "worst" case that it will be exported for use from a package. The important thing to learn from this is:

By default, all cross-unit global variable access is performed indirectly via a pointer

The implication is that if you have performance critical code that access a global variable, you should cache it in a local variable inside the loop. You can only do this if you do not need to "see" updates to the global variable while the loop is running (think multithreaded code).

For standalone applications that do not use packages at all, it is a bit irritating to know that the compiler generates sub-optimal code for global variable access. While both the performance and size overhead of the indirection should be negligible in most situations, it would still be nice to force the compiler to get rid of this indirection.

$ImportedData OffAnd as it happens there is a compiler directive that does exactly this. Enter the $ImportedData (aka $G) directive. This is what the Delphi help file has to say:

The {$G-} directive disables creation of imported data references. Using {$G-} increases memory-access efficiency, but prevents a packaged unit where it occurs from referencing variables in other packages."

By default the setting is {$ImportedData On} - this enables the pointer indirection in code that access unit-external global variables. By using the {$ImportedData On} directive in a unit, you turn off this indirection, resulting in tighter faster code for global variable access. Notice that you have to use it in every unit referencing global variables, not just in the unit declaring it.

The code here is identical to the code in Unit2, but now we have included the $ImportedData Off directive to tell the compiler generate optimized code for globals. Run the program again and when it stops at the breakpoint in Unit3, look in the CPU view.

This works fine in Delphi 6 and 7. As it happens it no longer works in Delphi 2006 (and probably not 2005). Looks like a bug has sneaked into the compiler here. The directive is effectively ignored, still producing the indirection as we saw for Unit2 above. Hopefully Borland/DevCo will be able to fix this little issue in a future version of the compiler[1].

IDE Compiler OptionsKnowing that $ImportedData Off generates better code for global variable access in a standalone application, we would of course like to set it for all the units in the application as a whole. Unfortunately that is not so easy to do. You see the Project | Options | Compiler Options dialog page does not give access to this option... :(.

Because of this issue you have to use one of the following solutions:

Manually insert {$IMPORTEDDATA OFF} at the top of all units in the project

Manually insert an {$ MyAppSettings.Inc} file in all units. The .inc file would contain settings such as {$IMPORTEDDATA OFF}

Compile using Dcc32.exe setting the option from the command-line

In other words it is a bit awkward to enable this for a given application.

It is hard to set {$ImportedData Off} from the IDE.

I hope that they will be able to make this option available from the compiler options in the IDE in a future version. In fact, I went ahead and reported this as a enhancement request in QC - (please vote for it!):

"Can we please have the $G switch (AKA $IMPORTEDDATA) promoted to appear in the Project Options | Compiler dialog? It makes it easier to switch it off globally for those of us who never use run-time packages."

While it can be argued that introducing this IDE option runs the danger of users producing unusable packages, I don't think this is reason to deny the large number of people writing standalone applications easy access to this option.

The solution could be to only enable this option for projects that are compiled with run-time packages turned off (on the Project Options, Packages page).

Still, if a unit is compiled with IMPORTEDDATA OFF and then moved to a package, it has to be recompiled (i.e. the package project must be rebuilt).

To get around this problem you could:

a) Have the compiler detect this case and recompile all units with the wrong IMPROTEDDATA setting

b) Document the issue and require the user to rebuild himself

c) Combined with b) make the option less obvious and make the IDE compiler options future proof by adding a free-text field for additional compiler options. The user must manually type IMPORTEDDATA OFF in this field, supposedly this makes him qualified to know what he is doing.

The following Dcc32.exe compiler options are currently unavailable from the IDE Compiler Options:

PS. Just as I had finished this piece, I started experimenting some more...;) In Delphi 7 it is actually possible (but still awkward) to compile an application with $ImportedData Off for all units without messing with each unit or the command line compiler.

You only need to

close the project

manually edit the project's .dof file

change "-G+" to "-G-"

save and close the .dof file

reopen the project

rebuild the application

If you compile from the command line you can update the .cfg file in a similar manner.

It is probably possible to do the same in Delphi 2006 by manually editing the XML in the .bdsproj file, changing

<Compiler Name="G">1</Compiler>

to

<Compiler Name="G">0</Compiler>

But it is a little hard to check, because of the Delphi 2006 bug of ignoring the directive. In both cases, the manually set compiler options are preserved even when changing compiler options from the IDE.

Sunday, September 24, 2006

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 infoWhen 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:

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.

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.

Thursday, September 21, 2006

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.

Thursday, September 14, 2006

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!

Tuesday, September 12, 2006

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

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.

[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."

Monday, September 11, 2006

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 theinterface 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 thecalculated offset with the IOffset field - when you have a match you have the GUID in the IID field.

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 ;)).

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.

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.

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.

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.

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.

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.

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.

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 ;).

Thursday, September 07, 2006

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.

Wednesday, September 06, 2006

As has been mentionedearlier, 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.

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:

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.

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.

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 BorlandDevCo 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.