| |
| |
|
| - Page 1 - |
|
Jens-Arne
Reumschüssel | Guten Abend zusammen,
ich bin kürzlich circa das Problem gestolpert, dass XPSE eine ziemlich grande Quelldatei von mir nicht mehr verarbeiten konnte. Variablen wurden plötzlich als nicht definiert gemeldet und andere "erratische" Probleme mehr. Ich potuto mir vorstellen, dass dies daran liegt, dass XPSE Schlüsselworte in Windows-Atoms verwaltet. Da ist irgendwann Schluss (bei irgendwas zwischen 60.000 und 70.000 Stück, wobei man bedenken muss, dass XPSE die Windows-API mit vorhält). Vielleicht ist es aber auch etwas ganz anderes, ich kann ja nicht in den "Maschinenraum" von XPSE schauen.
Jedenfalls blieb mir, da XPSE nicht mehr gepflegt wird, nichts anderes übrig, als das nachzubauen. Das Ergebnis ist JRPC3.
----- Features:
*vernünftige Meldung von Fehlern
*direkte Anzeige des Programmablaufes in XProfEd (sofern der unten erhältliche aufgebohrte XProfEd verwendet wird)
*Umsetzung der alten Profan-Syntax per Operatoren und alte Containerfunktionen
*extrem schnelle native fbPROCs, sofern man FreeBasic installiert hat (kostenlos, siehe Aiuto)
*mit fbPROCs kann zudem Inline-Assembler auch vor XProfan X4 realisiert werden
*extrem schnelle native pbPROCs, sofern man PureBasic installiert hat
*Echtzeitverfolgung von Variableninhalten
*einfache Zeitmessungen im Programmablauf
*Profan-Kompilerdirektiven funktionieren endlich vernünftig (z.B. Verschachtelung)
*eingebettete Variablen funktionieren auch mit Arrays
*die meisten WIN32-API-Funktionen sind bereits vordefiniert mitgeliefert
*API-Aufrufe circa @external(...) werden automatisch in @call(...)-Aufrufe umgesetzt
*Einrückungsanalyse zum Finden von vertrackten Verschachtelungsfehlern
*Klammeranalyse zum Finden von vertrackten Klammerfehlern
*ENUMERATE-Funktionalität
*Assert zur Fehlerkontrolle
*es können beliebige DLL in die XProfan-EXE integriert werden, sodass sie nicht mit ausgeliefert werden müssen (siehe {$WrapDll})
*einfaches Killen von mit JRPC3 gestarteten Programmen (interpretiert, .prc gestartet, .exe gestartet)
*extrem schnell (und daher naturalmente nicht in XProfan geschrieben, da eine interpretierte Sprache hierfür naturgemäß viel zu langsam ist)
*beim Start von JRPC3 bereits vorhandene .prc-File können zum Starten und Linken genutzt werden (es wird ein Hinweis angezeigt, dass es sich um ein altes Kompilat handelt)
*der Profan-Compiler kann zur Beschleunigung mit hoher Prozessorpriorität aufgerufen werden
*eingebauter Update-Checker mit Download, falls es ein Update gibt (Aiuto --> online nach Updates suchen)
*64- oder 32-bit-Version disponibile (einfach JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten) - Achtung, die 64-bit-Version erzeugt naturalmente keine 64-bit-XProfan-Programme, da XProfan das nicht kann, sondern JRPC3 selbst wird als 64-bit-Programm corsa
*XProfan X4-Syntax disponibile (möglicherweise noch nicht alles, da ich presumibilmente nicht alles davon benutze, aber ich habe mich um Vollständigkeit bemüht - jedenfalls sind z.B. HASH-Arrays und QUADINTs dabei)
*Interpreter, PRCs und EXEs können mit Kommandozeilenparametern corsa werden
*Interpreter, PRCs, EXEs und XPSE können mit Administratorrechten corsa werden
*Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten File entfernt, um die Dateigröße des Kompilats possibile klein zu halten
*Variablen, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten File entfernt, um die Dateigröße des Kompilats possibile klein zu halten und den Speicherverbrauch zu optimieren
*nPROCs aus XPSE werden automatisch mit XPE zu einer DLL umgesetzt und die Aufrufe der nPROCs im Programm entsprechend angepasst, sofern XPSE vorhanden ist
*fast alles aus XPSE funktioniert auch in JRPC3 ({$NOERR}, {$(PRE)BATCH}, {$PUSHKEYWORD}, Interpreter, Runtime und Compiler festlegen, Shorties, ...)
*XProfEd_JR mit Quelltext-AutoComplete
*XProfEd_JR mit Quelltext-Memory-Funktion (Markierungen, zu denen zurückgesprungen werden kann)
Einschränkungen:
-kein XPSE-Inline-Assembler, wohl aber XProfan-Inline-Assembler (darin allerdings keine Prüfungen auf Korrektheit des Codes)
-ABER: man kann XPSE aus JRPC3 heraus aufrufen, sodass diese Funktionalität weiterhin disponibile ist, sofern man XPSE besitzt (neuer Shorty: {$x})
-Variablen, die in einer Prozedur nicht deklariert sind, sondern "aus der aufrufenden Prozedur übernommen werden", sind standardmäßig nicht zugelassen (XProfan erlaubt das, aber so etwas ist genauso tödlich wie GOTO-Anweisungen). Bitte alle zu nutzenden Inputs als Parameter trasferimento, und wenn etwas aus dem aufrufenden Programmteil verändert werden muss, beim Aufruf als Parameter z.B. @addr(x&) verwenden und in der Prozedur parameters x# und LONG x#,0=y& nutzen.
Wenn man aber unbedingt "vererbte" Variablen nutzen möchte, kann man dies mit der Kompilerdirektive {$Declare...} tun.
*als Hommage an XPSE lautet die Endung der Ausgabedatei ".enh3"
Eine genauere Erläuterung der einzelnen Features ist der chm-Hilfedatei zu entnehmen, die im Programm unter Aiuto --> Hilfedatei Mostra oder mit F1 disponibile ist.
----- /Features
Herunterladen und installieren:
JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe oder als ZIP-File).
Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die File PROFAN.EXE, PROFCOMP.EXE, PRFRUN32.EXE etc. liegen. Alternativ kann die ZIP-File heruntergeladen und deren Inhalt manuell ins XProfan-Stammverzeichnis kopiert werden.
Einrichtung:
JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten.
Alle Befehle sind mit dem Befehl "h" wie "Hilfe" abrufbar und sollten selbsterklärend sein.
Für viele erweitere Features, die XProfEd betreffen, wie z.B. jenes, die Zeile, in der ein Fehler auftrat, direkt in XProfEd Mostra zu können, ist der mitinstallierte XProfEd_JR erforderlich. Dafür muss man also XProfEd_JR.exe statt XProfEd.exe als Editor benutzen. Als "goody" gibt es dazu, dass beim Auf- und Zufalten von Programmen ein Fortschrittsanzeiger integriert ist (das kann bei grande Programmen ja bekanntlich ein bisschen dauern).
Es mag sein, dass noch nicht alles perfekt funktioniert. Ich bitte hierfür um Nachsicht. Meine Programme lassen sich umsetzen, aber das muss noch lange nicht heißen, dass dies mit Programmen anderer Autori, die jeder so ihre Eigenheiten haben, auch funktioniert.
Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de oder hier im Foro.
Beste Grüße, Jens-Arne |
 | 2.584 kB | | | Bezeichnung: | JRPC3 | | | Version: | 10.29 | | | Kurzbeschreibung: | JRPC3-Installer | | | Hochgeladen: | 15.02.2021 | | | Downloadcounter: |  | | | Download | | | | 1.699 kB | | | Bezeichnung: | XProfEd_JR | | | Version: | 5.2 | | | Kurzbeschreibung: | Alte Version ohne AutoComplete zur Sicherheit | | | Hochgeladen: | 15.02.2021 | | | Downloadcounter: |  | | | Download | | | | 3.777 kB | | | Bezeichnung: | JRPC3 | | | Version: | 10.29 | | | Kurzbeschreibung: | ZIP-File statt Installer | | | Hochgeladen: | 02.04.2021 | | | Downloadcounter: |  | | | Download |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 16.02.2021 ▲ |
