DE69637182T2

DE69637182T2 - Vorrichtung und verfahren zur vorverarbeitung von computerprogrammen vor netzwerkübertragung

Info

Publication number: DE69637182T2
Application number: DE69637182T
Authority: DE
Inventors: James A. Cupertino HOUHA; Gordon J. Palo Alto FREEDMAN
Original assignee: PowerTV Inc
Current assignee: PowerTV Inc
Priority date: 1995-12-29
Filing date: 1996-12-27
Publication date: 2008-07-31
Anticipated expiration: 2016-12-28
Also published as: EP0870235A4; EP0870235A1; WO1997024674A1; EP0870235B1; US5734822A; KR19990076824A; KR100422103B1; DE69637182D1; AU1466497A

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Technik
Diese Erfindung bezieht sich allgemein auf Systeme zum Herunterladen von Computerprogrammen über ein Netz in Endgeräte wie Heimkommunikations-Endgeräte (HCT: home communication terminals) in einem Kabelfernsehnetz. Konkreter stellt die Erfindung ein Gerät und ein Verfahren zur Verfügung, um die Effizienz zu steigern, mit der Computerprogramme in solche Endgeräte heruntergeladen und für den Ablauf vorbereitet werden können.
2. Verwandte Informationen
Im Dokument EP-A-0 645 685 wird ein Computersystem zur Vorbereitung eines Computerprogramms für den Ablauf in einem Endgerät offenbart, worin Objektcode einen Codeabschmitt mit Computerbefehlen, einen Datenabschnitt mit modifizierbaren Datenwerten und einen Verschiebungsabschnitt mit Informationen für eine Verschiebung von Computerbefehlen im Codeabschnitt umfasst.
Systeme, die in der Lage sind, Computersoftware in Endgeräte wie HCTs in einem Abonnentenfernsehsystem herunterzuladen, sind gut bekannt. Zum Beispiel beschreibt das US-Patent Nr. 5 440 632 mit dem Titel „Reprogrammable subscriber terminal" [Umprogrammierbares Teilnehmer-Endgerät] ein System, das Mittel enthält, um Teilnehmer-Endgeräte durch Herunterladen von Code in einer Reihe von Datenbewegungen umzuprogrammieren. Solche Systeme können verwendet werden, um neue Anwendungen hinzuzufügen oder veraltete bzw. defekte Software zu ersetzen.
Das Bedürfnis, neue Merkmale wie Multimedien-Anwendungen, leistungsfähigere Grafik und dergleichen zur Verfügung zu stellen, hat zu zusätzlichen Verarbeitungsmöglichkeiten und Speicheranforderungen in den HCTs geführt. Weil Speicherplatz eine signifikante Kostenkomponente in HCT darstellt, kann eine ineffiziente Speichernutzung leider zu unannehmbar hohen Kosten führen.
Die gegenwärtigen Erfinder haben festgestellt, dass herkömmliche Verfahren zum Verknüpfen und Laden neuer oder modifizierter Computerprogramme in HCTs den Speicherplatz im HCT nicht effizient nutzen, weshalb ein innovativeres Vorgehen erforderlich ist, um den erforderlichen Speicherplatz zu minimieren. Insbesondere verlangt die Art und Weise, in der HCTs herkömmlicherweise aus einem Headend oder einer anderen Quelle des Herunterladens Computerprogramme laden, im HCT viel Speicherplatz. Um ein Beispiel zu nennen, verlangt das herkömmliche Vorgehen zusätzlich zur Zuweisung der end gültigen Zielspeicherplätze für ein neu heruntergeladenes Image die Zuweisung eines Pufferbereichs im HCT, um das neue oder modifizierte Lade-Image zu empfangen. Der zugewiesene Pufferbereich ist im Wesentlichen verschwendet, da er nach dem Herunterladen nicht gebraucht wird.
Um ein weiteres Beispiel zu nennen, verlangt das herkömmliche Vorgehen beim Herunterladen neuer Programme entweder, dass ein vollständiges, ablauffähiges Image vor dem Herunterladen in das HCT verknüpft wird – wodurch ein selektives Herunterladen getrennter Programme in das HCT vermieden wird – oder es verlangt einen Bindelader im HCT, der unnötigen Speicherplatz beansprucht und die HCT-Softwareauslegung kompliziert. Angesichts dieser und weiterer Probleme hat, wie festgestellt wurde, das herkömmliche Vorgehen beim Herunterladen beträchtliche Nachteile.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung löst die zuvor erwähnten Probleme, indem Bindeladerfunktionen wohl überlegt zwischen einer Herunterladequelle (wie einem Entwicklungscomputer, einem Headendcomputer oder einer Kombination beider) und einem Endgerät wie einem HCT aufgeteilt werden. Insbesondere werden viele Funktionen, die herkömmlicherweise durch einen Bindelader ausgeführt werden, stattdessen während eines Paketverwaltungsschrittes („packaging” step) vor dem Herunterladen in das Endgerät ausgeführt. Ein Packagerdienstprogramm an der Herunterladequelle wirkt auf die Ausgabe eines Compilers, um die durch einen Lader im Endgerät ausgeführten Ladeoperationen zu vereinfachen. In verschiedenen Ausführungsformen kann der Packager („Verpacker”) Funktionen wie 1) eine partielle Codeverschiebung; 2) eine Bestimmung der Ladegrössenparameter; und 3) die Formatierung eines ablauffähigen Codes zu einem gemeinsamen Format unabhängig vom Codetyp, aus dem er stammt, ausfüllen. Jede dieser Funktionen wird unten getrennt diskutiert.
Partielle Codeverschiebung. Ein herkömmliches Paradigma für die Erzeugung eines ablauffähigen Codes besteht aus den Schritten, Quellencode zu Objektcode zu kompilieren, den Objektcode zu einem ablauffähigen Image zu verknüpfen und zu verschieben und das ablauffähige Image in das Endgerät herunterzuladen. Im Gegensatz dazu werden in der vorliegenden Erfindung die Schritte in Betracht gezogen, 1) Quellencode zu Objektcode zu kompilieren; 2) den Objektcode zu „verpacken", indem unter Verwendung eines Sprungtabellenmappers und weiterer, bei der Herunterladequelle bekannter Informationen über das Endgerät nach der Kompilierzeit noch nicht definierte Symbole aufgelöst werden; 3) den „verpackten" Code über das Kabelnetz ins Endgerät herunterzuladen; und 4) übrigen Code, soweit erforderlich, im Endgerät zu verschieben. Viele herkömmliche Bindeladerfunktionen werden daher vom Endgerät zur Herunterladequelle herübergenommen, um Speicherplatzanforderungen im Endgerät zu verringern.
Da der Packager bei der Herunterladequelle die Sprungtabelle in den Endgeräten kennt, kann er viele Adressen auflösen, ehe ein Ladestrom zum Endgerät übermittelt wird, wodurch die Ladeoperation beschleunigt und der Umfang des Ladestromes verringert wird. Der Packager kann zum Beispiel viele Befehle „branch relative to program counter" (verzweige bezüglich des Programmschrittzählers), die durch den Compiler erzeugt werden, mit absoluten Befehlen (branch to absolute address: verzweige zu absoluter Adresse) ersetzen, ehe sie zum Lader im Endgerät übermittelt werden. Der Packager kann auch das Gegenteil tun (d. h. er kann absolute Verzweigungen zu relativen Verzweigungen verändern). Dadurch wird der Umfang des Ladestroms verringert, und viele Adressenverschiebungsoperationen werden vom Endgerät weggenommen. (Wenn zum Beispiel nicht aufgelöste Adressen zum Endgerät übermittelt werden, müssen Hilfsdaten übermittelt werden, um den Ort der nicht aufgelösten Adressen im Ladestrom anzuzeigen; wenn diese Adressen bei der Herunterladequelle aufgelöst werden, dann entfallen diese Hilfsdaten, und Speicherplatz wird gespart.) Zusammengefasst werden einige der normalerweise durch einen Bindelader ausgeführten Verschiebefunktionen in Funktionen, die bei der Herunterladequelle ausgeführt werden können, und Funktionen, die durch einen Lader im Endgerät ausgeführt werden müssen, unterteilt.
Bestimmung der Ladegrössenparameter im Headend. Der Packager bei der Herunterladequelle bestimmt, wie gross verschiedene Teile des Ladestromes sein werden, und übermittelt diese Grösseninformationen im Voraus zum Endgerät, das dann nur die minimale Menge an Speicherplatz zuzuweisen braucht, die erforderlich ist, um die Ladeoperation auszuführen. Der Lader im Endgerät kann somit fortlaufend Speicherplatz für jeden getrennten Ladestromabschnitt zuweisen, ohne zusätzlich noch verschwenderische Zwischenspeicherbereiche zuweisen zu müssen.
Wenn zum Beispiel ein Ladestrom von 400 Kilobytes von der Herunterladequelle empfangen werden soll, sind vielleicht 200 Kilobytes davon nicht modifizierbarer Code, 100 Kilobytes modifizierbare Daten und die verbleibenden 100 Kilobytes zeitweilige Symboldaten, die nach der Ladeoperation verworfen werden. (Wie herkömmlich werden Code- und Datenabschnitte typischerweise zu verschiedenen Bereichen im Speicher geleitet, so dass der Code in ROM gespeichert oder im Speicher schreibgeschützt gemacht werden kann.)
Herkömmliche Lader würden 400 Kilobytes an Speicherplatz zuweisen, um den Ladestrom zu fassen, und würden danach (nach Feststellung der vorliegenden Codemenge) einen 200-Kilobyte-Puffer zuweisen, um den Code zu halten, einen 100-Kilobyte-Puffer, um die Daten zu halten (nach Bestimmung der vorliegenden Datenmenge), sowie einen weiteren 100-Kilobyte-Puffer, um die zeitweiligen Symboldaten zu halten. Dieses herkömmliche Vorgehen verlangt doppelt so viel Speicherplatz wie letztendlich erforderlich, um das ablauffähige Image zu halten.
Während herkömmliche Lader Zugriff auf ein Plattenlaufwerk haben, um während der Ladeoperation Zwischendaten zu speichern, hat ein HCT typischerweise keine solche Platte, sondern hat sehr begrenzten Speicherplatz. Daher kann es sich das Endgerät nicht leisten, Datenzwischenspeicherbereiche während der Ladeoperation zu verwenden. Durch die Möglichkeit, im Voraus festzustellen, dass nur 200 Kilobytes an Codebereich benötigt werden, braucht das Endgerät vor dem eigentlichen Laden nur diese Menge an Platz in seinem Speicher zuzuweisen, statt 400 Kilobytes zuzuweisen und dann zu verwerfen, was nicht benötigt wurde.
Ablauffähigen Code zu einem gemeinsamen Format formatieren. In verschiedenen Ausführungsformen kann der Packager ablauffähigen Code zur Verwendung durch einen Lader in den Endgeräten in ein gemeinsames Format „destillieren". Dadurch kann der Lader in den Endgeräten möglichst einfach gehalten werden, indem Logik, die mit unterschiedlichen Codedateiformaten (COFF; ELF, PEF) arbeiten kann, zum Packager weggeladen wird. Durch Verwendung eines gemeinsamen Formats werden auch weitere Optimierungen möglich, die den Umfang des Codestromes verringern können, der über das Netz in die Endgeräte geladen werden muss.
Weitere Merkmale und Vorteile der vorliegenden Erfindung werden durch die folgende eingehende Beschreibung, die Zeichnungen und die angefügten Ansprüche klar werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt eine mögliche Konfiguration eines Heimkommunikations-Endgeräts (HCT), in das Code gemäss unterschiedlichen Aspekten der Erfindung heruntergeladen werden und darin ablaufen kann.
2 zeigt eine Folge von Stufen einschliesslich der auf jeder Stufe erzeugten Produkte, um ein Paket von ladbaren Moduln gemäss unterschiedlichen Aspekten der Erfindung zu erzeugen.
3 zeigt, wie ein Packager 303 an einer Herunterladequelle 301 einen Satz von Objektcodebefehlen 307 durch Verwendung eines Sprungtabellenmappers 308 zu einem Ladepaket umwandeln kann.
4 zeigt ein mögliches Format für ein Ladepaket 309, das gemäss unterschiedlichen Aspekten der Erfindung über ein Netz in ein Endgerät heruntergeladen werden kann.
5 zeigt ein mögliches Schema der Speicherplatzzuweisung für ein Endgerät, in dem getrennte Bereiche für Code, Daten, Sprungtabelle und zeitweilige Symbole zugewiesen werden können, um Anteile des Ladepakets von 4 zu speichern.
6 zeigt verschiedene Schritte, die ausgeführt werden können, um einen Satz von Objektcodebefehlen zu einem Ladepaket umzuwandeln, das in ein Endgerät heruntergeladen und für den Ablauf vorbereitet wird.
7A zeigt, wie ein Packager 703 einen oder mehr als einen kompilierten Objektcodemodul A, B, C zum Herunterladen über ein Netz und nachfolgendes Laden durch den Endgerätelader 705 zu einem Paket 704 kombinieren kann.
7B zeigt Einzelheiten des partiellen Verschiebeprozesses bei einer Herunterladequelle (Schritt 601 von 6), wie er durch Packager 703 ausgeführt werden kann.
7C zeigt, wie Abschnitte jeder von mehreren Eingabedateien kombiniert werden können, ehe die in 7B gezeigten Verarbeitungsschritte ausgeführt werden.
8 zeigt Einzelheiten der verbleibenden Verschiebeschritte, die in einem Endgerät ausgeführt werden können (Schritt 609 von 6), zum Beispiel durch den Endgerätelader 304 von 3.
EINGEHENDE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
1 zeigt ein Blockdiagramm eines Heimkommunikations-Endgeräts (HCT), das als ein mögliches Endgerät für das Herunterladen von Modulpaketen dienen kann. Das Endgerät kann eine CPU-Karte 100, eine Grafikkarte 101, eine Decodierkarte 102, Anzeigetafel und Tastenfeld 103, eine Hauptplatine 104, ein Frontend 105, einen Abstimmabschnitt 106 und einen Audioabschnitt 107 enthalten. Es wird in Betracht gezogen, dass die Prinzipien der Erfindung mit jeder geeigneten CPU 100a wie einem PowerPC oder der Motorola-Serie 68000, geeigneten EPROM 100c und RAM 100b umgesetzt werden können. Es wird ferner in Betracht gezogen, dass auf einer CPU 100a ablaufende Anwendungsprogramme mit verschiedenen Peripheriegeräten wie einer Maus, Spielcontrollern, Tastenfeldern, Netzschnittstellen und dergleichen in Wechselwirkung treten können, wie im Fach wohlbekannt. Ein Endgeräte-Laderprogramm kann in einem Speicher auf der CPU-Karte 100 residieren und durch CPU 100a ausgeführt werden.
2 zeigt eine Folge von Stufen einschliesslich der auf jeder Stufe erzeugten Produkte für die Erzeugung von Paketen ladefähiger Moduln bei einer Herunterladequelle gemäss unterschiedlichen Aspekten der Erfindung. Auf der Stufe 201 kann Quellencode durch einen Programmierer in einem Entwicklungssystem in einer geeigneten Programmiersprache wie C erzeugt werden. Zum Beispiel kann ein Programmierer eine neue Videospielanwendung erzeugen, die es einem Endgerätebenutzer ermöglicht, auf einem mit seinem Endgerät verbundenen Fernseher Poker zu spielen.
Auf der Stufe 202 wandelt ein Compiler wie ein herkömmlicher C-Compiler den Quellencode in eine Objektcodedatei 203 um. Im Unterschied zum herkömmlichen Vorgehen wird aber die Objektdatei nicht verknüpft und in ein ablauffähiges Bild geladen und wird auch nicht für ein nachfolgendes Verknüpfen und Laden sofort zum Endgerät übermittelt. Stattdessen wird ein Packager 205 verwendet, um Objektdatei 203 unter Verwendung von Programmressourcen 204 zu einem Paket ladefähiger Moduln mit Header 206 umzuwandeln. Die Programmressourcen 204 können ein Mapping von Symbolnamen auf Sprungtabelleneinträge in jedem Endgerät einschliessen, wie hier eingehender diskutiert werden wird.
Zum Beispiel kann der Packager 205 einen verschiebbaren Befehl im Objektcode 203 mit einem absoluten Befehl ersetzen, und zwar auf Grund der Erkenntnis, dass auf eine dem Symbol entsprechende Funktion durch eine bekannte Endgeräte-Sprungtabelleneintragung zugegriffen werden kann. wodurch die Notwendigkeit, Laderzwischendaten über das Netz zu übermitteln, vermieden wird. In den verschiedenen Ausführungsformen wird der ladefähige Modul 206 dann zum endgültigen Laden über das Netz an ein oder mehr als ein Endgerät übermittelt. Ein Paket ladefähiger Moduln kann zum Beispiel eine Bibliothek von Funktionen, einen Betriebssystempatch, eine Betriebssystemerweiterung, Systembetriebsmittel oder ein Anwendungsprogramm umfassen.
3 zeigt, wie ein Packager 303 bei einer Herunterladequelle 301 eine Objektcodedatei 307 zum Herunterladen in ein Endgerät 302 über ein Netz N wie ein Kabelfernsehnetz in ein Modulpaket 309 einschliesslich Headerfeld 309d umwandeln kann. Der Packager 303 braucht nicht physisch bei der Herunterladequelle 301 zu residieren, sondern kann stattdessen in einem Entwicklungscomputer residieren. Andere Konfigurationen der Komponenten sind natürlich möglich.
Allgemein wird ein Anwendungsprogramm oder eine andere Sammlung von Quellencode 305 unter Verwendung eines herkömmlichen Compilers 306 wie eines Compilers C oder C++ zu Objektcode 307 kompiliert. Wie in 3 illustriert, kann der Objektcode unterschiedliche Typen von Bezügen auf Befehle und Daten enthalten, die aufgelöst werden müssen, ehe sie ausgeführt werden können. Zum Beispiel kann der Objektcode 307 einen Bezug auf eine Anwendungsprogrammier-Schnittstellenroutine 307a (TV_set_chan), einen Bezug auf eine allgemeine Bibliotheksfunktion 307b (GLib_3D_Draw) und einen Bezug auf einen absoluten Speicherplatz 307c (0F62 hex) im Endgerät enthalten. Gemäss unterschiedlichen Aspekten der Erfindung wandelt der Packager 303 einige dieser nicht definierten Symbole vor der Übermittlung ans Endgerät 302 zu aufgelösten Symbolen im Modulpaket 309 um. Der Packager 303 kann diese Symbole unter Verwendung des Sprungtabellenmappers 308 auflösen, der Einträge enthält, die Symbole auf Sprungtabelleneinträge im Endgerät 302 abbilden.
Es wird in Betracht gezogen, dass das Endgerät 302 eine Sprungtabelle 310 enthält, die Einträge von Zeigern und/oder Verzweigungs-(Sprung-) befehlen umfasst. Wenn zum Beispiel ein ablauffähiges Anwendungsprogramm 313 wie ein Videospiel eine Betriebssystemfunktion aufruft, wird der Aufruf durch die Sprungtabelle 310 „gepatcht", die einen Zeiger zu dem Speicherplatz im Betriebssystem 312 enthält, wo der Code für die Funktion beginnt. Dieses Merkmal ermöglicht es, Funktionen im Betriebssystem zu ersetzen oder zu verschieben, ohne Programme zu modifizieren, die sie aufrufen. Weiter ermöglicht dieses Merkmal, dass ein Betriebssystem auf Dauer in einem ROM gespeichert wird (d. h. Funktionen werden zu Speicheradressen im ROM gepatcht), aber ermöglicht es auch, dass Änderungen in andere modifizierbare Speicherplätze „gepatcht" werden, indem die Zeiger in der Sprungtabelle 310 verändert werden.
So kann zum Beispiel die neue Version einer Betriebssystemfunktion installiert werden, indem lediglich die neue Version im modifizierbaren Speicher gespeichert und der Zeiger zur Funktion in der Sprungtabelle 310 so verändert wird, dass er nicht mehr zur ROM-Version der Funktion zeigt (d. h. die Funktion zur neueren Version in einen anderen Speicherbereich „umgeleitet" wird).
Anstelle von Zeigern zu Funktionen können wirkliche Sprung- oder Verzweigungsbefehle als Einträge in der Sprungtabelle 310 verwendet werden, um die Verarbeitung zu beschleunigen. Wenn zum Beispiel eine ablauffähige Grafikanwendung 313 auf eine Funktion Bezug nimmt, die auf Platz 164C in der Sprungtabelle 310 abgebildet ist, dann enthält der Eintrag für diesen Platz statt eines Zeigers, der geladen werden muss, und eines nachfolgenden Verzweigungsbefehls zu diesem Zeiger einen Befehl „zu X verzweigen", der direkt ausgeführt werden kann.
Noch einmal zur Arbeit des Packagers 303 in der Herunterladequelle 301 zurückkommend, werde angenommen, dass die Ausgabe des Compilers 306 den Bezug auf eine Funktion TV_set_chan enthält, die die derzeitige Kanalnummer des Endgeräts für Abstimmzwecke einstellt. Der Packager 303 findet einen entsprechenden Eintrag 308a im Sprungtabellenmapper 308, der anzeigt, dass die erforderliche Funktion (TV_set_chan) durch den Sprungtabelleneintrag 164C (hex) in der Sprungtabelle 310 im Endgerät 302 gepatcht werden kann. Entsprechend ersetzt der Packager 303 den Bezug auf das Symbol TV_set_chan im Objektcode mit einem Bezug auf den Sprungtabelleneintrag 164C. Danach ist im Endgerät 302 nach Herunterladen des Pakets keine weitere Verschiebung dieses Befehls erforderlich, wodurch Symbolraum gespart wird.
Als ein weiteres Beispiel sei angenommen, dass sich GLib_3D_Draw in einer dem Packager 303 bekannten, gemeinsam genutzten Bibliothek befindet. Der Packager 303 kann dieses Symbol GLib_3D_Draw in der Datei 307 zu einem Bezug auf das Symbol in der gemeinsam genutzten Bibliothek verändern. Er kann dies tun, indem er sich zuerst vergewissert, dass in einer Tabelle, die er zum Paket 309 hinzufügt, auf die Bibliothek mit dem Symbol Bezug genommen wird. Die Tabelle der gemeinsam genutzten Bibliotheken kann den Namen der gemeinsam genutzten Bibliothek enthalten, und die Position jedes Eintrags in der Tabelle kann als ein Index innerhalb des Symbols verwendet werden, um die gemeinsam genutzte Bibliothek anzuzeigen, auf die das Symbol Bezug nimmt. Das Symbol im Paket 309 schliesst somit einen Index in der Tabelle der gemeinsam genutzten Bibliotheken zu derjenigen gemeinsam genutzten Bibliothek ein, die den tatsächlichen Wert für GLib_3D_Draw enthält, und der Packager 303 kann die anderen relevanten Daten von der gemeinsam genutzten Bibliothek in eine Symboltabelle im Paket 309 kopieren (den Abschnitt – Daten oder Code – in dem sich GLib_3D_Draw befindet, sowie das Offset zu diesem Abschnitt). Der Endgerätelader 304 wird somit in der Lage sein, diese Daten zu verwenden, um den relevanten Abschnitt (Code oder Daten) in der gemeinsam genutzten Bibliothek aufzufinden, der in das Engerät geladen werden muss, und Bezüge im Paket auf dieses Symbol zu verschieben.
Zusätzlich zu einer „Endgeräte"-Sprungtabelle in jedem Endgerät kann mit jedem Modul dessen eigene Sprungtabelle verbunden sein, die Einträge für eine beliebige Funktion enthält, die ausserhalb des Moduls aufgerufen werden kann (d. h. sogenannte „exportierte" Funktionen). Diese Sprungtabellen können zu einer Modulsprungtabelle (MDT: module dispatch table) verkettet und zur Speicherung in jedem Endgerät in das Ladepaket einbezogen werden; jedes Endgerät kann danach die MDT herausziehen und benutzen, um auf Funktionen in Verbindung mit der Sprungtabelle des Endgeräts Bezug zu nehmen. Ein Makro kann verwendet werden, um eine Sprungtabelle für alle „exportierten" Funktionen in einem Modul zu erzeugen.
Es sollte vermerkt werden, dass der Verpackungsschritt in den Kompilierschritt kombiniert werden kann, so dass der Compiler selbst bestimmte Bezüge auflöst, wie oben erklärt. Ausserdem könnten die Kompilier- und Verpackungsschritte zu verschiedenen Zeiten oder auf verschiedenen Maschinen ausgeführt werden.
Endgerät 302 enthält den Endgerätelader 304, der das Ladepaket 309 empfängt und die Headerdaten daraus herauszieht (siehe die Diskussion von 4 unten). Zusätzlich kann Endgerät 302 eine Symbolliste 311 einschliessen, die eine Liste von Symbolen enthält, die noch aufgelöst werden müssen. Die Symbolliste 311 kann von zwei Quellen stammen: einmal aus einer statischen Liste, die in den Endgerätelader 304 kompiliert wird und auf das Betriebssystem bezogene, gänzlich aufgelöste Symbole enthalten kann; und zum anderen aus dem hereinkommenden Ladestrom. Diese Liste von Symbolen kann sich entweder auf die Symbole der gemeinsam genutzten Bibliotheken (wie oben beschrieben) oder auf Stellen innerhalb der lokalen Daten- und Codeabschnitte des Ladestromes beziehen. Die Informationen in den auf die gemeinsam genutzten Bibliotheksabschnitte bezogenen Symbolen können zusammen mit dem Anfangspunkt der Code- und Datenbereiche in diesen gemeinsam genutzten Bibliotheken verwendet werden, um Bezüge auf die Symbole in diesen gemeinsam genutzten Bibliotheken zu verschieben. Die in den lokalen Symbolen enthaltenen Informationen können zusammen mit dem Anfangspunkt der Code- und Datenbereiche, wo der Ladestrom geladen wird, verwendet werden, um Bezüge auf lokale Symbole des Ladestromes aufzulösen.
Wie in weiteren Einzelheiten unten erläutert, empfängt allgemein der Endgerätelader 304 ein Ladepaket von der Herunterladequelle 301, zieht daraus einen Header heraus, weist auf der Basis der Headerdaten getrennte Speicherbereiche zu, dekomprimiert Daten von den getrennten Speicherbereichen und löst etwelche verbleibenden, nicht aufgelösten Bezüge auf, um so einen vorbereiteten Modul wie zum Beispiel die ablauffähige Grafikanwendung 313 zu erzeugen.
4 zeigt, wie ein Paket, das in ein Endgerät geladen werden soll, als ein segmentierter Datenstrom mit vorausgehendem Header 401 übermittelt werden kann. Wenn zum Beispiel eine neue Videospielanwendung in einem vorhandenen Endgerät installiert werden soll, kann sie zu einem Paket wie dem in 4 gezeigten formatiert und in einem Datenstrom an das Endgerät übermittelt werden. Eine solche Übermittlung kann in Beantwortung einer punktuellen Anfrage erfolgen oder stattdessen unter Verwendung eines Multicast-Download-Vorgehens vorgenommen werden.
Wie in 4 illustriert, umfasst das Ladepaket bevorzugt einen Header 401, der die Grössen der verschiedenen Abschnitte anzeigt, die im Ladepaket folgen. Zum Beispiel kann der Header 401 einen Namen 401a, der den Namen des Lademoduls anzeigt, ein Feld 401b, das die Anzahl von Modulsprungtabellen-(MDT-)Einträgen anzeigt, die in das Ladepaket eingeschlossen worden sind, Berechtigungsdaten 401c, die verwendet werden können, um das Ladepaket zum Beispiel durch eine digitale Signatur zu authentifizieren, eine Grösse 401d des Codeabschnitts 401 im Ladepaket, eine Grösse 401e eines Datenabschnitts 403 im Ladepaket usw. einschliessen, wie in 4 gezeigt. Diese Grössen werden bevorzugt durch den Packager 303 als Teil des Verpackungsprozesses bestimmt und in den Header eingefügt.
Zusätzlich kann der Packager 303 bestimmte Gesamtgrössen wie die Grösse eines Pseudo-ROMs 401m (die Grösse des für den Codeabschnitt und nicht modifizierbare Ressourcen erforderlichen Festspeichers); die Grösse der Benutzerdaten 401n (die Grösse des Datenabschnitts und der modifizierbaren Ressourcen); sowie die Grösse des zeitweiligen Speichers 401o (Grösse der Symbole, der Code- und Datenverschiebungen, der Zeichenfolgetabelle, der Ressourceneinträge, der Tabelle der gemeinsam genutzten Bibliotheken) berechnen. Diese Grössen können durch den Endgerätelader 304 benutzt werden, um zu bestimmen, wieviel von jedem Speicherbereichstyp zugewiesen werden sollte.
Auf den Header 401 folgend finden sich die tatsächlichen Code-, Daten-, Symbol-, Verschiebungs- und anderen Abschnitte, wie in 4 illustriert. In unterschiedlichen Ausführungsformen kann die Modulsprungtabelle (MDT) im Datenabschnitt 403 gespeichert werden, statt einen getrennten Bereich dafür zu schaffen.
Das in 4 gezeigte Ladepaket kann komprimiert werden, um die Übermittlung über das Netz zu beschleunigen, bevorzugtermassen dadurch, dass jeder individuelle Bereich wie 402, 403 usw. komprimiert wird. Bei Empfang des in 4 gezeigten Datenstromes zieht der Endgerätelader 304 die Grössen aus dem Header 401 heraus, weist getrennte Speicherbereiche zu, um die in 4 gezeigten Bereiche zu speichern und (wahlweise) zu dekomprimieren.
5 zeigt, wie Speicherplatz in einem Endgerät wie einem HCT zugewiesen werden kann, um ein hereinkommendes Paket effizient zu laden. Wie herkömmlich kann Speicher 500 durch einen Firewall 501 unterteilt werden, der Speicheradressen, die nicht durch Benutzermoduscode modifiziert werden können (oberhalb des Firewalls 501 in 5, d. h. Speicherplatz, der nur durch Supervisormoduscode modifiziert werden kann) von Adressen trennt, die durch Benutzermoduscode modifiziert werden können (unterhalb des Firewalls 501 in 5, d. h. Speicherplatz, der durch jedes Anwendungsprogramm, das auf dem Endgerät abläuft, modifiziert werden kann).
Wie in 5 ersichtlich, ist der geschützte Speicherteil 500 oberhalb des Firewalls 501 weiter in einen Sprungtabellenbereich 502, einen Betriebssystembereich 503, einen Codebereich 504 und einen Bereich 505 für „anderes" unterteilt, der zum Beispiel geschützte Betriebssystemdaten enthalten kann. Ähnlich ist der nicht geschützte Teil des Speichers 500 unterhalb des Firewalls 501 weiter in einen Datenbereich 506, einen zeitweiligen Speicherbereich 507 und einen Bereich 508 für „anderes" unterteilt. Die kreuzweise schraffierten Bereiche in 5 zeigen Speicherbereiche an, die bereits zugewiesen worden sind und daher für eine Verwendung durch den Endgerätelader 304 nicht verfügbar sind.
Gemäss unterschiedlichen Aspekten der Erfindung empfängt der Endgerätelader 304 (siehe 3) den Header 401 (siehe 4) und zieht daraus die Grösse des Pseudo-ROM (der Festspeicherplatz für den Codeabschnitt 402 sowie für nicht modifizierbare Ressourcen von den Ressourcendaten 410 enthält), der Benutzerdaten (die modifizierbaren Speicherplatz für einen Datenabschnitt 403 und modifizierbare Ressourcen von den Ressourcendaten 410 enthalten) und des zeitweiligen Speichers heraus, der nur benutzt werden soll, während das Paket geladen wird, und danach verworfen wird (z. B. Symbolabschnitt 4Q4, Codeverschiebungsabschnitt 405, Datenverschiebungsabschnitt 406, Zeichenfolgetabelle 407, Tabelle der gemeinsam genutzten Bibliotheken 408 sowie Ressourceneinträge 409). Der Endgerätelader 304 weist danach entsprechende Speicherbereiche in den zutreffenden Firewallteilen des Speichers 500 zu. Die Abschnitte werden dann in die zutreffenden Teile der zugewiesenen Speicherbereiche eingelesen. Man bemerke, dass die Reihenfolge, in der die Abschnitte im Paket erscheinen, nicht die gleiche Reihenfolge zu sein braucht, in der sie im Speicher 500 erscheinen; wenn sie aber Stück für Stück in die Teile der zugewiesenen Speicher eingelesen werden, kann ein heruntergeladenes Programm in die richtigen Bereiche des Speichers eingelesen werden, ohne einen grossen Zwischenspeicherbereich zu verschwenden.
Zum Beispiel weist der Endgerätelader 304 Speicherplatz in den Speicherbereichen 504 und 505 für Daten vom Pseudo-ROM-Typ zu, liest den Codeabschnitt 402 in den Bereich 504 und liest jede Ressource (von 410), die durch eine entsprechende Ressourceneintragung in 409 als nicht modifizierbar gekennzeichnet ist, in den modifizierbaren Bereich 508 ein. Er weist auch den Bereich 507 zur zeitweiligen Verwendung während des Ladens zu und liest den Symbolabschnitt 404, den Codeverschiebungsabschnitt 405, den Datenverschiebungsabschnitt 406, die Zeichenfolgetabelle 407, die Tabelle der gemeinsam genutzten Bibliotheken 408 und die Resourceneinträge 409 in den Bereich 507 ein. Er weist auch Speicherplatz für die MDT aus dem Abschnitt 502 in einer durch 401b angezeigten Grösse zu und kopiert die MDT in den nicht modifizierbaren Bereich 502. Es wird bevorzugt, dass der Header im Datenstrom den Datenbereichen vorausgeht, damit der Endgerätelader 304 Speicherbereiche für die übrigen, hereinkommenden Teile des Datenstromes zuweisen kann.
In verschiedenen Ausführungsformen können der Code-, der Daten-, der Sprungtabellen- und der Bereich der verfügbaren Symbole für die Übermittlung über das Netz komprimiert werden. Entsprechend kann jeder komprimierte Bereich in den zutreffenden Speicherbereich kopiert und unter Verwendung der wohlbekannten Prinzipien „an Ort und Stelle dekomprimiert" werden. Wenn eine solche Datenkomprimierung verwendet wird, dann würden die im Header übermittelten (und im Speicher zugewiesenen) Grössen der vorerwähnten Bereiche der dekomprierten Grösse entsprechen, und die Dekomprimierung würde erfolgen, nachdem die komprimierten Bereiche in die zugewiesenen Bereiche geladen worden sind.
Das in 4 und 5 illustrierte Vorgehen liefert wichtige, Speicherplatz sparende Vorteile in jedem Endgerät. Durch Bestimmung der Grösse jedes Speicherbereichs und Übermittlung dieser Grösseninformationen am Anfang des Ladestromes braucht der Endgerätelader 304 nur die minimale Menge an getrennten Speicherbereichen zuzuweisen, die gebraucht werden, um die hereinkommenden Daten zu halten, statt einen grossen zeitweiligen Haltebereich zuzuweisen, um den gesamten hereinkommenden Datenstrom zu speichern, danach getrennte Speicherbereiche zuzuweisen, um auszupacken und den Datenstrom weiter zu verarbeiten.
6 zeigt eine Reihe von Schritten, die ausgeführt werden können, um Objektcode zum Laden in ein Endgerät in ein Modulpaket umzuwandeln. Einige oder alle von den Schritten 601 bis 605 können an einer Herunterladequelle bzw. Autorenquelle ausgeführt werden, während Schritte 606 bis 610 innerhalb eines Endgeräts wie einem HCT ausgeführt werden können.
Mit Schritt 601 beginnend, kann ein Verpackungsdienstprogramm wie der Packager 303 von 3 verwendet werden, um eine partielle Verschiebung von Objektcode in Übereinstimmung mit Programmressourcen wie einer bekannten Sprungtabelle im Endgerät vorzunehmen. Dieser Prozess wird eingehender unten beschrieben. Im Schritt 602 können die Grössen des Codes, der Daten, des Sprungtabellenbereichs und der verfügbaren Symbole im Paket auf der Grundlage der teilweisen Verschiebung berechnet werden. Im Schritt 603 kann jeder der vorerwähnten Bereiche komprimiert und im Schritt 604 zu einem Paket mit einem Header formatiert werden, der die vorerwähnten Grössen enthält. Im Schritt 605 wird das formatierte Paket mit Header über ein Netz zum Endgerät übermittelt.
Im Schritt 606 zieht das empfangende Endgerät den Header heraus und bestimmt die Speicherbereichsgrössen, die für jeden der entsprechenden Bereiche gebraucht werden. Im Schritt 607 werden getrennte Speicherbereiche in Übereinstimmung mit dem Speicherzuweisungsschema zugewiesen, das in 5 gezeigt ist. Im Schritt 608 wird jeder Bereich an Ort und Stelle dekomprimiert, wodurch der Bereich zu seiner vollen Aufnahmekapazität im Speicher expandiert wird. Zusätzlich zur Dekomprimierung kann das Endgerät eine digitale Signatur überprüfen, um sicherzustellen, dass jedes heruntergeladene Paket authentisch ist. Im Schritt 609 nimmt der Endgerätelader 304 verbleibende Verschiebungen im Endgerät vor, wie eingehender unten erklärt. Schliesslich kann im Schritt 610 die verschobene Anwendung im Endgerät ablaufen.
Der Packager 303 kann so implementiert werden, dass Benutzereingaben akzeptiert werden, um den Verpackungsprozess zu steuern. Die folgenden Arten von Befehlen können zum Beispiel verwendet werden, um die Umwandlung von Objektcode 307 in den ladefähigen Modul 309 zu steuern:

