Deutsch
SDK-Helfer/ Tools

JRPC neuer Präkompiler für XProfan X4 - JRPC3

 
- Seite 1 -



Jens-Arne
Reumschüssel
Guten Abend zusammen,

ich bin kürzlich über das Problem gestolpert, dass XPSE eine ziemlich große Quelldatei von mir nicht mehr verarbeiten konnte. Variablen wurden plötzlich als nicht definiert gemeldet und andere "erratische" Probleme mehr. Ich könnte 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 für Operatoren und alte Containerfunktionen
*extrem schnelle native fbPROCs, sofern man FreeBasic installiert hat (kostenlos, siehe Hilfe)
*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 über @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 DLLs 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 natürlich nicht in XProfan geschrieben, da eine interpretierte Sprache hierfür naturgemäß viel zu langsam ist)
*beim Start von JRPC3 bereits vorhandene .prc-Dateien 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 (Hilfe --> online nach Updates suchen)
*64- oder 32-bit-Version verfügbar (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 natürlich keine 64-bit-XProfan-Programme, da XProfan das nicht kann, sondern JRPC3 selbst wird als 64-bit-Programm ausgeführt
*XProfan X4-Syntax verfügbar (möglicherweise noch nicht alles, da ich vermutlich 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 ausgeführt werden
*Interpreter, PRCs, EXEs und XPSE können mit Administratorrechten ausgeführt werden
*Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst klein zu halten
*Variablen, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst 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 verfügbar 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 übergeben, 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 Hilfe --> Hilfedatei anzeigen oder mit F1 verfügbar ist.

----- /Features

Herunterladen und installieren:
JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe oder als ZIP-Datei).
Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die Dateien PROFAN.EXE, PROFCOMP.EXE, PRFRUN32.EXE etc. liegen. Alternativ kann die ZIP-Datei 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 anzeigen 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 großen 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 Autoren, die jeder so ihre Eigenheiten haben, auch funktioniert.

Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de oder hier im Forum.

Beste Grüße, Jens-Arne

2.584 kB
Bezeichnung:JRPC3
Version:10.29
Kurzbeschreibung: JRPC3-Installer
Hochgeladen:15.02.2021
Ladeanzahl363
Herunterladen
1.699 kB
Bezeichnung:XProfEd_JR
Version:5.2
Kurzbeschreibung: Alte Version ohne AutoComplete zur Sicherheit
Hochgeladen:15.02.2021
Ladeanzahl224
Herunterladen
3.777 kB
Bezeichnung:JRPC3
Version:10.29
Kurzbeschreibung: ZIP-Datei statt Installer
Hochgeladen:02.04.2021
Ladeanzahl291
Herunterladen
 
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
16.02.2021  
 



 
- Seite 10 -


« Dieser Beitrag wurde als Lösung gekennzeichnet. »

- Seite 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 X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
24.09.2022  
 




funkheld
Die Erweiterung mit FreeBasic ist etwas Superleichtes , es ist Basic.

Dazu Lernen macht nicht dumm.
XPSE kommt nicht mehr klar ab XProfan3 stellte Jens-Arne fest.


Vielleicht gerade der Performance wegen.


Ich glaube du hast es ansatzweise verstanden warum Jens-Arne das gemacht hat.
Natürlich wegen dieser Performance. Er möchte das XProfanx4 nicht neu erfinden.

Gruss
 
15.01.2022  
 




Jens-Arne
Reumschüssel
Ich verdeutliche es nochmal an einem Beispiel, das vielleicht ein bisschen die Hemmungen nimmt:

Nehmt an, Ihr wolltet ein Apfelmännchen zeichnen. Das Problem ist, dass die Berechnung der Farbwerte der Pixel den Flaschhals bei der Geschwindigkeit darstellt. Das, und nur das als fbProc sieht bei mir wie folgt aus:

fbPROC fbIteration(ByRef xr As Integer,ByRef yi As Integer) As Integer Export
dim as double a,b,r,i,x,xalt,y
dim as integer v,ergebnis
r=_rmin!+_xr&*_ar!
i=_imin!+_yi&*_ai!
v=0
x=0.0
y=0.0
do
xalt=x
a=x*x
b=y*y
x=a-b+r
y=2*xalt*y+i
v=v+1
loop until (((a+b)>_tiefe%) or (v=_tiefe%))
if v=_tiefe% then
ergebnis=0
else
ergebnis=(v mod _maxf&)+1
end if
return ergebnis
ENDPROC

Es sind, wie man sieht, ein paar gepushte XProfan-Variablen dabei. Für diese Funktion muss man eigentlich gar nichts neu lernen bis auf die Art, wie in FreeBasic Variablen deklariert werden, dass auf ein "if" ein "then" folgt und wie ein "repeat...until" aussieht (do...loop until). Gäbe es fbProcs nicht, müsste man sich eine DLL hierfür mit einer ganz anderen Sprache basteln. Das ist, glaube ich, viel aufwändiger, als sich einmal anzusehen, wie man das mit den Variablen macht. So kann man das alles in einem einzigen Quelltext schreiben und muss sich sonst um nichts kümmern. Ich glaube, das ist es wert, sich damit kurz auseinanderzusetzen. Aber müssen tut man gar nichts.

Beste Grüße, Jens-Arne
 
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
15.01.2022  
 




Jens-Arne
Reumschüssel
Na gut, ich habe jetzt bei fbProcs folgende Konzessionen gemacht (die erforderlichen Umsetzungen nimmt JRPC3 automatisch vor, vorausgesetzt jeder Befehl steht in einer eigenen Zeile):

- "then" kann bei if weggelassen werden
- es kann "endif" statt "end if" benutzt werden
- es kann "repeat ... until" statt "do ... loop until" benutzt werden
- es kann "endwhile" statt "wend" benutzt werden
- es kann "endfor" statt "next" benutzt werden [später hinzugefügt, siehe unten im Forum]
 
Mit diesen einfachen Anpassungen kann man nun - bis auf die Variablendeklarationen - tatsächlich fast reinen XProfan-Code schreiben, wenn man fbProcs für das benutzt, wofür sie da sind: schnelle Berechnungen anzustellen.

Beste Grüße, Jens-Arne

EDIT:
Ich finde es übrigens phantastisch, dass sich auch +70-Jährige mit diesen Dingen auseinandersetzen! Mein Vater hat noch Mainframes mit Lochkarten programmiert; leider ist er vor kurzem verstorben. Wie viel einfacher haben wir es heute mit XProfan und dem einen oder anderen kleinen Helferlein dazu. Sich damit zu beschäftigen, hält bestimmt geistig fit.
 
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
15.01.2022  
 




p.specht

Jetzt kann sogar ich wieder aufspringen:


- "then" kann bei if weggelassen werden
- es kann "endif" statt "end if" benutzt werden
- es kann "repeat ... until" statt "do ... loop until" benutzt werden
- es kann "endwhile" statt "wend" benutzt werden
Mit diesen ... Anpassungen kann man nun - bis auf die Variablendeklarationen - tatsächlich fast reinen XProfan-Code schreiben, ...(bei)... fbProcs


Eine hervorragende Lösung!

P.S.: Mein Beileid, Jens-Arne! Auch mein Vater verstarb vor kurzem.
 
XProfan 11
Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...
15.01.2022  
 




funkheld
Danke für deine Erweiterung.
Ich freue mich immer über Erneuerungen, da sieht man dann das es weitergeht.

Damit hast du sogar einen ungläubigen Thomas geholfen der wieder auf Pferd springt.

Dann kann man bestimmt bald kleine Beispiele mit FreeBasic von p.specht sehen.

Es geht aufwärts mit XProfanx4 und FreeBasic.

Spannend wird es noch wenn es mit sendmessage...zu XProfanx4 zurück geht.

Gruss
 
15.01.2022  
 




Jens-Arne
Reumschüssel
Danke Euch beiden! Ja, es geht hoffentlich wieder etwas aufwärts.

Sendmessage sollte eigentlich nicht nötig sein, weil das ja alles sequentiell abgearbeitet wird und die DLL mit dem Hauptprogramm über Variablen kommunizieren kann. Allerdings kann man eine fbProc natürlich als Thread starten, was mit XProfan-Procs nicht geht. Da wird sendmessage dann tatsächlich sehr interessant, weil das XProfan-Hauptprogramm ja unabhängig von dem Thread weiterliefe. Allerdings habe ich mir mit Threads bisher immer furchtbar die Finger verbrannt, jedenfalls dann, wenn mehr als ein Thread laufen sollte. Da gibt's ständig Abstürze ohne irgendwelche Fehlermeldungen, egal, wie sehr ich einzelne Teile mit Mutexes abgesichert habe. Von Optimierungen wie Register-Alignment bei Variablen und Parametern mal ganz abgesehen. Da bräuchte ich wohl noch Nachhilfe...

Gruß, Jens-Arne
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
15.01.2022  
 




Jens-Arne
Reumschüssel
Hier mal ein Beispiel, wie es *nicht* funktioniert, vielleicht kann mir ja jemand sagen, was ich da falsch mache (die Warnungen vom FreeBasic-Compiler kann man ignorieren, das Programm läuft):

{$FBSYNTAX on}

declare _hE1%,_hE2%,_Mutex% SharedInFbProcs
declare _hE3%,_Ende%,_Zaehler%,_hDLL%

fbPROC fbThreadProc(ByVal p As Integer) As Integer Export
dim as integer zaehler,i,t,ende
dim as zstring pointer s
ende=0
zaehler=0
t=timer
s=HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,1000)
while ende=0
zaehler=zaehler+1
if p=1
poke zstring,s,"Thread "+str(p)+" läuft... "+str(zaehler)
WaitForSingleObject(_Mutex%,0)
sendmessage(_hE1%,WM_SETTEXT,0,s)
ReleaseMutex(_Mutex%)
else
poke zstring,s,"Thread "+str(p)+" läuft... "+str(zaehler)
WaitForSingleObject(_Mutex%,0)
sendmessage(_hE2%,WM_SETTEXT,0,s)
ReleaseMutex(_Mutex%)
endif
sleep 1000-(timer-t)
t=timer
endwhile
HeapFree(GetProcessHeap(),0,s)
return 0
ENDPROC

