XProfan

- Página 4 -

RGH

Frank Abbing

Oooch Roland. Hast pero no beachtet, el uno en el Programa GetProcAdress() pro Función sólo EINMAL benutzen muss. Zum Guardar el Adresse genügt entonces una simple Variable.

Oooch Franco, hast No beachtet, daß mein erstes Programa GetProcAdress() auch sólo una vez aufruft y el zweite sólo dazu dient, el Zeitaufwand zwischen GetProcAdress() y LoadLibrary() a vergleichen, para determinar, wer beim dynamischen Aufruf el Tiempo verbrät?

Wenn Yo en XProfan el dynamische Linken bevorzuge, entonces muß Yo el Adresse entonces bestimmen, si la Función el erste Tiempo verwandt se. Wenn ellos entonces a otro Punto en el Programa otra vez verwandt se, muß Yo ellos otra vez bestimmen oder Yo müßte en uno Tabla nachsehen, si el ya bekannt (y todavía gültig) es y ellos entonces uso. Das wäre zusätzlicher Verwaltungsaufwand.

El otro Alternative Es el Umwandlung en una statischen Aufruf, ya que el XPSE (y mein obiges Ejemplo) macht. Como en el zeitkritischen Dingen Sinn hacer kann, Yo sí ya vorgeschlagen, el en el nächste XProfan-Versión como Alternative einzubauen. Como ya he dicho: beide Varianten haben ihre Vor- y Nachteile.

Saludo
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

y el zweite sólo dazu dient, el Zeitaufwand zwischen GetProcAdress() y LoadLibrary() a vergleichen, para determinar, wer beim dynamischen Aufruf el Tiempo verbrät?

Como ya dijo - al Thema vorbei.

Lo liegt me fern dir algo vorschreiben a querer y yo mag solche Diskussionen auch nada. Usted hast hier una Möglichkeit el Effizienz de XProfan todavía a steigern. Was du letztendlich lo machst, y si y cómo du el Kritik deiner User umsetzt, es deine Sache.

Hola Roland...

Tiempo a deinem Code:
Kann lo ser, dass du como algo mogelst? Usedll es doch una statischer Aufruf y GetProcAdress - se el como no dynamisch aufgerufen???

¡Hola Franco...

Hast du dir el Quellcode veces angesehen? Yo reingesehen... Das ha así aber rein gar nichts a tun.

Bin alles otro como una Experte para ASM. Was mach el Code de GetProcAdress porque genau? Durchsucht el no el Table después de el angegebenen Función?
Lerne gerne qué dazu.

Wo liegt el Denkfehler en folgendem Code:
Kompilieren Marca Separación

 $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

Was mach el Code de GetProcAdress porque genau? Durchsucht el no el Table después de el angegebenen Función?

Es sólo una API-Función, el el absolute Adresse uno Función uno geladenen Moduls zurückgibt. Como ellos el macht, entzieht se meiner Kenntnis. Como Microsoft seine Quellcodes (weitestgehend C y C++ con ASM-Teilen) no veröffentlicht, es auch no bastante simplemente el herauszubekommen. (Außerdem sería el eh no weiterhelfen.)
Yo vermute aber simplemente folgendes: Un DLL enthält en ihrem Encabezamiento una Liste el en ihr exportierten Características con el Einsprungadressen. Yo nehme por lo tanto a, daß GetProcAdress encima el Handle el DLL en esta Liste zugreift.

Saludo
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

- Página 5 -

RGH

Andreas Hötker

Hola Roland...

Tiempo a deinem Code:
Kann lo ser, dass du como algo mogelst? Usedll es doch una statischer Aufruf y GetProcAdress - se el como no dynamisch aufgerufen???

Nein, Yo bin No bewußt a mogeln. Aber tal vez debería wir veces el Begriffe dynamisch y statisch en diesem Zusammenhang klären:

dynamisch
Wenn Yo una DLL dynamisch linke, bedeutet el, Yo sólo entonces en el DLL zugreife, si el gerade ausgeführte Code tatsächlich benötigt. Posesiones Yo z.B. en un Grafikprogramm una Lade-Rutina para una exotisches Grafikformat, el una teure externe DLL benötigt, así kann Yo en dynamischem Zugriff en el DLL auch sin DLL con diesem Programa trabajo, así largo Yo no Expediente dieses Formates invitar möchte. Der Programmteil, el esta DLL dynamisch verwendet, se eben nie aufgerufen. Dieser dynamische Aufruf geschieht, algo vereinfacht sin Fehlerbehandlung y Parameterverwaltung, con folgendem Code:
Kompilieren Marca Separación

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

Wobei, como oben dargelegt, LoadLibrary sólo entonces el DLL physikalisch de Platte en el Speicher läft, si ellos todavía no geladen es y FreeLibrary sólo entonces el Speicher el DLL freigibt, si la erwähnte Zähler en 0 va. Was gegenüber el statischen Variante jedesmal anfällt y el Zeitunterschied ausmacht, es el GetProcAdress().

statisch
Wenn Yo una DLL statisch linke, entonces bedeutet el, daß el en el Programa benutzten Funktionsadressen sólo una vez, y zwr al Anfang des Programmes con LoadLibrary y GetProcAdress ermittelt y ser en el más Progreso sólo todavía Calls en el bekannten Adressen nötig son. Der Vorteil Es el höhere Geschwindigkeit*, el Nachteil eben, daß el Programa grundsätzlich no startet, si la DLL fehlt. (Diese ließen se allerdings por geschickte Programación o más weniger ausgleichen.)
Also Usted necesita auch hier, allerdings sólo una vez al Anfang des Programmes, LoadLibrary y GetProcAdress. Im Programa es entonces sólo todavía el Aufruf con Call (auch hier verkürzt a Parameterverwaltung):
Kompilieren Marca Separación

