DE69912601T2

DE69912601T2 - Anpassung von umbasierten und neu ausgerichteten exekutierbaren dateien

Info

Publication number: DE69912601T2
Application number: DE69912601T
Authority: DE
Inventors: Carey Nachenberg
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 1998-04-17
Filing date: 1999-04-16
Publication date: 2004-09-23
Anticipated expiration: 2019-04-17
Also published as: EP1084469A1; US6230316B1; CA2329522A1; EP1084469B1; DE69912601D1; CA2329522C; WO1999054816A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf das Updaten oder Aktualisieren von Software. Insbesondere bezieht sich die vorliegende Erfindung auf ein System und ein Verfahren zur Durchführung eines Updates einer ausführbaren Datei, die einer Rebasierung oder Neuausrichtung unterzogen wurde.
HINTERGRUND DER ERFINDUNG
Das Dokument WO-A-97/12508 beschreibt ein System zum Transformieren eines originalen Objektcodes in einen plattformunabhängigen Objektcode, der durch Hinzufügen oder Ändern von Funktionen modifiziert ist, und das anschließende Rücktransformieren des Objektcodes in den gleichen Typ wie der originale Objektcode. Die Arbeit „A Cross-Platform Binary Diff von K. Coppieters, erschienen in Dr. Dobss's Journal vom 1.5.1995, Seiten 32, 35 und 36, bezieht sich auf den binären Dateivergleich, der nützlich ist, um Updates großer Dateien über eine Datenübertragungsleitung zu senden.
Einige Hersteller von Computer-Software aktualisieren häufig ihre Software-Anwendungen (Computerprogramme und Dateien in Zusammenhang mit den Programmen). Diese Updates erweitern die Anwendungen oft um neue Funktionen und beseitigen bekannte Fehler. Für das Aktualisieren bzw. Updaten von Software-Anwendungen werden meist mehrere Verfahren eingesetzt. Das einfachste Verfahren ist die Verteilung einer kompletten Software-Anwendung, um die ältere zu ersetzen. Dieses Voll-Update-Verfahren ist einfach, aber auch teuer und unpraktisch. Im allgemeinen wird die Software auf einem wechselbaren Datenträger oder Medium wie z. B. Disketten oder CD-ROMs verbreitet, deren Herstellung und Vertrieb teuer ist. Die Zeit, die ein Endanwender warten muss, bis der Datenträger eintrifft, und die Zeit zum Installieren der Software-Anwendung auf einem Computersystem sind unattraktiv. Diese Unannehmlichkeit wird noch verstärkt, wenn Updates häufig erfolgen.
Aufgrund des großen Umfangs vieler Software-Anwendungen ist es im Allgemeinen nicht sinnvoll, solche Updates über Computernetze wie etwa das Internet zu verbreiten. Wenn Voll-Updates größerer Anwendungen über das Internet verbreitet werden, verursachen sie oft so hohe Belastungen auf den Servern, dass andere Benutzer eine Verlangsamung des Netzwerkes bemerken, und die Server haben Schwierigkeiten, die Nachfrage zu decken.
Um viele der Probleme zu überwinden, die mit dieser Form von Software-Updates verbunden sind, verbreiten einige Software-Hersteller inkrementelle Updates. Diese Updates enthalten keine vollständigen Software-Anwendungen, sondern vielmehr die Daten, die erforderlich sind, um eine bestimmte Version einer Software-Anwendung in eine neuere Version zu transformieren. Zu den Verfahren, die für die Durchführung solcher inkrementeller Software-Updates zur Verfügung stehen, gehört auch das binäre Patchen, das z. B. mit Hilfe von Programmen wie RTPatch von Pocket Soft, Inc., erfolgt. Ein binärer Patcher ändert die binären Teile einer Software-Anwendung, die sich in einer neueren Version geändert haben. Weil viele Software-Updates Änderungen nur an einem geringen Teil einer Software-Anwendung betreffen, braucht ein binärer Patcher zusätzlich zu der alten Software-Anwendung nur eine kleine Datei mit den Unterschieden zwischen den beiden Versionen. Die kleineren Dateien, die für ein binäres Patch-Update vertrieben werden, haben oft eine Größe von weniger als 1 Prozent eines Voll-Updates, wobei sie von der großen Redundanz in den beiden Versionen profitieren.
Der Einsatz von inkrementellen Update-Verfahren ermöglicht kleinere Updates, die mit Mitteln verbreitet werden können, die für den Vertrieb von Voll-Updates nicht sinnvoll sind, z. B. per Internet. Die kleineren inkrementellen Updates machen auch den Vertrieb per Diskette sinnvoller, denn während ein Voll-Update viele Disketten erfordern würde, reicht für ein inkrementelles Update eventuell eine Diskette aus.
Herkömmliche inkrementelle Update-Verfahren setzen jedoch voraus, dass die zu aktualisierenden Anwendungsdateien exakt einer bekannten Vor-Update-Version entsprechen. Weil beim binären Updaten ausgewählte Teile einer Datei verschoben und ersetzt werden, können eventuelle Abweichungen zwischen der zu aktualisierenden Datei und der erwarteten Vor-Update-Datei zu unberechenbaren Ergebnissen führen.
Es gibt zahlreiche Verfahren, mit denen Dateien mit ausführbaren Code-Modulen modifiziert werden können, um unter einem bestimmten Betriebssystem oder auf einem bestimmten Computersystem effektiver zu funktionieren. Zwei dieser Verfahren sind das „Rebasieren" und das „Neuausrichten". Unter Rebasieren versteht man das Ändern von Informationen in einer Datei, um die in den Speicher geladene Datei an einer neuen Basisadresse anzuordnen. Im Allgemeinen umfasst das Rebasieren das Ändern von ab soluten Speicheradressen, die in Code- und Datensegmenten erscheinen, so dass die richtigen Speicheradressen erscheinen. Das Neuausrichten ist das Verschieben von Code- und Datensegmenten innerhalb einer Datei, so dass die Segmente an bestimmten numerischen Grenzen beginnen. Das Rebasieren und das Neuausrichten werden nachstehend ausführlich beschrieben. Beide Formen der Dateiverarbeitung erzeugen Dateien, die sich von den auf dem System installierten Originaldateien unterscheiden können. Wenn ein Software-Hersteller frühere Versionen einer Anwendung mit einem inkrementellen Update auf eine neue Version aktualisieren möchte, geht er im Allgemeinen davon aus, dass die zu aktualisierenden Dateien einer Version einer endlichen Anzahl von älteren Versionen entsprechen. Update-Patches für diese bekannten Versionen können hergestellt und den Anwendern zugeschickt werden. Sind einige der Anwendungsdateien rebasiert und/oder neu ausgerichtet worden, liegen diese Anwendungsdateien nicht in einem für eine Aktualisierung mit dem inkrementellen Update erkennbaren Format vor. Weil die rebasierte oder neu ausgerichtete Datei dem Hersteller des inkrementellen Updates im Allgemeinen nicht zur Verfügung steht, sind herkömmliche inkrementelle Update-Verfahren nicht ausreichend.
Benötigt wird daher ein System zur Durchführung von inkrementellen Updates an Anwendungsdateien, die rebasiert und/oder neu ausgerichtet worden sind.
Aspekte der vorliegenden Erfindung sind in den anliegenden Ansprüchen festgelegt.
Die bevorzugte Ausführungsform ist ein System, ein computer-implementiertes Verfahren und ein computerlesbares Medium zum inkrementellen Updaten einer Datei (100), die rebasiert oder neu ausgerichtet worden ist. Eine kanonische Form (100B) wird vorgesehen. In Bezug auf das Rebasieren ist eine kanonische Form (100B) eine solche, die auf eine vorgegebene Basisadresse (104) rebasiert worden ist. Bei einer Ausführungsform ist diese vorgegebene Basisadresse (104) Null. In Bezug auf das Neuausrichten ist eine kanonische Form (100B) eine solche, die auf eine bestimmte Weise neu ausgerichtet worden ist. Bei einer Ausführungsform werden die Segmente (110) der Datei (100) so neu ausgerichtet, dass es keine ungenutzten Speicherplätze (114) zwischen dem Ende eines Segments (110) und dem Anfang des nächsten Segments (110) gibt. Bei einer anderen Ausführungsform werden die Segmente (110) der Datei (100) an Seitengrenzen (112) einer vorgegebenen Größe neu ausgerichtet.
Ein inkrementelles Update (124) für die Datei (100) wird bestimmt, das die Datei (100) aus der kanonischen Form (100B) in die gewünschte Update-Form (100C) bringt. Der Prozess des Updatens der Datei (100) umfasst das Transformieren der Datei (100) in die kanonische Form (100B) und das Anwenden des inkrementellen Updates (124) auf die kanonische Form (100B), wodurch die gewünschte Update-Form (1000) erhalten wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Diese und andere ausführlichere und spezifische Ziele und Merkmale der vorliegenden Erfindung werden in der folgenden Spezifikation anhand der anliegenden Zeichnungen ausführlich beschrieben.
1 zeigt eine Illustration einer Datei 100 mit ausführbarem Code.
2 zeigt eine Illustration einer Datei 100, bei der die Basisadresse 104 geändert worden ist, ohne die Verweise 102 auf absolute Speicheradressen zu ändern.
3 zeigt eine Illustration einer Datei 100, die rebasiert worden ist.
4 zeigt eine Illustration einer Datei 100, die der kanonischen Form der gezeigten Ausführungsform entspricht.
5 zeigt eine Illustration einer Datei 100, die keine Segmente 110 aufweist, die an Seitengrenzen 112 ausgerichtet sind.
6 zeigt eine Illustration einer Datei 100, die neu ausgerichtet worden ist.
7 zeigt eine Illustration einer Datei 100, die der kanonischen Form der gezeigten Ausführungsform entspricht.
8 zeigt eine Illustration einer Ausführungsform der vorliegenden Erfindung.
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Zur Überwindung der Probleme beim inkrementellen Updaten von Dateien, die rebasiert und/oder neu ausgerichtet worden sind, wird eine kanonische Form benutzt. Eine kanonische Form ist eine solche vorgegebene Form, bei der für eine Gruppe von Dateien, die jeweils den anderen in der Gruppe gleichwertig sind, die kanonische Form jeder Datei in der Gruppe identisch ist mit der kanonischen Form einer beliebigen anderen Datei in der Gruppe. Der Nutzen einer kanonischen Form besteht darin, dass nicht identische Dateien, sofern sie einander gleichwertig sind, identisch sind, wenn sie in eine kanonische Form gebracht werden. Eine rebasierte Datei ist funktional gleichwertig mit der originalen Datei, und der ausführbare Code in der Datei funktioniert vor und nach dem Rebasieren in der gleichen Weise. Gleichermaßen ist eine neu ausgerichtete Datei funktional gleichwertig mit der originalen Form der Datei. Eine in eine kanonische Form gebrachte Datei ist identisch mit einer gleichwertigen Datei, welche in die kanonische Form gebracht wurde, unabhängig von einem Rebasieren oder Neuausrichten, dem die Dateien unterzogen worden sind, ehe sie in die kanonische Form gebracht wurden. Weil eine kanonische Form so ausgelegt ist, dass sie die Unterschiede zwischen gleichwertigen Dateien eliminiert, ist die Definition einer bestimmten kanonischen Form abhängig von der Form der bewahrten Gleichwertigkeit oder Äquivalenz. Bei der beispielhaft gezeigten Ausführungsform werden Äquivalenzen zwischen rebasierten Dateien und Äquivalenzen zwischen neu ausgerichteten Dateien genutzt. Andere Äquivalenzen sind für den Fachmann erkennbar.
Alle Updates erfolgen an Dateien, die in eine kanonische Form gebracht worden sind. Zur Erläuterung der Attribute der kanonischen Formen in der gezeigten Ausführungsform der vorliegenden Erfindung ist es erforderlich, zunächst das Rebasieren und Neuausrichten etwas genauer zu beschreiben.
Rebasieren
In 1 enthält die Datei 100 (bei der es sich z. B. um eine normale ausführbare Datei oder eine Laufzeitbibliothek [DLL-Datei] handeln kann) ausführbaren Code, der Verweise 102 auf absolute Speicheradressen enthält, die sich in dem für die Datei 100 vorgesehenen Speicher befinden. Diese Verweise 102 basieren auf der Annahme, dass die Datei 100 an einer bestimmten vorgegebenen Adresse 104 (der „Basis") in den Speicher geladen wird. Bei der Datei 100 in 1 hat die Basisadresse 104 den Wert 9000h (alle Adressen im Hexadezimalformat). Manchmal ist es jedoch nicht möglich, die Datei 100 durch Laden an der vorgesehenen Basisadresse 104 im Speicher unterzubringen. Befindet sich z. B. schon eine DLL-Datei an der Basisadresse 104, wenn die Datei 100 geladen wird, kann die Datei 100 an der Adresse 104 nicht geladen werden. Wie in 2 gezeigt, hat ein Ändern der Basisadresse 104 ohne Änderung der absoluten Speicherverweise 102 die Folge, dass der Code nicht mehr ordnungsgemäß funktioniert. Wenn Daten aus einer festen Adresse gelesen werden, werden die falschen Daten gelesen. Ein Sprung oder eine Verzweigung zu einer festen Adresse bewirkt die Ausführung von falschem Code. Daher wird eine solche Datei 100 nach Möglichkeit rebasiert, um sie an einer anderen Basisadresse 104 laden zu können. Das Rebasieren kann zum Zeitpunkt der Ausführung, d. h. bei Laufzeit, im Direktzugriffsspeicher (RAM) erfolgen, oder es kann einmal ausgeführt werden, wobei die rebasierte Datei anstelle der originalen Datei 100 gespeichert wird.
Wie es für rebasierbare Dateien typisch ist, enthält die Datei 100 einen Header-Block 106 am Anfang der Datei 100, der angibt, welche Speicherverweise 102 in der Datei 100 geändert werden müssen, um die Änderung der Basisadresse 104 zu berücksichtigen. Das Rebasieren erfolgt durch Lesen des Header-Blocks 106 und Ändern jedes solchen Speicherverweises 102 entsprechend der neuen Basisadresse 104. 3 zeigt eine ordnungsgemäß rebasierte Form der Datei 100 in 1. Der Unterschied zwischen der alten Basisadresse 104 und der neuen Basisadresse 104 ist auf alle absoluten Speicherverweise 102 angewendet worden. Ausführbare Dateien und DLL-Dateien nach dem „Portable Executable"- oder PE-Format können im Allgemeinen auf diese Weise rebasiert werden. Der Prozess des Rebasierens dauert eine gewisse Zeit, was im Falle der Ausführung bei Laufzeit unerwünscht ist. Wird das Rebasieren durch ein Betriebssystem bei Laufzeit ausgeführt, besteht der Effekt darin, dass die Ausführung des in der Datei 100 enthaltenen Codes verzögert wird.
Die mit dem Rebasieren verbundene Laufzeitverzögerung kann vermieden werden, indem die Datei 100 so rebasiert wird, dass sie an einer Basisadresse 104 geladen wird, von der erwartet wird, dass sie frei ist, und die rebasierte Version der Datei 100 anstelle der Originalversion gespeichert wird. Wenn sie geladen ist, braucht diese neue Datei 100 im Allgemeinen nicht erneut rebasiert zu werden. Diese Art des Rebasierens kann an bestimmten Dateien mit einem Rebasierungs-Werkzeug wie z. B. dem Dienstprogramm „REBASE.EXE" von Microsoft Corp. vorgenommen werden. Ein Systemoptimierungsprogramm kann ebenfalls benutzt werden, um alle ausführbaren Dateien und DLL-Dateien auf einem Computersystem so zu rebasieren, dass die nötige Laufzeit-Rebasierung auf ein Minimum reduziert wird. Eine solche Funktion könnte auch in ein Betriebssystem integriert sein, das Dateien in einem lokalen Dateisystem rebasiert, um die Instanzen einer Laufzeit-Rebasierung zu vermeiden.
Um sicherzustellen, dass die Datei 100 eine erwartete Form hat, ehe sie mit einem Update aktualisiert wird, wird sie in die kanonische Form konvertiert. Bei der gezeigten Ausführungsform liegt eine Datei 100 in der kanonischen Form vor, wenn sie auf einen vorgegebenen Wert rebasiert worden ist. Dieser vorgegebene Wert kann in einem Update enthalten sein oder er kann bei der Erstveröffentlichung der Datei 100 festgelegt werden. In 4 ist die kanonische Form eine solche, bei der die Datei 100 auf eine Basisadresse 104 von Null rebasiert worden ist. Bei anderen Ausführungsformen kann die Datei 100 auf einen beliebigen vorgegebenen Wert rebasiert werden. Auch wenn die Datei 100 in der kanonischen Form nicht unbedingt identisch ist mit der Form, in der die Datei 100 ursprünglich vertrieben worden ist, eignet sich diese kanonische Form als ein gemeinsamer Ausgangspunkt.
Neuausrichten
Bezug nehmend auf 5 weisen viele Dateien 100 mit ausführbarem Code mehrere Code- und Datensegmente 110 auf. Bei einem typischen Dateiformat folgen diese Code- und Datensegmente 110 hinter einem Header-Block 106 am Anfang der Datei 100. Bei einem Betriebssystem, das die Datei 100 in den Speicher abbildet und Speicherseiten mit einer festen Größe benutzt, um Teile der Datei 100 in den Speicher einzulagern und aus diesem auszulagern, ist es sinnvoll, dass die Code- und Datensegmente 110 in der Datei 100 an Speichergrenzen 112 ausgerichtet sind, die der Seitengröße entsprechen. Arbeitet das Betriebssystem z. B. mit Speicherseiten von 4 kB Größe und beginnt ein 4 kB großes Codesegment 110 (z. B. das zweite Codesegment 110 in 5) an der 6 kB-Adresse in der Datei 100, muss das Betriebssystem zwei 4 kB-Abschnitte (4 kB bis 12 kB) der Datei 100 in den Speicher schieben, um das betreffende Codesegment 110 zu laden. Befände sich das Codesegment 110 an der 8 kB-Grenze, wie in 6 gezeigt, könnte das Segment 110 in nur eine 4 kB-Seite des Speichers geladen werden. Durch Ausrichten der Code- und Datensegmente 110 in der Datei 100 an den Seitengrenzen 112 können Dateien 100 mit ausführbarem Code schneller geladen werden.
Es werden viele Dateien 100 mit ausführbarem Code hergestellt, die keine Code- und Datensegmente 110 aufweisen, die an Seitengrenzen 112 entsprechend einem bestimmten Betriebssystem ausgerichtet sind. Dies kann zum Teil darauf zurückzuführen sein, dass die Seitengröße des Betriebssystems, auf dem die Anwendung laufen soll, zum Zeitpunkt des Kompilierens und Linkens der Dateien 100 noch nicht bekannt ist. Einige Anwendungen werden hergestellt, ohne den Versuch zu unternehmen, die Segmente 110 an bestimmten Seitengrenzen 112 auszurichten.
Dateien 100, die nicht für ein bestimmtes Betriebssystem ausgerichtet sind, können zur effizienten Nutzung durch das betreffende Betriebssystem neu ausgerichtet werden, nachdem sie auf dem System installiert worden sind. Der Prozess des Verschiebens von Segmenten 110 in der Datei 100 mit ausführbarem Code ist vergleichbar mit dem Rebasieren. Informationen über die Position der Code- und Datensegmente 110 in der Datei 100 sind im Allgemeinen im Header-Block 106 enthalten. Wie in 6 gezeigt, können die Segmente 110 durch Hinzufügen oder Löschen von ungenutztem Platz 114 zwischen den Segmenten 110 so angeordnet werden, dass sie sich mit bestimmten Seitengrenzen 112 decken. Nach dem Neuausrichten der Segmente 110 wird der Header-Block 106 mit den neuen Segmentadressen aktualisiert, und alle nötigen Änderungen werden an den absoluten Speicherverweisen 102 vorgenommen, damit der Code ordnungsgemäß funktioniert. Diese neu ausgerichtete Datei 100 ersetzt die originale Datei 100, wodurch die Datei 100 schneller in den Speicher geladen werden kann.
Wie in 7 gezeigt, ist eine kanonische Form der Datei 100 eine solche, bei der alle Segmente 110 verschoben worden sind, um einen zusammenhängenden Bereich zu bilden. Dies ist gleichbedeutend mit einem Neuausrichten der Datei 100 an Ein-Byte-Grenzen 112. Alternativ kann eine beliebige Grenze 112 zu dem Zeitpunkt festgelegt werden, wenn ein inkrementelles Update berechnet wird. In der kanonischen Form sind die Segmente 110 an diesen Grenzen 112 ausgerichtet. Bei einer anderen Ausführungsform sind die Grenzen 112 nicht fest bezogen auf die Datei 100, sondern stattdessen fest bezogen auf das vorhergehende Segment 110. Bei einer solchen Ausführungsform würden ungenutzte Speicherbereiche 114 mit einer vorgegebenen Größe festgelegt.
Inkrementelles Updaten
Unter Bezugnahme auf 8 möchte ein Software-Hersteller 118 eine erste Version einer Anwendungsdatei 100A auf eine neue Version 100C aktualisieren. Weil die Anwender Dateien 100 haben können, die der Version 100A entsprechen, aber rebasiert oder neu ausgerichtet worden sind, setzt der Hersteller eine kanonische Konvertiervor richtung 120 ein, um aus einer Datei der Version 100A eine Datei der Version 100B herzustellen. Die Version 100B entspricht der kanonischen Form der Version 100A. Die kanonische Konvertiervorrichtung 120 kann Rebasierungs- und Neuausrichtungsverfahren benutzen, wie sie vorstehend beschrieben sind. Ein Update-Erstellmodul 122 berechnet dann die binären Unterschiede zwischen der Datei 100B und der Datei 100C. Bei dem Update-Erstellmodul 122 kann es sich um jedes herkömmliche Erstellmodul für binäre Patch-Dateien handeln, das binäre Update-Dateien 124 aus zwei Versionen einer Datei 100 herstellen kann. Die Unterschiede werden benutzt, um die Update-Datei 124C–B zu erzeugen.
Die Update-Datei 124C–B wird anschließend an einen Anwender weitergegeben, der sie auf dem Computer 126 installiert. Der Computer 126 umfasst ebenfalls eine kanonische Konvertiervorrichtung 120. Die Vor-Update-Version der Datei 100 auf dem Computer 126 ist rebasiert und neu ausgerichtet worden, so dass sie sich in einem Zustand 100D befindet. Die kanonische Konvertiervorrichtung 120 auf dem Computer 126 nimmt die Datei 100D und erzeugt daraus die kanonische Version 100B. Jetzt kann das Update-Modul 128 die Update-Datei 124C–B benutzen, um die gewünschte Version 1000 der Datei zu erzeugen. Bei dem Update-Modul 128 kann es sich um jeden herkömmlichen binären Patcher handeln, der die mit dem Update-Erstellmodul 122 hergestellten Patches 124 anwenden kann.
Durch Konvertieren der Datei 100, die rebasiert und/oder neu ausgerichtet worden ist, in eine kanonische Form werden die mit der Rückführung der Datei 100 in die originale Form verbundenen Probleme vermieden. Weil die Datei 100 möglicherweise keine ausreichenden Informationen zur Bestimmung der originalen Form enthält, wäre es für einen Prozess, der durch Rückführen der Datei 100 in die originale Form funktioniert, erforderlich, dass das Patch 124 eine ganze Menge an Informationen im Hinblick auf die originale Form enthält. Die vorliegende Erfindung überwindet diese Situation durch Benutzung einer unabhängigen kanonischen Form.
Durch anderen Transformationen außer der Rebasierung und Neuausrichtung können ebenfalls äquivalente und daher kanonische Formen erhalten werden. Beispielsweise können die Code- und Datensegmente in einer Datei umgeordnet werden. Eine kanonische Form, die dies berücksichtigt, kann die Segmente anhand der numerischen Rei henfolge etwaiger spezieller Tags ordnen, die den Segmenten zugeordnet sind. Alternativ können die Segmente numerisch anhand des Inhalts der Segmente geordnet werden.
Die vorstehende Beschreibung zeigt die Funktionsweise einer beispielhaften Ausführungsform und versteht sich nicht als Einschränkung des Umfangs der Erfindung. Der Umfang und Anwendungsbereich der Erfindung ist lediglich durch die anliegenden Ansprüche begrenzt. Aus der vorstehenden Beschreibung sind für den Fachmann viele Variationen erkennbar, die ebenfalls unter den Umfang der vorliegenden Erfindung fallen.

Claims

Verfahren zum inkrementellen Updaten einer Datei (100) mit einem ausführbaren Code auf eine neue Form, wobei die Datei einer Rebasierung, einer Neuausrichtung und/oder einer Umordnung unterzogen wurde, mit folgenden Schritten Konvertieren der Datei (100D) in eine nicht originale kanonische Form (100B), die die an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen nicht umfasst, und Anwenden eines Updatepatches (124) auf die kanonische Form, der dazu ausgelegt ist, die Datei von der kanonischen Form (100B) in die neue Form (100C) zu konvertieren.
Verfahren nach Anspruch 1, wobei die kanonische Form eine solche ist, in welcher ein rebasierbarer Code auf eine vorgegebene Basisadresse (104) rebasiert ist.
Verfahren nach Anspruch 2, wobei die vorgegebene Basisadresse (104) Null ist.
Verfahren nach Anspruch 1, wobei die Datei mindestens ein Segment (110) umfaßt, und die kanonische Form eine solche ist, in welcher jedes Segment an einer aus einem Satz vorgegebener Segmentgrenz-(112)-Adressen angeordnet ist.
Verfahren nach Anspruch 4, wobei die kanonische Form eine solche ist, in welcher ein rebasierbarer Code auf eine vorgegebene Basisadresse (104) rebasiert ist.
Verfahren nach Anspruch 5, wobei die vorgegebene Basisadresse (104) Null ist.
Verfahren nach Anspruch 1, wobei die Datei mindestens ein Segment (110) umfasst, und die kanonische Form eine solche ist, in welcher jedes Segment bezüglich irgendeines vorhergehenden Segments an einer vorgegebenen Position angeordnet ist.
Verfahren nach Anspruch 7, wobei die kanonische Form eine solche ist, in welcher es keinen ungenutzten Speicher (114) zwischen aufeinanderfolgenden Segmenten gibt.
Verfahren nach Anspruch 7, wobei die kanonische Form eine solche ist, in welcher ein rebasierbarer Code auf eine vorgegebene Basisadresse (104) rebasiert ist.
Verfahren nach Anspruch 9, wobei die vorgegebene Basisadresse (104) Null ist.
Verfahren nach Anspruch 1, wobei die Datei mindestens ein Segment (110) umfasst, und die kanonische Form eine solche ist, in welcher: es zwischen aufeinanderfolgenden Segmenten keinen ungenutzten Speicher (114) gibt; und ein rebasierbarer Code auf eine Basisadresse von Null rebasiert ist.
System zum inkrementellen Updaten einer Datei (100) mit einem ausführbaren Code auf eine, neue Form, wobei die Datei einer Rebasierung, einer Neuausrichtung und/oder einer Umordnung unterzogen wurde, mit: einer kanonischen Konvertiervorrichtung (120) mit Zugang zu der ausführbaren Datei (100D), um daraus eine Datei (100B) in nicht-originaler kanonischer Form zu machen, die die an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen nicht umfasst; und einem Update-Modul (128), das mit der kanonischen Konvertiervorrichtung verbunden ist, um die kanonische Form daraus zu empfangen, und um einen Updatepatch (124) mit Informationen über die Unterschiede zwischen der kanonischen Form und der neuen Form zu empfangen und den Updatepatch auf die kanonische Form anzuwenden, um eine Datei (100C) der neuen Form herzustellen.
System nach Anspruch 12, wobei die kanonische Form eine solche ist, in welcher ein rebasierbarer Code auf eine vorgegebene Basisadresse (104) rebasiert ist.
System nach Anspruch 13, wobei die vorgegebene Basisadresse (104) Null ist.
System nach Anspruch 12, wobei die Datei mindestens ein Segment (110) umfasst, und die kanonische Form eine solche ist, in welcher jedes Segment an einer aus einem Satz vorgegebener Segmentgrenz-(112)-Adressen angeordnet ist.
System nach Anspruch 12, wobei die Datei mindestens ein Segment (110) umfasst, und die kanonische. Form eine solche ist, in welcher jedes Segment bezüglich einem vorhergehenden Segment an einer vorgegebenen Position angeordnet ist.
System zum Erstellen eines Updatepatches zum inkrementellen Updaten von Dateien (100) mit einem ausführbaren Code auf eine neue Form, wobei die Dateien einer Rebasierung, einer Neuausrichtung und/oder einer Umordnung unterzogen wurden, mit: einer kanonischen Konvertiervorrichtung (120) mit Zugang zu den ausführbaren Dateien (100A), um daraus Dateien (100B) von nicht-originaler kanonischer Form, die die an den ausführbaren Dateien während der Rebasierung, der Neuausrichtung und/oder der Umordnung durchgeführten Änderungen nicht umfassen, herzustellen; und ein Update-Erstellmodul (122), das mit der kanonischen Konvertiervorrichtung verbunden ist, um von dieser die kanonische Form zu empfangen und um eine Datei (100C) der neuen Form zu empfangen und daraus einen Updatepatch (124) mit Informationen über die Unterschiede zwischen der kanonischen Form und der neuen Form herzustellen.
System nach Anspruch 17, wobei die kanonische Form eine solche ist, in welcher ein rebasierbarer Code auf eine vorgegebene Basisadresse (104) rebasiert ist.
System nach Anspruch 17, wobei die Datei mindestens ein Segment (110) umfasst, und die kanonische Form eine solche ist, in welcher jedes Segment an einer aus einem Satz von vorgegebenen Segmentgrenz-(112)-Adressen angeordnet ist.
System nach Anspruch 17, wobei die Datei mindestens ein Segment (110) umfaßt, und die kanonische Form eine solche ist, in welcher jedes Segment bezüglich einem vorhergehenden Segment an einer vorgegebenen Position angeordnet ist.
Computerlesbares Medium mit einem Computerprogramm zum inkrementellen Updaten einer Datei (100) mit einem ausführbaren Code auf eine neue Form, wobei die Datei einer Rebasierung, einer Neuausrichtung und/oder einer Umordnung unterzogen wurde, wobei das Updaten folgende Schritte aufweist: Konvertieren der Datei (100D) in eine nicht-originale kanonische Form (100B), die die an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen nicht umfaßt; und
Anwenden eines Updatepatches (124) auf die kanonische Form, der dazu ausgelegt ist, die Datei von der kanonischen Form (100B) in die neue Form (1000) zu konvertieren.
Computerlesbares Medium nach Anspruch 21, wobei die kanonische Form eine solche ist, in welcher ein rebasierbarer Code auf eine vorgegebene Basisadresse (104) rebasiert ist.
Computerlesbares Medium nach Anspruch 21, wobei die Datei mindestens ein Segment (110) umfasst, und die kanonische Form eine solche ist, in welcher jedes Segment an einer aus einem Satz vorgegebener Segmentgrenzen-(112)-Adressen angeordnet ist.
Computerlesbares Medium nach Anspruch 21, wobei die Datei zumindest ein Segment (110) umfaßt, und die kanonische Form eine solche ist, in welcher jedes Segment bezüglich eines vorhergehenden Segments an einer vorgegebenen Position angeordnet ist.
Verfahren nach Anspruch 1, wobei der Schritt des Konvertierens das Eliminieren der an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen umfaßt.
System nach Anspruch 12, wobei die kanonische Konvertiervorrichtung die an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen eliminiert.
Computerlesbares Medium nach Anspruch 21, wobei der Schritt des Konvertierens das Eliminieren der an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen umfaßt.
System nach Anspruch 17, wobei die kanonische Konvertiervorrichtung die an der ausführbaren Datei während der Rebasierung, der Neuausrichtung und/oder der Umordnung gemachten Änderungen eliminiert.