Leaderboard

In case this of use to anyone: Quite often you find a bug in Delphi RTL and you come up with a fix. Patching involves replacing the RTL procedure with a new patched one. To do that you can use your favorite patching routine or library (I use Detours), but you need the address of the original function/method. a) Patching a non-virtual public method This is quite straight-forward: type TMethodType = procedure ... of object function GetAddress: Pointer; var MethodPtr : TMethodType; begin MethodPtr := TRTLClass(nil).PublicMethod; Result := TMethod(MethodPtr).Code; end; Note the type cast TRTLClass(nil). b) Patching a virtual public method If for example PublicMethod is virtual the above type cast TRTLClass(nil) with result in access violation, since to resolve the virtual method you need to access Self which is nil. You could create a class instance and use that instead of TRTLClass(nil), but apart from not being elegant, in some cases this has side-effects (for example it may require a valid windows handle). The trick is described in this Stackoverflow question. function GetAddress: Pointer; var VMT : NativeInt; MethodPtr: TMethodType; begin VMT := NativeInt(TRTLClass); MethodPtr := TRTLClass(@VMT).PublicMethod; Result := TMethod(MethodPtr).Code; end; This is based on two facts. A class is a pointer to the Virtual Method table (VMT) and an Object structure has as the first field a pointer to the VMT of its class. c) Patching a private virtual method The trick this time involves using a class helper to access the private method of the TRTLClass type TPrivateMethodType = procedure ... of object; TRTLClassHookFix = class helper for TRTLCLass function GetPriveMethodAddr: Pointer; end; function TRTLClassHookFix.GetPriveMethodAddr: Pointer; var VMT : NativeInt; MethodPtr: TPrivateMethodType; begin // Adjust Self to point to the VMT VMT := NativeInt(TRTLCLass); Self := TRTLCLass(@VMT); with Self do MethodPtr := PrivateMethod; Result := TMethod(MethodPtr).Code; end; That's it.

I would only use SQLLite for smaller mobile projects. I have found that Firebird 3.04 performance is much better than SQLLite on my laptop and it has a richer set of data types and more features.

Totally agree with you.

I have a Pixel 3a running in 64-bit mode with 4GB of RAM.

New version 13.5.0 released! + TMiTeC_SMBIOS WindowsProductKey property added - contains Windows Product Key read from ACPI.MSDM table + TMiTeC_SMBIOS UEFIGUID property added - contains UEFI GUID read from ACPI.UEFI table + TMiTeC_SMBIOS - SMBIOS 3.3 compliance * TProcMonThread handles enumeration fixed * TProcMonThread Process monitor memory leak fixed + TProcMonThread Average CPU usage added to thread record, many new properties added, DpiAwareness detection enhanced * TMiTeC_EventLog message expansion precised + TMiTeC_OperatingSystem Application theme mode and system theme mode detection added + TMiTeC_EventLog WinEvt API implemented (MiTeC_WinEvt.pas) + Library for working with certificates rewritten and greatly improved (MiTeC_Cert.pas) + TProcListMonThread new TotalProcessPrivateBytes and TotalProcessWorkingSet properties, DpiAwareness detection enhanced + TSysMonThread new PagedPool and NonPagedPool class functions + TMiTeC_CPU Physical CPU and Thread count calculation fixed For more information about the library, download locations and documentation, see the MiTeC System Information Component Suite Home Page

1) DB admin features - PostgreSQL 2) DB developer features - PostgreSQL / FireBird 3) Encryption, and ... speed - InterBase. On many tests IB outperforms FB, at least. 4) Mobile platforms - InterBase 5) Change Views is unique InterBase feature If to put SQLite into this list, then if you does not need multi-user access, scalability, DB is relatively small, then SQLite is the right way. If something from this list is not true, or may become false in future, then not SQLite. In order of descending preferences - SQLite, IbToGo / Firebird embedded, PostgreSQL

Interbase and FireBird also got embedded versions without the need of a server. The databse files are compatible to the server version.

PODBALMMSG2 = ^ODBALMMSG2; ODBALMMSG2 = packed record alm_no: LongInt; atype: SmallInt; axis: SmallInt; dummy: SmallInt; msg_len: SmallInt; alm_msg: array [0 .. 63] of AnsiChar; end; In Delphi，if you has code like this: procedure DoSometiing(xxxxx: xx); var MyR: ODBALMMSG2 begin ////do something... end; Here, you got a record MyR, its memory is prepared statically. It is a instance, you can use it directly. And the pointer of this instance is: @MyR. If you has code like this: procedure DoSometing(xxx: xxx); var MyR_P: PODBALMMSG2 begin /// Here, MyR_P is a pointer that type is PODBALMMSG2 but it is a pointer, you can just use a normal pointer type instead PODBALMMSG2. /// Here, MyR_P is just a variable, there is no instance, no memory that store data. If you want use it, you must allocate memory for it. And, you must free the memory when you want to give up it. MyR_P := GetMem(SizeOf(ODBALMMSG2)); try do something... finally FreeMem(MyR_P); end; /// or, you can use this function: New(MyR_P); try Do something.... finally Dispose(MyR_P); end; end;

http://rvelthuis.de/articles/articles-pointers.html

Updating a single application even if complex is not a hard task, almost every other major IDE out there can do it. Only Delphi developers have to manually apply hotfixes by unzipping some archive and unblock the contained binaries...