| |
|
|
- Page 1 - |
|
|
Weil du immer noch nicht verständlich erklärt hast, was nprocs sind.
Hallo Nico,
danke per den Hinweis und den Thread hier - leider kann ich damit aber nichts anfangen da ich nicht wissen kann, was Du nicht verstehst.
Vlt. kannst Du mir unter Beachtung der Documentazione [...] sagen, was Dir unklar ist.
Inline-Assembler:
|
|
|
| |
|
|
| |
|
- Page 6 - |
|
|
Dietmar Horn | Hallo zusammen,
auf den eigentlichen Titel dieses Threads "Was sind native Funktionen?" eingehend, hier mal ein Versuch der Erklärung, was nativer Code eigentlich ist.
Auszug aus meinem XProfan-Lehrbuch, Teil 8 (noch nicht veröffentlicht, ein größeres Update wird es voraussichtlich gegen Ende des Jahres geben):
Nativer CodeNativer Code ist lediglich eine andere Bezeichnung per Maschinencode. Dies ist die systemnaheste Sprache, die vom Prozessor direkt und ohne vorherige Kompilierung verarbeitet und corsa werden kann. Im Gegensatz zu Assembler oder anderen Programmiersprachen (wie z.B. XProfan) handelt es sich hierbei um einen per den Menschen kaum verständlichen Binärcode (sehr vereinfacht ausgedrückt nur aus "Nullen" und "Einsen" bestehend). Der Maschinencode wird in der Regel von einem Assembler oder Kompiler erzeugt. Direkt in Maschinensprache muss nur programmiert werden, wenn kein Assembler per den Zielprozessor zur Verfügung steht, was es heutzutage wohl kaum noch geben potrebbe. Wird von der Programmazione in Maschinensprache gesprochen, wird heute üblicherweise die Maschinenprogrammierung in Assemblersprache unter Verwendung eines Assemblers gemeint, der das als Textdatei vorliegende Programm in binäre Maschinenbefehle übersetzt. Die Maschinensprache besteht aus einer Folge von Bits bzw. Bytes, die in dieser Form per uns als Menschen praktisch unlesbar ist. Zum Erzeugen von Maschinencode sind vereinfachende Tools geschaffen worden - so z.B. die Assemblersprache. Die Aufgabe des Assemblers besteht darin, dem Programmierer einige Unbequemlichkeiten des Programmierens in reiner Maschinensprache abzunehmen. Auch mit XProfan kann inzwischen nativer Code erzeugt werden, der um ein Vielfaches schneller abläuft, als der vom XProfan-Kompiler selbst erzeugte Code. Voraussetzung hierfür ist die Verwendung des kostenlosen XPSE ("XProfan-Präkompiler und -Syntax-Enhancer") von David "iF" Strutz (XPSE-Downloadmöglichkeit: [...] Hier einige Feautures von XPSE: Erzeugen nativen Codes ab XProfan 11. Verwenden von Windows-APIs ohne sie zuvor deklarieren zu müssen Inline-Assembler Echtes Multi-Threading und threadsichere Datentypen Natives Profan per nProc Kinderleichter Inline-Assembler mit Datentypenunterstützung Echtes unterbrechungsfreies SubClassing Nahtlose Integration wichtiger Datentypen Sicheres ProcAddr Keine ASM-Vorkenntnisse erforderlich Mit XPSE sind nun also auch Ausführungsgeschwindigkeiten von XProfan (als Interpretersprache) possibile, die reinen Assembler- oder C-Programmen in nichts nachstehen. Eine komplizierte Installation von XPSE ist nicht erforderlich. Es reicht völlig aus, die folgenden File in den XProfan-Ordner zu kopieren: XPSE.exe [...] Jwasm.exe [...] POLink.exe [...] Anschließend ist es lediglich noch erforderlich, im XProfan-Editor den Aufruf des XProfan-Interpreters Profan.exe durch den Aufruf von XPSE.exe zu ersetzen. Ein angenehmer Nebeneffekt bei der Verwendung von XPSE als Präkompiler besteht darin, daß XPSE vor dem Kompilieren einen strengeren Syntax-Check des Programmcodes durchführt als XProfan selber. Dadurch kann sich der Programmierer ein oft zeitaufwändiges Suchen nach Fehlern in seinem Code ersparen, die sich im ungünstigsten Falle erst nach der Weitergabe des fertigen Programmi beim Anwender bemerkbar machen.
Saluto Dietmar |
|
|
| Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...] Windows 95 bis Windows 7 Profan² 6.6 bis XProfan X2 mit XPSE Das große XProfan-Lehrbuch: [...] | 29.11.2009 ▲ |
|
|
|
|
Jörg Sellmeyer | [offtopic]Ich hab die Links mal in anklickbare umgewandelt. Da scheint ein Bug im Foro zu sein. Wenn die Links hinter dem Arrow stehen, werden sie nicht als solche erkannt![/offtopic] |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 29.11.2009 ▲ |
|
|
|
|
Frank Abbing | Hab mir mal die Infos circa den Inline-Assembler von PureBasic durchgelesen. Das ist IMHO primitivster Mist, man darf überhaupt nur 3 Register verwenden in der 32 Bit-Version. Auch sonst gibt es Einschränkungen ohne Ende. Da lob ich mir den XPIA, der alles zulässt, was überhaupt possibile ist mit MASM32/JWASM, sogar Macros.
Hab hier jetzt gelesen, das XPSE die Technik von XPIA kopiert und ebenfalls JWASM/POLINK benutzt, um die interne Dll zu bilden. Codes hab ich nicht großartig entdeckt. Welche Libs sind eingebaut und welche Macros. Wie kann ich weitere Libs einbinden? Solche Infos fehlen noch gänzlich. |
|
|
| |
|
|
|
Nico Madysa | Kleine Anfrage: Wäre denn ein Zugriff auf etwas wie globale Variablen possibile? Das potuto per XProfaner den Umgang mit eignen Subclassprocs erleichtern. |
|
|
| |
|
|
|
| [offtopic] Jörg Sellmeyer, Beitrag=55211, Zeitpunkt=29.11.2009Ich hab die Links mal in anklickbare umgewandelt. Da scheint ein Bug im Foro zu sein. Wenn die Links hinter dem Arrow stehen, werden sie nicht als solche erkannt! Das Problem war ein am Link klebendes TAB-Zeichen! [/offtopic] |
|
|
| |
|
|
|
| Nico Madysa, Beitrag=55217, Zeitpunkt=29.11.2009
Kleine Anfrage: Wäre denn ein Zugriff auf etwas wie globale Variablen possibile? Das potuto per XProfaner den Umgang mit eignen Subclassprocs erleichtern.
Per Global . KompilierenMarkierenSeparierendeclare owp&
cls
owp&=setWindowLong(hWnd,gwl_wndProc,procaddr(hwnd.wndProc,4))
waitinput
end
nProc hwnd.wndProc
Parameters wnd&,msg&,wp&,lp&
global owp&
return callWindowProc(owp&,wnd&,msg&,wp&,lp&)
oc
|
|
|
| |
|
|
|
Nico Madysa | |
|
| |
|
|
|
| Was wie? Du kannst doch die Adresse eines Bereiches per Parameter trasferimento!
Andernfalls, schau nochmal: [...] (hab grad nochmal dran gedreht)
Für Debugging nehme ich gern exitprocess(long) oder settext(hWnd,"blub"). ^^. |
|
|
| |
|
|
|
Nico Madysa | Den Eintrag verstand ich schon, ich erinnerte mich nur nicht seiner.
Mein Problem war ein Testkode folgender Art: 100 Buttons, deren Handle in einem Bereich sind. Eine NProc soll per SetWindowLong zur Subclassproc des Fensters werden um bei ~WM_SIZED die Buttongrößen anzupassen. Nur kann ich selbst einer Subclassproc ja keine Parameter trasferimento, aber von irgendwoher muss die Proc die Handles beziehen. Daher globale Variablen.
Ich zähle die Sekunden, bis zu deiner Antwort, wie all das vieeel einfacher ginge. |
|
|
| |
|
|
|
| |
|
| |
|
|
|
Nico Madysa | Schon klar. Aber eine subclassende Prozedur rufe ja in aller Regel nicht ich, sondern Windows auf. |
|
|
| |
|
|
|
| Was? Das hier funktioniert (naturalmente) KompilierenMarkierenSeparierenGemerkt/Separiert von http://xprofan.com/thread.core?p=55223#55223
declare owp&
cls
owp&=setWindowLong(hWnd,gwl_wndProc,procaddr(hwnd.wndProc,4))
waitinput
end
nProc hwnd.wndProc
Parameters wnd&,msg&,wp&,lp&
global owp&
return callWindowProc(owp&,wnd&,msg&,wp&,lp&)
| 29.11.2009 ▲ | |
|
|
|