XProfan

là Externe interne même chose ist comment alle DLL Aufrufe, veux Du uns dire, aucun DLL trop nutzen?

08.10.2006 ▲

Nö.

und dir mir um cela Herausfinden qui anzuspringenden Adresse au cours de qui Laufzeit des Quelltextes. cela Einklinken sur den Exporttable qui jeweiligen DLL scheint là besonders simple trop son...

...

car je dois là rien sur qui Festplatte changement et peux direct im grenier aggieren...

...qui paramètre qui Funktion abgreifen et wieder zur Funktion envoyons...

...sans dans irgendeiner Weise Ahnung de MSAM et Diassembling avons trop doit...

...quoi naturellement aussi pour qui Verwendung de APIs aus Headern heraus gelten serait.

RGH

XProfan kennt trois Wege, um Funktionen dans externenDLLs (et somit aussi qui WindowsAPI) aufzurufen:

CALL: qui Aufruf folgt sur qui directe Adresse., en supplément doit alors im XProfan-Programme qui DLL geladen et qui FunktionsAdresse ermittelt volonté. cette Weg ist compliqué (= lente) et nécessaire plusieurs Zeilen im XProfan-Programme. pouvoir eigentlich seulement Sinn, si on, etwa chez COM-Interfaces, seulement qui Adressen zur Disposition hat.

EXTERNAL: qui bevorzugte Weg, là aussi pour Headerfiles approprié: une la ligne im Programme. qui DLL doit pas dans chaque le cas auparavant geladen volonté. (Hängt de qui Funktion ab.) cela magasin qui DLL et cela Ermitteln qui Funktionsadresse volonté im Interpreter bzw. qui Runtime (Delphi-Programme) erledigt.

DEF: qui historische Weg: cela quoi chez Externe direct im Aufruf steht, steht dans qui DEF-la ligne: DLL-nom et Funktionsname. Im Interpreter quelque chose langsamer comme EXTERNAL, im fertigen Programme naturellement pas, là qui Compiler qui Adresse qui DEF-la ligne einträgt et cela DEF pas plus gesucht volonté doit.

EXTERNAL et DEF sommes technique weitgehend identique et es volonté im Interpreter/dans qui Runtime qui gleichen Routinen aufgerufen, à Funktionsadresse trop ermitteln. qui eigentliche Aufruf qui externe Funktion avec Übermittlung qui paramètre ist chez allen trois Varianten dieselbe Routine dans Interpreter et Runtime.

je crois à peine, qui qui Aufruf externer Funktionen aus DLL/APIs dans XProfan plus ou bien moins sicherheitsrelevant ist, comme dans espace den anderen Programmen qui derartige Aufrufe beinhalten ... et ce sont eigentlich alle Windowsprogramme.

BTW: quoi soll Laufzeit des Quelltextes bedeuten? Beim fertigen Programme fonctionne ne...aucune Voir le texte source, mais cela Compilat.

Salut
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

si je avec DEF qui externe Funktion am Anfang meines Programmes deklariere, quand wird ensuite qui dagehörige Sprungadresse ermittelt? Beim prochain Aufrufen qui Funktion im Programme ou bien chez qui Deklaration?

Wird cet Sprungadresse irgendwann ermittelt, au cours de mon Prozess fonctionne, peux je im geladenen Programme qui Exporttables qui DLL changement et so qui aufgerufenen Funktionen abgreifen. Wird qui Adresse beim magasin des Programmes am Anfang meines Quelltextes ermittelt, allez cela pas so simple.

cela allez dans aucun Weise vers Profan, sommes Gedanken zum Programmieren schlechthin...

RGH

Nachtrag:

Einen Unterschied chez DLL-Aufrufen gibt es (allerdings pas dans einem XProfan-Programme):

DLL peut statisch et dynamisch gelinkt volonté:

statisch: ici volonté juste beim Programmstart qui DLL geladen et qui Funktionsadressen gelesen, so dass chez späteren Aufrufen, cet bereits zur Disposition stehen. Vorteil: Ist quelque chose plus rapide et dans den meisten Programmiersprachen (z.B. Delphi) einfacher trop programmieren. le tort: si qui DLL et/ou bien Funktionen pas vorhanden sommes, startet cela Programme pas et Windows meldet, qui une zum Effectuer des Programmes notwendige DLL fehlt.
là qui OpenGL-DLL sur allen de XProfan unterstützten Systemen (ab Windows 95/NT 3.51) vorhanden sommes, sommes cet dans XProfan statisch gelinkt.