1) Erzeugen eines neuen Modulpakets und Angabe des Namens des darin enthaltenen Moduls. Der Name des Moduls braucht nicht der gleiche wie der Name seiner Modulsprungtabelle zu sein.
2) Lesen und Verarbeiten von Befehlen aus einer vorgegebenen Datei. Dadurch können zum Beispiel Bezüge auf eine Anwendungsprogrammierschnittstellen-(API: application programming interface)funktion aufgelöst werden, die im Endgerät residiert, indem eine Definitionendatei geliefert wird, die ein Mapping der Symbolnamen auf Einträge in der Modulsprungtabelle des Endgeräts enthält.
3) Hinzufügen einer Systemressource zum Modulpaket. Eine Systemressource ist etwas, das eventuell von einer Anwendung gebraucht wird, damit sie ablaufen kann, wie ein graphisches Bild oder eine digitalisierte Tondatei. Ressourcen können entweder modifizierbar oder nicht modifizierbar sein. Der Endgerätelader stellt modifizierbare Ressour cen bevorzugt in einen Lese-/Schreibspeicher, aber nicht modifizierbare Ressourcen in einen Festspeicher im Endgerät.
4) Hinzufügen eines Symbols zu einem Paket, indem der Name des Symbols und seine Systemadresse angegeben werden. Ein Symbol kann eine Prozedur, Variable, Ein-Ausgabe-Vorrichtung usw. darstellen.
5) Festlegen der Basisadresse eines Moduls. Dies kann benutzt werden, um die Adresse vorzugeben, an der der Codeabschnitt des Moduls im Endgerätespeicher geladen werden wird.
6) Hinzufügen einer oder mehr als einer Objektdatei zum Modulpaket, indem deren Dateinamen aufgeführt werden. Objektdateien können in einem von verschiedenen Formaten wie COFF, ELF oder PEF geliefert werden (jedes dieser Formate ist eine Industrienorm), und der Packager kann sie in ein gemeinsames Format umwandeln.
7) Sichern eines Modulpakets unter einem vorgegebenen Dateinamen.
8) Öffnen des in der vorgegebenen Datei gespeicherten Modulpakets. Dies kann zum Beispiel vor Hinzufügen einer Ressource zum Modulpaket verwendet werden.
9) Löschen einer Systemressource aus einem existierenden Modulpaket.
10) Löschen des Wertes eines Symbols (nicht des Symbols selbst) aus einem existierenden Modulpaket. Dadurch bleibt der Wert des Symbols undefiniert.
11) Strippen eines Modulpakets (löscht Verschiebungen und allgemeine Symbole, die nicht mehr benötigt werden). Dies ist eine Optimierung, die das Laden schneller macht und die Grösse der Modulpaketdateien verringert.
12) Verschieben (der Prozess, in dem Bezüge zwischen Code und Daten, Code und Code sowie Daten und Daten geschaffen werden). Dieser Prozess kann automatisch ausgeführt werden, nachdem Objektdateien zu einem Modulpaket hinzugefügt worden sind (siehe Befehl (6) oben). Das Verschieben kann an einem Modulpaket, das bereits verschoben worden ist, einfach dadurch wiederholt werden, dass Ablauffähige zu einem Modulpaket hinzugefügt oder daraus entfernt werden.
13) Aufzeigen nicht aufgelöster Bezüge. Dies kann verwendet werden, um Bezüge auf Dinge zu zeigen, die der Packager nicht finden konnte, um zu überprüfen, dass Symbole aufgelöst worden sind.

