XProfan

Da External intern dasselbe ist wie alle DLL Aufrufe, willst Du uns sagen, keine DLLs zu nutzen?

08.10.2006 ▲

Nö.

Es geht mir um das Herausfinden der anzuspringenden Adresse während der Laufzeit des Quelltextes. Das Einklinken über den Exporttable der jeweiligen DLL scheint da besonders einfach zu sein...

...

denn ich muß da nichts auf der Festplatte ändern und kann direkt im Speicher aggieren...

...die Parameter der Funktion abgreifen und wieder zur Funktion schicken...

...ohne in irgendeiner Weise Ahnung von MSAM und Diassembling haben zu müssen...

...was natürlich auch für die Verwendung von APIs aus Headern heraus gelten würde.

RGH

XProfan kennt drei Wege, um Funktionen in externenDLLs (und somit auch die WindowsAPI) aufzurufen:

CALL: Der Aufruf folgt über die direkte Adresse., Dazu muß also im XProfan-Programm die DLL geladen und die FunktionsAdresse ermittelt werden. Dieser Weg ist umständlich (= langsam) und benötigt mehrere Zeilen im XProfan-Programm. Macht eigentlich nur Sinn, wenn man, etwa bei COM-Interfaces, nur die Adressen zur Verfügung hat.

EXTERNAL: Der bevorzugte Weg, da auch für Headerfiles geeignet: Eine Zeile im Programm. Die DLL muß nicht in jedem Fall vorher geladen werden. (Hängt von der Funktion ab.) Das Laden der DLL und das Ermitteln der Funktionsadresse werden im Interpreter bzw. der Runtime (Delphi-Programm) erledigt.

DEF: der historische Weg: Das was bei External direkt im Aufruf steht, steht in der DEF-Zeile: DLL-Name und Funktionsname. Im Interpreter etwas langsamer als EXTERNAL, im fertigen Programm natürlich nicht, da der Compiler die Adresse der DEF-Zeile einträgt und das DEF nicht mehr gesucht werden muß.

EXTERNAL und DEF sind technisch weitgehend identisch und es werden im Interpreter/in der Runtime die gleichen Routinen aufgerufen, um die Funktionsadresse zu ermitteln. Der eigentliche Aufruf der externen Funktion mit Übermittlung der Parameter ist bei allen drei Varianten dieselbe Routine in Interpreter und Runtime.

Ich glaube kaum, daß der Aufruf externer Funktionen aus DLLs/APIs in XProfan mehr oder weniger sicherheitsrelevant ist, als in all den anderen Programmen die derartige Aufrufe beinhalten ... und das sind eigentlich alle Windowsprogramme.

BTW: Was soll Laufzeit des Quelltextes bedeuten? Beim fertigen Programm läuft kein Quelltext, sondern das Compilat.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Wenn ich mit DEF die externe Funktion am Anfang meines Programmes deklariere, wann wird dann die dagehörige Sprungadresse ermittelt? Beim nächsten Aufrufen der Funktion im Programm oder bei der Deklaration?

Wird diese Sprungadresse irgendwann ermittelt, während mein Prozess läuft, kann ich im geladenen Programm die Exporttables der DLL ändern und so die aufgerufenen Funktionen abgreifen. Wird die Adresse beim Laden des Programmes am Anfang meines Quelltextes ermittelt, geht das nicht so einfach.

Das geht in keiner Weise gegen Profan, sind Gedanken zum Programmieren schlechthin...

RGH

Nachtrag:

Einen Unterschied bei DLL-Aufrufen gibt es (allerdings nicht in einem XProfan-Programm):

DLLs können statisch und dynamisch gelinkt werden:

statisch: Hier werden gleich beim Programmstart die DLLs geladen und die Funktionsadressen gelesen, so dass bei späteren Aufrufen, diese bereits zur Verfügung stehen. Vorteil: Ist etwas schneller und in den meisten Programmiersprachen (z.B. Delphi) einfacher zu programmieren. Nachteil: Wenn die DLLs und/oder Funktionen nicht vorhanden sind, startet das Programm nicht und Windows meldet, daß eine zum Ausführen des Programmes notwendige DLL fehlt.
Da die OpenGL-DLLs auf allen von XProfan unterstützten Systemen (ab Windows 95/NT 3.51) vorhanden sind, sind diese in XProfan statisch gelinkt.

