XProfan

- page 4 -

RGH

Frank Abbing

Oooch Roland. la hâte mais pas beachtet, cela on im Programme GetProcAdress() pro Funktion seulement EINMAL benutzen muss. Zum Sauver qui Adresse suffisant ensuite une simple Variable.

Oooch Frank, la hâte Du pas beachtet, qui mon erstes Programme GetProcAdress() aussi seulement einmal aufruft et cela zweite seulement en supplément dient, den Zeitaufwand entre GetProcAdress() et LoadLibrary() trop comparer, à déterminer, qui beim dynamischen Aufruf qui Zeit verbrät?

si je dans XProfan cela dynamische Linken bevorzuge, ensuite doit je qui Adresse ensuite bestimmen, si le Funktion cela erste la fois verwandt wird. si vous ensuite à anderer Stelle im Programme wieder verwandt wird, doit je vous wieder bestimmen ou bien je devrait dans einer Tabelle nachsehen, si qui bereits bekannt (et encore gültig) ist et vous ensuite verwenden. cela wäre zusätzlicher Verwaltungsaufwand.

l'autre Alternative ist qui Umwandlung dans une statischen Aufruf, so comme qui XPSE (et mon obiges Beispiel) pouvoir. là cela chez zeitkritischen Dingen Sinn faire peux, habe je oui bereits vorgeschlagen, cela dans qui prochain XProfan-Version comme Alternative einzubauen. Comme je le disais: beide Varianten avons ses avant- et Nachteile.

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

27.03.2007 ▲

Frank
Abbing

et cela zweite seulement en supplément dient, den Zeitaufwand entre GetProcAdress() et LoadLibrary() trop comparer, à déterminer, qui beim dynamischen Aufruf qui Zeit verbrät?

comment déjà dit - am Thema vorbei.

Es liegt mir loin dir quelque chose vorschreiben trop voulons et j'aime solche Diskussionen aussi gar pas. tu as ici une Possibilité qui Effizienz de XProfan encore trop steigern. quoi du letztendlich daraus fais, et si et comment du qui Kritik deiner User umsetzt, ist deine l'affaire.

allô Roland...

la fois trop deinem Code:
peux es son, dass du là quelque chose mogelst? Usedll mais est un statischer Aufruf et GetProcAdress - wird cela là pas dynamisch aufgerufen???

allô Frank...

la hâte du dir den Quellcode la fois angesehen? je hab reingesehen... cela hat avec cela mais rein gar rien trop 1faire.

suis alles autre comme un Experte pour ASM. quoi mach qui Code de GetProcAdress car oui c'est ca? Durchsucht qui pas den Table pour qui angegebenen Funktion?
Lerne volontiers quoi en supplément.

wohin liegt qui Denkfehler dans folgendem Code:
Kompilieren Marque Séparation

 $H Windows.ph        WindowsHeaderdatei nutzen
Declare hDLL&, Time&, DLL$,LoadLibraryA&,GetProcAddress&,Funktion$,StringAddr&
LET DLL$=Kernel32.DLL
hDLL& = ~LoadLibraryA(@addr(DLL$))
LET Funktion$=GetProcAddress
LET GetProcAddress&=~GetProcAddress(hDLL&, @addr(Funktion$))
LET Funktion$=LoadLibraryA
LET LoadLibraryA&=~GetProcAddress(hDLL&, @addr(Funktion$))
LET DLL$=USER32.DLL
hDLL& = ~LoadLibraryA(@addr(DLL$))
Print Ohne irgendwas: ;
Time& = &GetTickCount

whileLoop 1, 100000

endwhile

print Int(&GetTickCount - Time&)
LET DLL$=$SYSPATH+USER32.DLL
Print LoadLibraryA +DLL$+ :;
StringAddr& = addr(DLL$)
Time& = &GetTickCount

whileLoop 1, 100000

    call(LoadLibraryA&,StringAddr&)

endwhile

print Int(&GetTickCount - Time&)
LET DLL$=USER32
Print LoadLibraryA +DLL$+ :;
StringAddr& = addr(DLL$)
Time& = &GetTickCount

whileLoop 1, 100000

    call(LoadLibraryA&,StringAddr&)

endwhile

print Int(&GetTickCount - Time&)
Print GetProcAdress ActivateKeyboardLayout: ;
Let Funktion$=ActivateKeyboardLayout
StringAddr& = addr(Funktion$)
Time& = &GetTickCount

whileLoop 1, 100000

    call(GetProcAddress&,hDLL&, StringAddr&)

endwhile

print Int(&GetTickCount - Time&)
Print GetProcAdress wvsprintfW: ;
Let Funktion$=wvsprintfW
StringAddr& = addr(Funktion$)
Time& = &GetTickCount

whileLoop 1, 100000

    call(GetProcAddress&,hDLL&, StringAddr&)

endwhile

print Int(&GetTickCount - Time&)
waitinput

ss=s4 href='./../../funktionsreferenzen/XProfan/end/'>end

RGH

Andreas Hötker

quoi mach qui Code de GetProcAdress car oui c'est ca? Durchsucht qui pas den Table pour qui angegebenen Funktion?

