XProfan

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

08.10.2006 ▲

Nö.

Es geht mir um das Herausfinden der anzuspringenden Adresse während der Laufzeit des Quelltextes. Das Einklinken circa 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 naturalmente auch per 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 circa die direkte Adresse., Dazu muß also im XProfan-Programm die DLL geladen und die FunktionsAdresse ermittelt werden. Dieser Weg ist umständlich (= langsam) und necessario 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 per 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 naturalmente 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 DLL/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 corre kein Quelltext, sondern das Compilat.

Saluto
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 Programmi 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 corre, kann ich im geladenen Programm die Exporttables der DLL ändern und so die aufgerufenen Funktionen abgreifen. Wird die Adresse beim Laden des Programmi 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):

DLL können statisch und dynamisch gelinkt werden:

statisch: Hier werden gleich beim Programmstart die DLL 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 DLL und/oder Funktionen nicht vorhanden sind, startet das Programm nicht und Windows meldet, daß eine zum Ausführen des Programmi notwendige DLL fehlt.
Da die OpenGL-DLL 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 DLL erst geladen und die Funktionsadressen ermittelt, wenn sie im Programm aufgerufen werden. Vorteil: Wenn bestimmte Funktionalitäten vom Anwender nicht necessario werden, braucht er auch nicht die DLL 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-DLL per 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 per alle mit DEF, EXTERNAL oder CALL erzeugten DLL-Aufrufen die notwendigen DLL dynamisch gelinkt. (Das wäre beim Interpreter auch gar nicht anders possibile, da dieser ja nicht wissen kann, was per Schweinereien der geschätzte Programmierer alles mit ihm programmieren will.)

Saluto
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 Programmi 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.

Saluto
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 circa die direkte Adresse., Dazu muß also im XProfan-Programm die DLL geladen und die FunktionsAdresse ermittelt werden. Dieser Weg ist umständlich (= langsam) und necessario 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 naturalmente kompensiert werden und dann einen kleinen Tempo-Vorteil bedeuten.

Saluto
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 corsa. Die sicherere Methode wäre dann wirklich die circa 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??