dynamisch: Hier werden die DLLs erst geladen und die Funktionsadressen ermittelt, wenn sie im Programm aufgerufen werden. Vorteil: Wenn bestimmte Funktionalitäten vom Anwender nicht benötigt werden, braucht er auch nicht die DLLs auf seinem Rechner haben. Eine Fehlermeldung kommt erst, wenn die entsprechende Funktionalität aufgerufen wird. Nachteil: Es ist ein ganz klein wenig langsamer und z.B. in Delphi etwas aufwändiger zu implementieren.
Die ODBC-DLLs für die SQL-Schnittstelle habe ich in XProfan dynamisch gelinkt. XProfan startet also auch auf Systemen ohne installierte ODBC-Treiber (z.B. Win95/98 ohne MS-Office) völlig problemlos, erzeugt aber eine Fehlermeldung, wenn man auf solchen Systemen ein SQLInit versucht.

Im XProfan-Programm werden für alle mit DEF, EXTERNAL oder CALL erzeugten DLL-Aufrufen die notwendigen DLLs dynamisch gelinkt. (Das wäre beim Interpreter auch gar nicht anders möglich, da dieser ja nicht wissen kann, was für Schweinereien der geschätzte Programmierer alles mit ihm programmieren will.)

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

[quote:b7f9a07702=Andreas Hötker]Wenn ich mit DEF die externe Funktion am Anfang meines Programmes deklariere, wann wird dann die dagehörige Sprungadresse ermittelt? Beim nächsten Aufrufen der Funktion im Programm oder bei der Deklaration?[/quote:b7f9a07702]
Erst beim Aufruf der Funktion im Programm. Von daher gibt es keinen Unterschied zwischen DEF und EXTERNAL.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

[quote:b7ae512a2a=RGH]
CALL: Der Aufruf folgt über die direkte Adresse., Dazu muß also im XProfan-Programm die DLL geladen und die FunktionsAdresse ermittelt werden. Dieser Weg ist umständlich (= langsam) und benötigt mehrere Zeilen im XProfan-Programm. Macht eigentlich nur Sinn, wenn man, etwa bei COM-Interfaces, nur die Adressen zur Verfügung hat.[/quote:b7ae512a2a]
Beim Aufruf mit Funktionsnamen muß intern auch erst die Funktionsadresse ermittelt werden, so das es mit Call IMHO nicht länger dauern kann, sondern genauso schnell sein sollte und ab dem 2ten Funktionsaufruf einen Geschwindigkeitszuwachs bedeutet.

Da es in der Tat umständlicher ist, lohnt die Verwendung aber meist nicht

RGH

[quote:8841b3a260=TS-Soft]Beim Aufruf mit Funktionsnamen muß intern auch erst die Funktionsadresse ermittelt werden, so das es mit Call IMHO nicht länger dauern kann, sondern genauso schnell sein sollte und ab dem 2ten Funktionsaufruf einen Geschwindigkeitszuwachs bedeutet.[/quote:8841b3a260]
Da XProfan auch compiliert leider immer noch nicht so schnell wie TurboDelphi ist ;) , ist es schon ein kleiner Vorteil, wenn Delphi die DLL lädt und die Funktionsadresse ermittelt und nicht XProfan.
Bei mehrfachem Aufruf derselben Funktion kann das natürlich kompensiert werden und dann einen kleinen Tempo-Vorteil bedeuten.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Vorneweg: Erst mal vielen Dank.

Ich habs mit TNT grad mal selbst ausprobiert und die API MessageBeep aus der User32 auf die Funktion MessageBoxA umgeleitet. Bei DEF und External wird dann wirklick MessageBoxA statt MessageBeep ausgeführt. Die sicherere Methode wäre dann wirklich die über Call und GetProcAddress (wobei GetProcAddress bei Programmstart aufgerufen werden müßte).

Was mich gefreut hat,: Die Profanfunktion Beep erzeugte weiter ein Beep, statt einer Messagebox - ich denke mal, das ist aber nicht bei allen Funktionen so - oder??