XPSE

Michael war así nett y ha el Xpse

-Test auch una vez durchgeführt.

Hier seine Results:

328ms con xpse
594ms sin xpse

1891ms con xpse interpreter
2297ms sin xpse interpreter

Yo habe soebend auch veces Okrea

en el neuen XPSE adaptado - y el code algo umgeschrieben. Das Ganze Programa se ejecuta IMHO mejor de - wirkt stabiler y macht una saubereren Eindruck.

Yo glaub como Tuve a Abwechslung auch veces ne gute Concepto.

Michael
Wodrich

Yo glaub como Tuve a Abwechslung auch veces ne gute Concepto

Ohne esta ständige Abwechslung wäre dieses Foro auch no el qué lo nun una vez es.

Einfach TOP

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Jörg
Sellmeyer

Yo habs auch veces getestet:
Interpreter:
Apifunktion: 1422
Call: 1222

Compiliert
Api: 290 - 300
Call: 200 - 210

Sehr interessante Entdeckung.

IF

Yo glaub como Tuve a Abwechslung auch veces ne gute Concepto.

Wurde en efecto veces Tiempo!

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

Jac
de
Lad

Heißt el ahora, el Def ... langsamer es como el XPSE-Gedöns (also sin jegliche Deklaration y 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 se en efecto en Davids Variante. Er weist sólo el deklarierten Características igual una feste Einsprungadresse (? oder como heißt lo? Funktionhandle?) a y el se entonces por Call anscheinend más rápido angesprochen.
Saludo
Jörg

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

Jac
de
Lad

@IF: Defst Si es usted el Call-Dingens cada veces neu, si XPSE qué erkennt? Und qué es, si la Programmierer el Call-Dingens ya incluso en el Ver código fuente definiert ha?

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 así una umgewandelte Línea sieht entonces z.B. así de:
Kompilieren Marca Separación

Nein XPSE Deft nix.

Erklärung Yo en el Nachfolgenden con ApiCall mi: Aufruf uno Api welche en un Headerfile deklariert es.

Wenn Roland una ApiCall umwandelt - así tut él dies encima Externo.

Wenn XPSE una ApiCall umwandelt - así tut él dies encima Call. XPSE macht se como muy viel mühe - deklariert bastante para Anfang des Programmes entsprechende Variables a Aufnahme el Funktionsadressen de el DLL, se para Programmanfang el Funktionsadressen y wandelt el ApiCalls en Calls en welche el entsprechenden Funktionsadressen tragen.

Dieses Posting zeigt lo doch bastante deutlich: [...]

Und hier veces el Block des neuen Okrea:
Kompilieren Marca Separación

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

Und natürlich deklariert XPSE nix doppelt - y sólo el Apis welche tatsächlich genutzt voluntad.

Como uno el Angabe de Headerfiles nun incluso gänzlich weglassen kann es el Vorgang des Kompilierens auch todavía deutlich más rápido - also no sólo el Programa se ejecuta mejor pero...

Verstanden?

Wenn XPSE una ApiCall umwandelt - así tut él dies encima Call. XPSE macht se como muy viel mühe - deklariert bastante para Anfang des Programmes entsprechende Variables a Aufnahme el Funktionsadressen de el DLL, se para Programmanfang el Funktionsadressen y wandelt el ApiCalls en Calls en welche el entsprechenden Funktionsadressen tragen.

Un Mühe, que auszahlt.
Wer viel con Headern y API, umgeht erhält para Geschwindigkeitsvorteil ni verbesserte Sicherheit hinzu - porque es no mehr posible, APIs encima el Cambio el Exporttables wärend des Laufens des Prozesses a hooken.

Das bedeutet genau:
APIs el mittels DEF y EXTERNAL angesprochen voluntad, ermitteln el anzuspringende Adresse en el DLL sólo, si la Función en el Ver código fuente aufgerufen se. Durch Cambio des Headers el DLL en el el API angesprochen se (ändern en el Speicher mi Yo), es posible el CALL en una propio DLL umzuleiten y el Parámetro abzugreifen. En uno Codierung uno Freischaltungscodes para una Shareware podría el ya algo problematisch ser.

Como XPSE el Adressen beim Starten des Programmes ya festlegt, nützt una solche Attacke nichts mehr - lo voluntad trotzdem el richtigen Adressen angesprungen.