| |
|
|
- Page 1 - |
|
| Wer in seiner Anwendung mit sicherheitstechnisch sensiblen Daten hantiert, sollte sehr genau circa die Nutzung der Profanfunktion @External nachdenken.
|
|
|
| |
|
|
|
| |
|
- Page 1 - |
|
| 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 | 09.10.2006 ▲ |
|
|
|
|
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 | 09.10.2006 ▲ |
|
|
|
|
| [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 | 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 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?? |
|
|
| |
|
|
|
| Juhu dann mach ichs mit XPSE ja richtig das ich aus Headerfiles genutzte Apis in Calls umwandle... |
|
|
| |
|
|
|
| Ja, deshalb meine Frage hier. |
|
|
| |
|
|
| |
|
- Page 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 Programmi umgeleitet werden => - kein ändern von DLL auf der Festplatte - keine MASM Kenntnisse - keine Kenntnisse von Disassembling
sind dafür nötig. Wenn die Sprungadresse schon beim Start des Programmi feststeht, reicht ein Ändern der Exporttabellen der DLL 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.
Saluto
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 naturalmente statisch gelinkt. Lediglich die ODBC-DLL sind aus besagten Stabilire dynamisch gelinkt.
Statisch linken geht naturalmente nur bei DLL, die definitiv vorhanden sind und nicht bei DLL, die fakultativ zur Anwendung kommen.
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 | 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 naturalmente statisch gelinkt. Lediglich die ODBC-DLL sind aus besagten Stabilire dynamisch gelinkt. [/quote:627b335246] Das hört sich sehr gut an. |
|
|
| |
|
|