Und ist sicherlich ein Thema, wenn es darum geht, Methoden auszuführen oder zu überschreiben, die vom Entwickler einer Klasse so nicht vorgesehen waren. So wie hier mit der TRestClient-Klasse. Ich habe dich doch richtig verstanden?
Ja, richtig. Leider hat Embarcadero schon eine Kunstform daraus gemacht, erweiterte Funktionalitäten so zu verstecken, dass man sie von außen nicht nutzen kann. Dann bleibt leider nur, den Code selbst ein zweites Mal zu schreiben, die
Unit herauszukopieren und zu ändern oder in die Funktionalität einzugreifen wie hier.
Leider stößt man darauf immer wieder, dass Funktionalität in
RTL,
VCL usw. eigentlich schon vorhanden ist, aber leider nicht so genutzt werden kann, wie man es braucht. Das ist wirklich schade, vor allem, weil solche Einschränkungen an einigen Stellen wirklich keinerlei Sinn machen.
Und auch mit Delphi 11 kommt man im konkreten Fall an den Request selbst nicht so einfach heran, kann also andere ggf. nicht unterstützte Optionen weiter nicht ohne solche Tricks über die Windows
API setzen.
Rein interessehalber, funktioniert diese Methodik, dieses "Hooking", generell mit jeder Klasse, egal aus welchem Compilier sie stammt, Borland , M$, C++ / C# / usw., oder nur mit Delphi-Binarys?
Das Prinzip funktioniert mit objektorientierten Sprachen, die ein late binding unterstützen (sprich, wo die konkret aufzurufende Methode aufgrund der Vererbung mit überschreiben usw. zur Laufzeit ermittelt werden muss), recht universell. Ja, z.B. in C++, Java und C# funktioniert das.
Es gibt dafür auch Bibliotheken, so dass man die Umleitung nicht mehr manuell im Speicher machen muss, z.B. DDetours, die Delphi Detours Library. Da ich ohnehin im Speicher herumfummeln musste, um hinterher an das
Handle der Verbindung zu kommen, habe ich es aber manuell gemacht.