| |
|
|
Claus Santa | XPIA: No External DLL! Hier noch kleine Veränderungs-Tips... Ansonsten ist XPIA gut. Assembly direkt codieren und nicht uber DLL, denn CALL funktion ist SCHNELLER!
1. Vorteil: ReverseEnginiering mit DLLs ist Kinderleicht, was schlecht ist für Datenverschlüsselung. ;(
2. Vorteil: Direktes einbinden in sourcecode, wie:
if getfocus( hb_MakeSomting& ) whileloop 10 print your cpu said: +AMSMcall MeineASMproc, MyText, ... ) endwhile
3. Vorteil: Rückgabe von 0-Terminated Strings ist möglich [!]. Dann ginge ja auch das:
print AssemblyFunk() retruns: > +string( AssemblyFunk#, 0 ) +<
4. Vorteil: Ein weiterer Vorteil ist dann auch externe Module handling (wie: PLUGIN-MODULES) -> MORE IMPLIMENTATIONS. ;)
blockread( #1, ExternalModule#, 0, getfilesize( #1 ) ) ... call( ExternalModule# ) -> call_addr = addr( ExternalModule# )
5. Vorteil: Objekt Orientiertes Assembling - wichtig für MS Foundation Classes!
ASMcode$ contains suff of MemoryAddress# class A = ASMcode$[ SIZE ], ....
AObject# ist ein Objekt der Klasse A (in diesem Besipiel) call( AObject#, ... )
Syntax-Vorschlag:
Bitte nicht über Parameters, da schlecht/verwirrend für alle ANFÄNGER! Es soll ganz PROFAN (einfach?) bleiben!
--- ROOT SOURCE --- ASMproc WhatEverItMakes( params ) return ? ASMendproc
ASMcall( WhatEverItMakes, [params..] )
--- PATCHED SOURCE --- on app init dim WhatEverItMakes#, (SizeOfObj) byte WhatEverItMakes#, 0 = ...code source...
somewhere in your app call( WhatEverItMakes# )
on uninit dispose WhatEverItMakes#
--- appendix --- Ich hab eine Seite in Deutsch mit OpCodes gleich beigefügt - BESSER ALS MEIN DEUTSCH!. ;/
Genereller BinaryCode: offsetdescription +1 byteoperation code +?operands ->byte = +1 ->single word = +1 ->double word = +1 ->quard word = +1
Die Struktur sollte dann so aussehen für eine ASM-Funktion (e.g. WhatEverItMakes#):
[ on call ] offsetvalue/datacontentasm code +1$E9buffer skip jumpjmp +4?? ?? ?? ??WhatEverItMakes# + RetrunSize(WhatEverItMakes# + RetrunSize) +(RetSz-Offs)$90reserved data buffernop +??...your stuff here......
[ on return ] offsetvalue/datacontentasm code +RetSz?WhatEverItMakes# + RetrunSize [return data] ( Habe fleisig im Deutschprachigen Chats geübt. Hoffe es ist lesbar... [thx2sabine*] ) |
|
|
| Snoozel, [[StA/oXr]] // life is just'n bugfree, cos coding is life | 30.10.2005 ▲ |
|
|
|
|
Frank Abbing | Hi,
> XPIA: No External DLL! > Hier noch kleine Veränderungs-Tips... Ansonsten ist XPIA gut. > Assembly direkt codieren und nicht uber DLL, denn CALL funktion ist SCHNELLER!
Mag sein, nur hat das ziemliche Nachteile. Ich zähl mal einige auf, die mir spontan einfallen:
- APIs funktionieren so nur sehr aufwendig. - Keine Hight-Level-Syntax - Keine Library-Unterstützung - Komplizierte Parameter- und Variablenübergabe - Keine Makro-Unterstützung - Keine Debugging-Unterstützung - Keine MASM32 Erweiterungen (MASM32.lib)
> 3. Vorteil: > Rückgabe von 0-Terminated Strings ist möglich [!]. Dann ginge ja auch das: > > print AssemblyFunk() retruns: > +string( AssemblyFunk#, 0 ) +<
Dll-Funktionen übergeben bei STDCALL grundsätzlich nur Long-Werte. Deswegen kannst du aber den Zeiger eines Strings übergeben, wo ist das Problem?
> 5. Vorteil: > Objekt Orientiertes Assembling - wichtig für MS Foundation Classes! > > ASMcode$ contains suff of MemoryAddress# > class A = ASMcode$[ SIZE ], .... > > AObject# ist ein Objekt der Klasse A (in diesem Besipiel) > call( AObject#, ... ) >
Ich bin bekennender OOP Gegner. OOP und Assembler, das beisst sich eh von vornherein.
> Syntax-Vorschlag: > > Bitte nicht über Parameters, da schlecht/verwirrend für alle ANFÄNGER! Es soll ganz PROFAN (einfach?) bleiben! > > > --- ROOT SOURCE --- > ASMproc WhatEverItMakes( params ) > return ? > ASMendproc > > ASMcall( WhatEverItMakes, [params..] ) > > > --- PATCHED SOURCE --- > on app init > dim WhatEverItMakes#, (SizeOfObj) > byte WhatEverItMakes#, 0 = ...code source... > > somewhere in your app > call( WhatEverItMakes# ) > > on uninit > dispose WhatEverItMakes# > > > --- appendix --- > Ich hab eine Seite in Deutsch mit OpCodes gleich beigefügt - BESSER ALS MEIN DEUTSCH!. ;/ > > Genereller BinaryCode: > offset description > +1 byte operation code > +? operands > ->byte = +1 > ->single word = +1 > ->double word = +1 > ->quard word = +1 > > > Die Struktur sollte dann so aussehen für eine ASM-Funktion (e.g. WhatEverItMakes#): > > [ on call ] > offset value/data content asm code > +1 $E9 buffer skip jump jmp > +4 ?? ?? ?? ?? WhatEverItMakes# + RetrunSize (WhatEverItMakes# + RetrunSize) > +(RetSz-Offs) $90 reserved data buffer nop > +? ? ...your stuff here... ... > > [ on return ] > offset value/data content asm code > +RetSz ? WhatEverItMakes# + RetrunSize > [return data] Mal ehrlich! Du hast erwähnt, Profan sei eine Anfängersprache und alles sollte leicht sein. Hälst du deinen oben angeführten Code für leicht verständlich? Also ich nicht. Da finde ich meine Prozeduren-artige Syntax für erheblich Anfänger-geeigneter... Die (optionale) Vereinfachung der Parameterangabe innerhalb des Assembleraufrufs ziehe ich aber gerne in Erwägung. |
|
|
| |
|
|
|
Claus Santa | Hmm...
Fieleicht hast Du recht... Da bleibt nur einen SourceConverter zu schreiben.
...Und das will etwas heisen - Ich bin ein wirklicher LazyDog! Schade, aber trotzdem Danke! |
|
|
| Snoozel, [[StA/oXr]] // life is just'n bugfree, cos coding is life | 03.11.2005 ▲ |
|
|
|
|
Frank Abbing | Hi,
Source-Converter, ja? Die Idee scheint weiter verbreitet zu sein, als du vielleicht ahnst...
Ich bin Neuerungen aber durchweg nicht negativ geneigt und begrüsse solche Vorschläge, die du hier gebracht hast. Wenn sie mir sinnvoll erscheinen und wenn sie realisierbar sind, dann bau ich sie auch ein. Lass dich also nicht abschrecken.
Cooles Cape! |
|
|
| |
|
|
|
Claus Santa | Sehe ich auch so. Aber wenn nur als Zusatz - XProfan soll XProfan bleiben, okey?
P.S.: DEBIAN CAP nimby rulers (=für selberfummler) |
|
|
| Snoozel, [[StA/oXr]] // life is just'n bugfree, cos coding is life | 05.11.2005 ▲ |
|
|
|
|
Melanie Brayer | ...(M)eine objektive Meinung...
( )`·.¸¸.-> Sicherheit: Leider muss ich Frank recht geben, da das API-Handling (besonders bei XP) echt schlecht ist - Windos-like eben. Du hast zwar recht mit Deiner Safe-Is-Safe-Einstellug, aber vergiss nicht das Anwender die Software benutzen und nicht Hardliner wie Du! --> Hardware ist HARD und Software eben SOFT! Warum benutzt du nicht Deine PMC, das klappt auch under Windows!
( )`·.¸¸.-> In-Runtime: In-Runtime-DLLs blähen die Runtime unnötig auf und die In-Source-DLL kann nicht verändert werden. Als Beispiel dient eine PLUG-IN-Funktion, namens RenderScene. Wir wollen unsere Runtime aber flexibel machen und DirectX und OpenGL rendern. Dazu soll jedes PLUG-IN die Funktion RenderScene besitzen, was mit In-Runtime-Code nicht geht... Dieses Problem kann man aber mit Externen .PRC-Dateien lösen! Ein Aufruf könnte dann z.B. so aus sehen: Drehfux32.exe opengl.prc RenderScene -mem $0000.
Tut mir wirklich leid Sani, aber wo Frank recht hat, ...
PS: Dein deutch ist 1000x besser als vor einem 3/4 Jahr. |
|
|
| mele (¯`·.¸¸.{ WinXP Pro, XProfan9, XPIA }.¸¸.·´¯)
<Bugs zählen ist besser als Schafe zählen, da der Computer nur so schlau ist wie der der Mensch der ihn bedient.> | 08.11.2005 ▲ |
|
|
|
|
Frank Abbing | Hi,
In-Runtime-Dlls mit XPIA muss man ja nicht einsetzen. XPIA erzeugt ja die Dll auch separat und den Quellcode dazu. |
|
|
| |
|
|
|
Frank Abbing | Claus, ich hab eine deiner Anregungen mal aufgegriffen. Die nächste XPIA-Version wird, zusätzlich zur herkömmlichen Form, auch eine Kurzform der Parameter- und Rückgabevariablen kennen. Hier ein Beispiel: KompilierenMarkierenSeparieren P.S.: iFs Syntaxbuilder kommt mit dem Code (noch) nicht klar. Da muß er wohl noch nachbessern... |
|
|
| |
|
|
|
| So die Community erkennt Deine syntaktische Erweiterung jetzt und reagiert entsprechend. |
|
|
| |
|
|
|
Frank Abbing | Super, danke. |
|
|
| |
|
|
|
Claus Santa | ( Damn good! ) Habe vielen Dank!! |
|
|
| Snoozel, [[StA/oXr]] // life is just'n bugfree, cos coding is life | 18.11.2005 ▲ |
|
|
|
|
Michael Dell | Hallo Frank,
die neue Parameterübergabe kommt echt gut! Da bleiben kaum noch Wünche offen, einen hab ich aber noch. Manchmal werden spezielle Funktionen nur zur internen Anwendung benötigt und sollten also nicht Exportiert werden.
Ist es möglich einen Schalter einzubauen der XPIA sagt das eine Funktion nicht in die Export- Tabelle gehört? Bislang mach ich das ja von Hand aber es wär schön wenns auch Automatisch ginge etwa in der Art:
AsmStart Test (p1&,p2&) I I steht hier natürlich für Intern. |
|
|
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 22.11.2005 ▲ |
|
|
|