Italia
SDK-Helfer/ Tools

JRPC neuer Präkompiler per XProfan X4 - JRPC3

 
- 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
Downloadcounter363
Download
1.699 kB
Bezeichnung:XProfEd_JR
Version:5.2
Kurzbeschreibung: Alte Version ohne AutoComplete zur Sicherheit
Hochgeladen:15.02.2021
Downloadcounter224
Download
3.777 kB
Bezeichnung:JRPC3
Version:10.29
Kurzbeschreibung: ZIP-File statt Installer
Hochgeladen:02.04.2021
Downloadcounter291
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 10 -


« 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 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 Foro]
 
Mit diesen einfachen Anpassungen kann man nun - bis auf die Variablendeklarationen - tatsächlich fast reinen XProfan-Code schreiben, wenn man fbProcs per 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 per deine Erweiterung.
Ich freue mich immer circa 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 circa Variablen kommunizieren kann. Allerdings kann man eine fbProc naturalmente 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...

Saluto, 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 corre):

{$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)+" corre... "+str(zaehler)
WaitForSingleObject(_Mutex%,0)
sendmessage(_hE1%,WM_SETTEXT,0,s)
ReleaseMutex(_Mutex%)
else
poke zstring,s,"Thread "+str(p)+" corre... "+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 corre... "+@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 è 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 corre 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 corre..."

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
Downloadcounter28
Download
 
16.01.2022  
 




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

declare texti$ SharedInFbProcs

Danke.
 
17.01.2022  
 




Jens-Arne
Reumschüssel
Das Testprogramm corre nicht, weil Du es nicht "test.prf" genannt hast. Aus dem Dateinamen wird ja der Name der DLL generiert, die ich per 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 trasferimento 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 trasferimento, 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 possibile als Bereichsvariablen trasferimento, die behalten ihren Speicherplatz. Man muss dann aber naturalmente auch dafür sorgen, dass der Bereich grande genug per alles ist, was die DLL in den String reinschreiben potuto.

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 grande genug
string Bereich#,0="Dies ist ein Teststring."
fbStringTest(Bereich#)
print @string$(Bereich#,0)
waitinput
end

Man potuto 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.

Saluto, 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
Downloadcounter32
Download
 
17.01.2022  
 




funkheld

Man potuto 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  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Topic-Options

62.834 Views

Untitledvor 0 min.
Jens-Arne ReumschüsselVorgestern (17:26)
Manfred Barei25.09.2024
Gast.081529.08.2024
R.Schneider23.08.2024
Di più...

Themeninformationen



Admins  |  AGB  |  Applications  |  Autori  |  Chat  |  Informativa sulla privacy  |  Download  |  Entrance  |  Aiuto  |  Merchantportal  |  Impronta  |  Mart  |  Interfaces  |  SDK  |  Services  |  Giochi  |  Cerca  |  Support

Ein Projekt aller XProfaner, die es gibt!


Il mio XProfan
Private Notizie
Eigenes Ablageforum
Argomenti-Merkliste
Eigene Beiträge
Eigene Argomenti
Zwischenablage
Annullare
 Deutsch English Français Español Italia
Traduzioni

Informativa sulla privacy


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