...da das zugrundeliegende Problem in XProfan wohl ein Variablenproblem ist, bräuchte man das eigentlich gar nicht. Unter Umständen ist die Lösung dafür viel einfacher (und auch kompletter).
Subclassen per nProc
-
-
-
Zitat von AHT;771527
Unter Umständen ist die Lösung dafür viel einfacher (und auch kompletter).
Du sagst es: http://xprofan.com/xpse/
Alles oben beschriebene funktioniert bereits, jeder XProfaner kann bereits echte Threads und Callbacks programmieren.
Wem es nicht gelingt, nutzt einzig keine hierfür brauchbare Entwicklungsumgebung - die es dennoch aber gibt.
Andernfalls, viel Spaß beim weiterwarten - wir programmieren solange...
Salve, iF.
-
Es will aber nicht jeder XPSE benutzen, und so kommt es doch auf meine Liste des "Will-in-XProfan-12-Haben".
-
Was man "kann" klärt der Hinweis, doch aber nicht, "was jeder will".
Wer nur nicht können will, dem bleibt doch z.B. das Abwarten auf XProfan 12, 13, 14...,
um dann doch zu programmieren, was dann aber zuvor schon ("jahrlang") seit XProfan 11
programmiert wurde.Stolz bin ich z.B. jetzt schon auf das neue Scroll-Control ( http://xprofan.com/t/?6274 ),
welches jeder auch ab sofort nutzen kann, statt auf eine XProfan-Version zu warten,
die dieses von Haus aus mitbringt.Sowas vereinfacht wohlmöglich auch Roland die Arbeit, sei es, es bringt auf Ideen,
wie man was warum umsetzen könnte.Salve, iF.
-
Na ja - mit XPIA geht das sogar noch besser .
Für mich ist eine Programmiersprache, mit der ich nicht richtig programmieren kann (hier wichtige APIs nutzen), keine vernünftige Programmiersprache. Daran ändert sich auch nichts, wenn man vor das Ding irgendwelche Tools schalten kann, die angeblich diese Fehler ausbügeln.Um XPSE habe ich mich schon Jahre lang nicht mehr gekümmert.
Wenn du so überzeugt von dem Tool bist, stelle es doch einfach mal hier irgendwo vor und beschreibe mal, wie man zum Beispiel einen steuerbaren Service mit XPSE programmiert...
Bin echt gespannt, und ich schaue es mir auf jeden Fall an. -
@iF: Wieso soll ich es dann nicht auf meine Wunschliste stellen? Ich wünsche mir ebenso, dass Progressbars implementiert werden, obwohl ich die bereits seit Ewigkeiten mit einer INC und ein wenig API erstellen kann.
-
Genau so ist. Ich kann auch fehlerfrei Callbacks aufrufen während irgendwelche anderen Profanschleifen laufen (und das mit XProfan9 und ohne XPSE) - bloß was ändert das an dem Problem???
-
Du scheinst XPSE nicht zu kennen, denn andernfalls und spätestens wer behauptet, SubClassing ginge mit XPIA noch einfacher, als mit XPSE, kennt entweder XPIA oder XPSE nicht oder scheitert beim Zählen von Zeilen und Anweisungen.
So gehts mit Windows:
- und genau so gehts auch mit XPSE: Funktionsreferenz
So kann eine WNDProc aussehen:
CodenProc hWnd.wndProc Parameters wnd&,msg&,wp&,lp& return callWindowProc(getWindowLong(wnd&,gwl_userData),wnd&,msg&,wp&,lp&) endproc
>> Wenn du so überzeugt von dem Tool bist
Es ist eine ergänzende Programmiersprache für XProfan, die imho hält, was sie verspricht und genau dort angreift, wo XProfans Potential technisch endet. Überzeugung bekommst Du vlt. in der Kirche.
>> Für mich ist eine Programmiersprache, mit der ich nicht richtig programmieren kann (hier wichtige APIs nutzen), keine vernünftige Programmiersprache.
Naja, nach meiner Theorie, kannst Du ja mit gar keiner Programmiersprache "richtig" Programmieren und nur deshalb entspringen Dir überhaupt erst solche "Aussagen". Nicht der Sprache wegen, sondern des Programmierens wegen. Scriptkiddis die im OS rumwurschteln wie Du es tust, verwechseln dies immer gerne mit "Programmieren", haben aber trotzdem meist nie programmiert. Ebenso ist eine Programmiersprache selten unzweckmässig, wer also meint, Sprache X sei nicht "vernünftig", weil sie nicht all seine Wünsche erfüllt, hat irgendwas komplett nicht verstanden.
>> Daran ändert sich auch nichts, wenn man vor das Ding irgendwelche Tools schalten kann, die angeblich diese Fehler ausbügeln.
Interessant und totaler Unfug, denn Du nimmst auch nicht Notepad als IDE, sondern wahrscheinlich eher XProfEd, um einfacher/besser mit XProfan programmieren zu können. Du kannst ja mal mit einer vernünftigen Programmiersprache namens C probieren, ohne "Tools" eine Exe zu erzeugen. Worüber reden wir, dass ist doch kein Level.
>> wie man zum Beispiel einen steuerbaren Service mit XPSE programmiert
Übersetze ich Dir gerne nach Profansyntax, wenn Du da Hilfe brauchst.
-
Zitat von Jac de Lad;771784
@iF: Wieso soll ich es dann nicht auf meine Wunschliste stellen? Ich wünsche mir ebenso, dass Progressbars implementiert werden, obwohl ich die bereits seit Ewigkeiten mit einer INC und ein wenig API erstellen kann.
He, ich habe doch niemals gewünscht, dass Du es nicht auf Deine Wunschliste stellst! Ich habe ebenso Deinen Wunsch, kann ich auch beweisen - habe mir der Erfüllung wegen ja sogar XPSE für programmiert.
Ich hatte Deinem Wunsch doch nur hinzugefügt, dass dieser eigentlich vielleicht "unnötig" ist, weil bereits Lösungen frei für jedermann abrufbar - super Lösungen!
Das war doch kein Angriff auf Deinen Wunsch, den wir ohnehin "alle" hegen.
-
Ich hab die XPSE-Lösungen schon probiert und auch mit API. Bisher war das nicht zufriedenstellend, vielleicht liegts auch an mir (davon gehe ich fast aus). Deshalb auf meiner Wunschliste. Vielleicht meldet sich ja noch Roland zu Wort.
-
Ich denke hier geht es um Wünsche, die nativ in XProfan enthalten sein sollen, nicht um Tools die irgendetwas ermöglichen sollen und nicht um API's. Denn so gesehen könnte man die Entwicklung von XProfan dann einstellen, vielleicht noch ein paar Variablentypen dazu geben und fertig. Das weitere muss dann jeder selbst über API oder Tools regeln.
Was XPSE kann oder nicht kann, kann ich nicht beurteilen, da mir die Syntax nicht unbedingt zusagt und ich es deshalb auch nicht benutze. Mir sind native Funktionen auch lieber, denn die machen eine Programmiersprache aus, nicht irgendwelche Tools.
-
Ja Bankog, das sehe ich auch so!
-
> Ich denke hier geht es um Wünsche, die nativ in
> XProfan enthalten sein sollen, nicht um Tools die
> irgendetwas ermöglichen sollen und nicht um API's.Das schließt diese Tools und Apis aber nicht aus
sondern ein, oder willste Gedankenpolizei.> Denn so gesehen könnte man die Entwicklung von
> XProfan dann einstellen, vielleicht noch ein paar
> Variablentypen dazu geben und fertig.Das sehe ich nicht so, denn Du stellst damit ja
in Frage, dass es Entwicklungsschritte gibt, und
behauptest, dass die Bedürfnisse der XProfaner
einfrieren. Ich meine, dass Gegenteil ist der Fall.Tools und Apis helfen und ermöglichen die Entwicklung
des XProfan, Tools und Apis ermöglichen die Entwicklung
jeder guten Software, keiner hier entwickelt ohne
Tools, kaum einer ohne Apis.Das Bedürfnis nach sicherem ProcAddr bestand,
in XProfan (ohne Präkompiler) wird es dieses sicherlich
auch irgendwann geben, was nur eben dem nichts nutzt,
der es jetzt benötigt, für den dieser Hinweis galt.> mir die Syntax nicht unbedingt zusagt
C-Style ist doch optional, muss doch keiner nutzen?!
Standart, auch in nativen Funktionen, ist doch
normale Syntax, verstehe nicht, was Du meinst.> Mir sind native Funktionen auch lieber
Ich weiß ja, dass Du in XProfan direkt eingebaute
Funktionen meinst, sei nur angemerkt, dass die
nativen Funktionen nicht weniger nativ sind,
als die in XProfan eingebauten. Die Sache ist nur,
habe ich eine Wahl, wenn mir XProfan eine native
Funktion nicht bietet, mir diese selber programmieren
zu können, oder eben nicht - die NProcs stehen
den in XProfan eingebauten nativen Funktionen
technisch jedenfalls in nichts nach, eher im Gegenteil,
sind sie immer direkt adressierbar und schnellst
aufrufbar aber der Hauptvorteil ist, dass man sich
diese selbst programmieren kann und dass sie mehr
"abkönnen" im Bezug auf Multithreadfähigkeit,
Callbacks und Hooks, sodass eben obige Jac-Wünsche
technisch bereits gebändigt sind, wenn auch noch nicht
mit reinem XProfan.Wer das nicht braucht, oder mit anderen Tools gleiches
Verhalten erzielen kann, wollte ich mit meinem Hinweis
garnicht erfragt haben - zurecht wie ich finde. -
Und wieder ein Thread zerquatscht. Vielleicht kann ein Admin das abtrennen, damit hier nur mein Wunsch steht, für den der Thread gedacht war. Damit will ich nicht sagen, dass ich was gegen diese Diskussion habe, ich finds hier nur fehl am Platz.
-
------------ abgetrennt --------------
Wer einen Precompiler benötigt, soll ihn doch benutzen. Es darf aber nicht verschwiegen werden, dass die native Technik, die XPSE von XPIA abgeschaut hat, einen großen Haken haben könnte, ist jedenfalls eine Vermutung von mir:
Damit erstellte Exedateien könnten anfällig gegenüber Virenwächtern sein. Es könnte eventuell damit gerechnet werden, dass ein Virentool diese Exe irtümlicherweise als infiziert anmeckert oder das in Zukunft plötzlich machen könnte...
Die eingebettete JWASM-Dll könnte von den Wächtern als Assembler-Dll erkannt werden, und da Viren oft in Assembler programmiert sind, werden solche Dateien strenger begutachtet. Mir ist das selber schon passiert, z.B. mit meiner Datei "Bewegungsmelder.exe" und ein bis zwei anderen kleineren Exen, die ich mit XPIA erzeugt habe. Der Prozentsatz ist zwar klein, aber der Nachteil könnte gegeben sein. Ein Nutzer deiner n-Procs könnte eventuell an den Fehlalarmen dann auch dann nichts ändern. XPIA-Code könnte ich zumindest noch entsprechend anpassen, auch wenn die Chancen auch nicht gut stehen.Mir ist eine XProfan-native Funktion darum lieber als 4 nProcs oder XPIA-Funktionen. Nativ ist nicht gleich nativ.
-
Zitat von Frabbing;771853
Es darf aber nicht verschwiegen werden, dass die native Technik, die XPSE von XPIA abgeschaut hat, einen großen Haken hat:
Hm nö, XPSE nutzt eine sehr angepasse/zweckoptimierte Version
der MemoryModule.Inc von Sebastian König
( http://xprofan.com/thread.core?rd=rss&t=4044#bottom )
- genau so - wie wir beide es bereits in der Community beredet hatten.Schau Dir die Implementationen einmal an, da war nichts abzuschauen,
Binärdateien in den Quelltext ablegen hast Du auch nicht erfunden,
Präkompiler schon garnicht, die XPSE Umwandlung ist auch noch
optimierter, weil ich halt persönlichen Wert darauf legte, also was
habe ich abgeschaut?Zitat von Frabbing;771853Damit erstellte Exedateien sind anfällig gegenüber Virenwächtern! Es muss immer damit gerechnet werden, dass ein Virentool diese Exe irtümlicherweise als infiziert anmeckert oder das in Zukunft plötzlich machen wird...
Die eingebettete JWASM-Dll wird von den Wächtern als Assembler-Dll erkannt, und da Viren oft in Assembler programmiert sind, werden solche Dateien strenger begutachtet.Haha, da lach ich aber - bis es soweit ist, müssten da noch einige
Assembler-Optimierungs-Pässe programmiert werden, genau so,
wie ich es in der Community aber auch schon erwähnt hatte,
und Du imho auch bereits gelesen hast.XPSE legt die kompletten Projektdateien an und belässt diese doch
selbstverständlich, jederzeit hat man immer die Möglichkeit, genau
zu sehen, was da produziert wurde. Wenn Du Dir das anschaust,
wirst Du unschwer erkennen, dass es sich bei dem von XPSE erzeugten
Assembler-Code, um weitestgehend unoptimierten Assembler-Code
handelt, welcher von regulären Kompilern kaum erzeugt wird!Optimierungspässe stehen immer auf dem Plan, diese kann ich allein
höchstens Stück für Stück umsetzen - grundsätzlich sind diese aber
zum Glück für die Funktionalität nicht notwendig.Zitat von Frabbing;771853Wäre es vermessen zu fragen, ob du mal Stücke Assembler-Quellcode davon bereitstellst?
Wäre merkwürdig ja, als würde XPSE Projektdateien verstecken?!
Zitat von Frabbing;771853Nativ ist nicht gleich nativ.
Dann zeig uns doch mal, was nativer als Call(adresse&) ist, und
besonders, dass es langsamer ist, als eine in XProfan eingebaute
Funktion und zeig doch dann auch gleich in XProfan eingebaute
Funktionen, deren Adresse Du beliebig nutzen kannst. Es ist eine
Zweckfrage. -
Übrigens ist der Titel "Nativ: Precompiler vs. XProfan" falsch, das Verfahren stellt sicher, die Zielsprache zu ergänzen. In diesem Thema geht es nach der Abtrennung darum, wie man optimal Subclasst, "Nativ: SubClassing mit XPSE" oder SubClassing mit NProc wäre angepasster, es gibt keinen Präkompiler der gegen XProfan ist.
-
Zitat
Schau Dir die Implementationen einmal an, da war nichts abzuschauen,
Binärdateien in den Quelltext ablegen hast Du auch nicht erfunden,
die XPSE Umwandlung ist zudem noch optimierter, weil ich halt persönlichen
Wert darauf legte, also was habe ich abgeschaut?Die Schritte zur Erzeugung sind bei beiden gleich. Asm-Dll wird erzeugt, JWASM erzeugt Objektdatei, Polink compiliert sie. Ich sehe da deutliche Paralellen.
Mich stört das nicht, hab ja kein Patent darauf.ZitatWäre merkwürdig ja, als würde XPSE Projektdateien verstecken?!
Gut, hab ich nicht gewusst.
ZitatHaha, da lach ich aber - bis es soweit ist, müssten da noch einige
Assembler-Optimierungs-Pässe programmiert werden, genau so,
wie ich es in der Community aber auch schon erwähnt hatte,
und Du imho auch bereits gelesen hast.Wir reden wohl aneinander vorbei. Ich spreche davon, das demnächst eine Exe die eine von XPSE erzeugte Dll beinhaltet z.b. von Kaspery oder Antivir oder sonsteinem Programm fälschlicherweise angemeckert werden könnte. Ich habs - wie gesagt - schon mit XPIA-erzeugten Exen erlebt.
-
Zitat von iF_;771883
Übrigens ist der Titel "Nativ: Precompiler vs. XProfan" falsch, das Verfahren stellt sicher, die Zielsprache zu ergänzen. In diesem Thema geht es nach der Abtrennung darum, wie man optimal Subclasst, "Nativ: SubClassing mit XPSE" oder SubClassing mit NProc wäre angepasster, es gibt keinen Präkompiler der gegen XProfan ist.
Das zu verbessern ist das kleinste Problem
-
Zitat von Frabbing;771884
Die Schritte zur Erzeugung sind bei beiden gleich. Asm-Dll wird erzeugt, JWASM erzeugt Objektdatei, Polink compiliert sie. Ich sehe da deutliche Paralellen.
Mich stört das nicht, hab ja kein Patent darauf.Das stimmt, das habe ich abgeschaut.
Zitat von Frabbing;771884
Wir reden wohl aneinander vorbei. Ich spreche davon, das demnächst eine Exe die eine von XPSE erzeugte Dll beinhaltet z.b. von Kaspery oder Antivir oder sonsteinem Programm fälschlicherweise angemeckert wird. Ich habs - wie gesagt - schon mit XPIA-erzeugten Exen erlebt.Wir reden nicht aneinander vorbei. Die Sache ist, der von XPSE
erzeugte ASM dürfte so ziemlich nichts mit dem zu tun
haben, was Virenscanner gerne erwarten. Ich erklärte das damit,
dass hierzu noch sehr viel ASM-Optimierungsarbeit notwendig wäre,
bis dieser Effekt so häufig auftritt, wie bei DLLs, die nicht mit XPSE
erzeugt wurden. So gesehen ists ja eine "neue" Sprache und es wären
vlt. erst in dieser Sprache geschriebene Viren notwendig, um eine
brauchbare Signatur zu erhalten.Aber wie gesagt, das Optimieren des ASM sehe ich eher als stätige
Aufgabe, dass bekomme ich nur Stück für Stück hin.Du als ASM-Meister hast doch das Potential, über den erzeugten ASM
zu lachen, jeder Optimierungstipp von Dir geht doch um ein vielfaches in
die Programme mit ein. Bedenke beim Lachen aber auch, dass vieles
wegen der Threadsicherheit notwendig ist, und sich insgesammt die
Sprache in der Alpha-Phase befindet - aber bereits ganz wunderbar
und imho fehlerfrei funktionert. -
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!