dynamisch: ici volonté qui DLL seulement geladen et qui Funktionsadressen ermittelt, si vous im Programme aufgerufen volonté. Vorteil: si bestimmte Funktionalitäten vom Anwender pas nécessaire volonté, braucht il aussi pas qui DLL sur seinem calculateur avons. une Fehlermeldung venez seulement, si le entsprechende Fonctionnalité aufgerufen wird. le tort: c'est un entier petite wenig langsamer et z.B. dans Delphi quelque chose aufwändiger trop implementieren.
qui ODBC-DLL pour qui SQL-Schnittstelle habe je dans XProfan dynamisch gelinkt. XProfan startet alors aussi sur Systemen sans installierte ODBC-Treiber (z.B. Win95/98 sans MS-Office) völlig problemlos, erzeugt mais une Fehlermeldung, si on sur solchen Systemen un SQLInit versucht.

Im XProfan-Programme volonté pour alle avec DEF, EXTERNAL ou bien CALL erzeugten DLL-Aufrufen qui notwendigen DLL dynamisch gelinkt. (cela wäre beim Interpreter aussi gar pas anders possible, là cette oui pas savons peux, quoi pour Schweinereien qui geschätzte Programmierer alles avec ihm programmieren veux.)

Salut
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-part:b7f9a07702=Andreas Hötker]si je avec DEF qui externe Funktion am Anfang meines Programmes deklariere, quand wird ensuite qui dagehörige Sprungadresse ermittelt? Beim prochain Aufrufen qui Funktion im Programme ou bien chez qui Deklaration?[/quote-part:b7f9a07702]
seulement beim Aufruf qui Funktion im Programme. de daher gibt es keinen Unterschied entre DEF et EXTERNAL.

Salut
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-part:b7ae512a2a=RGH]
CALL: qui Aufruf folgt sur qui directe Adresse., en supplément doit alors im XProfan-Programme qui DLL geladen et qui FunktionsAdresse ermittelt volonté. cette Weg ist compliqué (= lente) et nécessaire plusieurs Zeilen im XProfan-Programme. pouvoir eigentlich seulement Sinn, si on, etwa chez COM-Interfaces, seulement qui Adressen zur Disposition hat.[/quote-part:b7ae512a2a]
Beim Aufruf avec Funktionsnamen doit interne aussi seulement qui Funktionsadresse ermittelt volonté, so cela es avec Call IMHO pas länger dauern peux, mais genauso vite son sollte et ab dem 2ten Funktionsaufruf une Geschwindigkeitszuwachs bedeutet.

là es dans qui acte umständlicher ist, lohnt qui Verwendung mais meist pas

RGH

[quote-part:8841b3a260=TS-Soft]Beim Aufruf avec Funktionsnamen doit interne aussi seulement qui Funktionsadresse ermittelt volonté, so cela es avec Call IMHO pas länger dauern peux, mais genauso vite son sollte et ab dem 2ten Funktionsaufruf une Geschwindigkeitszuwachs bedeutet.[/quote-part:8841b3a260]
là XProfan aussi compilé malheureusement toujours pas so vite comment TurboDelphi ist ;) , ist es déjà un kleiner Vorteil, si Delphi qui DLL invite et qui Funktionsadresse ermittelt et pas XProfan.
chez mehrfachem Aufruf derselben Funktion peux cela naturellement kompensiert volonté et ensuite une kleinen Tempo-Vorteil bedeuten.

Salut
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: seulement la fois vielen Dank.

je habs avec TNT grad la fois selbst ausprobiert et qui API MessageBeep aus qui User32 sur qui Funktion MessageBoxA umgeleitet. chez DEF et Externe wird ensuite wirklick MessageBoxA statt MessageBeep fonctionnement. qui sicherere Methode wäre ensuite wirklich qui sur Call et GetProcAddress (wobei GetProcAddress chez Programmstart aufgerufen volonté devrait).

quoi mich gefreut hat,: qui Profanfunktion Beep erzeugte plus un Beep, statt einer Messagebox - je denke la fois, c'est mais pas chez allen Funktionen so - ou bien??