XPSE

Michael était so gentil et hat den Xpse

-Test aussi einmal durchgeführt.

ici sa Results:

328ms avec xpse
594ms sans xpse

1891ms avec xpse interpreter
2297ms sans xpse interpreter

j'ai soebend aussi la fois Okrea

sur den neuen XPSE angepasst - et den code quelque chose umgeschrieben. cela Ganze Programme fonctionne IMHO besser ab - wirkt stabiler et pouvoir une saubereren impression.

je glaub là J'ai eu zur Abwechslung aussi la fois ne gute concept.

Michael
Wodrich

je glaub là J'ai eu zur Abwechslung aussi la fois ne gute concept

sans cet ständige Abwechslung wäre cet Forum aussi pas cela quoi es eh bien einmal ist.

simple TOP

belle Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Jörg
Sellmeyer

je habs aussi la fois getestet:
Interpreter:
Apifunktion: 1422
Call: 1222

Compiliert
Api: 290 - 300
Call: 200 - 210

très interessante Entdeckung.

iF

je glaub là J'ai eu zur Abwechslung aussi la fois ne gute concept.

Wurde oui aussi la fois Zeit!

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Jac
de
Lad

Heißt cela maintenant, cela Def ... langsamer ist comme cela XPSE-Gedöns (alors sans jegliche Deklaration et Verheaderung)?

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

Jörg
Sellmeyer

Nö, geDeft wird oui aussi chez Davids variante. il weist seulement den deklarierten Funktionen juste une feste Einsprungadresse (? ou bien comment est es? Funktionhandle?) trop et qui wird ensuite par Call anscheinend plus rapide angesprochen.
Salut
Jörg

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Jac
de
Lad

@iF: Defst du cela Call-Dingens chaque la fois récente, si XPSE quoi erkennt? et quoi ist, si qui Programmierer cela Call-Dingens déjà selbst im Voir le texte source défini hat?

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

et so une umgewandelte la ligne sieht ensuite z.B. so aus:
Kompilieren Marque Séparation

non XPSE Deft nix.

Erklärung quoi je im Nachfolgenden avec ApiCall mon: Aufruf einer Api quelle dans einem Headerfile deklariert ist.

si Roland une ApiCall umwandelt - so tut il ca sur Externe.

si XPSE une ApiCall umwandelt - so tut il ca sur Call. XPSE pouvoir sich là très viel mühe - deklariert entier zum Anfang des Programmes entsprechende Variablen zur Aufnahme qui Funktionsadressen aus den DLL, holt sich zum Programmanfang qui Funktionsadressen et wandelt qui ApiCalls dans Calls um quelle qui entsprechenden Funktionsadressen tragen.

cet Posting zeigt es doch entier deutlich: [...]

et ici la fois qui Block des neuen Okrea:
Kompilieren Marque Séparation

Def __cf1(2) !KERNEL32,GetProcAddress
Def __cf2(1) !KERNEL32,GetModuleHandleA
__cf1&=__cf1(__cf2(user32.dll),GetAsyncKeyState)
__cf2&=__cf1(__cf2(user32.dll),KillTimer)
__cf3&=__cf1(__cf2(user32.dll),GetWindowLongA)
__cf4&=__cf1(__cf2(user32.dll),SetWindowLongA)
__cf5&=__cf1(__cf2(user32.dll),SetClassLongA)
__cf6&=__cf1(__cf2(user32.dll),LoadCursorA)
__cf7&=__cf1(__cf2(user32.dll),SendMessageA)
__cf8&=__cf1(__cf2(user32.dll),SetWindowPos)
__cf9&=__cf1(__cf2(user32.dll),InvalidateRect)
__cf10&=__cf1(__cf2(user32.dll),UpdateWindow)
__cf11&=__cf1(__cf2(user32.dll),CallWindowProcA)
__cf12&=__cf1(__cf2(user32.dll),SetTimer)
__cf13&=__cf1(__cf2(user32.dll),GetCursorPos)
__cf14&=__cf1(__cf2(user32.dll),WindowFromPoint)
__cf15&=__cf1(__cf2(user32.dll),ClientToScreen)
__cf16&=__cf1(__cf2(user32.dll),GetSysColor)
__cf17&=__cf1(__cf2(user32.dll),FindWindowExA)
__cf18&=__cf1(__cf2(kernel32.dll),TerminateProcess)
__cf19&=__cf1(__cf2(kernel32.dll),OpenProcess)
__cf20&=__cf1(__cf2(kernel32.dll),GetCurrentProcessId)
__cf21&=__cf1(__cf2(user32.dll),SetWindowsHookExA)
__cf22&=__cf1(__cf2(user32.dll),GetWindowThreadProcessId)
__cf23&=__cf1(__cf2(user32.dll),UnhookWindowsHookEx class=s2>)

call(__cf5&,_HWND&,-12,call(__cf6&,0,32649))
était la fois:
SetClassLongA(_hwnd&,-12,LoadCursorA(0,32649))

et naturellement deklariert XPSE nix doppelt - et seulement qui Apis quelle réellement genutzt volonté.

là on qui Angabe de Headerfiles eh bien sogar gänzlich omettre peux ist qui Vorgang des Kompilierens aussi encore deutlich plus rapide - alors pas seulement cela Programme fonctionne besser mais...

Verstanden?

si XPSE une ApiCall umwandelt - so tut il ca sur Call. XPSE pouvoir sich là très viel mühe - deklariert entier zum Anfang des Programmes entsprechende Variablen zur Aufnahme qui Funktionsadressen aus den DLL, holt sich zum Programmanfang qui Funktionsadressen et wandelt qui ApiCalls dans Calls um quelle qui entsprechenden Funktionsadressen tragen.

une Mühe, qui sich auszahlt.
qui viel avec Headern et API, umgeht erhält zum Geschwindigkeitsvorteil encore une verbesserte Sicherheit hinzu - car c'est pas plus possible, APIs sur cela Changement qui Exporttables wärend des Laufens des Prozesses trop hooken.

cela bedeutet oui c'est ca:
APIs qui mittels DEF et EXTERNAL angesprochen volonté, ermitteln qui anzuspringende Adresse dans qui DLL seulement, si le Funktion im Voir le texte source aufgerufen wird. par Changement des Headers qui DLL dans qui qui API angesprochen wird (changement im grenier mon je), ist es possible den CALL sur une eigene DLL umzuleiten et qui paramètre abzugreifen. chez einer Codierung eines Freischaltungscodes pour une Shareware pourrait cela déjà quelque chose problematisch son.

là XPSE qui Adressen beim Starten des Programmes déjà festlegt, nützt une solche Attacke rien plus - es volonté quand même qui richtigen Adressen angesprungen.