XProfan

Was Du möchtest ginge per Call, einfach Funktionsadressen (bzw. in eine / aus einer Liste) beziehen.

Deine Execute

-Syntax ist aber imho falsch, klicke mal auf den Befehl.

07.10.2008 ▲

Jörg
Sellmeyer

(warum eigentlich? )

Weil Profan eine Interpretierte Sprache ist. Das heißt: der compiler wandelt Dein Programm in etwas ganz anderes um. Da das Runtimemodul die Interpretersprache nicht liest, sondern die compilierte Form, kann es mit dem Code in Textform nichts anfangen.

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

07.10.2008 ▲

Hierbei wird XP-Script aber mal Abhilfe schaffen. Wenn es denn als "Service" installiert ist, dann kann mit mit einer Include einfach auch aus eigenen Exen XProfancode interpretiert zur Ausführung bringen.

08.10.2008 ▲

H.Brill

Sorry, daß ich das Execute S mal wieder hoch pushe.
Früher, zu DOS-Zeiten, gab es mal in Turbo Pascal 4.5
in der IDE einen Menü - Befehl :

Compile to Memory

Damit konnte man ins Memory compilieren. War interessant, um nicht immer
auf Diskette zu kompileren und auszuführen. Und es war logischerweise auch
viel schneller in der Ausführung.

Vielleicht wäre so was auch für XProfan möglich ?

Compile Befehl$, bereich#' Kann ein Befehl oder eine Proc sein

Der bereich# müßte dann intern auf die richtige Größe gebracht werden
und könnte dann auch mit

Call(F[,P1,P2,...,Pn])

aufgerufen werden. Oder evtl. auch über eine Systemvariable.

Set("Memory", 1) aktiviert einen bereich#, der von Compile genutzt wird.
Call &Memory, [P1, P2...PN]

Das wäre dann praktisch eine compilierte .prc - Datei im RAM, die dann die
Runtime aufruft. Ein selber compiliertes XProfan- Programm macht ja auch
nichts anderes.

Benutze XPROFAN X3 + FREEPROFAN
Wir sind die XProfaner.
Sie werden von uns assimiliert.
Widerstand ist zwecklos!
Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.

Was die Borg können, können wir schon lange.

27.04.2025 ▲

H.Brill

Vielleicht hier noch zur Ergänzung und damit es z.b. in Paules Forum nicht
verloren geht. Das habe ich mittlerweile rausgefunden :

Shell Par$(0) + s

s = prfdatei bzw. prcdatei
Im Interpreter ist es Profan.exe und müßte mit einer .prf gefüttert werden.
Bei einer .exe ist es Prfrun32.exe, die mit einer .prc Datei gefüttert wird.

Wichtig ist in der Hilfe bei Par$() folgender Satz :

Bei der .EXE-Datei versucht das integrierte Runtime-Modul zunächst, den ersten Parameter <par1> als XProfan-Compilat (*.prc) zu interpretieren. Handelt es sich um eine solches, wird es ausgeführt, ansonsten das Programm selbst. Eine PRC-Datei wird auch als solche erkannt, wenn sie eine andere Endung hat.

Ob eine Unit geht, weiß ich nicht, da sie ja eigentlich mit $U eingebunden und vom integrierten Linker hinzugefügt wird.

Aber man kann sich ja auch .prf Dateien, die nur Procs (Proc ... EndProc) enthalten, compileren lassen. Ob die dann aber auch eingehängt werden.

Also am besten mit .prf Dateien arbeiten. Das geht mit Interpreter und Runtime
mit normalem Quellcode. Am besten macht man das mit den Compiler-Direktiven :

 $IFDEF INTERPRETER
s = " " + prfdatei
Shell Par$(0) + s
 $ENDIF
 $IFDEF COMPILER
s = " " + prcdatei
Shell Par$(0) + s
 $ENDIF

Gestern (07:26) ▲