Speicherschutz und Amiga OS 3.x - amiga-news.de Forum

amiga-news.de Forum > Amiga, AmigaOS 4 > Speicherschutz und Amiga OS 3.x

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

23.12.2009, 10:09 Uhr

68kassembler
Posts: 62
Nutzer

Hallo,
da schon mehrmals in den News Diskutiert worden ist, das Speicherschutz bei der Classic API des Amiga OS nicht möglich sei, frage ich mal, warum nicht?

Wenn ich das richtig sehe, kann man das für Speicherbereiche sehr leicht realisieren, da die doch über die API reserviert werden. Daher, man muss doch nur merken, welches Programm welche Speicherbereiche Reserviert hat.

Bei der GUI sehe ich das ähnlich, nur das man da merken muss, welches Programm welches Fenster besitzt.

Nur bei Treibern und Dingen, wo man Speicherbereiche an anderen Programmen weiter gibt (.z.b. Message) sehe ich ein gewisses Problem. Ich denke aber, das man es dadurch in den Griff bekommt, in dem man dort sich merken muss, an welchen Programm der Speicherbereich weitergegeben worden ist, wenn das möglich sein sollte. Aber da müssen wohl wirklich die Programme angepasst werden, oder man benutzt ein Kompatibilitätsmodus, der so aus sieht, das alle Programme auf den Speicherbereich des betroffenen Programmes zugreifen dürfen. Allerdings kann man ja Treiber so erweitern, das sie zuminestens auf die Hardware zugreifen dürfen.

Sollte auf den Stack zugegriffen werden und der Stack überlaufen, so kann man das feststellen und Dynamisch den Stack erweitern. Daher sehe ich da auch nicht das Problem.

Daher, mal an alle, die sich hier auskennen, wo ist das Problem? Liegt das Problem nun wirklich daran, das die meisten Programme einfach davon ausgehen, das so was wie Speicherschutz nicht gibt, und deswegen so Programmiert worden ist, das sie so schon laufen werden? Wenn das der Fall sein sollte, dann wird es Speicherschutz wirklich auf den Amiga schwer haben.

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 10:35 Uhr

whose
Posts: 2156
Nutzer

@68kassembler:

Es wurde nie gesagt, daß "Speicherschutz" nicht möglich ist. Was gesagt wurde ist, daß "Speicherschutz" in der Form, wie z.B. Unix ihn anbietet, nicht möglich ist. Das hat recht simple Gründe.

Unter AmigaOS teilen sich alle Programme den gesamten Speicherbereich bzw. die gesamte Maschine. Unter z.B. Unix läuft jedes Programm "für sich", d.h. für das Programm sieht es so aus, als hätte es die gesamte Maschine für sich, also auch den gesamten Speicher.

Letzteres ist der Grund dafür, weshalb der Speicherschutz bei Unix & Co. "dichter" ist, sprich, es können wesentlich mehr Speicherschutzverletzungen erkannt und abgefangen werden. Dadurch ist es dann auch möglich, abgestürzte Programme aus dem Speicher zu entfernen, ohne das OS selbst in Verlegenheit zu bringen.

Bei AmigaOS ist das schwieriger, u.A. aufgrund der Teilung gemeinsamen Speichers zwischen Programmen u. Betriebssystem. Unter OS4/MOS gibt es Speicherschutz, aber halt nicht so, wie manche Leute ihn gerne hätten. Theoretisch wäre es möglich, z.B. OS4-API mittels wüstem Gepatche auch zu OS3.x zu bringen, aber wer will das machen?

Von der ganzen Arbeit mal abgesehen, wie Du schon richtig bemerkt hast, sind einige Programme ziemlich schludrig geschrieben, damit gibts dann auf jeden Fall reichlich Ärger (wie unter OS4 auch) und die Leute meckern, daß Programm X und Programm Y aber essentiell sind, weil... was dann noch mehr Arbeit für Kompatibilitätshacks nach sich zieht.

Zusammengefaßt: Teilweise machbar wärs, aber es wäre ein Kompromiß, den viele Leute nicht eingehen möchten.

