XPSE

Michael war so nett und hat den Xpse

-Test auch einmal durchgeführt.

Hier seine Results:

328ms mit xpse
594ms ohne xpse

1891ms mit xpse interpreter
2297ms ohne xpse interpreter

Ich habe soebend auch mal Okrea

auf den neuen XPSE angepasst - und den code etwas umgeschrieben. Das Ganze Programm corre IMHO besser ab - wirkt stabiler und macht einen saubereren Eindruck.

Ich glaub da hatte ich zur Abwechslung auch mal ne gute Idee.

Michael
Wodrich

Ich glaub da hatte ich zur Abwechslung auch mal ne gute Idee

Ohne diese ständige Abwechslung wäre dieses Foro auch nicht das was es nun einmal ist.

Einfach TOP

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Jörg
Sellmeyer

Ich habs auch mal getestet:
Interpreter:
Apifunktion: 1422
Call: 1222

Compiliert
Api: 290 - 300
Call: 200 - 210

Sehr interessante Entdeckung.

iF

Ich glaub da hatte ich zur Abwechslung auch mal ne gute Idee.

Wurde ja auch mal Zeit!

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

Jac
de
Lad

Heißt das jetzt, das Def ... langsamer ist als das XPSE-Gedöns (also ohne jegliche Deklaration und 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 ja auch bei Davids Variante. Er weist nur den deklarierten Funktionen gleich eine feste Einsprungadresse (? oder wie è es? Funktionhandle?) zu und die wird dann durch Call anscheinend schneller angesprochen.
Saluto
Jörg

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

Jac
de
Lad

@iF: Defst du das Call-Dingens jedes mal neu, wenn XPSE was erkennt? Und was ist, wenn der Programmierer das Call-Dingens schon selbst im Quelltext definiert 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

Und so eine umgewandelte Zeile sieht dann z.B. so aus:
Kompilieren Markieren Separieren

Nein XPSE Deft nix.

Erklärung was ich im Nachfolgenden mit ApiCall meine: Aufruf einer Api welche in einem Headerfile deklariert ist.

Wenn Roland einen ApiCall umwandelt - so tut er dies circa External.

Wenn XPSE einen ApiCall umwandelt - so tut er dies circa Call. XPSE macht sich da sehr viel mühe - deklariert ganz zum Anfang des Programmi entsprechende Variablen zur Aufnahme der Funktionsadressen aus den DLL, holt sich zum Programmanfang die Funktionsadressen und wandelt die ApiCalls in Calls um welche die entsprechenden Funktionsadressen tragen.

Dieses Posting zeigt es doch ganz deutlich: [...]

Und hier mal der Block des neuen Okrea:
Kompilieren Markieren Separieren

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))
war mal:
SetClassLongA(_hwnd&,-12,LoadCursorA(0,32649))

Und naturalmente deklariert XPSE nix doppelt - und auch nur die Apis welche tatsächlich genutzt werden.

Da man die Angabe von Headerfiles nun sogar gänzlich weglassen kann ist der Vorgang des Kompilierens auch noch deutlich schneller - also nicht nur das Programm corre besser sondern...

Verstanden?

Wenn XPSE einen ApiCall umwandelt - so tut er dies circa Call. XPSE macht sich da sehr viel mühe - deklariert ganz zum Anfang des Programmi entsprechende Variablen zur Aufnahme der Funktionsadressen aus den DLL, holt sich zum Programmanfang die Funktionsadressen und wandelt die ApiCalls in Calls um welche die entsprechenden Funktionsadressen tragen.

Eine Mühe, die sich auszahlt.
Wer viel mit Headern und API, umgeht erhält zum Geschwindigkeitsvorteil noch eine verbesserte Sicherheit hinzu - denn es ist nicht mehr possibile, APIs circa das Ändern der Exporttables wärend des Laufens des Prozesses zu hooken.

Das bedeutet genau:
APIs die mittels DEF und EXTERNAL angesprochen werden, ermitteln die anzuspringende Adresse in der DLL erst, wenn die Funktion im Quelltext aufgerufen wird. Durch Ändern des Headers der DLL in der der API angesprochen wird (ändern im Speicher meine ich), ist es possibile den CALL auf eine eigene DLL umzuleiten und die Parameter abzugreifen. Bei einer Codierung eines Freischaltungscodes per eine Shareware potuto das schon etwas problematisch sein.

Da XPSE die Adressen beim Starten des Programmi schon festlegt, nützt eine solche Attacke nichts mehr - es werden trotzdem die richtigen Adressen angesprungen.