c'est arrêt une API-Funktion, qui qui absolute Adresse einer Funktion eines geladenen Moduls zurückgibt. comment vous cela fait, entzieht sich meiner Kenntnis. là Microsoft sa Quellcodes (weitestgehend C et C++ avec ASM-partager) pas veröffentlicht, ist es aussi pas entier simple cela herauszubekommen. (Aussi serait cela eh pas weiterhelfen.)
je vermute mais simple folgendes: une DLL contient dans ihrem En-tête une liste qui dans son exportierten Funktionen avec den Einsprungadressen. je prends daher à, qui GetProcAdress sur cela Handle qui DLL sur cet liste zugreift.

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

- page 5 -

RGH

Andreas Hötker

allô Roland...

la fois trop deinem Code:
peux es son, dass du là quelque chose mogelst? Usedll mais est un statischer Aufruf et GetProcAdress - wird cela là pas dynamisch aufgerufen???

non, je suis Je ne bewußt trop mogeln. mais peut-être devrait wir fois le Begriffe dynamisch et statisch dans diesem Zusammenhang klären:

dynamisch
si je une DLL dynamisch linke, bedeutet cela, qui je seulement ensuite sur qui DLL zugreife, si es qui justement ausgeführte Code réellement nécessaire. Habe je z.B. dans einem Grafikprogramm une Lade-Routine pour un exotisches Grafikformat, cela une teure externe DLL nécessaire, so peux je chez dynamischem Zugriff sur qui DLL aussi sans DLL avec diesem Programme travailler, so longtemps je aucun Dossier cet Formates magasin voudrais. qui Programmteil, qui cet DLL dynamisch verwendet, wird plan nie aufgerufen. cette dynamische Aufruf geschieht, quelque chose vereinfacht sans Fehlerbehandlung et Parameterverwaltung, avec folgendem Code:
Kompilieren Marque Séparation

hDLL := LoadLibrary(DLL-Name)
aFunc := GetProcAdress(hDLL, Funktions-Name)
call(aFunk, Parameter)
FreeLibrary(hDLL)pre>

Wobei, comment dessus dargelegt, LoadLibrary seulement ensuite qui DLL physikalisch de Platte dans den grenier läft, si vous encore pas geladen ist et FreeLibrary seulement ensuite den grenier qui DLL freigibt, si qui erwähnte Zähler sur 0 allez. quoi à qui statischen variante chaque fois anfällt et den Zeitunterschied ausmacht, ist cela GetProcAdress().

statisch
si je une DLL statisch linke, ensuite bedeutet cela, qui qui im Programme benutzten Funktionsadressen seulement einmal, et zwr am Anfang des Programmes avec LoadLibrary et GetProcAdress ermittelt volonté et im weiteren Verlauf seulement encore Calls sur qui bekannten Adressen nötig sommes. qui Vorteil ist qui höhere Geschwindigkeit*, qui le tort plan, qui cela Programme grundsätzlich pas startet, si le DLL fehlt. (cet ließen sich allerdings par geschickte Programmation plus ou bien moins ausgleichen.)
alors brauchst Du aussi ici, allerdings seulement einmal am Anfang des Programmes, LoadLibrary et GetProcAdress. Im Programme erfolgt ensuite seulement encore qui Aufruf avec Call (aussi ici verkürzt à Parameterverwaltung):
Kompilieren Marque Séparation

call(aFunk, Parameter)

aFunk ist ici qui globale Variable, qui qui Adresse qui Funktion beim Programmstart zugewiesen wurde. là ici GetProcAdress verwandt wurde, ist cet variante naturellement plus rapide, quoi sich chez Programmem avec vielen API-Aufrufen naturellement bermerkbar pouvoir. Diesen Weg allez iF avec XPSE et erreicht daher den Tempozuwachs.

qui meisten Programmiersprachen erlauben beide Varianten qui DLL-Bindung, so aussi Delphi, dans dem XProfan geschrieben ist. So sommes chez mir qui ODBC-Aufrufe dynamisch gelinkt, cela est: XProfan startet aussi sur Rechnern sans installierte ODBC-Treiber (Windows 95 kam encore sans cet Treiber sur den marché). qui OpenGL-Aufrufe (sur qui OGL-Funktion) sommes statische gelinkt, là es ici a) um Tempo allez et b) alle XProfan-fähigen Windowsversionen OpenGL de Hause aus à Bord avons. sans OpenGL serait XProfan pas starten.

Salut
Roland

* combien cela oui c'est ca ausmacht, hängt naturellement de qui jeweiligen API-Funktion ab. chez aufwändigen API-Funktionen wird qui Tempovorteil à peine ins Gewicht tomber, au cours de il chez einfachsten API-Funktionen, qui selbst seulement solange comment cela GetProcAdress brauchen, ensuite naturellement une la quantité ausmacht!

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

allô Roland - encore la fois zum mogeln...

Wir hatten cela déjà la fois:
Ist es chez den Profanfunktionen (ici usedll) pas so, cela là qui Adresse bereits beim Aufrufen des Programmes ermittelt wird?