Andere Vorgehensweisen sind natürlich möglich, und die obigen Befehlstypen sind nicht einschränkend zu verstehen. Ein Modul könnte eine oder mehr als eine der folgenden Formen annehmen:

1) eine Bibliothek von Funktionen ähnlich einer dynamischen Verknüpfungsbibliothek (DLL: dynamic link library); diese Funktionen können durch andere Anwendungen im Endgerät aufgerufen werden.
2) ein Betriebssystempatch bzw. eine Betriebssystemerweiterung, die Ersatzcode für bereits im Betriebssystem enthaltene Funktionen enthält. Nachdem ein Patch in das Endgerät geladen worden ist, werden Zeiger zum alten Code so aktualisiert, dass sie auf den Ersatzcode zeigen.
3) eine Systemressource wie eine neue Schriftart oder ein Tonclip.
4) ein Anwendungsprogramm.

Gemäss unterschiedlichen Aspekten der Erfindung kann jedem Modul eine eindeutige Kennung zugewiesen werden, die verwendet werden kann, um den Modul im Endgerät zu „starten". Zusätzlich kann jeder Modul dem Betriebssystem im Endgerät eine Modulsprungtabelle zur Verfügung stellen, die die folgenden Informationen enthält:

1) Die Zahl der Einträge in der Sprungtabelle des Moduls. Diese kann durch den Packager bestimmt werden. Wenn ein Modul ins Endgerät geladen wird, wird seine Sprungtabelle zur Sprungtabelle des Systems hinzugefügt; wenn er herausgeladen wird, wird seine Sprungtabelle aus der Sprungtabelle des Systems herausgeladen.
2) Einen Zeiger auf die Datenfolge des Moduls. Dies schliesst Informationen über den Modul wie eine Textfolge ein, die seine Versionsnummer, seinen Autor, das Datum usw. identifiziert. Unmittelbar nach dem Datenfolgeeintrag kann die tatsächliche Sprungtabelle des Moduls selbst hereingebracht werden.
3) Einen Zeiger auf das Initialisierungsverfahren des Moduls. Dies versetzt das Endgerät in die Lage, einen Modul unmittelbar nach seiner Ladung zu initialisieren. In anderen Worten liefert der Modul einen Zeiger auf eine Routine, die bewirkt, dass sich der Modul selbst initialisiert.
4) Einen Zeiger auf das Abschaltverfahren des Moduls. Dies versetzt das Endgerät in die Lage, den Modul auszuladen und seine Sprungtabelle freizusetzen. In anderen Worten liefert der Modul einen Zeiger auf eine Routine, die, wenn sie ausgeführt wird, den Modul auslädt und seine Sprungtabelle frei setzt.