Grüße

--
---

µA1 PPC 750GX-800

A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 10:59 Uhr

Dennis_50300
Posts: 613
Nutzer

Ich habe nicht wirklich viel Plan davon, allerdings soweit ich das
verstehe soll so ein Speicherschutz das System stabiler machen ?

Mal meine Meinung als Jahrelanger Microdoof-PC User,
seitdem ich mit dem Amiga 500 angefangen habe,
genauer noch seitdem der dann KickROM 3.1 hatte
und die WB 3.1 auf Festplatte habe ich das 1. mal
das gefühl gehabt einen anständigen Computer zu besitzen.

Seit Gestern hat mein A1200 eine Blizzard 1230,
68030 mit 50 MHZ und 128 MB EDO RAM(Damit ich den Trapdoor
zu machen kann habe ich aus meinem ur-alten PC 16 MB EDO
reingesteckt,die 128 kommen wieder rein wenn ich
ihn in einem anderen Gehäuse drinnen habe da dann der Platz dafür da ist)

Momentan sieht es so aus das ich damit meine Diskettenbackup's
in Form von ADF-Dateien mit Tracksaver auf eine 3,5" Festplatte
ziehe und mit DosControl 6.0a eine wenig sortiere.
Also verschieben Schubladen erstellen und umbennen.