call(aFunk, Parameter)

aFunk es hier el globale Variable, el el Adresse el Función beim Programmstart zugewiesen wurde. Como hier GetProcAdress verwandt wurde, es esta Variante natürlich más rápido, qué se en Programmem con vielen API-Aufrufen natürlich bermerkbar macht. Diesen Weg va IF con XPSE y erreicht por lo tanto el Tempozuwachs.

El meisten Programmiersprachen erlauben beide Varianten el DLL-Bindung, así auch Delphi, en el XProfan geschrieben es. So son en me el ODBC-Aufrufe dynamisch gelinkt, el heißt: XProfan startet auch en Rechnern sin installierte ODBC-Treiber (Windows 95 kam todavía sin esta Treiber en el Markt). El OpenGL-Aufrufe (en OGL-Función) son statische gelinkt, como lo hier a) en Tempo va y b) todos XProfan-fähigen Windowsversionen OpenGL de Casa de a Bord haben. Ohne OpenGL sería XProfan no starten.

Saludo
Roland

* Wieviel el genau ausmacht, hängt natürlich de el jeweiligen API-Función de. En aufwändigen API-Características se el Tempovorteil kaum en el Gewicht fallen, während él en einfachsten API-Características, el incluso sólo solange como el GetProcAdress brauchen, entonces natürlich una Menge 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

Hola Roland - una vez más para mogeln...

Wir hatten el ya veces:
¿Es en el Profanfunktionen (hier usedll) no así, el hay el Adresse ya beim Aufrufen des Programmes se determina?

~GetProcAdress dürfte aber GetProcAdress sólo beim Aufruf el Función aufrufen - es el correcto? Verschaffst du así Usedll (hier LoadLibraryA - por lo tanto es sí ) no una ungerechten Vorteil?

Müssten no beide Características encima Call aufgerufen voluntad, en überhaupt sólo una vez gleiche Voraussetzungen a schaffen?

El Cuestión Was mach GetProcAdress genau? war a Franco gerichtet, el se sí el Función angesehen ha -
trotzdem danke!

@Franco:
Das, wo geladene Module gespeichert voluntad, stinkt para mich después de uno LDR_DATA_TABLE_ENTRY Struktur, also uno doppelt verlinkten Liste, como Yo ellos de MIster Root y Fu her saber. Innerhalb uno solchen Struktur se auch el Loadcount gespeicheit - como es no viel Speicher a scannen.
El API GetProcAdress probablemente el Exporttable uno DLL scannen, y como puede locker 1000 verschiedene Características drin posición - aber darüber wirst du mich wohl todavía genau aufklären

(voluntad Yo jedenfalls hoffen).

Frank
Abbing

El API GetProcAdress probablemente el Exporttable uno DLL scannen, y como puede locker 1000 verschiedene Características drin posición - aber darüber wirst du mich wohl todavía genau aufklären (voluntad Yo jedenfalls hoffen).

Yo versuchs. Hab natürlich auch sólo el disassemblierten Quellcode vorliegen, hay es no así simplemente a erkennen, welche Tabellen como wo vorliegen.
Zuersteinmal se geprüft, si en el Parámetro el twain_32.dll gemeint es. Wenn sí, se schonmal una más Verfahren angewendet.
Ansonsten se primero API el NT.Dll aufgerufen. Stringvergleiche/umwandlungen (A/W) y algo como.
Dann se Heap-Speicher angefordert y danach en el verschiedenen Systemdirectories nachgesehen, si el Dll überhaupt vorliegt, y welcher Versión. Und otra vez zurück a NT.Dll, wo wohl el eigentliche Test weitergeht. Dort tener Yo auch nachgesehen. Lo va como tief en el Sistema hinein, con Aufruf de allerhand (undokumentierten) Lowlevel-APIs con vielen Zugriffen en Speicher y Directories. Scheint una echte Schatzkiste a ser, esta Dll.
Alles en Allem also nix eben veces Handle hochzählen...

Was como sonst todavía passiert, ha aber nichts con Speicher después de Handles scannen a tun, el va muy rápidamente, como lo hay una LDR_DATA_TABLES_ENTRY Struktur es, el doppelt verlinkt es.
U.a. se como en LoadLibraryA el Pfad el DLL überprüft - USER32 / USER32.dll / $SYSPATH+/USER32.dll verweisen sí en el gleiche DLL, y el DLL se como no nochmals geladen voluntad. Hast du dir veces veces media Ver código fuente-Test angesehen? Das sieht lo ya bastante anders de, con el Ergebnis, como Rolands Test.
Mache Yo como irgendwelche gedanklichen Fehler???

Yo glaube, Roland verschafft como en seinem Code LoadLibraryA una ungerechten Vorteil.

RGH

Andreas Hötker

Hola Roland - una vez más para mogeln...

Ah, ahora verstehe Yo, lo que quiere decir! Sí, como hast Usted vermutlich bastante. Das Tuve übersehen. SORRY!

So müßte getestet voluntad:
Kompilieren Marca Separación

 $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

... y luego brauchen ellos beide ungefähr igual lang. Como war Yo wohl en el Irrtum.

Como el auch sei: Beim statischen Linken braucht uno beide sólo beim Start y nachher no mehr, así dass dadurch el Tempogewinn erzielt se.

Saludo
Roland
(ha ya Ideen, el statische Linken en XProfan 11 komfortabler a 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 el hört uno sí gerne.

Das el Ganze todavía una Sinn gehabt.