cls
_hE1%:=@create("EDIT",%HWnd,"",10,10,@width(%HWnd)-20,20)
_hE2%:=@create("EDIT",%HWnd,"",10,40,@width(%HWnd)-20,20)
_hE3%:=@create("EDIT",%HWnd,"",10,70,@width(%HWnd)-20,20)
_Mutex%=~CreateMutex(0,0,0)
_hDLL%=@usedll("test_fbprocs.dll")
~CreateThread(0,0,~getprocaddress(_hDLL%,"FBTHREADPROC@4"),1,0,0)
~CreateThread(0,0,~getprocaddress(_hDLL%,"FBTHREADPROC@4"),2,0,0)
_Zaehler%:=0
_Ende%:=0
whilenot _Ende%
inc _Zaehler%
settext _hE3%,"Das Hauptprogramm läuft... "+@str$(_Zaehler%)
waitinput 1
if %scankey=27
_Ende%:=1
endif
endwhile
freedll _hDLL%
end

EDIT:
Das scheint etwas damit zu tun zu haben, dass dieselbe fbProc 2x als Thread gestartet wird. Wenn man zwei getrennte (inhaltlich gleiche) Procs benutzt, funktioniert es. Das heißt also wohl, dass dieselben Variablenadressen von beiden Threads benutzt werden, was nicht gutgehen kann. Aber warum ist dann p einmal "1" und einmal "2", jedenfalls zu Anfang? Sehr merkwürdig.
 
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
15.01.2022  
 