~GetProcAdress pourrait mais GetProcAdress seulement beim Aufruf qui Funktion appel - ist cela richtig? Verschaffst du avec cela Usedll (ici LoadLibraryA - tout autor ca va oui ) pas une ungerechten Vorteil?

Müssten pas beide Funktionen sur Call aufgerufen volonté, um überhaupt seulement einmal gleiche Voraussetzungen trop créer?

qui Frage quoi mach GetProcAdress oui c'est ca? était à Frank gerichtet, qui sich oui qui Funktion angesehen hat -
quand même merci!

@Frank:
cela, wohin geladene Module gespeichert volonté, stinkt pour mich pour einer LDR_DATA_TABLE_ENTRY Struktur, alors einer doppelt verlinkten liste, comment je vous de MIster Racine et Fu her kenne. dedans einer solchen Struktur wird aussi qui Loadcount gespeicheit - voilà pas viel grenier trop scannen.
qui API GetProcAdress wird wohl den Exporttable einer DLL scannen, et là peut locker 1000 verschiedene Funktionen drin stehen - mais par-dessus wirst du mich wohl encore oui c'est ca aufklären

(veux je jedenfalls espérer).

Frank
Abbing

qui API GetProcAdress wird wohl den Exporttable einer DLL scannen, et là peut locker 1000 verschiedene Funktionen drin stehen - mais par-dessus wirst du mich wohl encore oui c'est ca aufklären (veux je jedenfalls espérer).

je versuchs. Hab naturellement aussi seulement den disassemblierten Quellcode vorliegen, là ist es pas so simple trop erkennen, quelle Tabellen comment wohin vorliegen.
Zuersteinmal wird geprüft, si im paramètre qui twain_32.dll gemeint ist. si oui, wird Schonmal un d'autre procéder angewendet.
Ansonsten wird erstmal API qui NT.Dll aufgerufen. Stringvergleiche/umwandlungen (A/W) et quelque chose comme.
ensuite wird Heap-grenier angefordert et après dans den verschiedenen Systemdirectories nachgesehen, si qui Dll überhaupt vorliegt, et dans quel Version. et wieder zurück zur NT.Dll, wohin wohl qui eigentliche Test weitergeht. là hab je aussi nachgesehen. und dir là tief ins System hinein, avec Aufruf de allerhand (undokumentierten) Lowlevel-APIs avec vielen Zugriffen sur grenier et Directories. Scheint une echte Schatzkiste trop son, cet Dll.
Alles dans Allem alors nix plan la fois Handle hochzählen...

quoi là sonst encore passiert, hat mais rien avec grenier pour Handles scannen trop 1faire, cela allez très vite, là es sich là um une LDR_DATA_TABLES_ENTRY Struktur handelt, qui doppelt verlinkt ist.
U.a. wird là dans LoadLibraryA qui Pfad qui DLL überprüft - USER32 / USER32.dll / $SYSPATH+/USER32.dll verweisen oui sur qui gleiche DLL, et qui DLL soll là pas nochmals geladen volonté. la hâte du dir la fois la fois meinen Voir le texte source-Test angesehen? cela sieht es déjà entier anders aus, avec dem Ergebnis, comme Rolands Test.
fais je là irgendwelche gedanklichen faute???

je crois, Roland verschafft là dans seinem Code LoadLibraryA une ungerechten Vorteil.

RGH

Andreas Hötker

allô Roland - encore la fois zum mogeln...

Ah, maintenant verstehe je, quoi Du meinst! oui, là la hâte Du probablement droite. cela J'ai eu übersehen. SORRY!

So devrait getestet volonté:
Kompilieren Marque Séparation

 $H Windows.ph        WindowsHeaderdatei nutzen
Die zu vergleichenden Funktionen statisch linken
Declare hDLL&, LoadLibrary&, GetProcAddress&
hDLL& = UseDLL(KERNEL32.DLL)
LoadLibrary& = ~GetProcAddress(hDLL&, LoadLibraryA)
GetProcAddress& = ~GetProcAddress(hDLL&, GetProcAddress)
print LoadLibrary&
print GetProcAddress&
print
Declare Time&
hDLL& = UseDLL(USER32.DLL)
Print UseDLL: ;
Time& = &GetTickCount

whileLoop 1, 100000

    Call(LoadLibrary&, USER32.DLL)

endwhile

print Int(&GetTickCount - Time&)
Print GetProcAdress: ;
Time& = &GetTickCount

whileLoop 1, 100000

    Call(GetProcAddress&, hDLL&, GetWindowTextA)

endwhile

print Int(&GetTickCount - Time&)
waitinput
end

... et ensuite brauchen vous beide ungefähr juste long. là était je wohl im Irrtum.

comment dem aussi sei: Beim statischen Linken braucht on beide seulement beim Start et après pas plus, so dass dadurch qui Tempogewinn erzielt wird.

Salut
Roland
(hat déjà idées, cela statische Linken dans XProfan 11 komfortabler trop gestalten)

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

Frank
Abbing

Na cela hört on oui volontiers.

cela cela Ganze doch encore une Sinn gehabt.