PACKER unter CP/M (MicroDOS)

von Jörg Linder

Für das Betriebssystem CP/M gibt es mehrere Programme zum Packen von Dateien. In der Ausgabe 3/92 unserer KCnews habe ich bereits eines der bekanntesten Programme dieser Art vorgestellt. Es war CRUNCH Version 1.1. Seitdem hat sich einiges getan. Ich habe neue Programme kennengelernt, die weitaus leistungsfähiger sind, aber auch CRUNCH hat sich weiterentwickelt.

Diesmal möchte ich einen Überblick über die derzeit verfügbaren Packprogramme geben, ihre Vor- und Nachteile aufzeigen und mit Testergebnissen ihre Leistungsfähigkeit zeigen.

Inwieweit jeder Nutzer bei den heutigen Diskettenpreisen davon Gebrauch macht, muß er selbst entscheiden. Ich persönlich nutze sie vor allem, um Bilddateien zu packen und mehrere zusammengehörige Dateien zusammen abzuspeichern.

Das Prinzip

Gegenüber den ersten einfachen Lauflängenkodierungen (das erste Byte sagt wie oft das nächste Byte geschrieben werden muß) ist das heutige Prinzip der Packer hochkomplex. Es wird nach unterschiedlichen Algorithmen gearbeitet. Oftmals sind die Namen der Entwickler eingeflossen. So steht z. B. "LZH" für Lempel-Ziv- Huffman.

Der Algorithmus des am weitesten verbreiteten CRUNCH wurde bereits in viele Programme integriert, so daß diese derart gepackte Dateien behandeln können.

Ein wesentlicher Unterschied teilt die Programme in zwei Gruppen. Die einen schreiben jede Datei einzeln auf die Diskette zurück und vergeben zur Unterscheidung einen neuen Dateityp. Die andere Gruppe faßt alle zu packenden Dateien in einem Archiv zusammen. Das spart mehr Platz (auch im Directory), allerdings kommt man nicht mehr ganz so einfach an eine einzelne Datei heran.

Die Programme

Wie bereits erwähnt, gibt es eine Vielzahl derartiger Programme. Einige sind an spezielle Anwendungen geknüpft (DBPLUS für dBase), andere wiederum sind schon veraltet und durch moderne Verfahren ersetzt worden (Squeezen - in NSWEEP enthalten). Von mir werden folgende Programme vorgestellt:

• CRUNCH V2.8
• CRLZH V2.0
• ARK V1.1
• PMARC V2.0

Zu allen Pack- und Entpackprogrammen gibt es eine dazugehörige deutsche Beschreibung auf dieser Diskette (-- in PACKER.PMA). Daher möchte ich hier nur kurz auf das jeweilige Programm eingehen. Ebenfalls sind die Packer und die dazugehörigen Entpacker in diesem Archiv enthalten.

CRUNCH und CRLZH

Beide Programme arbeiten nach dem zuerst erläuterten Verfahren. Sie schreiben die jeweilige Datei unter ihrem Namen, jedoch mit neuem Typ versehen, auf die Diskette zurück. Gecrunchte Dateien erkennt man an einem "Z" als zweiten Buchstaben des Dateityps, LZH-kodierte Dateien haben dort ein "Y".

Wesentlicher Vorteil beider Programme ist es, daß man auf jeden Nutzerbereich eines jeden (verfügbaren) Laufwerks zugreifen kann. Dateien können also von "überall geholt" und "überall hingeschrieben" werden. CRUNCH hat aufgrund seiner langen Tradition hier mit einigen Optionen deutlich die Nase vorn.

Zusätzlich bringt CRUNCH seine hohe Geschwindigkeit ins Spiel (siehe Test), was es für mich zum Favoriten für Text- und Bilddateien macht. Obwohl CRLZH ein relativ junges Programm ist und die Laufwerkshandhabung von CRUNCH abgekupfert hat, ist es trotz höherer Packdichte ein Langweiler, was die Geschwindigkeit angeht. Hier holt es sich eindeutig Minuspunkte. Hinzu kommt, daß nur sehr wenige Programme derart kodierte Dateien behandeln können. Es ist daher meiner Meinung nach nur etwas für dauerhaft beiseite gelegte Dateien, die man vielleicht nie mehr braucht, aber dennoch nicht gänzlich löschen möchte. Doch dafür gibt es schon bessere Programme.

ARK und PMARC

Sie arbeiten nach dem zweiten Verfahren. Alle angegebenen Dateien werden in einem Archiv abgelegt, das später noch ergänzt werden kann (bei PMARC ist sogar noch viel mehr möglich). Die Archive erkennt man an dem Dateityp "ARK" bzw. "PMA", jedoch ist bei PMARC die Wahl des Dateityps freigestellt - PMA wird standardmäßig vergeben.

Das Programm ARK gibt es schon etwas länger. Es besitzt zwei Packalgorithmen. Zuerst wird getestet (analyzing), welches das effizienteste Verfahren ist und dann wird danach gepackt. Manche Datei bleibt sogar ungepackt, wenn dies günstiger ist. Da das Analysieren und anschließende Packen natürlich eine Menge Zeit kostet, kann man ein Verfahren, das dem Crunchen ähnelt, vorschreiben (siehe Test). Der dazugehörige Entpacker kann sogar Dateien mit dem Dateityp "ARC" (auch von MS-DOS her) behandeln.

PMARC ist erst kürzlich nach Deutschland gekommen. Es wurde von einem Japaner programmiert. Selbst auf den alten CP/M-Maschinen sind uns die Leute aus Fernost voraus - PMARC schlägt alles bisher dagewesene. Durch die zusätzlichen Module kann man sogar selbstauspackende (!) Archive wie unter MS-DOS erstellen. Der Algorithmus ist so gut, daß er sogar LHA (von MS-DOS) schlägt, obwohl er daraus entwickelt wurde. Meiner Meinung nach wird sich dieses Super-Packprogramm durchsetzen, da es schon auf Geräten mit relativ wenig TPA läuft und wirklich die meisten Möglichkeiten zur Behandlung der Archive bietet.

Leider kann weder ARK noch PMARC auf einen anderen Nutzerbereich zugreifen. Man muß also den Packer im selben Bereich haben wie die zu packenden Dateien. Dieser Nachteil und die lange Bearbeitungszeit werden nur durch die hohe Dichte gerechtfertigt. Beide Programme sind besonders für das Zusammenfassen von zusammengehörigen Dateien geeignet. Gibt man das Archiv an einen anderen Nutzer weiter, kann man nichts vergessen.

Der Test

Zuerst möchte ich die Bedingungen nennen, unter denen der Test durchgeführt wurde.

Für die Packer wählte ich die Dateien der Systemdiskette. Dadurch kann jeder den Test nachempfinden und es sind die Schwächen der Packer gut zu erkennen, da eine gesunde Mischung der möglichen Dateiarten vorliegt (lange und kurze Dateien; COMs und TXTs).

Aufgrund der unterschiedlichen Blocklänge verschiedener Formate (z. B. 1 kByte auf Diskette, 2 kByte auf RAM-Floppy) sind alle Dateilängen in Records (1 Record = 128 Byte - wie sie CP/M intern verarbeitet) angegeben. Außerdem habe ich alles in der RAM-Floppy ablaufen lassen, da es beim Zugriff auf richtigen Disketten erhebliche Zeitunterschiede geben kann, wenn viel und auf unterschiedliche Spuren zugegriffen wird. In der RAM-Floppy wird so eine Verfälschung weitestgehend ausgeschaltet.

Zusätzlich wurde für CRUNCH und CRLZH der Quiet-Modus (ruhig) gewählt, da die recht langsame Bildschirmausgabe des KC diese Programme etwas bremst. Außerdem wird CRLZH dadurch gezwungen Dateien, die nicht kleiner sind als das Original trotzdem zu speichern (sonst nur Meldung, daß Datei nicht kleiner ist).

Da ARK und PMARC die Option für eine schnellere Arbeit bieten, sollte diese natürlich nicht ungetestet bleiben. ARK wurde dazu mit der Option -k (force crunching - nur crunchen) gestartet. An die Befehlszeile von PMARC wurde ein "/H" angehängt und damit der Highspeed-Modus angewählt. Im Vergleich sind diese Versionen mit einem "s" (schneller) gekennzeichnet.

Ausgangspunkt waren also 30 Dateien mit insgesamt 2.671 Records. Die folgende Aufstellung zeigt die Ergebnisse der verschiedenen Packer:

        Original  CRUNCH   CRLZH     ARK   ARK s   PMARC  PMARC s
