| |
|
|
- Seite 1 - |
|
| Wer in seiner Anwendung mit sicherheitstechnisch sensiblen Daten hantiert, sollte sehr genau über die Nutzung der Profanfunktion @External nachdenken.
|
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
| 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 | 09.10.2006 ▲ |
|
|
|
|
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 | 09.10.2006 ▲ |
|
|
|
|
| [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 | 09.10.2006 ▲ |
|
|
|
|
| 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?? |
|
|
| |
|
|
|
| Juhu dann mach ichs mit XPSE ja richtig das ich aus Headerfiles genutzte Apis in Calls umwandle... |
|
|
| |
|
|
|
| Ja, deshalb meine Frage hier. |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
| Und wenn ichs richtig verstanden habe dann ist die XPSE-Variante sogar noch sicherer als die External oder Def-Variante da die Funktionsadresse ja gleich beim Programmstart - und nicht erst bei erster Verwendung bezogen wird. |
|
|
| |
|
|
|
| Hallo IF...
Das sehe ich auch so. External und DEF können ja während des Laufens des Programmes umgeleitet werden => - kein ändern von DLLs auf der Festplatte - keine MASM Kenntnisse - keine Kenntnisse von Disassembling
sind dafür nötig. Wenn die Sprungadresse schon beim Start des Programmes feststeht, reicht ein Ändern der Exporttabellen der DLLs im Speicher nicht aus; ich muß direkt die Sprünge im Quelltext der DLL umleiten - und das ist nicht so einfach. Ob man dann überhaupt an die übergebenen Parameter kommt, ist auch fraglich.
Du kannst ja selbst mal mit TNT testen, wie einfach es ist, mit DEF oder External aufgerufene Funktionen umzuleiten. Mein kleiner Test hat 10 Sekunden gedauert.
Gruß
Andreas |
|
|
| |
|
|
|
RGH | [quote:0917fcffa2=Andreas Hötker]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??[/quote:0917fcffa2] Nein, nicht alle Profan-Funktionen erzeugen einen Beep! ;)
Im Ernst: Es ist bei allen Funktionen (außer SQL) so: Die gesamte Windows-API ist natürlich statisch gelinkt. Lediglich die ODBC-DLLs sind aus besagten Gründen dynamisch gelinkt.
Statisch linken geht natürlich nur bei DLLs, die definitiv vorhanden sind und nicht bei DLLs, die fakultativ zur Anwendung kommen.
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 | 09.10.2006 ▲ |
|
|
|
|
| [quote:627b335246=RGH][quote:627b335246=Andreas Hötker]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??[/quote:627b335246] Nein, nicht alle Profan-Funktionen erzeugen einen Beep! ;) [/quote:627b335246]
[quote:627b335246=RGH]Im Ernst: Es ist bei allen Funktionen (außer SQL) so: Die gesamte Windows-API ist natürlich statisch gelinkt. Lediglich die ODBC-DLLs sind aus besagten Gründen dynamisch gelinkt. [/quote:627b335246] Das hört sich sehr gut an. |
|
|
| |
|
|