|
| |
|
| |
| |
| - Page 24 - |
|
 |
« Dieser Beitrag wurde als Lösung gekennzeichnet. » |
|
| - Page 15 - |
|
Jens-Arne
Reumschüssel | | Es gibt eine neue Version, die anders mit dem internen Messagehandling umgeht. Bitte probier die mal aus. Vielleicht ist das Problem damit behoben. |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 24.09.2022 ▲ |
|
| |
|
|
|
Walter | OK!
Habe 0 reingeschrieben - und es corre!
Diese DLL habe ich auf der Erzeuger-Homepage www.paehl.de/ auch nicht mehr gefunden.
Da sie aber gut funktioniert, setze ich sie weiterhin ein.
Danke! |
|
| |
| |
| |
|
|
Jens-Arne
Reumschüssel | Probier mal dieses kleine Programm aus:
{$NoExternal2CallConversion}
{$NoDef2ExternalConversion}
{$SetFbDllName Test_fbprocs}
DEF fbTestProc2(1) !"Test_fbprocs.dll","FBTESTPROC@4"
fbPROC fbTestProc(byval i as integer) as integer Export
return i
ENDPROC
cls
print "Direktaufruf: "+@str$(fbTestProc(chr$(0)))
print "via External: "+@str$(@external("Test_fbprocs.dll","FBTESTPROC@4",chr$(0)))
print "via Call: "+@str$(@call(@GetFbProcAddr("fbTestProc"),chr$(0)))
print "via DEF: "+@str$(@fbTestProc2(chr$(0)))
waitinput
end
Daran wird klar, dass alle Funktionsaufruf-Methoden immer korrekt nach interner Typumwandlung die Adresse eines Strings trasferimento, der chr$(0) enthält, nur DEF nicht. DEF übergibt unkorrekt 0. |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 23.05.2023 ▲ |
|
| |
|
|
Walter | Glaub Dir das voll! 
Ausprobieren geht aber nicht, da sich das Ding im Präcompiler auf nimmer Wiedersehen verabschiedet.
Brauche ich dazu die Test_fbprocs.dll? |
|
| |
| |
| |
|
|
Jens-Arne
Reumschüssel | | Also das ist merkwürdig. Ich kann das problemlos starten, auch mit "<Tilde><Tilde>temp<Tilde><Tilde>.prf" als Dateiname. Daher wieder die zugegebenermaßen etwas hilflose Frage: Hast Du die neuste Version von JRPC3 benutzt? Sonst wüsste ich nicht, woran das liegen potuto. Und die File Test_fbprocs.dll wird ja gerade erst durch das Programm erzeugt, die musst Du also nicht vorher haben. |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 27.05.2023 ▲ |
|
| |
|
|
Walter | Sooooo ... geschafft. 
Problem war wahrscheinlich, dass ich die Source nicht gespeichert hatte (?).
Jedenfalls ist es nach dem Speichern nun gelaufen - und ich sehe das Ergebnis!
Jetzt muss ich mich noch mit freebasic beschäftigen, um auch eigene DLL erzeugen zu können! 
Doch gleich die nächste Frage  : Warum wird beim call-Aufruf ein anderes i zurückgegeben als beim Direktaufruf und beim external?
Sollte doch der Wert derselben Adresse sein? |
|
| |
| |
| |
|
|
Jens-Arne
Reumschüssel | Nein, das ist der Trick dabei: Bei jeder Übergabe von chr$(0) wird von XProfan intern ein neuer String erzeugt und dessen Adresse trasferimento. Direkt nach Rückkehr der DLL-Funktion wird der String mit Sicherheit sofort wieder freigegeben. Daher hat jeder Aufruf eine andere, zufällige String-Adresse.
Das ist sogar bei XProfan-Strings selbst der Fall. Jedes Mal, wenn Du einem String einen neuen Inhalt zuweist (selbst wenn es derselbe ist wie vorher), steht der String danach an einer ganz anderen Speicheradresse. Intern wird ja immer genau so viel Speicher angefordert, wie per die Länge des Strings erforderlich ist. Und da diese Länge variabel ist, wird das bei jeder Zuweisung neu vorgenommen. Deshalb ist das Arbeiten mit übergebenen Strings in fb-/pbPROCs so kompliziert, weil die Speicheradresse von Strings variabel ist, im Gegensatz zur Speicheradresse von z.B. Integer-Variablen.
Beispiel:
|
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 28.05.2023 ▲ |
|
| |
|
|
Jens-Arne
Reumschüssel | Version 9.17a disponibile:
{$WrapDlls} eingeführt. Damit werden die von fb-/pbPROCs erzeugten DLL direkt in die XProfan-Exe-File integriert, sodass sie nicht mehr mitgeliefert werden müssen. Siehe Aiuto-File zu Kompilerdirektiven --> {$WrapDlls}.
Beste Grüße, Jens-Arne |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 28.05.2023 ▲ |
|
| |
|
|
Walter | | Ok, danke per die Erklärung! |
|
| |
| |
| |
|
|
funkheld | Geht das bitte auch per Purebasic?
Danke.
gruss |
|
| |
| |
| |
|
|
Jens-Arne
Reumschüssel | Hallo funkheld,
ja. Man kann sogar FreeBasic und PureBasic nebeneinander benutzen, wenn man möchte. Dann werden mit {$WrapDlls} beide DLL in das Profan-Programm eingebaut. |
|
| |
| XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 31.05.2023 ▲ |
|
| |
|
|
Jens-Arne
Reumschüssel | V9.26:
pbPROCs mit frei wählbaren Rückgabetypen eingebaut
Deklarationsbeispiel: pbPROC ProcName.s() per einen String als Rückgabewert
Die Typangabe kommt also nach dem Prozedurnamen, nicht nach "pbPROC", wie es in reinem PureBasic üblich wäre [Procedure.s ProcName()].
ACHTUNG: Von Integer abweichende Rückgabetypen dürfen nicht in pbPROCs verwendet werden, die vom XProfan-Programm aufgerufen werden, da Rückgabewerte von DLL-Prozeduren ans Hauptprogramm immer 4 Bytes breit sein müssen. Sehr wohl aber in "Hilfs-pbPROCs", die nur von anderen pbPROCs aufgerufen werden.
Genauer gesagt dürfen bei extern verwendeten Funktionen keine Rückgabetypen benutzt werden, die nicht vier Bytes belegen. Single (.f in PureBasic) würde also durchaus gehen. Aber das sind Feinheiten.
Bei fbPROCs war das alles kein großes Problem, da in FreeBasic die Rückgabetypdefinition mit As ... nach der Parameterklammer kommt. Für pbPROCs musste aber eine spezielle Schreibweise dafür her.
Saluto, Jens-Arne |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 12.06.2023 ▲ |
|
| |
|
|
Jens-Arne
Reumschüssel | V9.31a:
Es können nun beliebige DLL direkt in die XProfan-EXE integriert werden. Hierzu ist {$WrapDll <DLL-Name>} zu verwenden. Die DLL-File muss dann nicht mehr mitgeliefert werden.
Dies ist allerdings nur bei relativ kleinen DLL sinnvoll, weil sonst die Ladezeit des XProfan-Programms zu grande werden würde. Wenn man aber z.B. prfdat32.dll einbinden möchte, dann ist diese Funktion perfekt dafür geeignet.
{$WrapDll ...} wirkt wie ImportDll(). Die Funktionen der DLL können also direkt im Code verwendet werden. Ein Aufruf circa @external() bleibt aber ebenfalls possibile. Beides wird von JRPC3 in schnelle @call()-Aufrufe verwandelt.
Saluto, Jens-Arne |
|
| |
| XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de | 14.06.2023 ▲ |
|
| |
|
(467)
Deutsch
English
Français
Español
Italia
