|
|
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
Diskarchive - DMS, FMSIn diesem Teil des Workshops lernen wir DMS kennen, einen der berüchtigten Amiga-Cracker-Kultur entstammenden Diskarchiver. Weiters befassen wir uns mit FMS, das es erlaubt, die Floppy auf die Festplatte "auszulagern". Ein bisserl GeschichteIn der grauen Anfangszeit des Amigas war von Festplatte noch keine Rede. Alles wurde auf Disketten gespeichert. Internet blieb uns damals noch erspart, weil dank seiner damals noch ehrlichen Unbrauchbarkeit kaum verwendet. Unglaublich aber wahr, Gopher und WAIS wurden zu der Zeit als Innovation gefeiert. Eine Art Netzkultur gab es dennoch schon in den Bulletinboard Systems, kurz BBS Im Gegensatz zum krankhaft liberalen Upperclass-Gesäusel der amerikanischen Bildungselite im Internet war dort aber erdiger Westentaschenanarchismus pubertierender Schulkinder angesagt, der sich unter anderem darin äußerte, möglichst viele Raubkopien unter die Leute zu bringen. (Um nicht der unzulässigen Verallgemeinerung bezichtigt zu werden: es gibt auch krankhaft liberale BBS's - auch Intellektuelle können in ein Bierzelt gehen. Und das Internet hat seine "binary newsgroups" und "warez sites". Diese stellen aber keinen aktiven Kulturbeitrag dar, sondern nur eine billige Download-Möglichkeit.) Beim Verteilen von Raubkopien ist natürlich der besser, der schneller ist. Weil die Post bekanntlich nicht besonders schnell ist - vor allem ins Ausland - war es natürlich indiskutabel, die aktuellen Raubkopien in einen Brief zu stecken. Mal davon abgesehen, daß Disketten mit Raubkopien leicht zu physikalischen Beweisstücken werden können. Ein einfacherer Weg mußte her, um solche Daten in die BBS zu kriegen. DMS - Der MaischapparatUnd genau diese Lösung war DMS, der "Disk Masher" bzw. später auch "Device Masher". Wie es dazu wirklich kam, ist für einen Lamer wie mich nicht mehr rekonstruierbar. Als gesichert gilt, daß es keinen krankhaft pseudo-demokratischen "request for comments" gab, wo nach einiger Zeit der unfruchtbaren Diskussion sich einer hinsetzt und das implementiert, was er für richtig hält. Stattdessen hat sich eher sofort einer hingesetzt und das implementiert, was er für richtig hielt. Der Bedarf für DMS war da, und somit war es schnell akzeptiert. Weil aber nicht alles richtig war, was der Ur-DMS-Autor für richtig hielt und etliche Features fehlten, wurde DMS nach und nach erweitert. So kamen diverse Kompressionsschemata (vgl. ADZ), eine (aus heutiger Sicht primitive) Möglichkeit für Passwörter und etliche Kleinigkeiten dazu. Das geschah natürliche wieder nicht in einer krankhaft pseudo-demokratischen Diskussion, sondern jeder verbesserte DMS auf seine Weise, je nach dem was er brauchte. Der Effekt ist vergleichbar mit dem TAR der Unix-Männer: es gibt etliche Programme mit dem selben Namen, die unterschiedliche Dinge machen, teilweise abhängig von der Mondphase. Nach kurzer Zeit trieben sich etliche zueinander kreuzweise inkompatible DMS-Tools in den BBS's herum. Dazu kam dann noch, daß Virenprogrammieren damals recht populär war. Zwar war es ein leichtes, seinen eigenen Virus in die gerade aktuelle Raubkopie zu packen, nur war es nicht garantiert, daß jeder diese wirklich herunterladet. Viel effektiver hingegen war das Plazieren von Viren in DMS, weil man es ja andauernd aktualisieren mußte, um an die Raubkopien zu kommen. Viele der herumgeisternden DMS-Programme sind wahrscheinlich nach wie vor verseucht. Eines kann man aber dennoch mit halbwegs guten Gewissen empfehlen:
Denn wie wir wissen, wird alles, was am Aminet landet, auf Viren geprüft. Es passiert zwar hin und wieder, daß ein ganz neuer Virus durchschlüpft, die Anzahl der "Aminet Virus Warnings" der letzten Jahre kann man auf einer Hand abzählen. Nicht zuletzt deshalb, weil inzwischen alle Virenprogrammierer auf PCs arbeiten. Schon mehr ein Problem kann darstellen, daß dieses DMS nicht alles extrahieren kann, was man findet. Für den Hausgebrauch und Demo-Gucken sollte es aber reichen, und die anderen Aktivitäten wollen wir eh nicht fördern. DMS ExtrahierenWie bereits im letzten Teil ist auch diesmal ein Test-Archive enthalten (siehe am Ende des Artikels). Der Konsistenz halber heißt es sepp.dms. Nach DF0: extrahieren kann man es mit mit folgendem Aufruf:
Daraufhin zeigt DMS einen unten genauer erkärten Text an, bittet DMS, eine Disk in DF0: einzulegen, RETURN zu drücken, und ab geht die Post. Gepackte Archive erkennt DMS von selbst und werden für den Anwender vollkommen transparent behandelt. Das funktioniert ansich, leider zeigt sich bei etlichen DMS-Archiven der Selbstbeweihräucherungstrieb des jeweiligen pubertierenden Schulkinds, das das Archive zusammengestellt hat. Vor dem eigentlichen Extrahieren zeigt DMS einen sogenannten "banner text", indem der Archiveur dann in der Tradition von Musikentenstadls und Wurlitzer Leute grüßen kann. Dabei bedient man sich gerne einfältiger ASCII-Grafiken (vgl. die ebenso sinnlosen EMail-Signatures im Internet). Aus Gründen der Veranschaulichung hat auch der kleine sepp.dms ein solchen Text verpaßt bekommen, wenn auch einen kulturell wesentlich wertvolleren. (Der Vers wurde dem Lied "Goaß" vom ersten Attwenger Album "Most" entnommen.) Solchem Unfug entgegen wirken kann man mit der CLI-Option NoText:
Und a Rua is in da Hittn. DMS ErzeugenWer die Einleitung gelesen hat, der wird verstehen, warum es unverantwortlich wäre, zu erklären, wie man DMS-Archive erzeugt. Wer Disketten archivieren will, der lese im ersten Teil des Workshops nach, wie man ein ADZ-Archiv erzeugt. DMS für den Rest der WeltEin großer Nachteil von DMS ist, daß es nur für Amiga existiert. Hat man ein DMS-Archiv und befindet sich auf einem anderen Rechner, so kommt man schwer an die enthaltene Daten heran. Selbst wenn es den originalen Quellcode gäbe, er würde wohl im wenig portierbaren 68k-Assembler vorliegen. Anfangs war das ein großes Problem für die armen Menschen, die nur über emulierte Amigas verfügen. Letztendlich hat sich aber doch ein aufrechter Masochist hingesetzt, ein bisserl "reverse engineering" betrieben und ein portables C-Programm geschrieben:
Dieses gute Stück wandelt ein DMS-Archiv in eine ADF-kompatible 880K-Wurscht um. Details entnehme man der Dokumentation. Inzwischen sind die Emulatoren so schlau, daß sie xdms automatisch aufrufen, wenn sie ein DMS-Archiv laden sollen. Viel inkompatibler zu DMS als DMS selbst kann es wohl kaum sein. Weiters ist erwähnenswert, daß es PPC-Versionen von xdms gibt. Siehe Aminet, im selben Verzeichnis. FMSFMS geht einen etwas anderen Weg als TransADF und DMS. Zwar wird auch hier eine Disk als Datei dargestellt. Im Unterschied zu den anderen beiden ist FMS aber kein Programm, das diese Datei wieder auf eine Disk schreibt, sondern ein Gerätetreiber, der selbige als Laufwerk anmeldet. Damit ist das Archiv direkt von Workbench und CLI aus zugänglich, was natürlich äußerst praktisch ist. Wofür die Abkürzung FMS eigentlich steht, verschweigt die Dokumentation aber beharrlich.
Ein Installerscript ist leider nicht enthalten, darum beschreiben wir die Installation aus der CLI-Perspektive. Man begebe sich in das Verzeichnis, in das man das Archive extrahiert hat, und gebe unten stehende Befehle ein. (Achtung beim type Befehl, daß man wirklich zwei > eingibt. Dies bewirkt, daß die neue Mountlist an die alte drangehängt wird. Würde man nur ein >, so würde die alte Mountlist überschrieben werden.)
Jetzt braucht man noch eine Festplattenpartition mit etwas Platz. Für unsere Experimente hier sollten 4MB genug sein, aber es kann ruhig auch mehr sein. In unserem Beispiel ist das Work:. Dort legt man dann ein Verzeichnis an, wo die Diskarchive gespeichert werden. Abschließend muß diesem Verzeichnis der Assign fms: zugewiesen werden:
Den Assign-Befehl gebe man auch in die s:user-startup, damit FMS auch nach einem Neustart noch funktioniert. Jetzt kann man endlich sein erstes leeres "Archiv" erzeugen:
Danach sollte auf der Workbench ein neues Icon für ein Laufwerk FF0: auftauchen. Huch!? Dabei hat ja niemand eine neue Disk eingelegt! Tatsächlich werden die Daten der "Disk" auf der Festplatte gespeichert. Um genau zu sein, in der Datei fms:Unit0. Die haben wir durch unseren Aufruf von mount angelegt. Wie jede neue Diskette gehört auch diese erst einmal formatiert, bevor man Daten darauf speichern kann:
Und was bringt uns das? Erstens ist dieses Laufwerk viel schneller als das langsame DF0:, womit es ein praktisches Ziellaufwerk zum Entpacken von ADF und DMS darstellt. Zweitens können wir praktisch beliebig viele "Laufwerke" anlegen. Ein FF1: kann analog wie zuvor erzeugt werden:
Unser devs:Mountlist enthält auch Einträge für FF2: und FF3:. Ein FF4: kann sich jeder leicht erzeugen, der ein bißchen Ahnung über Einträge in der Mountlist hat (Tip: "Copy-and-Paste", UNIT ändern). Einzige Grenze ist der verfügbare Platz auf der Festplatte. Wollen wir also den guten sepp.dms nach FF0: entpacken, so gibt man ein:
Das einzige, das den Aufruf von dem zuvor unterscheidet ist das FF0: statt dem DF0:. Und die Geschwindigkeit, mit der er ausgeführt wird. Aus fast einer Minute werden ein paar Sekunden. FazitIm zweiten Teil des Workshops haben wir DMS und seine obskure Entstehungsgeschichte kennengelernt. Von der Handhabung her ist es vergleichbar mit TransADF aus dem ersten Teil. FMS hingegen erlaubt uns, Disketten auf der Festplatte abzulegen und von dort anzumelden. Damit eignet es sich hervorragend als Ziellaufwerk für DMS und TransADF. Etwas bremsen tut die Freude die unnötig aufwendige und kryptische Installation von FMS. Doch Hilfe naht im dritten Teil: dort werden wir die umständlichen CLI-Aufrufe in ein ARexx-Script verpacken. Wer bei den Erläuterungen zu FMS schon nach der dritten Zeile nicht mehr wußte, wo ihm der Kopf stand, der warte noch ein Weilchen. |
||||||||||||||||||||||||||||||||||
|
Thomas Aglassinger ...........
|
||||||||||||||||||||||||||||||||||
|
|
|