funkheld


Bei mir läuft es nicht wie es soll.
Es wird sauber mit deiner neuesten Version compiliert.

Wenn ich es starte kommt die Fehlermeldung (Bild)

Wenn ich auf Ok drücke kommt unten die Meldung und das Programm steigt dann aus.
"Das Hauptprogramm läuft..."

Ich habe das XProfanx4 mit PatchXProfanX4a

Mit Thread ist eine gefährliche Sache.
Manchmal reagieren sogar verschiedene PC drauf zb wie bei mir : geht oder geht nicht
Bei Thread kann ich auch die Fehler nicht finden.

Bei Purebasic spiele ich gerne mit Filemap.
Sender und Empfänger.
Hat das was mit Thread zu tun?
Zwei Programme laufen und können sich gegenseitig Daten zuschieben und auch gegenseitig steuern.

Gruss

27 kB
Hochgeladen:16.01.2022
Ladeanzahl28
Herunterladen
 
16.01.2022  
 




funkheld
Wie können bitte Strings übergeben werden?
Dieses wird nicht anerkannt :

declare texti$ SharedInFbProcs

Danke.
 
17.01.2022  
 




Jens-Arne
Reumschüssel
Das Testprogramm läuft nicht, weil Du es nicht "test.prf" genannt hast. Aus dem Dateinamen wird ja der Name der DLL generiert, die ich für die Threads mit @usedll() mit einem Handle versehen muss. Und da habe ich "test_fbprocs.dll" in diesem Beispiel hardgecodet. Alternativ muss Du "test_fbprocs.dll" bei usedll in den Namen ändern, der sich aus dem Namen ableitet, den Du dem Testprogramm gegeben hast.