Übertragung vom PC geht im Moment nur über das Micronik
HD Diskettenlaufwerk(CrossDOS 7 Gold),weil der PCMCIA erstmal repariert werden muss.
(Verbogene und leider auch abgebrochene PIN's)

Der läuft mit WB 3.1 locker genauso geil wie mein
AMD Windsor 6000+ mit 4 GB RAM und 512 MB NVIDIA Grafik.

Dabei vorallem noch stabiler.

Da sag mal einer das so alte Sachen heutzutage Schrott seien.
Vom Gefühl her finde ich mein 1200er sogar stabiler als mein
64-Bit AMD Dualcore-Design Highend Rechner.(Also als AM2 b.z.w.
AM2+ noch Stand der Dinge war wobei ich denke AM3 ist bestimmt
auch nicht viel anders, da lediglich ein höher getakteter Bustakt
wieder zu noch mehr instabilität führen kann denke ich mal)

Kombiniere mal:
Ich glaube sowas gab es seit dem PC.
MS-DOS ?

Ich denke sowas braucht ein gut erhaltener Commodore Amiga
garnicht weil das nur ein Feature ist das das schrottige
Microdoof-Schrott programmiergefusche nötig hat.

Gruß Dennis_50300
--
Amiga 500Plus
Amiga 600(Zu verkaufen mit vielen Extras)
Amiga 1200

[ Dieser Beitrag wurde von Dennis_50300 am 23.12.2009 um 11:03 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 11:41 Uhr

MaikG
Posts: 5172
Nutzer

Zitat:
Original von whose:

Zusammengefaßt: Teilweise machbar wärs, aber es wäre ein Kompromiß, den viele Leute nicht eingehen möchten.

Und wie wäre es mit einer neueinführung?
z.B.
AllocVecNew() optional mit MEMF_SHARED falls man vor hat den Speicher zusammen mit anderen Programmen zu nutzen.

So wären alle neuen Programme besser vor fehlern geschützt.
Es ist leider nicht so das man nur früher Fehler gemacht hat,
es wird weiterhin vorkommen. Auch wenn nicht so häufig da
Enforcer etc. zur Verfügung steht.

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 11:46 Uhr

Thore
Posts: 2266
Nutzer

@Dennis_50300:
> allerdings soweit ich das verstehe soll so ein Speicherschutz das System stabiler machen ?
Genau, und daß niemand in den "heiligen" Speicherbereich der in den RAM geladenen Systemdaten pfuscht.

Das System wird aber im Grunde nur dann stabiler, wenn die Programmierer anständig programmieren. Denn auch bei Win lösen diese Zugriffe "Exceptions" (Ausnahmebehandlungen) aus oder zwingen Win gar zum Absturz, trotz Speicherschutz.

Auf einem Mehrbenutzersystem ist Speicherschutz sinnvoll, genauso wie der vorig beschriebene "virtuelle Speicher" (M$ verwechselt diesen Begriff oft mit dem Auslagerungsspeicher, der eigentlich swap heißt und nicht virtueller Speicher)
Virtuell heißt er deshalb, da die nach außen gezeigten Adressbereiche anders sind, wie die, die intern vom System benutzt werden. So können 2 Benutzer auf der gleichen Maschine die Adressen $12345-$54321 verwenden, obwohl sie sich nicht in die Quere kommen, intern sind die Adressen nämlich anders. Dieses Mapping wird von der MMU gesteuert über Reloc-Tables.
Dieses Mapping wurde in AmigaOS nicht implementiert und ohne gewaltige Patches ist dies auch nicht zu machen (alles ist hier direktadressiert).

Eine Lösung ist z.B. Enforcer, welcher über die MMU angibt, welche Speicherbereiche nicht beschrieben werden können. Beim Versuch darauf zu schreiben, wird eine Ausnahme-Routine angestoßen.

Das letzte Problem ist die Abhängigkeit der Komponenten untereinander. In einem Button steht z.B. nicht drin, welcher Task dem Button zugrundeliegt, und kann so nicht "von außen" gefreed werden, wenn die App crasht (bisschen mein denglisch aufpolieren, hehe)
Dadurch bleiben Code-Leichen (Fenster etc) liegen.
Es gibt zwar manchmal eine "Zuordnung" jedoch kann man sich nicht immer drauf verlassen.

Ich denke das ist auch der Grund, warum Amiga-Programme in der Regel Bugfeier sind als Win-Programme, denn die Programmierer MÜSSEN sauber programmieren

[ Dieser Beitrag wurde von Thore am 23.12.2009 um 11:48 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 12:13 Uhr

Bluebird
Posts: 3260
Nutzer

@Dennis_50300:ab einem bestimmten niveau wird es auch am amiga ziemlich buggy

also wenn mal die anzahl der programme die gleichzeitig und miteinander laufen sollen groesser wird , gibts auch mehr konflickte

wobei man wenn man seinen amiga lange nuzt und kennt , kann man schon sagen wie gross das risiko ist wenn programm X und oder programm Y laeuft , so gehts mir mal hehe
ansonsten vielleicht auch aberglaube dabei , aber umso mehr ram ich hatte umso stabiler lief die kiste .
gerade einige programme verkraften das ganz und garnicht wenn das ram ausgeht , also oft bekommen man ne meldung aber wie gesgat schmiert die kiste oft genug auch ab oder friert ein ...
ansonsten bin ich mit der stabilitaet des amiga os 3 meistens zufrieden , wie gesgat mit der zeit kennt man die soft die anfaehlliger ist ...

mfg Bluebird

--
A1200 Tower, BPPC 060/50-603e/175 256mb, BVision, Z4, ConneXion, DelfinaLite, Oktagon, VarIO, Deneb, RBMKeyInterface, AmigaIIIT, 540mbQuantumFireball, 74gbSamsungSpinPoint, 4gbQuantumFireball,
Yamaha6416S, Mitsumi2801TE, LS120, Siemens17P1, NECP2x

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 13:20 Uhr

Thore
Posts: 2266
Nutzer

@Bluebird:
> also oft bekommen man ne meldung aber wie gesgat schmiert die kiste oft genug auch ab

Passiert nur wenn die Programme keine gscheite Fehlerbehandlung haben, wie gesagt, der Programmierer entscheidet obs crasht oder nicht. Oder z.B. wenn direkt auf ChipRAM adressiert wird ohne den Speicher zu reservieren (mache Spiele tun sowas...)
Ebenso beim Zusammenspiel zweier Programme ist der Programmierer schuld wenns hängt, nicht das AmigaOS.

Speicherschutz ist daher auf dem AmigaOS und MorphOS nicht _nötig_ aber ein nice to have.

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 13:49 Uhr

eliotmc
Posts: 925
Nutzer

Mich wundert immer wieder, dass Amiga User Speicherschutz als unnötig ansehen.

--
regards
eliot
http://www.exception-dev.de

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 14:59 Uhr

GREX
Posts: 509
Nutzer

Ein guter Amiga könnte einen Warmstart binnen weniger Sekunden ausführen (vom Reset bis zum Wiedererscheinen der Workbench). Wie lange brauchen selbst schnelle PCs, vor allem dann, wenn Windows schon lange nicht mehr neu installiert wurde!? Das kann dutzende Male länger dauern (und geht auch gerne noch lange im Hintergrund weiter, wenn Windows offiziell schon geladen hat)!
Außerdem sind viele Crashes am Amiga nicht so schlimm, dass man nicht vorher noch zu anderen Anwendungen wechseln könnte, um gegebenenfalls ungesicherte Daten zu speichern.
Summa summarum kann ich also sehr gut ohne Speicherschutz leben. Man sollte die wenigen Resourcen im Programmiererbereich wohl lieber dazu nutzen, irgendwelche globigen OpenSourcePorts besser für 68k zu optimieren.

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 15:18 Uhr

Thore
Posts: 2266
Nutzer

@eliotmc:
> Mich wundert immer wieder, dass Amiga User Speicherschutz als unnötig ansehen.
Oh da hast Du mich aber falsch verstanden.
Speicherschutz auf Win und Lin sind ein _muss_ und auf AmigaOS gehts auch ohne und wird nicht benötigt. So meinte ich das.
Sicher ist Speicherschutz eine feine Sache, aber wenn man richtig programmiert ist dies auf unserem single-User-System nicht nötig (und sogar auch bei multiuser nicht wenn das virtaul memory mapping intelligent genug ist)
Allerdings macht z.B. Enforcer das System ein bisschen lahmer, wenn auch ein Stück weit sicherer.

Würde z.B. in Win der Speicherschutz deaktivieren würde, dann würde man mal merken wie oft es crasht, aber dann heftig... Gerade als Programmierer sieht man die schönen Fensterchen mit dem X doch recht häufig

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 16:20 Uhr

Der_Wanderer
Posts: 1229
Nutzer

> Würde z.B. in Win der Speicherschutz deaktivieren würde, dann würde man mal merken wie oft es crasht, aber dann heftig...
Genau das Gegenteil ist der Fall. Durch Speicherschutzt merkt man ja sofort, wenn ein Programm Mist baut.

Also hier haben einige Speicherschutz und dessen Konsequenzen nicht verstanden.

1. Speicherschutz ist dein Freund. Statt Memtrash, der zu einem späteren, zufälligen Zeitpunkt irgendein Programm, z.B. das arme input.device, crashen lässt, gibt es KEINEN Memtrash und es wird der Verursacher geschlossen und man erhält eine Fehlermeldung. Das ist prima zum Debuggen und ermöglicht erst das Schreiben von stabiler Software, wenn ein gewissen Komplexitätsgrad überschritten werden soll.

2. Speicherschutz ist was anderes als Resourcetracking. Fenster/Screens/Ports/Devices/Libraries/SubThreads etc. zu schliessen, wenn ein Programm crashed, nennt man Resourcetracking.
Speicherschutz nennt man, wenn man einem Programm nicht den Zugriff auf den kompletten Adressraum des Computers zugesteht, sondern nur auf eine Untermenge, idealerweise die, die das Programm auch selbst allokiert hat. Das geht natürlich nicht immer, siehe Messages, oder Libraries, bei AmigaOS im Kontext des Aufrufers laufen. Speicherschutz kann man auch schon nennen, wenn man NULL Pointer abfrägt, und geht bis dahin dass jedes Programm stenge gekapselt in einer eigenen Adresswelt lebt, und nur über OS Messages mit der Aussenwelt kommunizieren darf.

--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 16:50 Uhr

Thore
Posts: 2266
Nutzer

> Genau das Gegenteil ist der Fall
Ich meinte "crasht", also richtig abstürzt, nicht "in einer exception endet". Man kann illegale Speicherzugriffe auch einfach unterdrücken und die Fehlermeldung nicht angezeigen mit Speicherschutz.

> Durch Speicherschutzt merkt man ja sofort, wenn ein Programm Mist baut.
Nur wenn die Exception angezeigt wird...

> Also hier haben einige Speicherschutz und dessen Konsequenzen nicht verstanden.
Doch schon, nur verwechseln hier einige "nicht nötig" mit "unsinnig" wobei das gänzlich unterschiedliche Dinge sind.

> Das ist prima zum Debuggen und ermöglicht erst das Schreiben von stabiler Software, wenn ein gewissen Komplexitätsgrad überschritten werden soll.
Was z.B. mit dem MorphOS OWB widerlegt wurde, es kommt ohne Speicherschutz aus und ist sehr stabil.
Wenn man sich auf seinen reservierten Speicher verlässt und keine Overflows verursacht und keine wilden Adressen beschreibt, dürfte es auch bei komplexen Projekten kein Problem sein.
Auch das initialisieren von Klassen/structs mit NULL und vor dem Free auf NULL prüfen hilft, und bei Referenzen muss man aufpassen.

> Speicherschutz ist was anderes als Resourcetracking
Ja, bin vorhin nur auf einen vorangegangenen Beitrag eingegangen.

Speicherschutz ist im Grunde nur das Verbieten von Zugriffen auf bestimmte Adressräume. Alles andere beschriebene ist quasi AddOn.

Es gibt noch weitere Möglichkeiten, ein Programm sicherer zu machen.
Ich hab damals ein Programm geschrieben, welches Abstürze abfängt und das Programm ggf mit seinen Fenstern, Screens etc schließt. Es nutzt hierbei den TrapCode aus, und hängt dort einen Exception Code ein, der beim Absturz ausgeführt wird.

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 19:34 Uhr

eliotmc
Posts: 925
Nutzer

@Thore:
Stabilität ist die eine Sache, Sicherheit die andere.
Sie wurde hier noch gar nicht erwähnt.
Unter allen Amiga Systemen ist es möglich Schadcode
über den Browser, TCP, Email usw. einzuschleusen,
ohne dass es das Betriebssystem noch der Benutzer
mitbekommt.
Nicht wirklich gut.

Was OWb angeht: Owb stammt von Systemen, die
Speicherschutz haben.

Wer A sagt, muss auch B sagen.
Virtual Memory und Resourcetracking wären
logische weitere Schritte.

Was mich wundert: Der Kernel von Morphos beherrscht all
diese Techniken, nur werden sie nicht genutzt.
Wenn die ABox abraucht, sollte es eigentlich möglich
sein, nur die A Box neu zu starten, statt des gesamten Kernels.
Schade, dass die ABox nicht komplett virtualisiert ist.
--
regards
eliot
http://www.exception-dev.de

[ - Antworten - Zitieren - Direktlink - ]

23.12.2009, 21:47 Uhr

68kassembler
Posts: 62
Nutzer

Also, wenn ich das jetzt richtig verstanden habe, ist das so:

Man kann dafür sorgen, das Programme nicht mehr wahllos irgendwo hinschreiben bzw. lesen dürfen (ich nenne das mal Speicher schreib und lese Schutz):

Dies würde sich leicht Implementieren lassen aber es kann Inkompatibilitäten mit alter Software geben, weil da der Programmiere die Software Schlecht oder Fehlerhaft geschrieben hat. Aber da kann man notfalls, aus meiner Sicht, einzelne Programme ebene von diesen Schutz ausnehmen und es läuft weiter, wie vorher, nur, das jetzt vielleicht auch der Programmierer merkt, das er was falsch gemacht hat.

Man kann durch Ressourcen Tracking dafür sorgen, das man weiß, welche Sachen ein Programm genutzt haben und, falls das Programm diese nicht mehr frei geben sollte, dafür sorgen, das dies von Betriebssystem Frei gegeben wird. Wenn ich das richtig verstanden habe, gibt es aber kaum Speicher, der gleichzeitig von anderen Programmen genutzt wird. Daher wird man, bei beenden des Programmes durchaus alles Frei geben können. Bei GUI und anderen Sachen sehe ich das ähnlich. Und wenn man die Libraries, welche das Programm öffnet, als Teil des Programmes ansieht, so kann man das Ressourcen Tracking doch auf die meisten Libraries erweitern. Bei denen, wo das nicht möglich sein sollte, kann man ja ausnahmen definieren.

Und zuletzt, kann man das Programm in einen Virtuellen Speicherbereich laufen lassen, daher, das Programm sieht tatsächlich nur seinen eigenen Speicherbereiche, aber kann nicht sehen, wo irgendetwas anderes steht oder welche Speicherbereiche ein anderes Programm reserviert hat. (vgl. hierbei die Erklährung des Benutzers whose). Wenn ich die API richtig in Erinnerung habe, so kann man Speicherbereiche als "nicht verschiebbar" definieren. Daher, man kann vorher sagen, das gewisse Speicherbereiche nicht verschoben werden dürfen. Zwar wird (in der Literatur) immer empfohlen, dieses Bit zu setzen, was durchaus heute Probleme machen kann, aber so kann man dann sagen, das ab sofort, bei Speicher, der geteilt werden soll, dieses Bit gesetzt wird und das dieser Speicher in Adressraum für alle Programme nur einmal vergeben werden darf. Auf diese Art und weise sollten zumindest doch die meisten Probleme lösbar sein.

Daher, wo denke ich dieses mal Falsch oder ist es einfach nur so, das man noch nicht die Zeit oder die Programmierer gefunden hat, die das Implementieren? Ich denke schon, das dies nicht einfach zu Implementieren ist, aber ich denke schon, dass das für die meisten Benutzer einfacher ist, wenn diese drei Punkte ermöglicht werden.

[ - Antworten - Zitieren - Direktlink - ]

24.12.2009, 16:44 Uhr

68kassembler
Posts: 62
Nutzer

@eliotmc:
Die von dir genannten Angriffe sind auf JEDEN BETRIEBSSYSTEM möglich. Nur mal Windows oder Linux als Beispiel. Hat ein Programm ein Fehler, so kann man diesen ausnutzen, unabhängig von den hier besprochenen Maßnahmen. Und Code kann man auch dort bei jeden Programm einschleusen, wenn man will. Auch hier kann man diverse Programme als Beispiele nehmen.

Es gibt zwar Techniken, wie diese NX Bit (No Execution), daher, Speicherbereiche, die so Markiert werden, werden von der CPU nicht ausgeführt, sondern nur für Daten genutzt. Selbst dann hat man es aber trotzdem geschafft, diesen Schutz zu umgehen.

So weit ich weiß, hat man das mal bei Windows und bei PHP auf die Spitze getrieben, in den man alle Techniken verwendet hat, die sie Sicherheit erhöhen sollten. Der Effekt war der, das mal eben so 90% der Programme danach nicht mehr laufen. Daher, hat man es danach auch wieder sein gelassen.

Von daher, bleibt hier nur zu sagen, das man bei der Software Entwicklung vor Auslieferung des Programmes Automatische Tests durchführen sollte, die zuminestens die meisten Bekannten Probleme abdecken. Nur dann kann man die Sicherheit erhöhen.

Die Sicherheitstechniken, die ich oben erwähnt habe, kann man zwar auch werdenden und sind bei der Software Entwicklung sehr nützlich, aber das Problem liegt daran, das die meisten Programmierer leider nicht ausreichend Qualifiziert sind, sichere Software zu schreiben.

Die hier in dieser Diskussion besprochenen Maßnahmen sind sinnvoll, um vor Abstürzenden oder Fehlerhaften Programmen zu schützen. Mehr machen diese Maßnahmen aber auch nicht. Schutz vor Angriffen bieten keiner dieser Maßnahmen. Dazu sind die schon viel zu bekannt und verbreitet.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Amiga, AmigaOS 4 > Speicherschutz und Amiga OS 3.x

[ - Suche - Neue Beiträge - Registrieren - Login - ]