@DATABASE GPatch.guide @MASTER GPatch.guide @$VER: 3.0 @AUTHOR "Ralf Gruner" @(c) "© 1997, 1998 Ralf Gruner, Großschönau, Germany" @INDEX "Index" @NODE "Main" "GPatch Handbuch" @{JRIGHT}***RGR*** @{JCENTER} @{b}@{u}GCompare / GPatch:@{ub} Das Patch-System für Programm-Updates@{uu} Version 3.0 Autor: Ralf Gruner @{JLEFT} @{LINDENT 3} @{" Vorwort " LINK "Vorwort" 0} @{" GCompare " LINK "GCompare" 0} @{" GPatch " LINK "GPatch" 0} @{" Hinweise zur Benutzung " LINK "Hinweise" 0} @{" Technische Details " LINK "Details" 0} @{" Beispiele " LINK "Beispiele" 0} @{" Versionen für andere Betriebssysteme und PPC " LINK "IX Windows PPC" 0} @{" Copyright, Vertrieb und Haftungsausschluß " LINK "Copyright" 0} @{" Danksagungen " LINK "Credits" 0} @{" Änderungsliste " LINK "GPatchHistory.guide/MAIN"} (nur englisch) @ENDNODE @NODE "Vorwort" "Vorwort" @SMARTWRAP @{LINDENT 1} @{B}Vorwort@{UB} GCompare ist ein Programm zum Erzeugen von Patch-Dateien für den Vertrieb von Updates beliebiger Programme oder anderer Dateien. Eine solche Patch-Datei enthält nur noch die Unterschiede zwischen den alten und den neuen Dateien, womit die zu vertreibenden Datenmengen erheblich reduziert werden. GPatch dient dazu, diese Updates auszuführen. Die Vorteile von GCompare/GPatch gegenüber vergleichbaren Programmen sind: @{LINDENT 2} @{PARI -1} -Die Patch-Datei kann Änderungsdaten für eine beliebige Anzahl von Dateien enthalten. Dadurch ist es möglich, Updates für mehrere Versionen eines Programms zusammen zu vertreiben. Wenn sich die Verzeichnis-Struktur des Produktes nicht geändert hat, findet der Patcher selbständig die benötigten Änderungsdaten, ohne daß sich Ihr Skript darum kümmern muß. Außerdem können Sie die Patches für verschiedene Dateien in einer einzigen Patch-Datei unterbringen. -Wenn die Patchdatei jeweils die Änderungen von einer Programmversion zur nächsten enthält, dann ist es nicht mehr notwendig, alle alten Versionen zu archivieren. -Das Format der Patch-Datei ist bezüglich der Dateigröße aufwendig optimiert. GCompare kann mehrere verschiedene Kodierungsarten testen und diejenige auswählen, die das kürzeste Resultat liefert. Obwohl ich nicht allzu viele ähnliche Programme kenne, möchte ich behaupten, daß GCompare in den meisten Fällen die kürzesten Patchdateien aller verfügbarer Patchprogramme erzeugt. -Um zu verhindern, daß beim Anwender beschädigte Dateien ankommen, enthalten die Programme eine sehr zuverlässige Fehlererkennung (32-Bit-CRC-Signaturen für alle Dateien). Wenn keine Fehlermeldungen auftreten, dann können Sie sicher sein, daß die Ergebnisse des Patch-Vorgangs perfekt sind. -GCompare sucht passende Daten in der gesamten Datei, nicht nur innerhalb eines Relativbereichs, womit es vermutlich bisher einzigartig ist. Da eine solche Suche aber ziemlich aufwendig ist, arbeitet das Programm bei genügend Speicher mittels eines dreidimensionalen Sucharrays, wodurch ungeachtet des Aufwandes die Suchzeiten relativ gering sind. Wenn nicht genug Speicher zur Verfügung steht, wird auf ein zwei- oder eindimensionales Array zurückgegriffen. @ENDNODE @NODE "GCompare" "GCompare" @SMARTWRAP @{LINDENT 1} @{B}GCompare@{UB} GCompare ist ein Shell-Befehl mit folgender Syntax: GCompare [MODE [VARY ] | AUTO [DEEP]] [VERBOSE] [mem128 | mem256] GCompare vergleicht die alte Datei mit der neuen Datei und speichert alle Änderungen (Patches) in der Patchdatei. Wenn GCompare eine bereits bestehende Patchdatei findet, dann hängt es die Änderungen an diese Datei an, nachdem es überprüft hat, daß für die zu bearbeitende alte Datei noch keine Änderungen in der Patchdatei enthalten sind. Außerdem sucht es auch in der Patchdatei nach passenden Daten. Aus der alten Datei und der Patchdatei kann GPatch dann die neue Datei erzeugen. Bei Problemen gibt GCompare eine Fehlermeldung aus. Schwerwiegende Fehler werden immer von einem Return-Code von 15 begleitet, und wenn das Ergebnis eine in irgendeiner Form beschädigte oder unvollständige Patchdatei ist, dann wird sie gelöscht. Die Argumente @{B}MODE, VARY, AUTO@{UB} und @{B}DEEP@{UB} wählen die Betriebsart aus: Ohne Angabe einer Betriebsart arbeitet GCompare im Modus 3, der für alle Dateien ein brauchbares Ergebnis liefert. Mit dem Argument @{B}AUTO@{UB} wählt GCompare selbständig das optimale Dateiformat aus. Das zusätzliche Argument @{B}DEEP@{UB} bewirkt außerdem, daß die minimale Größe, ab der ein Datenbereich als passend gewertet wird, um -1 bis 1 verändert wird. Mit AUTO DEEP erzeugt GCompare die kürzeste mögliche Patch-Datei. Wenn Sie zusätzlich das Argument @{B}VERBOSE@{UB} angeben, dann zeigt Ihnen GCompare nach dem Abschluß der Vergleichsfunktion die Einstellungen an, mit denen das beste Resultat erzielt worden ist. Mit dem Argument @{B}MODE@{UB} können Sie das Dateiformat direkt angeben. Die möglichen Werte für nach MODE sind 1 bis 4. Das Argument @{B}VARY@{UB} verändert die internen Werte der Minimalgröße für passende Datenbereiche, die in der DEEP-Betriebsart automatisch getestet werden. Der kleinste zulässige Wert ist -3. Mit dem Argument @{B}VERBOSE@{UB} zeigt GCompare in allen Betriebsarten außer AUTO eine ausführliche Liste der Patchdaten an. GCompare braucht genug Arbeitsspeicher, um die alte, die neue und die Patchdatei gleichzeitig im Speicher halten zu können. Die Suchgeschwindigkeit von GCompare hängt vom dann noch verfügbaren Speicher ab. Der schnellste Suchalgorithmus benötigt insgesamt 9 mal die Dateigröße der alten Datei plus 128 MB. Der Suchalgorithmus mit einem zweidimensionalen Array benötigt insgesamt 9 mal die Dateigröße der alten Datei plus 514 KB. (Dieser Algorithmus war der schnellste in den Versionen 2 von GCompare.) Der einfache Listen-Suchalgorithmus benötigt insgesamt 9 mal die Dateigröße der alten Datei plus 2 KB. Wenn GCompare auch diesen Speicher nicht findet, dann arbeitet es nur noch in der Betriebsart 3 mit linearer Suche. Das gleiche gilt für die Suche in der möglicherweise vorhandenen Patchdatei. Die schnellste Suche braucht 9 mal die Dateigröße der Patchdatei plus 128 MB, die Suche mittels zweidimensionalem Array braucht 9 mal die Dateigröße der Patchdatei plus 514 KB und die einfache Suche 9 mal die Dateigröße plus 2 KB. Wenn der Speicher auch dafür nicht ausreicht, dann wird nur in der alten Datei gesucht. Die Angaben @{B}mem128@{UB} oder @{B}mem256@{UB} verhindern die Benutzung von beiden oder einem der 128-MB-Sucharrays. Das ist auf Systemen mit virtuellem Speicher sinnvoll, da die Suche nur mit physischem Speicher schnell ist - wenn auf die Festplatte zugegriffen werden muß, wird das Programm wesentlich langsamer als mit den 512-KB-Sucharrays. Ihr Computer sollte GCompare also @{I}mehr@{UI} als 128 MB physischen Arbeitsspeicher zur Verfügung stellen, um es für zum Erzeugen einer neuen Patchdatei schnell ausführen zu können. Zum Anhängen weiterer Daten an eine Patchdatei sind mehr als 256 MB zweckmäßig. Beispiel: Wenn Sie auf einem WinUAE-Rechner mit 256 MB RAM an eine Patchdatei einen weiteren Patch für eine 100 KB große Datei anhängen möchten, dann braucht GCompare für die schnelle Suche in der Datei ca. 129 MB und für die Suche in der Patchdatei weitere 128 MB. Da 257 MB nicht vorhanden sind (abzüglich Windows, dem Emulator und AmigaOS sind es vielleicht noch 200 MB), würde ein Teil der Suche den virtuellen Speicher von Windows brauchen. Deshalb sollten Sie in diesem Fall das Argument mem256 angeben. Damit benutzt GCompare nur für die Suche in der alten Datei das 128-MB-Array, die Suche in der Patchdatei würde dann mit einem 512-KB-Array durchgeführt. @ENDNODE @NODE "GPatch" "GPatch" @SMARTWRAP @{LINDENT 1} @{B}GPatch@{UB} GPatch ist ein Shell-Befehl mit folgender Syntax: GPatch [ | DIRECT [BACKUP ]] [RECURSIVE] [NOVERSION | QUIET] GPatch erzeugt aus der alten Datei und der Patchdatei die neue Datei. Die passenden Patches wählt es anhand der Dateilänge und der CRC-Signatur der alten Datei aus. Bei Problemen gibt GPatch eine Fehlermeldung aus. Schwerwiegende Fehler werden immer von einem Return-Code von 15 begleitet, und wenn das Ergebnis eine in irgendeiner Form fehlerhafte neue Datei ist, dann wird sie gelöscht. Anstelle des Dateinamens für die zu erzeugende neue Datei können Sie auch das Argument @{B}DIRECT@{UB} angeben. Dann erzeugt GPatch eine temporäre Datei, durch welche die alte Datei nach dem erfolgreichen Patchvorgang ersetzt wird. Mit dem zusätzlichen Argument @{B}BACKUP@{UB} läßt sich ein Dateiname für eine Sicherheitskopie der alten Datei angeben. Das Argument @{B}RECURSIVE@{UB} schaltet eine Betriebsart ein, in der GPatch, nachdem es erfolgreich eine neue Datei erzeugt hat, solange weitere Versuche zum Patchen unternimmt, bis keine passenden Daten mehr gefunden werden. Dabei wird immer die zuletzt erzeugte neue Datei als alte Datei benutzt. Diese Betriebsart können Sie verwenden, wenn Sie nicht alle alten Versionen Ihrer Programme archivieren wollen. Die Patchdatei sollte dann sinnvollerweise nicht die Änderungen aller alten Versionen auf die neueste Version enthalten, sondern jeweils die Änderungen von einer Version zur nächsten. Mit @{B}NOVERSION@{UB} läßt sich die Anzeige der Versionsdaten unterdrücken und mit @{B}QUIET@{UB} arbeitet GPatch völlig ohne Textausgaben (Fehler werden natürlich immer angezeigt). @ENDNODE @NODE "Hinweise" "Hinweise zur Benutzung" @SMARTWRAP @{LINDENT 1} @{B}Diskussion und Hinweise zur Benutzung:@{UB} Inzwischen habe ich einige Mails mit Kommentaren zur Geschwindigkeit und der Größe der resultierenden Patchdatei erhalten. Manche fanden die Patchdatei viel kleiner als die anderer Patcher, andere wiederum nicht, und fast allen ist das Compare-Programm nicht schnell genug. Das Thema Geschwindigkeit sollte sich seit Version 3 erledigt haben. Bisher habe ich kein anderes Programm gesehen, das die gleiche Suche schneller zustande bringt. Natürlich ist es für Amiga-Anwender momentan noch nicht selbstverständlich, 512 MB Hauptspeicher zu besitzen, aber zumindest mit Amithlon oder UAE ist das kein Problem. Somit ist die Suche mittels dreidimensionalem Array auch für die 68k-Version von GCompare sinnvoll. Wer momentan noch mit weniger Speicher auskommen muß, kann das Programm natürlich trotzdem benutzen, nur eben langsamer. Da es nicht möglich ist, ein Dateiformat für die Patchdatei zu entwickeln, das in allen Fällen das kürzeste Ergebnis liefert (die Größe der Datei hängt vom Abstand der passenden Daten ab und der Art und Weise, diesen Abstand zu adressieren), hat GCompare vier verschiedene Algorithmen. Der Optimierer, der mit AUTO aktiviert wird, kann das beste Format auswählen, was aber etwa die 4-fache Rechenzeit braucht. Die Verbesserungen, die DEEP zusätzlich bewirkt, hängen von den verglichenen Dateien ab. In vielen Fällen bewirkt DEEP keine Verbesserung mehr. Wenn Ihnen der Optimierer zu lange rechnet, dann empfehle ich MODE 3, der auch als Standardbetriebsart eingestellt ist. In der überwiegenden Anzahl von Fällen liefert dieser Modus das beste Ergebnis. Wenn Sie die Ergebnisse von GCompare mit denen anderer Programme vergleichen wollen, sollten Sie das auch mit komprimierten Versionen der Patchdateien tun. GCompare besitzt keine eingebaute Kompression (im Gegensatz zu anderen Vergleichsprogrammen mit Lauflängenkompression), weil ich denke, daß alle Vertriebsdateien vor ihrer Veröffentlichung ohnehin komprimiert werden und eine doppelte Kompression die Effizienz wieder verringert. GCompare sucht passende Daten nicht nur in der alten Datei, sondern gegebenenfalls auch in der bereits vorhandenen Patchdatei. Die resultierende Patchdatei wird also verglichen mit einzelnen Patchdateien um so effizienter, je mehr Patches verschiedener Versionen des gleichen Programms sie enthält. Wenn sich bei diesen Versionen immer nur wenig geändert hat, dann sollten Sie in der Patchdatei die Änderungen von einer Version zur nächsten speichern und GPatch im rekursiven Modus arbeiten lassen. So wird die Patchdatei besonders klein. Um GPatch nicht zu groß werden zu lassen, ist das Bearbeiten der älteren Dateiformate nicht mehr vorgesehen. Damit Sie bei Bedarf auch diese Patchdateien benutzen können, sind die Versionen 1.4, 1.6 und 2.6 ebenfalls noch im Lieferumfang. Wenn GPatch eine alte Patchdatei findet, dann teilt es Ihnen mit, welche Version Sie dafür brauchen. @ENDNODE @NODE "Details" "Technische Details" @SMARTWRAP @{LINDENT 1} @{B}Technische Details@{UB} Die Modi 1 und 2 eignen sich besser für Dateien beliebiger Art, während Modus 3 und Modus 4 Vorteile bei Programmdateien haben. @{B}MODE 1@{UB} Modus 1 ist am besten geeignet, wenn die meisten Änderungen der Dateien kleiner als 128 Byte sind. @{B}MODE 2@{UB} Modus 2 ist bei vielen sehr kleinen Änderungen am wirkungsvollsten. @{B}MODE 3@{UB} Modus 3 ist besonders für Programmdateien geeignet und bei vielen kleinen Änderungen (kleiner 32 Byte) effizient. @{B}MODE 4@{UB} Modus 4 ist ebenfalls für Programmdateien vorteilhaft und effizienter als Modus 3, wenn die Änderungen größere Blöcke betreffen. ------ Nachdem GCompare fertig ist, gibt es noch eine Liste der Patchdaten aus. Die angezeigten Werte sind alles, was in der Patchdatei über Ihre Dateien gespeichert ist. Die Angabe "type" ist das Kodierungsverfahren, das mit MODE ausgewählt worden ist. Falls Sie außerdem wissen wollen, welche Änderung der minimalen Blockgröße GCompare im Modus AUTO DEEP benutzt hat, dann müssen Sie zusätzlich VERBOSE angeben. Um die Änderungsdaten verschiedener Programme zu unterscheiden, benutzt GPatch die Dateigröße und die CRC-Signatur. Versionsangaben oder Dateinamen werden nicht berücksichtigt. Dieses Verfahren ist vollkommen sicher, da GCompare beim Erzeugen der Patchdatei auf dieselbe Weise überprüft, ob Änderungsdaten für eine bestimmte Datei bereits vorhanden sind, bevor es neue Daten anfügt. @ENDNODE @NODE "Beispiele" "Beispiele" @SMARTWRAP @{LINDENT 1} @{B}Beispiele@{UB} Als Beispiel für die Anwendung der Patchprogramme habe ich in der Schublade "ExampleScripts" Skripte für das Erzeugen und Anwenden einer Patch-Datei eines fiktiven Programms beigelegt. @{" MakePatchFile " LINK "ExampleScripts/MakePatchFile/MAIN"} erzeugt die Patch-Datei und @{" UpdateMyProgram " LINK "ExampleScripts/UpdateMyProgram/MAIN"} führt das Patchen aus. In dem Beispiel wird davon ausgegangen, daß verschiedene ältere Versionen des Programms "MyProgram" in einem Archiv namens "Archive" liegen. Der Patch für das Programm und eine Anleitung "MyProgram.readme" wird in diesem Beispiel direkt auf der Programmdiskette "MyProgram" ausgeführt. Und zum schnellen Experimentieren gibt es noch das @{" CompareScript " LINK "ExampleScripts/CompareScript/MAIN"}, mit dem Sie GCompare benutzen können, ohne Shell-Befehle eintippen zu müssen. Das Skript @{" GCompareAdd " LINK "ExampleScripts/GCompareAdd/MAIN"} kann mit denselben Argumenten wie GCompare aufgerufen werden. Dieses Skript erleichtert das Anhängen von neuen Versionen einer Datei an eine Patchdatei, die die Änderungen von jeweils einer Version zur nächsten enthält und im rekursiven GPatch-Modus benutzt werden soll. Sie müssen dann nur noch die älteste Version der Datei archivieren und können dann bei Bedarf aus der Patchdatei alle anderen wiederherstellen. Von Thomas Baust habe ich ein Beispiel-Skript für den Installer erhalten und im wesentlichen unverändert unter dem Namen @{" UpdateMyProgram.installer " LINK "ExampleScripts/UpdateMyProgram.installer/MAIN"} mit beigelegt. Es führt einen Patch für ein Programm names "MyProgram" in einem vom Anwender wählbaren Verzeichnis aus. @ENDNODE @NODE "IX Windows PPC" "Versionen für andere Betriebssysteme" @SMARTWRAP @{LINDENT 1} @{B}Versionen für andere Betriebssysteme und PPC@{UB} Die Versionen 3 für PPC und andere Betriebssysteme sind noch nicht fertiggestellt. Sobald sie zur Verfügung stehen, wird dieses Archiv im Aminet aktualisiert. @ENDNODE @NODE "Copyright" "Copyright, Vertrieb, Haftungsausschluß und Warenzeichen" @SMARTWRAP @{LINDENT 1} @{B}Copyright@{UB} Das Copyright © 1997-2002 von GCompare und GPatch liegt bei Ralf Gruner, An der Sense 5a, D-02779 Großschönau ralf.gruner@t-online.de @{B}Vertrieb@{UB} GCompare und GPatch für Amiga sind Freeware. Sie können beliebig eingesetzt werden, einschließlich der Anwendung für kommerzielle Programme. Wenn Sie aber Wert auf zukünftige Updates legen, dann senden Sie mir bitte eine E-Mail, damit ich weiß, daß es überhaupt Benutzer der Programme gibt. Es gibt immer noch einiges zu verbessern, aber die Zeit dafür nehme ich mir nur, wenn es auch jemand braucht. Die Versionen für andere Betriebssysteme sind nur für nichtkommerzielle Anwendungen Freeware. Für jeglichen kommerziellen Einsatz setzen Sie sich bitte mit mir in Verbindung. Und (wer's lesen will): @{B}Rechtliches@{UB} Bei der Entwicklung der Software wurde mit allergrößter Sorgfalt vorgegangen. Trotzdem sind Fehler nicht vollständig ausgeschlossen. Der Autor übernimmt keine Haftung für Schäden, die direkt oder indirekt auf die Benutzung seiner Programme zurückzuführen sind. @ENDNODE @NODE "Credits" "Credits" @{LINDENT 1} @SMARTWRAP @{B}Danksagung@{UB} an Dirk Stöcker für seine ausführliche Fehlersuche, die Idee der rekursiven Betriebsart von GPatch, die meisten der Portierungen auf diverse IX-Betriebssysteme und PPC und die Funktionen zur Codierung der Reloc-Hunks. @ENDNODE @NODE "Index" "Stichwortverzeichnis" @{LINDENT 1} @{B}Stichwortverzeichnis@{UB} @SMARTWRAP A @{" Änderungsliste " LINK "GPatchHistory.guide/MAIN"} B @{" Beispiele " LINK "Beispiele" 0} C @{" Copyright " LINK "Copyright" 0} G @{" GCompare " LINK "GCompare" 0} @{" GPatch " LINK "GPatch" 0} @{" GPatch 1.4 / 1.6 / 2.6 " LINK "Hinweise" 0} H @{" Hinweise " LINK "Hinweise" 0} M @{" MODE " LINK "Details" 0} P @{" PPC-Version " LINK "IX Windows PPC" 0} U @{" UNIX-Versionen " LINK "IX Windows PPC" 0} W @{" Windows-Version " LINK "IX Windows PPC" 0} @ENDNODE