Jede Modulsprungtabelle kann Einträge für die folgenden Objekte enthalten:

1) Einen Zeiger auf die Hauptschleife der Anwendung (identifiziert den primären Eingangspunkt der Anwendung). Nachdem eine Anwendung geladen worden ist, kann ein Anwendungsmanager im Endgerät die Hauptschleife der Anwendung ausführen, um die Anwendung ablaufen zu lassen.
2) Anwendungsflags (können verwendet werden, um anzuzeigen, ob die Anwendung nur im Hintergrund abläuft und nicht aktiviert werden kann, oder keine Flags).
3) Anwendungsstapelgrösse (die Grösse des zuzuweisenden Stapels in Bytes). Kann auf einen Standardwert oder auf eine vorbestimmte Konstante festgelegt werden.
4) Anwendungspriorität (wird verwendet, um die relative Priorität derzeit laufender Anwendungen zu bestimmen).
5) Einen Zeiger auf Anwendungsressourcen (die Dinge, die eine Anwendung für ihren Ablauf braucht, wie graphische Bilder oder digitalisierte Tondateien). Wenn Ressourcen zu einem Modulpaket hinzugefügt werden, kann dieser Eintrag automatisch durch den Packager hinzugefügt werden.

7A zeigt, wie ein Packager 703 einen oder mehr als einen kompilierten Objektcodemodul A, B, C zu einem Paket 704 verarbeiten kann, um ihn über ein Netz herunterzuladen und gemäss unterschiedlichen Aspekten der Erfindung dann durch den Endgerätelader 705 zu laden. Wie oben beschrieben, können verschiedene Benutzerbefehle in den Packager 703 eingegeben werden, um den Verpackungsprozess zu steuern.
Wie herkömmlich kann jeder kompilierte Objektcodemodul unterschiedliche Abschnitte für verschiedene Datentypen enthalten. Zum Beispiel enthält Modul A in 7A einen Codeabschnitt 700a, der ablauffähige Befehle umfasst; einen Datenabschnitt 700b, der modifizierbare Datensätze umfasst; einen Codeverschiebungsabschnitt 700c, der Flags enthält, dass bestimmte Befehle im Codeabschnitt 700a „verschoben" werden müssen (d. h. eine Verzweigung zu einer unbekannten Adresse enthalten); einen Datenverschiebungsabschnitt 700d, der Flags enthält, dass bestimmte Datensätze im Datenabschnitt 700b „verschoben" werden müssen (d. h. sich auf einen unbekannten Speicherort beziehen); eine Zeichenfolgetabelle 700e und eine Symboltabelle 700f, die anzeigt, ob ein bestimmtes Symbol lokal oder extern ist. Moduln B und C enthalten ähnliche Abschnitte. Gemäss unterschiedlichen Aspekten der Erfindung „verpackt" der Packager 703 die Moduln A, B und C zu einem Paket 704, indem bestimmte Symbole und Verschiebungen vor ihrer Übermittlung über ein Netz aufgelöst werden, wodurch die Datenmenge, die übermittelt werden muss, und der Speicherplatz, der durch den Endgerätelader 705 beansprucht wird, verringert werden.
7B zeigt weitere Einzelheiten des partiellen Codeverschiebungsschrittes (Schritt 601 von 6), der durch den Packager 703 ausgeführt werden kann. Allgemein kann es vorzuziehen sein, alle Symbole zu verarbeiten, ehe eine Verschiebung ausgeführt wird.
Mit Schritt 710 beginnend wird jedes nicht definierte Symbol aus einem Objektcodemodul wie dem Modul A wiedergewonnen. Im Schritt 711 wird geprüft, um festzustellen, ob weitere Symbole in der Symboltabelle enthalten sind. Unter der Annahme, dass weitere Symbole vorhanden sind, wird Schritt 712 ausgeführt; andernfalls wird die Verarbeitung von Verschiebungseinträgen mit Schritt 717 beginnend ausgeführt.
Im Schritt 712 wird geprüft, um festzustellen, ob sich ein nicht definiertes Symbol auf eine dem Packager bekannte Betriebssystemadresse bezieht. Der Packager kann solche Kenntnis zum Beispiel über einen Benutzerbefehl erhalten, der eine Datei zur Verfügung stellt, die ein Mapping von Betriebssystemsymbolen auf Sprungtabelleneinträge in jedem Endgerät enthält. Wenn das Symbol ein bekanntes Betriebssystemsymbol ist, dann wird im Schritt 713 die Adresse des Symbols durch eine absolute Adresse ersetzt, die dem Sprungtabelleneintrag entspricht, der sich auf eine Betriebssystemroutine oder einen Datenabschnitt für dieses Symbol bezieht. Die Verarbeitung wird dann im Schritt 710 mit dem nächsten nicht definierten Symbol wieder aufgenommen.
Im Schritt 714 wird geprüft, um festzustellen, ob sich das nicht definierte Symbol auf eine dem Packager bekannte, gemeinsam genutzte Bibliothek bezieht. Der Packager kann solche Kenntnis zum Beispiel über einen Benutzerbefehl erhalten, der eine Datei zur Verfügung stellt, die ein Mapping von Namen gemeinsam genutzter Bibliotheken auf Symbole enthält. Wenn das Symbol ein Symbol einer bekannten, gemeinsam genutzten Bibliothek ist, wird das Symbol so modifiziert, dass es auf die Adresse der gemeinsam genutzten Bibliothek Bezug nimmt. Um dies zu erreichen, kann dem Paket 704 eine Tabelle hinzugefügt werden, die Daten bezüglich des Namens der gemeinsam genutzten Bibliothek enthält, und die Position jedes Eintrags in der Tabelle kann als ein Index für das Symbol verwendet werden. Der Packager kann weitere relevante Daten von der gemeinsam genutzten Bibliothek in das Paket kopieren (wie den Daten- oder Codeabschnitt, in dem sich das Symbol befindet, sowie das Offset zu diesem Abschnitt), so dass der Endgerätelader 705 die Verschiebung aller Verschiebungseinträge, die auf das Symbol Bezug nehmen, beenden kann, nachdem sie über das Netz heruntergeladen worden sind. Nach Schritt 715 wird die Verarbeitung im Schritt 710 mit dem nächsten nicht definierten Symbol wieder aufgenommen.
Wenn sich ein Symbol weder im Betriebssystem noch in einer bekannten, gemeinsam genutzten Bibliothek findet, dann kann, allgemein gesagt, das Symbol im Schritt 716 undefiniert belassen werden, und der Endgerätelader 705 kann den Symbolauflösungs prozess auf der Grundlage von Daten beenden, die in der Folge über das Netz geladen werden oder sich bereits im Endgerät befinden.
Nachdem alle nicht definierten Symbole analysiert worden sind, kann dann im Schritt 717 der Prozess der partiellen Verschiebung begonnen werden. Im Schritt 717 wird der nächste Verschiebungseintrag (Code oder Daten) aus einem Modul wiedergewonnen. Im Schritt 718 wird geprüft, um festzustellen, ob weitere zu analysierende Verschiebungseinträge vorhanden sind, und wenn das Ende aller Verschiebungseinträge erreicht worden ist, wird eine Verzweigung zu Schritt 727 gemacht.
Unter der Annahme, dass im Schritt 718 weitere Verschiebungseinträge vorhanden sind, wird dann im Schritt 719 geprüft, um festzustellen, ob sich die Verschiebung auf ein Symbol mit einer bekannten Adresse bezieht. Wenn ja, wird im Schritt 723 der Eintrag „verschoben" (d. h. die Adresse der Daten oder des Befehls, auf die Bezug genommen wird, wird in Übereinstimmung mit wohlbekannten Verfahren angepasst), und der Verschiebungseintrag wird gelöscht. Danach wird im Schritt 726 ein Bezugszähler für dieses Symbol dekrementiert und, wenn der Zähler auf null steht, das Symbol selbst aus der Symboltabelle gelöscht.
Wenn im Schritt 720 die Verschiebung eine absolute Verzweigung in den derzeitigen Modul enthält, wird im Schritt 724 der Verzweigungsbefehl zu einer relativen Verzweigung umgewandelt, und die Zieladresse wird als die Differenz zwischen der Symboladresse, auf die sich die Verschiebung bezieht, und der Adresse des Verzweigungsbefehls, der zum Symbol verzweigen wird, berechnet. Es sei zum Beispiel angenommen, dass ein bei Offset 0 × 2000 im Objektcode befindlicher Befehl eine absolute Verzweigung zu einem bei einem Offset von 0 × 3000 im Code befindlichen lokalen Symbol ist. Der Verzweigungsbefehl wird zu einer relativen Verzweigung umgewandelt, und die Zieladresse ist 0 × 1000, nämlich 0 × 3000 minus 0 × 2000. Der Verschiebungseintrag wird ebenfalls entfernt, weil er nicht mehr gebraucht wird. Danach wird im Schritt 726 eine Bezugszählung für das Symbol, auf die er sich bezieht, dekrementiert und, wenn die Zählung null ist, das Symbol selbst gelöscht.
Wenn sich im Schritt 721 die Verschiebung auf Daten oder Code bezieht, die zum Modul lokal sind, dann wird im Schritt 725 der Verschiebungseintrag so modifiziert, dass er ein Offset in den zutreffenden Code- oder Datenabschnitt sowie ein Bit enthält, das den Abschnitt (Code oder Daten) anzeigt, auf den sie sich bezieht, und das Flag wird gesetzt, um anzuzeigen, dass diese Daten existieren und kein Symbol gebraucht wird. Danach wird im Schritt 726 die entsprechende Symbolbezugszählung dekrementiert und das Symbol gelöscht, wenn die Zählung null beträgt.
Wenn eine Verschiebung keines der Kriterien in den Schritten 719, 720 oder 721 erfüllt, dann wird im Schritt 722 der Verschiebungseintrag unberührt gelassen, und die Verarbeitung wird im Schritt 717 mit dem nächsten Verschiebungseintrag wieder aufgenommen. In anderen Worten wird es dem Endgerätelader 705 überlassen, die Verschiebung nach dem Herunterladen ins Endgerät zu verschieben.
Wiederum auf Schritt 718 Bezug nehmend, werden, nachdem alle Verschiebungseinträge verarbeitet worden sind, im Schritt 727 dann die Verschiebungs- und Symbolabschnitte „kompaktiert". In anderen Worten wird Speicherplatz, der gelöschten Symbolen und Verschiebungseinträgen entspricht, entfernt, wodurch der gesamte Speicherplatz, der gebraucht wird, um verbleibende, nicht definierte Symbole oder Verschiebungseinträge im Paket 704 zu speichern, „kompaktiert" wird. Zusätzlich kann der Zeichenfolgetabellenabschnitt – der verwendet wird, um Zeichenfolgen zu speichern, die mit Symbolnamen verbunden sind – so kompaktiert werden, dass nur diejenigen Zeichenfolgen behalten werden, die für die verbleibenden Symbole erforderlich sind. Ein Ergebnis dieser Kompaktierung ist die Verringerung der Bandbreite, die benötigt wird, um Moduln A, B, C an ein Endgerät zu übermitteln, da der Packager 703 einiges von der Symbolauflösung und -verschiebung ausgeführt hat, die andernfalls durch den Endgerätelader 705 ausgeführt werden müsste. Ein zweites Ergebnis dieser Kompaktierung besteht darin, dass weniger Speicherplatz in jedem Endgerät zugewiesen werden muss, damit der Endgerätelader 705 zeitweilige Ladedaten speichern kann, d. h. nicht definierte Symbole und Verschiebungseinträge.
Im Schritt 728 wird auf der Grundlage der obigen, ausgeführten Schritte ein Header für das Paket erzeugt. Wie in 4 gezeigt, wird zum Beispiel die Grösse des aggregierten Codeabschnitts 402, die Grösse des aggregierten Datenabschnitts 403, die Grösse des Sprungtabellenabschnitts 404a und der übrigen verfügbaren Daten wie 404 bis 409 bestimmt. Diese Grössen können bestimmt werden, indem die Grössen des Codes, der Daten und anderer Bereiche aus jedem in den Packager eingegebenen Modul herausgezogen und zusammengezählt werden, wobei alle Symbole und Verschiebungen davon abgezogen werden, die im Ergebnis des oben beschriebenen, partiellen Verschiebungsprozesses gelöscht worden waren.
Ein Sprungtabellenteil jedes Pakets kann erzeugt werden, indem die für jeden Modul erzeugten Sprungtabellen unter Verwendung von Makros verkettet werden. Allgemein gesagt kann jeder Modul mit seiner eigenen Sprungtabelle verbunden sein, die Ein träge für alle Funktionen enthält, die ausserhalb des Moduls aufgerufen werden können (d. h. sogenannte „exportierte" Funktionen). Nach ihrer Verkettung können diese Sprungtabellen in jedem Endgerät in einem Festspeicher gespeichert werden, um eine Zerstörung zu verhindern. Ein Makro kann verwendet werden, um eine Sprungtabelle für alle „exportierten" Funktionen in einem Modul zu erzeugen, und diese Sprungtabelle kann im Modul anfänglich im Datenabschnitt wie 700b gespeichert werden (siehe 7A). Der Packager 703 (siehe 7A) kann jede solche Sprungtabelle auffinden, ihre Grösse als ersten Eintrag initialisieren und die Tabellen zu Sprungtabelleneinträgen zum Herunterladen zum Endgerätelader 705 zu verketten. Der Endgerätelader 705 kann die Länge der Tabelle herausziehen und die Einträge daraus in den Speicher kopieren, der mit der Betriebssystem-Sprungtabelle 310 zusammen untergebracht werden kann (siehe 3).
7C zeigt, wie Abschnitte von jeder der verschiedenen Eingabedateien kombiniert werden können, ehe die in 7B gezeigten Verarbeitungsschritte ausgeführt werden (d. h. mehrere vorkompilierte Eingabedateien können, wie in 7A gezeigt, zu einem einzigen Paket 704 kombiniert werden). Im Schritt 730 werden die entsprechenden Abschnitte von jeder Eingabedatei durch Verkettung zu einem einzigen Abschnitt kombiniert (d. h. alle Codeabschnitte werden zu einem einzigen Codeabschnitt verkettet, und alle Datenabschnitte werden zu einem einzigen Datenabschnitt verkettet usw.).
Als Nächstes werden im Schritt 731 alle in den Abschnitten enthaltenen Offsets angepasst, um die Verkettung zu berücksichtigen. So müssen alle Offsets oder Indices in der einen Datei zu anderen Abschnitten innerhalb dieser Datei angepasst werden, da sie jetzt eventuell einer vorangehenden Datei folgen. Wenn zum Beispiel die erste Datei einen Codeabschnitt mit einer Grösse von 300 Bytes besitzt, müssen alle Bezüge in der zweiten Datei zu Offsets im Codeabschnitt der zweiten Datei um 300 erhöht werden, da der Code um diesen Betrag versetzt wird, wenn er hinter dem Codeabschnitt der ersten Datei verkettet ist.
Schliesslich können im Schritt 732 alle Verschiebungseinträge, Symboltabelleneinträge und Zeichenfolgetabelleneinträge unabhängig vom Dateityp (z. B. COFF-, ELF- oder PEF-Format) zu einem gemeinsamen Format umgewandelt werden. Jedes geeignete Format kann verwendet werden; dies kann durch eine direkte Umwandlung zwischen Formaten erfolgen (d. h. das gemeinsame Format kann die gleiche semantische Information wie das gemeinsame Format enthalten, aber stattdessen ein anderes strukturelles Format verwenden). Im Falle von Eingabeformaten, die einige der Abschnitte nicht direkt enthalten, jedoch Daten enthalten, die auf diese Abschnitte schliessen lassen, wird die zutreffende Umwandlung zum gemeinsamen Format auf der Grundlage der Daten im Eingabeformat ausgeführt.
8 zeigt zusätzliche Einzelheiten der verbleibenden Codeverschiebungsschritte im Endgerät (Schritt 609 von 6), d. h. wie Endgerätelader 705 die verbleibenden Schritte ausführt, die nötig sind, um jedes heruntergeladene Paket für den Ablauf im Endgerät vorzubereiten. Mit dem Schritt 801 beginnend werden alle gemeinsam genutzten Bibliotheken, auf die im heruntergeladenen Paket Bezug genommen wird, aufgefunden und abgebildet. Allgemein gesagt kann der Endgerätelader 705 eine im heruntergeladenen Paket enthaltende Tabelle der gemeinsam genutzten Bibliotheken verwenden, die Indices auf Namen von gemeinsam genutzten Bibliotheken abbildet, um alle für das Paket erforderlichen, gemeinsam genutzten Bibliotheken zu finden, und eine neue Tabelle erstellen, die von jedem Index auf die Datenstruktur der Tabelle abbildet und Zeiger zu Code und Daten für die gemeinsam genutzte Bibliothek enthält. Wenn eine gemeinsam genutzte Bibliothek nicht gefunden wird, kann eine Warnung protokolliert werden, und die Datenstrukturadresse in der Tabelle kann auf null gesetzt werden, was anzeigt, dass die gemeinsam genutzte Bibliothek nicht vorhanden ist.
Im Schritt 802 wird der nächste Verschiebungseintrag aus dem heruntergeladenen Paket herausgezogen. Im Schritt 803 wird geprüft, um zu sehen, ob weitere zu analysierende Verschiebungseinträge vorhanden sind, und wenn das Ende des Abschnitts mit den Verschiebungseinträgen erreicht ist, springt die Verarbeitung zu Schritt 812, während die Verschiebung beendet ist.
Unter der Annahme, dass weitere zu verarbeitende Verschiebungseinträge vorhanden sind, wird im Schritt 804 geprüft, um festzustellen, ob sich die Verschiebung auf ein Symbol in einer gemeinsam genutzten Bibliothek bezieht. Wenn ja, wird im Schritt 807 der Eintrag auf der Grundlage des Ortes der gemeinsam genutzten Bibliothek verschoben, und die Verschiebung wird gelöscht. Dies kann geschehen, indem die Datenstruktur der gemeinsam genutzten Bibliothek, auf die durch den Index zum Symbol Bezug genommen wird, aufgefunden wird. Wenn die Datenstruktur der gemeinsam genutzten Bibliothek null ist (was anzeigt, dass die gemeinsam genutzte Bibliothek nicht vorhanden ist), wird die Verschiebung übersprungen. Wenn sie nicht null ist, wird die Verschiebung vorgenommen, indem die Adresse des Codes oder der Daten verwendet wird, wie sie in der Datenstruktur definiert werden, und das Offset wird im Symbol angezeigt. Danach wird die Verarbeitung im Schritt 802 wieder aufgenommen.
Wenn im Schritt 805 der Verschiebungseintrag sich auf ein Symbol in der Modulsprungtabelle (MDT) bezieht, dann wird im Schritt 808 unter Verwendung der Sprungtabelle der Bezug (Befehl oder Daten) verschoben. Der Endgerätelader 705 kann ein Mapping von Namen auf Datenstrukturen aufrecht erhalten, worin die Datenstrukturen die Sprungtabellenadresse für jedes geladene Paket enthalten. Wenn die MDT die lokale MDT für den Modul ist, kann statt der internen MDT des Moduls die derzeitige MDT verwendet werden, die durch den Endgerätelader 705 initialisiert wurde.
Wenn im Schritt 806 die Verschiebung sich auf Code oder Daten bezieht, die bezüglich des Moduls lokal sind, dann wird im Schritt 809 der Eintrag unter Verwendung herkömmlicher Verfahren verschoben, da die Adressen des Anfangs der Code- und Datenabschnitte dem Endgerätelader 705 nunmehr bekannt sind, und die Verschiebung enthält den Abschnittsanzeiger (Code oder Daten) und das Offset zum Abschnitt.
Wenn eine Verschiebung keiner der Prüfungen in den Schritten 804, 805 bzw. 806 genügt, ist die Verschiebung nicht definiert. Nachdem alle Verschiebungseinträge verarbeitet worden sind, ist die Verschiebung im Schritt 812 fertig, und der verarbeitete Modul kann (die verarbeiteten Moduln können) ablaufen.
Es ist offensichtlich, dass viele Abwandlungen und Varianten der vorliegenden Erfindung möglich sind, und Bezugnahmen auf konkrete Werte sind nur beispielhaft. Obwohl die Erfindung Anwendungen auf Kabelfernsehnetze hat, ist beabsichtigt, dass der Begriff „Netz" Satellitenübertragungsnetze, Radioübertragungsmittel und andere Kommunikationsmedien einschliesst. Der Begriff „Moduln", wie er hier verwendet wird, schliesst Anwendungsprogramme, Programmunterteile, Betriebssysteme, Patche, Datentabellen, Gruppen von interpretierbaren Befehlen und dergleichen ein.
Daher versteht es sich, dass im Rahmen der beigefügten Ansprüche die Erfindung anders als konkret beschrieben ausgeführt werden kann.

Claims

Computer-implementiertes Verfahren zum Herunterladen eines Computerprogramms in ein Heimkommunikations-Endgerät (HCT), dadurch gekennzeichnet, dass das Verfahren die Schritte umfasst: 0) auf der Grundlage von Bezügen auf Symbole, die in einer Modulsprungtabelle enthalten sind, in einem Computer zumindest einige ablauffähige Computerbefehle zu verschieben, die in einer Sammlung von Objektcode enthalten sind, und dadurch partiell verschobenen Objektcode zu erzeugen; 1) im Computer den partiell verschobenen Objektcode in ein Paket umzuwandeln, das Symbole umfasst, die auf der Grundlage einer Tabelle, die bestimmte nicht definierte Symbole im Objektcode mit bekannten Adressen im HCT korreliert, partiell aufgelöst worden sind, wobei das Paket einen Codeabschnitt, der ablauffähige Computerbefehle enthält, die auf die teilweise aufgelösten Symbole Bezug nehmen, einen vom Codeabschnitt getrennten Datenabschnitt, der modifizierbare Datenelemente enthält, einen vom Codeabschnitt und vom Datenabschnitt getrennten zeitweiligen Speicherabschnitt, der zeitweilige Daten enthält, die benötigt werden, um ablauffähige Computerbefehle im Codeabschnitt zu verschieben, sowie einen Header umfasst, der die Grössen des Codeabschnitts, des Datenabschnitts und des zeitweiligen Speicherabschnitts enthält; 2) das Paket von Schritt (1) über ein Netz zu übermitteln; 3) das im Schritt (2) übermittelte Paket im HCT zu empfangen; 4) in Übereinstimmung mit den Grössen des Codeabschnitts, des Datenabschnitts und des zeitweiligen Speicherabschnitts im Header in einem Speicher des HCT getrennte Bereiche für jeden dieser Abschnitte zuzuweisen; und 5) den Codeabschnitt, den Datenabschnitt und den zeitweiligen Speicherabschnitt vom empfangenen Paket in die zugewiesenen, getrennten Speicherbereiche zu kopieren und 6) auf der Grundlage der zeitweiligen Daten sowie auf der Grundlage von im HCT gespeicherten Daten im Paket verbleibende, nicht definierte Symbole im HCT aufzulösen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Objektcode Verschiebungseinträge enthält, deren jeder eine andernorts im Objektcode gelegene Bezugnahme auf einen nicht definierten Speicherplatz anzeigt, wobei das Verfahren weiter die dem Schritt (2) vorausgehenden Schritte umfasst: a) auf der Grundlage eines der Verschiebungseinträge und eines im Schritt (1) aufgelösten Symbols eine oder mehr als eine Bezugnahme zu dem nicht definierten Speicherplatz zu verschieben; b) den Verschiebungseintrag aus dem Objektcode zu löschen; und c) die verschobenen Bezüge auf den nicht definierten Speicherplatz im Paket zu speichern; und dadurch, dass Schritt (6) den Schritt umfasst, auf der Grundlage von im HCT gespeicherten Daten verbleibende Verschiebungseinträge im Paket aufzulösen.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass Schritt (a) den Schritt umfasst, einen absoluten Speicherbezug durch einen relativen Speicherbezug zu ersetzen.
Verfahren nach Anspruch 1, weiter den dem Schritt (1) vorausgehenden Schritt umfassend, entsprechende Code- und Datenabschnitte aus getrennt kompilierten Moduln im Objektcode zu verketten.
Verfahren nach Anspruch 1, weiter die dem Schritt (6) vorausgehenden Schritte umfassend, 7) in einem geschützten Teil des Speichers im HCT einen der Grösse des nicht modifizierbaren Codeabschnitts entsprechenden ersten Speicherbereich zuzuweisen und in einem nicht geschützten Teil des Speichers im HCT einen der Grösse des modifizierbaren Datenbereichs entsprechenden zweiten Speicherbereich zuzuweisen; und 8) den nicht modifizierbaren Codeabschnitt vom empfangenen Paket im geschützten Teil des Speichers zu speichern und den modifizierbaren Datenabschnitt vom empfangenen Paket im nicht geschützten Teil des Speichers zu speichern.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass Schritt (8) den Schritt umfasst, den nicht modifizierbaren Codeabschnitt und den modifizierbaren Datenabschnitt in einem Speicher zu speichern, der bereits zumindest ein früher geladenes Anwendungsprogramm enthält.
Verfahren nach Anspruch 1, weiter den Schritt umfassend, den Codeabschnitt und/oder den Datenabschnitt und/oder den zeitweiligen Speicherabschnitt in den zugewiesenen, getrennten Speicherbereichen zu dekomprimieren.
Verfahren nach Anspruch 1, weiter den Schritt umfassend, einen oder mehr als einen der aus dem empfangenen Paket kopierten, ablauffähigen Computerbefehle zu verschieben.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der Verschiebungsschritt den Schritt umfasst, auf der Grundlage von Bezügen auf in einer Modulsprungtabelle enthaltene Symbole den einen oder mehr als einen ablauffähigen Computerbefehl zu verschieben.
Verfahren nach Anspruch 1, weiter den dem Schritt (1) vorausgehenden Schritt umfassend, auf der Grundlage von Bezügen auf in einer Modulsprungtabelle enthaltene Symbole den einen oder mehr als einen ablauffähigen Computerbefehl zu verschieben.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Schritt (5) den Schritt umfasst, den Codeabschnitt in einen Speicherbereich zu kopieren, der gegen eine Modifizierung geschützt ist, und den zeitweiligen Speicherabschnitt in einen Speicherbereich zu kopieren, der modifiziert werden kann.
Endgerät (302), dafür geeignet, Daten aus einem Abonnentenfernsehnetz zu empfangen, und umfassend: einen Speicher, der in einen ersten Bereich, der Speicherplätze umfasst, die gegenüber einer Modifizierung geschützt sind, und in einen zweiten Bereich, der Speicherplätze umfasst, die gegenüber einer Modifizierung nicht geschützt sind, unterteilt ist; Mittel, um aus dem Netz Objektcode (307) zu empfangen, der zu einem Paket (309) umgewandelt worden ist, das Symbole umfasst, die auf der Grundlage einer Tabelle (308), die bestimmte nicht definierte Symbole im Objektcode mit bekannten Adressen im Endgerät korreliert, partiell aufgelöst worden sind, wobei das Paket einen Codeabschnitt, der ablauffähige Compterbefehle enthält, die auf die teilweise aufgelösten Symbole Bezug nehmen, einen vom Codeabschnitt getrennten Datenabschnitt, der modifizierbare Datenelemente enthält, einen vom Codeabschnitt und vom Datenabschnitt getrennten zeitweiligen Speicherabschnitt, der zeitweilige Daten enthält, die benötigt werden, um ablauffähige Computerbefehle im Codeabschnitt zu verschieben, sowie einen Header (309d) umfasst, der die Grössen des Codeabschnitts, des Datenabschnitts und des zeitweiligen Speicherabschnitts enthält; Mittel, um auf der Grundlage von aus dem Header herausgezogenen Grössen einen Teil des ersten Bereichs für die Speicherung des Codeabschnitts und einen Teil des zweiten Bereichs für die Speicherung des Datenabschnitts und des zeitweiligen Speicherabschnitts zuzuweisen; und Mittel, um den Codeabschnitt in den ersten Bereich zu kopieren und den Datenabschnitt sowie den zeitweiligen Speicherabschnitt in den zweiten Bereich zu kopieren; und Mittel, um auf der Grundlage der zeitweiligen Daten und auf der Grundlage von im Endgerät gespeicherten Daten verbleibende, nicht definierte Symbole im Paket im Endgerät aufzulösen, dadurch gekennzeichnet, dass der Speicher weiter eine Sprungtabelle (310) umfasst, die Bezüge auf einen oder mehr als einen ablauffähigen Computerbefehl im Codeabschnitt auf Teile eines im Endgerät ablaufenden Betriebssystems (312) abbildet.
Endgerät nach Anspruch 12, weiter Mittel umfassend, um auf der Grundlage von im zeitweiligen Speicherabschnitt enthaltenen Daten einen oder mehr als einen ablauffähigen Computerbefehl im Codeabschnitt zu verschieben.
Endgerät nach Anspruch 12, dadurch gekennzeichnet, dass der ablauffähige Codeabschnitt Befehle umfasst, die auf der Grundlage einer Kenntnis der Sprungtabelle vor der Übermittlung über das Netz verschoben worden sind.
Endgerät nach Anspruch 12, dadurch gekennzeichnet, dass der Codeabschnitt, der Datenabschnitt und der zeitweilige Speicherabschnitt sämtlich komprimiert sind, und dadurch, dass das Endgerät jeden Abschnitt dekomprimiert, nachdem er in die betreffenden Speicherbereiche kopiert worden ist.
Endgerät nach Anspruch 12, dadurch gekennzeichnet, dass das Endgerät eine im Paket enthaltene Tabelle gemeinsam genutzter Bibliotheken verwendet, um einen oder mehr als einen ablauffähigen Computerbefehl zu verschieben, und einen entsprechenden Verschiebungseintrag im zeitweiligen Speicherbereich löscht.
System zur Übermittlung von Computercode an ein Abonnentenfernseh-Endgerät (302), wobei das System zumindest einen an ein Netz angeschlossenen Computer (301) umfasst und der Computer programmiert ist, um die Schritte auszuführen: 1) Quellencode zu Objektcode (307) zu kompilieren, wobei der Objektcode nicht definierte Symbole und ablauffähige Befehle umfasst, die im Abonnentenfernseh-Endgerät ausgeführt werden können; 2) den Objektcode in ein Modulpaket (309) zu verpacken, indem einige, aber nicht sämtliche der nicht definierten Symbole im Objektcode auf der Grundlage einer Tabelle (308) aufgelöst werden, die bestimmte nicht definierte Symbole mit bekannten Adressen im Abonnentenfernseh-Endgerät korreliert, wobei das Modulpaket einen Codeabschnitt, der Compterbefehle enthält, die auf teilweise aufgelöste Symbole Bezug nehmen, einen Datenabschnitt, der modifizierbare Datenwerte enthält, einen vom Codeabschnitt und vom Datenabschnitt getrennten zeitweiligen Speicherabschnitt, der zeitweilige Daten enthält, die benötigt werden, um ablauffähige Computerbefehle im Codeabschnitt zu verschieben, sowie einen Header (309d) umfasst, der die Grössen des Codeabschnitts, des Datenabschnitts und des zeitweiligen Speicherabschnitts anzeigt; und 3) das Modulpaket über das Netz zum Abonnentenfernseh-Endgerät zu übermitteln.
System nach Anspruch 17, dadurch gekennzeichnet, dass der Computer dafür programmiert ist, auf der Grundlage der Erkenntnis, dass auf eine dem Symbol entsprechende Funktion durch einen bekannten Endgeräte-Sprungtabelleneintrag im Abonnentenfernseh-Endgerät zugegriffen werden kann, einen verschiebbaren Befehl durch einen absoluten Befehl zu ersetzen.
System nach Anspruch 17, dadurch gekennzeichnet, dass das Modulpaket ein Anwendungsprogramm umfasst.
System nach Anspruch 17, dadurch gekennzeichnet, dass das Netz ein verkabeltes Abonnenten-Kabelfernsehnetz umfasst.
System nach Anspruch 17, dadurch gekennzeichnet, dass das Netz ein Satellitenübertragungsnetz umfasst.
Endgerät nach Anspruch 12, dadurch gekennzeichnet, dass das Endgerät ein Abonnentenfernseh-Endgerät ist, das dafür eingerichtet ist, von einer Herunterladequelle über ein Abonnentenfernsehnetz ein Paket zu empfangen, das aufgelöste und nicht aufgelöste Symbole enthält, und das weiter umfasst: eine zentrale Verarbeitungseinheit, die von der Herunterladequelle empfangene Befehle ausführt; und dadurch, dass die zentrale Verarbeitungseinheit und der Speicher mit einer Endgeräteladerfunktion programmiert sind, die die Schritte ausführt: 1) das Paket, das aufgelöste und nicht aufgelöste Symbole umfasst, über das Abonnentenfernsehnetz von der Herunterladequelle zu empfangen; 2) einen ersten Speicherblock im ersten Bereich zuzuweisen, um einen Codeabschntt aus dem Paket zu speichern, und einen zweiten Speicherblock im zweiten Bereich zuzuweisen, um einen Datenabschnitt und einen vom Code- und Datenabschnitt getrennten, zeitweiligen Speicherabschnitt zu speichern, der zeitweilige Daten enthält, die benötigt werden, um ablauffähige Computerbefehle aus dem Paket im Codeabschnitt zu verschieben, wobei beide Zuweisungen auf der Grundlage der Grössen des Codes, der Daten und der zeitweiligen Daten erfolgen, die in Verbindung mit dem Paket übermittelt werden; 3) den Codeabschnitt in den ersten Bereich und den Datenabschnitt und den zeitweiligen Speicherabschnitt in den zweiten Bereich zu kopieren; und 4) auf der Grundlage der im Paket enthaltenen zeitweiligen Daten nicht aufgelöste Symbole im Paket aufzulösen.
Abonnentenfernseh-Endgerät nach Anspruch 22, dadurch gekennzeichnet, dass der Speicher eine Sprungtabelle umfasst, die Bezüge in einem oder mehr als einem Befehl im Codeabschnitt auf Teile eines Betriebssystems abbildet, das im Endgerät abläuft.