Strings an die DLL zu übergeben ist heikel. Das habe ich deshalb nicht einfach mit "SharedInFbProcs" zugelassen, weil eine Stringvariable, sagen wir "s$", bei jeder neuen Zuweisung von Text einen ganz neuen Speicherplatz bekommt:

s$="Text 1" 's$ steht irgendwo im Speicher
s$="Text 2" 's$ steht jetzt irgendwo ganz anders im Speicher

Das bedeutet, man kann nicht einfach den Pointer übergeben, den s$ bei der Initialisierung der DLL hat, da sich der Inhalt von @addr(s$) jederzeit ändern kann, je nachdem, was der Benutzer so tut.

Strings musst Du daher möglichst als Bereichsvariablen übergeben, die behalten ihren Speicherplatz. Man muss dann aber natürlich auch dafür sorgen, dass der Bereich groß genug für alles ist, was die DLL in den String reinschreiben könnte.

Beispiel:

{$FBSYNTAX on}

declare Bereich#

fbPROC fbStringTest(ByVal pString As ZString Pointer) As Integer Export
MessageBox(0,*pString,"Testausgabe String",0) 'der Stern vor der Pointer-Variablen besagt, dass der Inhalt genommen werden soll, nicht der Wert des Pointers (es ginge aber in diesem Fall auch ohne Stern, die API-Funktion MessageBox nimmt auch den Pointer auf den String)
*pString="Dies ist ein neuer Teststring."
return 0
ENDPROC

cls
dim Bereich#,10000 '10000 ist auf jeden Fall groß genug
string Bereich#,0="Dies ist ein Teststring."
fbStringTest(Bereich#)
print @string$(Bereich#,0)
waitinput
end

Man könnte Bereich# auch mit SharedInFbProcs pushen, aber das wäre dann ein "Any Pointer", kein "ZString Pointer", und das führt bei Strings zu Problemen, weil FreeBasic schon wissen muss, dass es sich um einen nullterminierten String handeln soll, damit alles nahtlos zusammenspielt.

Mit FileMaps arbeite ich auch manchmal. Dann kann man immerhin einen zweiten Prozess laufen lassen und dort Daten verarbeiten, was wesentlich sicherer ist, als einen Thread zu starten. Aber manchmal ist ein Thread doch interessanter. Aber eben auch brandgefährlich, irgendwelche Implikationen scheine ich da noch nicht zu durchblicken, die Variablenwerte durcheinanderwirbeln und zu Zugriffsverletzungen führen können.

Gruß, Jens-Arne
 
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de
17.01.2022  
 




funkheld


Danke Jens-Arne hast du Super erklärt.
Jetzt funktioniert es.
Ich wollte es auch auf den FB-Screen haben,

Thread geht jetzt auch.

Gruss
 {$FBSYNTAX on}
declare Bereich#
fbPROC fbStringTest(ByVal pString As ZString Pointer) As Integer Export
Screenres(256,100)
print *pString
MessageBox(0,*pString,"Testausgabe String",0)
return 0

ENDPROC

cls
dim Bereich#,10000
string Bereich#,0="Dies ist ein Teststring."
fbStringTest(Bereich#)
print @string$(Bereich#,0)
waitinput
end

20 kB
Hochgeladen:17.01.2022
Ladeanzahl32
Herunterladen
 
17.01.2022  
 




funkheld

Man könnte Bereich# auch mit SharedInFbProcs pushen, aber das wäre dann ein "Any Pointer", kein "ZString Pointer", und das führt bei Strings zu Problemen, weil FreeBasic schon wissen muss, dass es sich um einen nullterminierten String handeln soll, damit alles nahtlos zusammenspielt.


Wie wird ein String im Bereich# nullterminiert zum Pushen mit SharedlnFbProcs?

Danke.
 
17.01.2022  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

63.043 Betrachtungen

Unbenanntvor 0 min.
Jens-Arne Reumschüssel vor 4 Tagen
Manfred Barei25.09.2024
Gast.081529.08.2024
R.Schneider23.08.2024
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie