F R E S H T H R A S H of C E R B E R U S is proud to present: /---------------------------\ < C R U N C H - M A N I A > \---------------------------/ V1.3 Release-Date: 09.06.91 -------------------------- ----«««<< Inhalt >>»»»---- -------------------------- I. Einleitung I.1 Copyright I.2 Empfohlene Hardware II. Allgemeine Informationen II.1 Erscheinungsbild II.2 Zahlen Ein-/Ausgabe II.3 Sonstige Infos III. Packen im Address-Modus III.1 Das Laden III.2 Das Packen III.3 Das Abspeichern III.3.1 Data-Files III.3.2 Normaler Decruncher III.3.3 Professioneller Decruncher IV. Packen im Link-Modus IV.1 Das Laden IV.2 Das Packen IV.3 Das Abspeichern V. Packen im Reloc-Modus V.1 Das Laden V.2 Das Packen V.3 Das Abspeichern V.3.1 Der Simple-Decruncher V.3.2 Der Normal-Decruncher VI. Unwichtiges ************************************************* I. Einleitung =================== I.1 Copyright ------------------ Dieses Programm ist (noch) Public-Domain. Es darf (soll) verbreitet werden, solange Folgendes eingehalten wird: - Es darf kein Geld für dieses Programm verlangt werden. (Ausnahmen: Strohmkosten, Schreib-/Lesekopfabnutzung, Porto, Telefongebühren) - Diese Anleitung muß immer mit dem Programm weitergegeben werden. - Die Data-Decrunch-Routine im File "DataDecr.s" muß immer mit dem Programm weitergegeben werden. - Das Programm muß virusfrei gehalten werden. Das Programm arbeitet nur korrekt bei einer Betriebstemperatur von 22°C, einer Luftfeuchtigkeit von 80% und einem Alokoholgehalt von 0,0%.. I.2 Empfohlene Hardware ---------------------------- Eine Speicherkapazität von mindestens 1MB wird dringend empfohlen, um auch längere Files bei optimaler Geschwindigkeit zu packen. Zwei Floppies sind komfortabel, aber nicht zwingend erforderlich. II. Allgemeine Informationen ================================= II.1 Erscheinungsbild ------------------------- Das Programmm öffnet ein CON: und ein RAW: Fenster und ist deshalb voll Multitasking-fähig. Die beiden Fenster passen sich den gegebenen Umständen (NSTC/PAL) an. Das linke Fenster ist das Eingabe-Fenster. Hier werden sämtliche Eingaben getätigt. Das rechte Fenster dient nur für Ausgaben wie z.B. Directory, Hunk-Struktur. II.2 Zahlen Ein-/Ausgabe ---------------------------- Das Programm verlangt oft Eingaben über die Tastatur und bombardiert seine zwei Windows mit Zahlen. Als Regeln gelten hierfür: - Alle Zahleneingaben sind hexadezimal! - Alle Zahlenausgaben ohne ein Zeichen vor der Zahl sind dezimal, alle mit einem "$" davor sind hexadezimal! II.3 Sonstige Infos ----------------------- Oft kommt man mit + wieder zum Anfang zurück. Beim Saven kann man mit "*" manche Optionen abändern/weglassen. Dieses Programm ist nicht 100% Bug-frei, doch kann im Normalbetrieb von Fehlerfreiheit ausgegangen werden. Trotzdem übernimmt der Programmierer keinerlei Haftung für etwaige Schäden und Abstürze. Oft liegt die Ursache jedoch beim AmigaDOS oder dem Benutzer, der einen oder mehere der zahlreichen Betriebsparameter falsch eingestellt hat. Auch Fehler durch Tippfehler sind wahrscheinlich. Alle allgemein verständlichen und mit normaler Intelligenz zu begreifenden Ausgaben werden in der folgenden Anleitung ausgelassen. Ich empfehle, das Lesen dieser Anleitung spätestens hier zu unterbrechen und erstmal alles auszuprobieren. III. Packen im Address-Modus ================================ Im Address-Modus können sämtliche addressabhängigen und relocatiblen Files gepackt werden. Zum Packen von Daten wird dieser Modus auch verwendet. Ich empfehle, diesen Modus nur im absoluten Notfall zu benutzen, da der Decruncher keinerlei Rücksicht auf das AmigaDOS nimmt. III.1 Das Laden ------------------ Das angegebene File wird normalerweise vollständig geladen und der dafür notwendige Speicher allokiert. Handel es sich jedoch um ein Executable, so verlangt der Packer die Adresse, an die das Programm dann geladen wird. Der Packer lädt jetzt die Hunks nacheinander in einen allokierten Speicherbereich und korrigiert alle in Hunk_Reloc32 angegebenen Adressen. Die Fixadresse sollte auch als Decrunchadresse verwendet werden. Der Range gibt hier den Speicherbereich an, den der Hunk mit integriertem BSS-Teil belegt und die Len gibt an, wieviel vom Range mit Daten gefüllt ist. Sind Ober- und Untergrenze des Range gleich der Len, so hat der Hunk keinen versteckten BSS-Teil. Eventuelle Speicherbereichslimitationen werden nicht angezeigt und auch nicht berucksichtigt. Um ein Executable wie ein Datafile zu laden, muß bei obiger Eingabe ein "*" eingegeben werden. Weiterhin gibt es noch die Möglichkeit, der Zahl ein "p" voranzustellen. Bei dieser Option fügt der Packer die für DOS und manche Programme not- wendigen Segment-BPTRs und die Längen der Segmente dem Code zu. Da sich diese immer vor dem jeweiligen Segment befinden, muß die Decrunchadresse 8 Bytes niedriger gewählt werden als die Fixadresse. Außerdem werden die zu packenden Daten um 8 Bytes pro Hunk länger. Gibt man statt eines Filenamens "*"+Dirname ein, so wird im Statusfenster das angegebene Directory angezeigt, das aktuelle Directory wird aber nicht geändert. III.2 Das Packen ------------------- Das Statusfenster zeigt den gerade aktiven Pack-Modus und das in diesem Modus maximale Crunch-Offset an. Dieses muß nun eingegeben werden. Vom Offset ab- hängig ist natürlich auch die Zeit, die der Packer zum packen braucht. Im Lightspeed-Modus werden 256KB zusammenhängender Speicher plus maximal 66KB Zusatzspeicher benötigt. Im Turbo-Modus veringern sich die 256KB auf 1KB, die Packzeit wird jedoch doppelt bis dreimal so lang. Natürlich kann auch zwischen diesen beiden Modi umgeschaltet werden. Zu diesem Zweck gibt man ein "l" bzw. ein "t" anstatt des Offsets ein. Das Offset 0 gibt es nicht, stattdessen wird bei der Eingabe von "0" ein Offset von $4200 angenommen. Ist der Speicher ausreichend, so steht jetzt anstelle des eingegebenen Offsets das tatsächlich zum Packen verwendete Offset. Da es sich hierbei um einen Packer der allerneuesten Generation handelt, sind Packzeiten länger als 5 Minuten im Lightspeed-Modus äußerst selten. III.3 Das Abspeichern ------------------------ Hier kann zwischen Datafiles, Executables mit normalem Decruncher und Executables mit professionellem Decruncher ausgewählt werden. Für alle normalen Anwendungen sollte der normale Decruncher genügen, der professionelle Decruncher ist nur für Fälle gedacht, in denen das Programm in sehr niedrige Speicherbereiche kopiert wird, oder wenn AmigaDOS uner- wünscht ist. III.3.1 Data-Files - - - - - - - - - - Bei DataFiles werden lediglich ein Header von 14 Bytes Länge und die Daten selbst abgespeichert. Der Header ist ausführlich im Decrunch-Sourcecode beschrieben. III.3.2 Normaler Decruncher - - - - - - - - - - - - - - Hier tritt zuerst die Frage nach einem langsamen oder einem schnellen Decruncher auf. Grundsätzlich kann gesagt werden, daß der langsame der kürzere Decruncher ist, der Längenunterschied ist jedoch nicht weltbewegend. Es spricht nichts dagegen, immer den schnelleren Decruncher zu benutzen, jedoch ist der Geschwindigkeitsvorteil bei kurzen Files so gering, daß er unter normalen Umständen nicht zum Tragen kommt. Jetzt wird die Decrunchadresse verlangt. Diese gibt an, wohin der Decruncher das entpackte Programm kopiert. Wird hier statt der Adresse ein "*" ein- gegeben, so wird das Programm in das Segment kopiert, in dem auch die ge- packten Daten stehen. Dies hat den Vorteil, daß AmigaDOS in keiner Weise gestört wird (und damit die Gefahr von Gurus erheblich gesenkt wird), was aber vorraussetzt, daß das Programm positionsunabhängig ist und nur aus einem Hunk besteht. Andernfalls ist diese Methode nicht mehr 100%ig. Für diese Fälle ist der Reloc-Modus vorgesehen. Es gibt auch noch die Möglichkeit, statt einem "*", "*c" einzugeben. Dies bewirkt, daß das Programm ins Chip-RAM entpackt wird, was z.B. bei ST-Modulen nötig ist. Die Jumpadresse gibt an, wohin der Decruncher nach dem Entpacken springt. Wurde vorher der DOSfreundliche Modus gewählt, so wird die Jumpadresse als Offset relativ zum Programmanfang angesehen. Wird anstelle der Jump- adresse ein "*" eingegeben, so kehrt der Decruncher nach dem Entpacken wieder zum aufrufenden Programm (oder DOS) zurück und springt nicht in das entpackte Programm. Dies kann z.B. bei Bildern oder Musikstücken vonnutzen sein. III.3.3 Professioneller Decruncher - - - - - - - - - - - - - - - - - - Auf die schon beim Normalen Decruncher besprochenen Optionen wird hier nicht näher eingegangen, sie haben die gleichen Funktionen und Auswirkungen. Zuerst wird der Benutzer gefragt, ob der professionelle Teil des Decrunchers vor und/oder nach dem Entpacken ausgeführt werden soll. Dann taucht die Frage nach der Stackadresse auf. Diese Adresse gibt an, wie a7 vor dem Entpacken initialisiert wird. Der alte Stackpointer wird nirgendwo gespeichert und geht verloren. Gibt man statt einer Adresse "*" ein, so wird der vorhandene Stackpointer verwendet. Wurde der professionelle Teil vor den Decruncher gewählt, so erscheint hier die Frage, ob die Laufwerke abgeschaltet werden sollen oder nicht. Der Unter- schied zwischen "lame" und "pro" besteht darin, daß im lamen Modus die Laufwerksmotoren zwar aus sind, aber die LEDs der externen Laufwerke noch brennen (bei mir jedenfalls). Jetzt können beliebige Speicherworte initialisiert werden. Der Packer erkennt selbstständig, ob die Adresse .w sein kann (z.B. $80.w für Trap #0). Nun verlangt der Packer den Wert, mit dem die Adresse initialisiert wurde. Normalerweise wird ein Wort verlangt, wird der Zahl jedoch ein "l" voran- gestellt, so wird diese Zahl als Langwort aufgefaßt. Es können maximal fünf Adressen initialisiert werden (jeweils vor und nach dem Entpacken). Mit "*" kann schon vorher abgebrochen werden. Soll der professionelle Teil nach dem Decruncher sein, so kann jetzt noch zusätzlich das Statusregister initialisiert werden. Dies kann aber mit "*" übergangen werden. Die Decruncheradresse gibt an, wohin sich der Decruncher vor dem Entpacken kopiert, um eventuellen Überlagerungen mit den ent-/gepackten Daten zu ent- gehen. Auch diese Option ist nicht zwingend und kann mit "*" ausgelassen werden. IV. Packen im Link-Modus ============================= Der Link-Modus zeichnet sich dadurch aus, daß es in ihm möglich ist mehrere Files in einen Speicherberich zu laden und diese dann gleichzeitig zu packen. IV.1 Das Laden ------------------ Bevor man Files laden kann, muß erstmal die untere und obere Grenze des Speicherbereiches festlegen, in den die Files dann geladen werden. Die beiden Grenzen müssen gerade sein und die obere Grenze muß größer sein als die untere Grenze. Der festgelegte Speicherbereich wird vor dem Laden auch noch gelöscht, um bessere Packergebnisse zu erreichen. Nun können Files geladen werden. Hier gibt es grundsätzlich die gleichen Möglichkeiten und Optionen. Zusätzlich muß nun auch bei Datenfiles eine Adresse angegeben werden, an die das File geladen wird. Alle Adressen müssen innerhalb des vorher festgelegten Speicherbereiches liegen und dürfen nicht über das Ende hinausreichen. Will man bei Executables auch noch die Segment-BPTRs mitpacken, so muß man darauf achten, daß die Fixadresse mindes- tens 8 Bytes über der unteren Speichergrenze liegt. Der Packvorgang wird durch Eingabe von "+" anstelle eines Filenamens gestartet. IV.2 Das Packen ------------------- siehe III.2 IV.3 Das Abspeichern ------------------------ Für die Decrunchadresse sollte man hier die untere Speichergrenze wählen, da sonst alle nicht pc-relativen Adressen nicht mehr stimmen Ansonsten bleibt alles wie bei III.3 V. Packen im Reloc-Modus ============================== Dieser Modus dient zum Packen von Executables, die dann auch gestartet werden können, ohne mit AmigaDOS in Konflikt zu kommen. Die Hunkstruktur wird vollständig übernommen, so daß das Programm nach dem Entpacken die gleichen Umstände vorfindet wie wenn es ungepackt gestartet worden wäre. Mit dieser Version ist es möglich, alle Executables zu packen. Es ist aber nicht möglich, Overlayed-Files zu packen. V.1 Das Laden ------------------ Das angegebene Programm wird geladen und die Hunkstruktur wird überprüft. Die Hunkstruktur wird dabei im Statusfenster angezeigt. Sämtliche End-Hunks werden dabei weggelassen. Danach werden die Reloc-Tables sortiert und die doppelten Einträge rausge- schmissen. Außerdem werden die Einträge wenn möglich auf Wortlänge reduziert. Die neue Länge wird nach diesem Vorgang im Eingabefenster angezeigt. V.2 Das Packen ------------------- siehe III.2 V.3 Das Abspeichern ------------------------ Momentan gibt es zwei Möglichkeiten, Reloc-File abzuspeichern. Diese werden nachfolgend beschrieben. Es sind aber noch weitere Decruncher geplant. V.3.1 Der Simple-Decruncher - - - - - - - - - - - - - - - Dieser Dercruncher ist sehr speicherfressend. Er benötigt doppelt soviel Speicher wie das ungepackte Programm. Das liegt daran, daß das Programm zuerst in einen zusammenhängenden Speicherbereich entpackt wird, und dann in die einzelnen Segmente kopiert wird. Dabei bleibt nach dem Entpacken der nicht benötigte Speicher noch allokiert und cli_module in der CLI-Struktur wird nicht geändert (z.B. CEd braucht das). V.3.2 Der Normal-Decruncher - - - - - - - - - - - - - - - Dieser Decruncher arbeitet genauso, wie der Simple-Decruncher. Er gibt jedoch nach dem Entpacken den jetzt nicht mehr benötigten Speicher frei. Lediglich ein kurzes Programm von ca. 80 Bytes Länge bleibt noch im Speicher. "cli_module" zeigt dann auf dieses Programm. Läßt man "cli_module" korrigieren, so wird dieses Programm auch noch aus dem Speicher geschmissen und "cli_module" auf den 1.Hunk des entpackten Programms umgebogen. Jedoch wird der 1.Hunk um 8 Bytes verlängert und dorthin ein kurzes Programm kopiert. VI. Unwichtiges ==================== Gedankt werden soll hier: Commodore für diesen Computer Cygnus Software für CED Buddha/Corsair für Masterseka 1.7/1.8 E.o.L. für das Beta-Testing Grüßen gehen an: The Fly Earl of Lennox/Tarkus Team und den Rest der Säufertruppe Assassins