Records    2.671   1.518   1.219   1.599   1.643   1.084    1.116
           100 %  56,8 %  45,6 %  59,9 %  61,5 %  40,6 %   41,8 %
Zeit (min:sek)     03:27   13:44   08:14   06:15   09:27    08:33

Trotz der relativ guten Zeit von 08:14 (bzw. 06:15) konnte ARK bei den Packergebnissen nicht überzeugen. Wer 19 Sekunden länger warten kann, bekommt von PMARC im Highspeed-Modus deutlich mehr Leistung geboten. Und obwohl CRUNCH nicht durch seine Packdichte überragt, ist es mit seiner Geschwindigkeit den anderen deutlich überlegen. Absolutes Schlußlicht ist CRLZH mit seinen gemütlichen 13:44 und damit wohl eher etwas für Leute, die sich gern vor dem Rechner langweilen.

Der Fairneß wegen sollte noch erwähnt werden, daß CRLZH durch den Zwang, alle Dateien (ob kleiner oder nicht) zu schreiben, in drei Fällen größere Dateien erzeugt hat. Das betrifft S3004.LST, S6005.LST und V24H12.KOP - sie sind 1 Record lang und wurden durch den Header von CRLZH 2 Records lang. Die prozentuale Ausbeute beeinträchtigt dies jedoch kaum.

Interessant ist jedoch, welche Dateien am besten von CRUNCH (und CRLZH) gepackt wurden. Das sind nämlich Dateien mit viel Text, wie die folgende Übersicht zeigt:

Original              CRUNCH           CRLZH
TPHT    .OVR 223r   115r = 51,6 %    97r = 43,5 %
TPIDAISY.TXT  34r    18r = 52,9 %    11r = 32,4 %
TPINSTD .000 331r   112r = 33,8 %    83r = 25,1 %
TPINSTD .001 518r   184r = 35,5 %   154r = 29,7 %
TPINSTD .002 124r    42r = 33,9 %    33r = 26,6 %

Im Gegensatz dazu werden bei COM-Dateien nur mäßige Packraten erzielt. Jedoch liegt auch hier CRLZH eindeutig vorn. Wenn es also darauf ankommt, kann man durchaus auf CRLZH zurückgreifen.

CAOSDISK.COM 197r   146r = 74,1 %   114r = 57,9 %
TPKC    .COM 137r   113r = 82,5 %    93r = 67,9 %

Die Empfehlung

An dieser Stelle möchte ich eine Empfehlung für die Wahl des Packprogramms geben. Diese ist selbstverständlich rein subjektiv. Jeder sollte selbst experimentieren und entscheiden.

Texte

CRUNCH (Ersparnis bis zu 50 % und mehr)
Die Dateien sind schnell gepackt und können mit anderen Utilities (z. B. QL.COM) gelesen werden.

 

Bilder

CRUNCH (Ersparnis bis über 90 %)
Wenn es schnell gehen soll. Bei vielen Dateien ist das Directory eher voll als die Diskette. Für den, der LBRs erzeugen kann, ist das kein Problem. Wer das nicht kann, sollte PMARC (Ersparnis bis über 90 %) nehmen. Man spart dann doppelt: Speicherplatz und Directory- Platz.

 

Pakete

PMARC
Programmpakete bleiben so zusammen und man kann beim Kopieren nichts vergessen. Die Packrate ist hier überragend hoch und da man nicht alle Tage Programmpakete zusammenstellt, ist die Zeit vertretbar.

 

COMs

???
Hier sollte man erst überlegen. Ist das Programm in Assembler geschrieben und enthält wenig Texte (Hilfe o. ä.), verschwendet man wahrscheinlich nur seine Zeit. Anders sieht es mitunter bei COM-Dateien aus, die in einer Hochsprache geschrieben wurden. Diese enthalten meist Programmbibliotheken, deren Code mittelmäßig bis gut gepackt werden kann.

 

Man erkennt deutlich, daß ich PMARC favorisiere. Es wird sich in kurzer Zeit als neuer Standard durchsetzen. Die Möglichkeit der selbstauspackenden Archive wird besonders die Harddisk-Besitzer begeistern. Große Datenbestände können durch ein Kommando von der Harddisk in die RAM-Floppy zur Bearbeitung extrahiert werden und das kostet kaum mehr Zeit (und Nerven) als das Kopieren - Double Space unter CP/M?