DE19681256C2

DE19681256C2 - Ausführung von Anwendungen am Platz vom Speicher

Info

Publication number: DE19681256C2
Application number: DE19681256T
Authority: DE
Inventors: John Garney; Clifton W Laney
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1995-02-27
Filing date: 1996-02-12
Publication date: 2000-02-03
Anticipated expiration: 2016-02-13
Also published as: GB2314182B; US5581768A; AU4986096A; WO1996027158A1; GB9715969D0; HK1006788A1; DE19681256T1; GB2314182A

Description

Die vorliegende Erfindung betrifft ein Computersystem bzw. ein Verfahren zum Erzeugen bzw. zum Ausführen eines aus einem Nur-Lese-Speicher ausführbaren Programms.

Computeranwendungsprogramme (im folgenden Anwendung ge nannt) werden üblicherweise für die Ausführung aus einem Speicher mit wahlfreiem Zugriff (RAM) geschrieben und kompi liert, gegenüber welchem sowohl Schreiboperationen als auch Leseoperationen ausgeführt werden können. Diese "RAM-ge stützten" Anwendungen werden außerdem üblicherweise so ge schrieben, daß sie "verschiebbar" sind, d. h. von jedem Spei cherort aus ausführbar sind, wodurch sie es ermöglichen, daß der Speicher zu verschiedenen Zeiten für verschiedene Anwen dungen wiederverwendet werden kann und wodurch eine maximale Flexibilität bei der Zuordnung des Speichers zu Anwendungs programmen geschaffen wird. Aus diesem Grund werden Spei cherreferenzen einer "verschiebbaren" und "RAM-gestützten" Computeranwendung zur Ladezeit dynamisch aufgelöst, da ihre genauen Orte zur Kompilierzeit nicht garantiert werden kön nen.

Speicherreferenzen in einer Anwendung können im allge meinen in zwei Kategorien eingeteilt werden; es gibt Spei cherreferenzen zu Speicherorten innerhalb der Anwendung selbst, d. h. interne Referenzen, oder Speicherreferenzen zu Speicherorten außerhalb der Anwendung, d. h. externe Referen zen. Zu den besonderen Beispielen für interne Referenzen ge hören Funktionsaufrufe, die Segmentgrenzen einer segmentier ten Anwendung überschreiten. Zu den besonderen Beispielen für externe Referenzen gehören Aufrufe zu Funktionen, die von dem Betriebssystem oder der Umgebung zur Verfügung ge stellt werden. Die relativen Orte dieser Speicherreferenzen (innerhalb der Anwendung), die auch als "Korrektur- bzw. Patch-Stellen" bekannt sind, sind üblicherweise als Teil der "Verschiebungsinformationen" der Anwendung gekennzeichnet und in diesen enthalten.

Wenn die Anwendung zur Vorbereitung der Ausführung in den RAM geladen wird, verwendet das Anwendungsladeprogramm sein Wissen über die zugeordneten Speicherorte der Anwen dung, die relativen Orte der "Patch-Stellen" und die Spei cherorte der Eingangspunkte der externen Funktionen, um die geeigneten Referenzwerte zu bestimmen oder "aufzulösen", die in dem Anwendungscode enthalten sein sollten. Das Ladepro gramm "korrigiert" oder "berichtigt" dann die Anwendung, in dem es die aufgelösten Referenzwerte in die "Patch-Stellen" der geladenen Anwendung schreibt.

Da in "Schreib-Einmal"-Speicher, wie z. B. Nur-Lese-Spei cher (ROM), und "Schreib-Selten"-Speicher, wie z. B. EPROM oder Flash-Speicher, nicht oder nicht "leicht" geschrieben werden kann, können übliche, in der oben beschriebenen Weise entwickelte Programme nicht "berichtigt" werden, wenn sie in diesen "Schreib-Einmal/Selten"-Speichern gespeichert sind und müssen am Platz ausgeführt werden bzw. "executed in place" (XIP). Traditionsgemäß müssen daher alle XIP-Anwen dungen speziell geschrieben werden, um sicherzustellen, daß es zur Zeit, wenn sie (d. h. das absolute Codeabbild) in dem "Schreib-Einmal/Selten"-Speicher gespeichert werden, keine unaufgelösten Referenzen gibt. In der Praxis ist dies für jede komplexe Folge von Anwendungen ein extrem komplexes Projekt, insbesondere wenn externe Verbindungsbibliotheken beteiligt sind.

Historisch bedingt waren die meisten XIP-Anwendungen au ßerdem für eingebettete Anwendungen entwickelt worden. Auf grund der Vorgaben der eingebetteten Umgebungen verwenden XIP-Anwendungen gewöhnlich Überlagerungen. Außerdem wird zu jedem Zeitpunkt nur eine XIP-Anwendung ausgeführt; mit ande ren Worten, es findet kein Multitasking von XIP-Anwendungen statt.

Mit dem Aufkommen der tragbaren Rechner und der Perso nalcomputer-Memory-Card-International-Association(PCMCIA)- Karten gibt es ein erneutes Interesse an XIP-Anwendungen. Wenn Anwendungen vom ROM, Flash-Speicher, PCMCIA-Karten oder dgl. am Platz ausgeführt werden können, bedeutet dies, daß weniger RAM und/oder Plattenspeicher zur Verfügung gestellt werden, wobei dies zu einer Verringerung der Größe und/oder des Gewichtes eines Notizbuchcomputers führen würde. Es ist besonders wünschenswert, daß neue XIP-Anwen dungen "leicht" entwickelt werden können und daß die große Anzahl existierender "RAM-gestützter" Anwendungen automa tisch für die Ausführung am Platz "konvertiert" werden kann, so daß sie nicht neu geschrieben zu werden braucht. Außerdem ist es wünschenswert, daß bei XIP-Anwendungen genau wie bei "RAM-gestützten" Anwendungen Multitasking möglich ist.

Es ist wenigstens ein früherer Versuch bekannt, Anwen dungen am Platz vom ROM für eine. Reihe von nun nicht mehr existierenden tragbaren Computern auszuführen. Jedoch ähnel ten diese XIP-Anwendungen den traditionellen eingebetteten XIP-Anwendungen, d. h. sie waren unter Verwendung von Überla gerungen und ohne unaufgelöste Anwendungen speziell ge schrieben. Außerdem mußten die XIP-Anwendungen ihr eigenes Speichermanagement zur Verfügung stellen, einschließlich dem Ein- und Auslagern der geeigneten Speicherbereiche in den und aus dem Adreßraum des Prozessors.

Nachfolgend wurde eine PCMCIA-Standardanwendungs-Pro grammierschnittstelle bzw. "standard application programming interface" (API) für XIP-Anwendungen entwickelt (vgl.: PCMCIA Standards, Release 2.01, Release Records, November 1992, Personal Computer Memory Card International Associa tion, Abschnitt 6. "Execute In Place (XIP)"). Sie ähnelte demjenigen, was auf der nun nicht mehr existierenden Reihe von Notizbuchcomputern geschah darin, daß die XIP-Anwendun gen unter Verwendung von Überlagerungen und ohne jegliche unaufgelösten Verschiebungsreferenzen speziell geschrieben werden mußten. Jedoch vereinheitlichte und unterstützte die PCMCIA-API das benötigte Speichermanagement, wobei den XIP- Anwendungen das Anbieten ihres eigenen Speichermanagements abgenommen wurde. Die Speichermanagementunterstützung ent spricht derjenigen von Erweiterungsspeichern (EMS) bei Per sonalcomputern.

Es wird eine Lösung benötigt, die es konventionell ent wickelten "RAM-gestützten" Anwendungen ermöglicht, am Platz in "Schreib-Einmal/Selten"-Speichern, d. h. ROM, EPROM, EE PROM, Flash-Speicher usw., in der oben beschriebenen ge wünschten Weise gespeichert und ausgeführt werden zu können.

Diese Aufgabe wird erfindungsgemäß durch ein Computersy stem mit den Merkmalen des Anspruchs 1 bzw. mit den Merkma len des Anspruchs 10 bzw. durch ein Verfahren mit den Merk malen des Anspruchs 22 oder denen des Anspruchs 25 gelöst.

Die gewünschten Ergebnisse werden vorteilhafterweise da durch erzielt, daß eine Anzahl neuer Dienstprogramm- und Laufzeitfunktionen einem ansonsten konventionellen Betriebs system eines Computersystems zur Verfügung gestellt werden, das einen virtuellen Speicher und Multitasking unterstützt. Zu diesen neuen Dienstprogramm- und Laufzeitfunktionen gehö ren neue Binde-, Installations-, Speichermanagement-, Lade- und Taskmanagementfunktionen. Die neue Bindefunktion wird dazu verwendet, um unaufgelöste Referenzen einer konventio nellen "RAM-gestützten" Anwendung zum Teil aufzulösen, so daß die zum Teil aufgelöste Anwendung zusammen mit den neuen Laufzeitfunktionen aus einem "Schreib-Einmal/Selten"-Spei chermedium am Platz ausgeführt werden kann. Die neue In stallationsfunktion wird verwendet, um die zum Teil aufgelö ste Anwendung in einem "Schreib-Selten"-Speichermedium zu installieren. Die neue Speichermanagementfunktion wird ver wendet, um einen vorgegebenen Abschnitt der Speichermanage mentdatenstruktur des Betriebssystems für die "Abbildung" des (der) physischen Adreßbereichs (-bereiche) einer instal lierten Anwendung in einen logischen Adreßraum zu reservie ren, wodurch der "abgebildeten" Anwendung eine Ausführung am Platz ermöglicht wird. Die neue Ladefunktion wird verwendet, um ein Pseudoladen einer XIP-Anwendung durchzuführen und die Ausführung einer XIP-Anwendung zu beginnen. Die neue Taskma nagementfunktion wird verwendet, um eine gemeinsame Nutzung des vorgegebenen Bereichs der Speichermanagementdatenstruk tur des Betriebssystems durch mehrere XIP-Anwendungen zu er leichtern, wodurch von dem Betriebssystem ein Multitasking der XIP-Anwendungen sowie der Nicht-XIP-Anwendungen oder konventionellen "RAM-gestützten" Anwendungen ermöglicht wird.

Die neue Bindefunktion liest die ausführbare Datei einer konventionellen "RAM-gestützten" Anwendung und löst zum Teil externe sowie interne Referenzen mit Hilfe eines vorgegebe nen Abschnitts der Speichermanagementdatenstruktur des Be triebssystems auf, der zur Zeit der Systeminitialisierung reservierbar ist, so daß diese zum Teil aufgelösten Referen zen zur Ausführungszeit vollständig aufgelöst werden können, indem der reservierte vorgegebene Abschnitt der Speicher managementdatenstruktur des Betriebssystems mit der richti gen physischen Adresse berichtigt wird. Außerdem struktu riert die neue Bindefunktion einige externe Referenzen in indirekte externe Referenzen über einen R/W-Datenbereich um. Die neue Bindefunktion berichtigt außerdem verschiedene Informationstabellen in der ausführbaren Datei und regene riert die ausführbare Datei. Die neue Installationsfunktion installiert die regenerierte ausführbare Datei auf einem "Schreib-Selten"-Medium, wobei die strukturellen gegenseiti gen Abhängigkeiten, d. h. örtliche Beziehungen der verschie denen Teile der regenerierten ausführbaren Datei, erhalten bleiben.

Die neue Speichermanagementfunktion reserviert den vor gegebenen Abschnitt der Speichermanagementdatenstruktur des Betriebssystems, indem sie veranlaßt, daß dieser zur System initialisierungszeit der neuen Speichermanagementfunktion zugeordnet wird. Die neue Ladefunktion führt eine Pseudo ladung einer installierten Anwendung durch, indem sie veran laßt, daß RAM dem R/W-Datenbereich der Anwendung zugeordnet wird, und indem der vorab zugeordnete, vorgegebene Abschnitt der Speichermanagementdatenstruktur des Betriebssystems mit den richtigen physischen Adressen berichtigt wird. Die neue Ladefunktion informiert außerdem die neue Taskmanagement funktion über jede neu "geladene" XIP-Anwendung.

Zur Systeminitialisierungszeit erzeugt die neue Taskma nagementfunktion eine private XIP-Taskmanagementdatenstruk tur für XIP-Anwendungen. Als Antwort auf jeden Hinweis auf eine neue XIP-Anwendung von der neuen Ladefunktion erzeugt die neue Taskmanagementfunktion für die neu "geladene" XIP- Anwendung ein neues XIP-Taskmanagementdatenelement in der XIP-Taskmanagementdatenstruktur. Jedes XIP-Taskmanagement datenelement enthält die Berichtigungsdaten für den vorab zugeordneten, vorgegebenen Abschnitt der Speichermanagement datenstruktur des Betriebssystems, einschließlich Daten, um eine ausgewählte Untermenge des vorab zugeordneten, vorgege benen Abschnitts mit einer geeigneten Untermenge des dyna misch zugeordneten Abschnitts der Speichermanagementdaten struktur des Betriebssystems in Verbindung zu bringen. Au ßerdem verwaltet die neue Taskmanagementfunktion aktuelle XIP-Taskinformationen. Wird dem neuen Taskmanagement von dem Betriebssystem ein Taskwechsel mitgeteilt, bestimmt es, ob eine XIP-Anwendung beteiligt ist. Wenn eine XIP-Anwendung beteiligt ist, lagert die neue Taskmanagementfunktion die richtigen Berichtigungsspeichermanagementdaten in den vorab zugeordneten, vorgegebenen Bereich der Speichermanagementda tenstruktur ein und aktualisiert dementsprechend die aktuel len XIP-Taskinformationen.

Bei einigen Ausführungsbeispielen sind die neuen Binde- und Installationsfunktionen als eigenständige Dienstprogram me ausgeführt, während die neuen Speichermanagement-, Lade- und Taskmanagementfunktionen ebenfalls als eigenständige "Erweiterungen" des Betriebssystems ausgeführt sind. Bei an deren Ausführungsbeispielen können die neuen Binde-, Spei chermanagement-, Lade- und Taskmanagementfunktionen als in tegraler Bestandteil der entsprechenden Teile des Betriebs systems ausgeführt sein.

Bei einem "eigenständiges Programm/Erweiterung"-Ausfüh rungsbeispiel, welches für die WindowsTM-Betriebssystemumge bung entwickelt wurde (Windows ist eine Marke der Microsoft Corporation aus Redmond, Washington), sind die neuen Binde- und Installationsfunktionen mit zwei eigenständigen ausführ baren Programmen (EXEs), XIP_Linker bzw. XIP-Binder und XIP_Installer bzw. XIP-Installierer, ausgeführt, während die neuen Speichermanagement-, Lade- und Taskmanagementfunktio nen zusammen mit einem dynamischen Verbindungsbiblio thek(DLL)-XIP_Loader bzw. -XIP-Lader und einem virtuellen Gerätetreiber(VxD)-XIP_Mgmt bzw. -XIP-Management implemen tiert sind.

Der XIP_Linker löst externe sowie interne Referenzen ei ner ansonsten konventionellen Windows^TM-Anwendung zu einem vorgegebenen Bereich von Segmentselektoren zum Teil auf, wo durch es ermöglicht wird, daß diese teilweise aufgelösten Referenzen zur Ausführungszeit vollständig aufgelöst werden, indem die zugehörigen Segmentdeskriptoren mit den geeigneten physischen Adressen berichtigt werden. Bei externen Referen zen unter Beteiligung von FAR CALLs bzw. FERN-AUFRUFEN strukturiert der XIP_Linker ferner die externen Referenzen in indirekte externe Referenzen über das automatische R/W- Datensegment der Anwendung um. Der XIP_Linker fügt außerdem ein selbstladenes Segment mit einer komplementären Aufruflo gik zum Aufrufen von XIP_Loader ein, bevor die verschiedenen Informationstabellen berichtigt werden und die ausführbare Datei regeneriert wird. Der XIP_Installer installiert die regenerierte ausführbare Datei auf einem "Schreib-Selten"- Speichermedium, wobei die relativen Orte der Segmente erhalten bleiben.

Zur Systeminitialisierungszeit ordnet das XIP_Mgmt vorab mit dem Kernprogramm bzw. Kernel von Windows den vorgegebe nen Bereich von Segmentselektoren zu und erzeugt eine Task managementstruktur. Zur "Lade"-Zeit einer XIP-Anwendung wird das selbstladende Segment der XIP-Anwendung geladen und ihm wird die Steuerung vom Windows-Ladeprogramm übergeben. Das selbstladene Segment wiederum gibt die Ausführungssteuerung an den XIP_Loader. Bei Empfang der Steuerung aktualisiert der XIP_Loader die Modultabelle der XIP-Anwendung, wobei die vorab zugeordneten, vorgegebenen Segmentselektoren mit den physischen Adressen des "Schreib-Einmal/Selten"-Mediums be richtigt werden, veranlaßt das Windows-Ladeprogramm RAM für das (die) automatische(n) R/W-Datensegment(e) der geladenen XIP-Anwendung zuzuordnen, wobei die XIP-Anwendung pseudoge laden wird. Beim "Laden" der XIP-Anwendung ruft der XIP_Loader außerdem das XIP_Mgmt auf.

Das XIP_Mgmt erzeugt beim Aufruf ein XIP-Taskmanagement datenelement in der XIP-Taskmanagementdatenstruktur für die XIP-Anwendung. Das XIP-Taskmanagementdatenelement enthält alle Berichtigungsdaten für die Segmentdeskriptoren des vorab zugeordneten, vorgegebenen Bereichs von Segmentselek toren, einschließlich Daten, um einige der vorab zugeordne ten Segmentselektoren und einige der dynamisch zugeordneten Segmentselektoren miteinander zu verbinden. Zur Zeit der Taskinitialisierung und des Taskwechsels einer XIP-Anwendung lagert das XIP_Mgmt die richtige Menge von Segmentselektor berichtigungen für die aktuelle XIP-Task in den Segmentdes kriptoren des vorab zugeordneten, vorgegebenen Bereichs von Segmentselektoren ein. Das XIP_Mgmt verfolgt außerdem, wel che XIP-Anwendung die aktuelle XIP-Task ist. Zur Taskab schlußzeit löscht das XIP_Mgmt das Taskmanagementdatenele ment der endenden XIP-Task. Das XIP_Mgmt wird über einen Taskstart, einen Taskwechsel und ein Taskende vom XIP_Loader informiert, der sich wiederum auf TOOLHELP.DLL von Windows^TM verläßt, um informiert zu werden.

Außerdem ist eine dritte Windows^TM-EXE XIP_Init, vorge sehen, um bestimmte einmalige Betriebscharakteristiken von Windows^TM zu adressieren. Der XIP_Init wird verwendet, um ein Blind-Modul bzw. Dummy-Modul unter Verwendung eines Blindsegmentes zu erzeugen und um alle zugehörigen Segment deskriptoren des vorab zugeordneten, vorgegebenen Bereichs von Segmentselektoren zu berichtigen, damit sie unter Ver wendung von XIP_Mgmt zur Systemstartzeit auf das Blindseg ment zeigen. Der XIP_Init ist in den während des Starts von Windows^TM ausgeführten Programme als Teil enthalten. Zusätz lich wird der XIP_Init zur Berichtigung von absichtlich er zeugten "bedeutungsvollen fehlerhaften Zeigern" verwendet, wenn von einer laufenden XIP-Anwendung auf sie verwiesen wird.

Schließlich ist eine Windows^TM-COM, Card_Mapper bzw. Karten-Abbilder, zur Ergänzung von Windows^TM vorgesehen, um eine eingefügte PCMCIA-Karte in einen oder mehrere vorgege bene Bereiche von physischen Adressen zur Zeit der Einfügung der PCMCIA-Karte abzubilden.

Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen gekennzeichnet.

Im folgenden wird die Erfindung anhand von Ausführungs beispielen näher beschrieben, die anhand der beigefügten Zeichnung erläutert werden, in der gleiche Bezugszeichen ähnliche Elemente bezeichnen, und in der:

Fig. 1 ein beispielhaftes Computersystem zeigt;

Fig. 2 die Abbildung von E/A-Einheiten in den physischen Adreßraum zeigt, und die Abbildung von logischen Adreßräumen in den physischen Adreßraum, die von dem beispielhaften Com putersystem gemäß Fig. 1 unterstützt werden;

Fig. 3a-3b zeigen verschiebene Aspekte des Segmentie rungsspeichermanagements, das von dem beispielhaften Compu tersystem gemäß Fig. 1 unterstützt wird;

Fig. 4 zeigt die wichtigsten Softwarekomponenten des beispielhaften Computersystems gemäß Fig. 1;

Fig. 5a-5b zeigen die Dienstprogramm- und Kernel- bzw. Kernerweiterungen der vorliegenden Erfindung detaillierter;

Fig. 6a-6g zeigen ein Ausführungsbeispiel der Dienstpro grammerweiterungen zur Unterstützung von für Windows^TM ent wickelten XIP-Anwendungen detaillierter;

Fig. 7a-7d zeigen ein Ausführungsbeispiel der für Windo ws^TM entwickelten Kernelerweiterungen zur Unterstützung von XIP-Anwendungen detaillierter;

Fig. 8 zeigt die von einem Ausführungsbeispiel eines XIP-Binders ausgeführten Schritte des Umstrukturierens und der teilweisen Auflösung von Speicherreferenzen einer anson sten konventionellen "RAM-gestützten" Anwendung;

Fig. 9 zeigt den Schritt "analysiere und zeichne auf" gemäß Fig. 8 detaillierter;

Fig. 10 zeigt den Schritt "erzeuge XIP-Anwendung" gemäß Fig. 8 detaillierter;

Fig. 11a-11b zeigen den Schritt "erzeuge XIP-Datei" gemäß Fig. 10 detaillierter;

Fig. 12a-12c zeigen den Schritt "löse Verschiebungselemente auf" gemäß Fig. 10 detaillierter;

Fig. 13a-13b zeigen den Schritt "verbessere Ort" gemäß Fig. 12s detaillierter;

Fig. 14 zeigt den Schritt "endgültige Korrektur" gemäß Fig. 10 detaillierter;

Fig. 15 zeigt die zur Systeminitialisierungszeit von einem Ausführungsbeispiel des XIP-Managements ausgeführten Arbeits schritte;

Fig. 16 zeigt die zur Windows^TM-Startzeit von einem Ausfüh rungsbeispiel des ergänzenden XIP-Initiators und des XIP- Managements ausgeführten Arbeitsschritte;

Fig. 17 zeigt die zur "Lade"-Zeit der XIP-Anwendung von dem XIP-Lader ausgeführten Arbeitsschritte;

Fig. 18a-18c, 19-21 zeigen die zur Taskstart-, Taskein gangs, Taskausgangs- und Taskendezeit von einem Ausführungsbei spiel des XIP-Managements ausgeführten Arbeitsschritte.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

In der folgenden Beschreibung werden zur Erklärung spe zielle Zahlen, Materialien und Konfigurationen angegeben, um ein besseres Verständnis der vorliegenden Erfindung zu ermögli chen. Jedoch ist es für den Fachmann klar, daß die vorliegende Erfindung ohne diese speziellen Details ausgeführt werden kann. In anderen Fällen sind bekannte Merkmale weggelassen oder ver einfacht worden, um die vorliegende Erfindung nicht unnötig zu belasten.

Es wird nun auf Fig. 1 Bezug genommen, in der ein Block schaltbild dargestellt ist, das ein die Lehre der vorliegenden Erfindung enthaltendes beispielhaftes Computersystem zeigt. Das beispielhafte Computersystem 10 enthält einen Prozessor 12, einen Cache-Speicher 14, einen Hauptspeicher 16, einen ROM 18a, einen Flash-Speicher 18b, einen Speichercontroller 20 und einen Prozessorbus 22, die miteinander in der dargestellten Weise ge koppelt sind. Außerdem enthält das beispielhafte Computersystem 10 einen E/A-Controller 24, eine PCMCIA-Schnittstelle 26, eine PCMCIA-Karte 28, andere E/A-Einheiten 30 und einen E/A-Bus 32, die in der dargestellten Weise miteinander gekoppelt sind. Die E/A- und Speichercontroller 20 und 24 sind außerdem miteinander gekoppelt und enthalten eine Schaltung zum Abbilden von E/A- Einheiten in den physischen Adreßraum des beispielhaften Compu tersystems 10. Die PCMCIA-Karte 28 ist lösbar mit der PCMCIA- Schnittstelle 26 gekoppelt, wodurch es möglich ist, daß ver schiedene PCMCIA-Karten 28 mit verschiedenen Programm- und/oder Dateninhalten mit der PCMCIA-Schnittstelle 26 verbunden werden können. Zu den anderen Einheiten 30 können gewöhnliche E/A-Ein heiten gehören, wie z. B. eine Tastatur, eine Maus usw., sowie spezielle E/A-Einheiten, wie z. B. eine Einheit zum Schreiben auf ein EPROM.

Diese Elemente sollen bis auf ihre Verwendungsweise eine breite Kategorie von ähnlichen, in vielen Computersystemen zu findenden Elementen repräsentieren, deren Aufbau und Funktionen bekannt sind und ansonsten nicht weiter beschrieben werden. Die erfindungsgemäße Verwendungsweise dieser Elemente wird mit zu sätzlichen Hinweisen auf die verbleibenden Figuren weiter unten detaillierter beschrieben.

Nun wird sich Fig. 2 zugewendet, die die Abbildung von E/A- Einheiten in den physischen Adreßraum und die Abbildung von lo gischen Adreßräumen in den physischen Adreßraum zeigt, die von dem beispielhaften Computersystem 10 gemäß Fig. 1 unterstützt werden. Wie es dargestellt ist, werden der RAM 16, der ROM 18a, der Flash-Speicher 18b, die PCMCIA-Schnittstelle und -Karte 26 und 28 und die anderen speicherabgebildeten E/A-Einheiten 30 in verschiedene Bereiche des physischen Adreßraumes 36 abgebildet. Die Positionen dieser Bereiche kann in Abhängigkeit von der von dem Speicher- und E/A-Controller 20 und 24 und dem Betriebs system des beispielhaften Computersystems 10 zur Verfügung ge stellten Unterstützung vorab bestimmt oder dynamisch bestimmt werden.

Wie es dargestellt ist, unterstützt das beispielhafte Com putersystem 10 außerdem die Abbildung von mehreren logischen Adreßräumen 34 in den physischen Adreßraum 36. Wie weiter unten detaillierter beschrieben wird, unterstützt das beispielhafte Computersystem 10 außerdem ein Mehrsegmentmodell des Speicher managements, in dem jedes Segment ein separater logischer Adreßraum 34 ist. Diese logischen Adreßräume 34 werden üb licherweise direkt oder indirekt (über (nicht dargestellte) li neare. "Zwischen-"Adreßräume) in verschiedene Bereiche des phy sischen Adreßraums 36 abgebildet. Jedoch können sie direkt oder indirekt auf den gleichen Bereich des physischen Adreßraumes 36 abgebildet werden.

Fig. 3a-3b zeigen verschiedene grundlegende Aspekte des beispielhaften Computersystems 10 zur Unterstützung des Mehr segmentmodells des Speichermanagements. Wie dargestellt ist, enthält eine logische Adresse 38 einen Segmentselektor 40 und einen Offset 42. Der Segmentselektor 40 wird zur Auswahl eines Segmentdeskriptors 46 verwendet, der in einer globalen oder lo kalen Deskriptortabelle 52 gespeichert ist, die im Hauptspei cher 16 gespeichert ist. Die Deskriptortabellen-Basisdresse und der Deskriptortabellen-Grenzwert bzw. -Limit der globa len/lokalen Deskriptortabelle 52 sind in einem der Register 50 der globalen/lokalen Deskriptortabellen gespeichert, das Teil des Prozessors 12 ist. Ein Bereich des Segmentselektors 40 wird verwendet, um zu bestimmen, ob der Inhalt des globalen oder lo kalen Segmentregisters 50 verwendet werden soll.

Jeder Segmentdeskriptor 46 enthält eine Segmentbasisadresse 54 und einen Segmentgrenzwert bzw. ein Segmentlimit 56 eines Speichersegments. Eine Adreßübersetzungsschaltung 48, die ein Teil des Prozessors 12 ist, verwendet die Segmentbasisadresse 54, das Segmentlimit 56 und den Offset 42, um für die logische Adresse 38 die zugehörige physische Adresse zu erzeugen.

Obwohl die vorliegende Erfindung anhand des ein Segment speichermanagement unterstützenden beispielhaften Computer systems 10 beschrieben wird, ist für den Fachmann klar, daß die vorliegende Erfindung auch mit einem flachen bzw. unstruktu rierten Modell des Speichermanagements ausgeführt werden kann, da die Abbildung aller logischen Adreßräume 34 auf den gesamten physischen Adreßraum 36 funktionsmäßig äquivalent zu einem fla chen Speichermanagementmodell ist. Außerdem kann die vorlie gende Erfindung mit Seitenwechseln anstelle von oder in Kombi nation mit entweder dem flachen Modell oder dem Segmentierungs modell des Speichermanagements ausgeführt werden.

Es wird nun auf Fig. 4 Bezug genommen, in der ein Block schaltbild gezeigt ist, das die wichtigsten Softwareelemente des beispielhaften Computersystems 10 veranschaulicht. Wie es dargestellt ist, gehören zu den wichtigsten Softwarelementen die in die Lehre der vorliegenden Erfindung aufgenommenen An wendungen 58 und das Betriebssystem 60. Die Anwendungen 58 ent halten konventionelle "RAM-gestützte" Anwendungen 62 und XIP- Anwendungen 64, die gemäß der Lehre der vorliegenden Erfindung erzeugt und ausgeführt werden. Das Betriebssystem 60 enthält einen Kernel bzw. ein Kernteil 66, Dienstprogramme 70, Einhei tentreiber 74 und vorzugsweise ein Subsystem 76 mit Fenster technik.

Der Kernel 66 führt Speichermanagement-, Programmlade-, Taskablaufplanungs-, Taskmanagementfunktionen und verwandte Funktionen aus. Insbesondere enthält der Kernel 66 eine Spei chermanagementdatenstruktur zur Verwaltung der Speicherzuord nung zu den Anwendungen 58. Der Kernel 66 ist außerdem mit "erweiterten" Speichermanagement-, Lade- und Taskmanagement funktionen 68 für XIP-Anwendungen 64 gemäß der Lehre der vor liegenden Erfindung versehen, wie weiter unten detaillierter beschrieben wird. Die Dienstprogramme 70 führen Funktionen, wie z. B. Verbinden, Taskwechselhinweis aus. Insbesondere enthalten die Dienstprogramme 70 eine Funktion zum Mitteilen eines Task wechsels. Die Dienstprogramme 70 sind außerdem mit "erweiterten" Binde- und Installationsfunktionen 72 für XIP-An wendungen 64 gemäß der Lehre der vorliegenden Erfindung verse hen, die ebenfalls weiter unten detaillierter beschrieben wer den. Einheitentreiber 74 und das Fenstersubsystem 76 führen ih re im Stand der Technik bekannten, konventionellen Funktionen aus.

Es wird nun auf die Fig. 5a-5b Bezug genommen, in der die gemäß der Lehre der vorliegenden Erfindung zur Verfügung ge stellten "erweiterten" Funktionen detaillierter dargestellt sind. Wie es dargestellt ist, enthalten die Dienstprogramm- "Erweiterungen" 72 für XIP-Anwendungen 64 eine neue Bindefunk tion 78 und eine neue Installationsfunktion 80, wogegen die Kernel-(oder Laufzeit-)"Erweiterungen" 68 für XIP-Anwendungen 64 eine neue Speichermanagementfunktion 82, eine neue Ladefunk tion 84 und eine neue XIP-Taskmanagementfunktion 86 enthalten.

Die neue Bindefunktion 78 wird verwendet, um Referenzen einer konventionellen "RAM-gestützten" Anwendung 62 teilweise aufzulösen, so daß die teilweise aufgelöste Anwendung 64 in Verbindung mit den neuen Laufzeitfunktionen 68 von einem "Schreib-Einmal/Selten"-Speichermedium 18a, 18b oder 28 am Platz ausgeführt werden kann. Die neue Installationsfunktion 80 wird zur Installation der teilweise aufgelösten Anwendung 64 auf einem "Schreib-Selten"-Speichermedium 18b oder 28 verwen det. Die "Installation" einer teilweise aufgelösten Anwendung 64 auf einem "Schreib-Einmal"-Speichermedium 18a kann unter Verwendung beliebig vieler, bekannter Halbleiterprozesse er zielt werden.

Die neue Speichermanagementfunktion 82 wird verwendet, um einen vorgegebenen Bereich 83 der Speichermanagementdatenstruk tur 81 des Betriebssystemkernteils für eine "Abbildung" des (der) physischen Adreßraums(-räume) einer installierten Anwen dung 64 in einen logischen Adreßraum 34 zu reservieren, wodurch es der "abgebildeten" Anwendung 64 ermöglicht wird, am Platz ausgeführt zu werden. (Es sei an die zurückliegende Beschrei bung erinnert, daß die XIP-Anwendung 64, die ein "Schreib-Ein mal/Selten"-Speichermedium 18a, 18b oder 28 hält, von einer Schaltung der Speicher- und E/A-Controller 20 und 24 und dem Betriebssystem 60 in den physischen Adreßraum 36 abgebildet wird). Die neue Ladefunktion 84 wird zum Pseudoladen und Pseu dostarten der Ausführung einer XIP-Anwendung 64 verwendet. Eine neue Taskmanagementfunktion 86 wird verwendet, um die gemein same Nutzung des vorgegebenen Bereichs 83 der Speichermanage mentdatenstruktur 81 mehreren XIP-Anwendungen 64 zu ermögli chen, wodurch ein Multitasking von XIP-Anwendungen 64 sowie von Nicht-XIP-Anwendungen oder konventionellen "RAM-gestützten" An wendungen 62 vom Betriebssystem 60 ermöglicht wird.

Insbesondere liest die neue Bindefunktion 78 die ausführbare Datei einer konventionellen "RAM-gestützten" Anwendung 62, lokalisiert die unaufgelösten externen sowie internen Referenzen 103a-103b (wie z. B. "unrslvd int_addr/ext_addr" der Steuerungsübertragungsinstruktionen "XCTL"), und löst sie teilweise auf. Die teilweise aufgelösten internen und externen Referenzen 107a-107c (wie z. B. "p_rslvd int_addr/ext_addr") werden zu dem vorgegebenen Bereich 83 der Speichermanagementdatenstruktur 81 aufgelöst, wodurch es ermöglicht wird, daß sie zur Ausführungszeit durch Berichtigung des vorgegebenen Bereichs 83 der Spei chermanagementdatenstruktur 81 mit den richtigen physischen Adressen vollständig aufgelöst werden. Für einige externe Refe renzen 106b strukturiert die neue XIP-Bindefunktion 78 ferner die externen Referenzen 106b in indirekte externe Referenzen 107c-107d durch den R/W-Datenbereich 105b um. Die neue XIP-Bin defunktion 78 berichtigt außerdem verschiedene Informationsta bellen in der "RAM-gestützten" ausführbaren Datei 62 und er zeugt die ausführbare XIP-Datei 64 (die später vollständiger beschrieben wird).

Die neue Speichermanagementfunktion 82 reserviert den vor gegebenen Bereich 83 der Speichermanagementdatenstruktur 81, indem sie sich diesen zur Systeminitialisierungszeit vorab zu ordnet. Die neue Ladefunktion 84 führt eine Pseudoladung an einer installierten Anwendung 64 durch, indem sie den Kernel 66 des Betriebssystems veranlaßt, einen RAM für den R/W-Datenbe reich 105b der XIP-Anwendung 64 und den vorab zugeordneten, vorgegebenen Bereich 83 der Speichermanagementdatenstruktur 81 zuzuordnen, der mit den richtigen physischen Adressen berich tigt werden soll. Die neue Ladefunktion 84 informiert außerdem die neue Taskmanagementfunktion 86 über jede neu "geladene" XIP-Anwendung 64. Die neue Taskmanagementfunktion 86 erzeugt zur Systeminitialisierungszeit eine Taskmanagementdatenstruktur 87 für XIP-Anwendungen 64. Als Antwort auf jeden Hinweis von der neuen Ladefunktion 84 erzeugt die neue Taskmanagementfunk tion 86 ein Taskmanagementdatenelement 89 in der Taskmanage mentdatenstruktur 87 für die neu "geladene" XIP-Anwendung 64. Das Taskmanagementdatenelement 89 enthält die Berichtigungsda ten für den vorab zugeordneten, vorgegebenen Bereich 83 der Speichermanagementdatenstruktur 81, einschließlich Daten, um geeignete Teilbereiche des vorab zugeordneten, vorgegebenen Be reichs 83 und Teilbereiche des dynamisch zugeordneten Bereichs 85 der Speichermanagementdatenstruktur 81 miteinander zu ver binden. Wenn der neuen Taskmanagementfunktion 86 von dem Be triebssystem 60 ein Taskwechsel mitgeteilt wird, bestimmt sie, ob eine XIP-Anwendung 64 beteiligt ist, und lagert die richti gen Berichtigungsspeichermanagementdaten 89 in den vorab zuge ordneten, vorgegebenen Bereich 83 der Speichermanagementdaten struktur 81 ein. In ähnlicher Weise löscht die neue Taskmanage mentfunktion 86 das Taskmanagementdatenelement 89 der endenden XIP-Task, wenn ihr vom Betriebssystem 60 ein Taskende mitge teilt wird und eine XIP-Anwendung 64 beteiligt ist.

Die neue Bindefunktion 78 und die neue Installationsfunk tion 80 zur Unterstützung von XIP-Anwendungen 64 können als ei genständige Dienstprogramme oder alternativ als integrale Teile eines konventionellen Binders bzw. eines konventionellen Datei systems ausgeführt werden. In ähnlicher Weise können die neue Speichermanagementfunktion 82, die neue Ladefunktion 84 und die neue XIP-Taskmanagementfunktion 86 zur Unterstützung von XIP- Anwendungen 64 als eigenständige "Erweiterungen" des Kernels 66 oder alternativ als ein integraler Teil des Kernels ausgeführt werden.

Fig. 6a-6g zeigen ein Ausführungsbeispiel sowohl der neuen Bindefunktion als auch der neuen Installationsfunktion 78' und 80' zur Unterstützung von für die Windows^TM-Betriebsumgebung entwickelten XIP-Anwendungen 64' detaillierter. Fig. 6a-6c zei gen diese Ausführungsbeispiele der neuen Binde- und Insta llationsfunktionen 78' und 80' mit Hilfe von zwei Ansichten der "RAM-gestützten" Anwendung 62' und der XIP-Anwendung 64', einer segmentierten Ansicht und einer Dateiorganisationsansicht. Die Fig. 6d-6e zeigen die Verschiebungsdaten 150 (d. h. beschrei bende Informationen der Referenzen) der "RAM-gestützten" Anwen dung 62' detaillierter, wobei die Fig. 6f-6g die Arbeitsdaten 78'c-78'd dieses Ausführungsbeispiels der neuen Bindefunktion 78' detaillierter zeigen. Zur leichteren Erklärung sind diese Ausführungsbeispiele der neuen Binde- und Installationsfunktio nen 78' und 80' in diesen Figuren mit einer "RAM-gestützten" Anwendung 62' dargestellt, die zwei Codesegmente 102b-102c und ein automatisches R/W-Datensegment 102d aufweist. Für den Fach mann ist es jedoch aufgrund der folgenden Beschreibung klar, daß die vorliegende Erfindung zusammen mit Anwendungen mit einer beliebigen Anzahl von Codesegmenten und einer beliebigen Anzahl von Datensegmenten ausgeführt werden kann, solange es ein "äquivalentes" automatisches R/W-Datensegment gibt.

Bei diesem Ausführungsbeispiel sind die neue Bindefunktion 78 und die neue Installationsfunktion 80 als zwei eigenständige Windows^TM-Ausführungen, XIP-Binder 78'a bzw. XIP-Installierer 80' ausgeführt. Außerdem ist der XIP-Binder 78'a mit einem er gänzenden Selbstladesegment 78'b und Arbeitsdaten 78'c verse hen. Wie es aufgrund der folgenden Beschreibung klar wird, müs sen andere Ausführungsbeispiele das Selbstladesegment 78'b nicht verwenden, wenn die Zielbetriebssysteme/-umgebungen Funk tionen zur Verfügung stellen, die "äquivalent" zu den von dem Selbstladesegment 78'b zur Verfügung gestellten Funktionen sind.

Der XIP-Binder 78'a liest die ausführbare Datei der "RAM- gestützten" Anwendung 62', lokalisiert externe sowie interne Referenzen 104a-104b (wie z. B. "unrslvd ext_addr/int_addr" der Steuerübertragungsinstruktionen "CALL/JMP" bzw. "RUFE AUFSPRINGE") und löst sie teilweise auf. Die teilweise aufgelösten Referenzen 106a-106d werden teilweise zu einem vom Windows-Kernel verwalteten, vorgegebenen Bereich von Segmentselektoren 83 (wie z. B. "pre-allocated selector:offset") aufgelöst, wodurch es den teilweise aufgelösten Referenzen 108a-108d ermöglicht wird, zur Ausführungszeit vollständig aufgelöst zu werden, indem der vorgegebene Bereich von Segmentselektoren 83 mit den richtigen physischen Adressen berichtigt wird. Der XIP-Binder 78'a zeichnet verschiedene Arbeitsdaten 78'c auf, um die teilweise Auflösung der Referenzen 104a-104d zu erleichtern. Der XIP-Binder 78'a er zeugt die ausführbare Datei 64', indem die teilweise aufge lösten Referenzen 108a-108d verwendet werden, das selbstladene Segment 78'b eingefügt wird und verschiedenen Informationsta bellen 103a-103f berichtigt werden.

Unaufgelöste Referenzen 104a-104b sind in den Verschie bungsdaten 120a-120c der zugehörigen Segmente 118a-118c be schrieben. Jede Gruppe von Verschiebungsdaten 120a, 120b und 120c enthält einen Verschiebungselement-Zählwert 152 und einen oder mehrere Verschiebungselemente 154 (wenn der Verschie bungselement-Zählwert ungleich Null ist). Jedes Verschiebungs element 154 enthält die Adreßart 156, die Referenzart 158, den Patch-Standort 160 und die Auflösung oder den Index des Ver schiebungselementes zu den Auflösungsdaten 162. Die Ver schiebungselement-Adreßart 156 enthält Selektor-, Zeiger- und Offsetadreßarten. Die Verschiebungsreferenzart 160 enthält die Art der internen Referenz, die Importordinalzahlart und die Importnamensart. Zu jeder Verschiebungsart 160 gehört ein additives Flag, welches anzeigt, ob der Offsetwert an dem Patch-Standort zu den Auflösungsdaten addiert werden soll oder als Zeiger auf einen verketteten Patch-Standort verwendet werden soll. Die Auflösung oder der Index zu den Auflösungsdaten 162 enthält entweder die Segment- und Offsetwerte für eine feste interne Referenz oder einen Indexwert zu den Auflösungsdaten für die anderen Verschiebungsreferenzarten. Die Verwendung dieser Daten wird weiter unten detaillierter beschrieben.

Die Arbeitsdaten 78'c enthalten eine Segmentinforma tionstabelle 164 und Variablen 190. Die Segmentierungsinforma tionstabelle 164 enthält für jedes Segment einen vorab zugeord neten, zugewiesenen Selektor 166, die Segmentart 168, die An zahl der Verschiebungselemente 170, die Anzahl der umstruktu rierbaren Verschiebungselemente 172, die Anzahl der Selektor verschiebungselemente 174, die Anzahl der Zeigerverschiebungs elemente 176 und die Anzahl der Offsetverschiebungselemente 178. Die Variablen 190 enthalten den nächsten ungenutzten vorab zugeordneten Selektor 191, ein Erzeuge-Automatisches-R/W-Daten segment-Flag 192, einen Einfügezeiger 193 für das automatische R/W-Datensegment, ein Wachstum des automatischen R/W-Datenseg mentes 194, ein Wachstum der Verschiebungsdaten des automati schen R/W-Datensegmentes 195, einen Patch-Selektor 196, einen Patch-Offset 196, ein Indirekter-Kandidat-Flag 198 und eine Anzahl von Aliasnamen 199. In ähnlicher Weise wird die Verwen dung dieser Daten weiter unten detaillierter beschrieben.

Das Selbstladesegment 78'b enthält eine komplementäre Auf ruflogik zum Aufrufen einer neuen XIP-Ladefunktion 84 in seinem Codesegment 118d, wobei das selbstladene Merkmal von Windows^TM verwendet wird (wobei dies weiter unten detaillierter be schrieben wird). Das Selbstladesegment 78'b enthält in ähnli cher Weise wie andere Segmente Verschiebungsdaten 120d.

Der XIP-Installierer 80' installiert die regenerierte ausführbare Datei 64' auf einem "Schreib-Selten"-Speichermedium 18b oder 28, wobei die relativen Orte der Segmente 106b und 106c erhalten bleiben, die am Platz ausgeführt werden soll. Der XIP-Installierer 80' kann auf viele verschiedenen Weisen imple mentiert werden, die alle im Rahmen der Fähigkeiten eines Fach manns liegen und daher nicht weiter beschrieben werden müssen.

Die Fig. 7a-7c in Verbindung mit Fig. 7d zeigen ein Ausfüh rungsbeispiel der neuen XIP-Speichermanagement-, -Lade- und -Taskmanagementfunktionen 82'a-82'c und 84' detaillierter, die für die Windows^TM-Betriebsumgebung entwickelt wurden. Fig. 7a zeigt Interaktionen dieser neuen Funktionen 82'a-82'c und 84 mit dem Windows-Kernel 66' und den Dienstprogrammen 70' und den XIP-Anwendungen 64', wogegen Fig. 7b die Interaktionen dieser neuen Funktion 82'a-82'c und 84 mit der Windows- Speichermanagementdatenstruktur 81' zeigt. Fig. 7c zeigt die Taskmanagementdatenstruktur 87' der vorliegenden Erfindung detaillierter, wogegen Fig. 7d die Windows- Speichermanagementdatenstruktur 81a' und 81b' detaillierter zeigt.

Bei diesem Ausführungsbeispiel sind die neuen XIP-Speicher management-, -Lade- und -Taskmanagementfunktionen 82-86 zusam men mit einem XIP-LADER 84' und einem XIP-Management 82'a im plementiert. Zusätzlich ist das XIP-Management 82'a durch einen XIP-Initiator 82'b und einen XIP-Abbilder 82'c ergänzt. Wie der folgenden Beschreibung zu entnehmen ist, müssen der XIP-Initia tor 82'b und der XIP-Abbilder 82'c bei anderen Ausführungsbei spielen nicht verwendet werden, die für andere Betriebssyste me/-umgebungen entwickelt sind, die "äquivalente" Funktionen zu den von dem XIP-Initiator 82'b und dem XIP-Abbilder 82'c zur Verfügung gestellten Funktionen bieten.

Wie es dargestellt ist, wird das XIP-Management 82'a zur Systeminitialisierungszeit aufgerufen, zu welcher Zeit das XIP- Management 82'a den vorgegebenen Bereich der Selektoren 83' da durch reserviert, daß die Segmentselektoren 83' vorab zugeord net werden. Das XIP-Management 82'a ordnet die Segmentselekto ren 83' dadurch vorab zu, daß der Windows-Kernel 66' wiederholt aufgefordert wird, Segmentselektoren dem XIP-Management 82'a zuzuordnen, bis der vorgegebene Bereich der Selektoren 83' auf diese Weise zugeordnet ist. Die Selektoren außerhalb des vorge gebenen Bereichs der Selektoren 83' werden dann von dem XIP- Management 82'a freigegeben. Die von dem Windows-Kernel 66' verwalteten Segmentselektoren werden im Windows-LDT 81'b ge speichert. Außerdem enthält der Windows-Kernel 66' das im Stand der Technik als Windows-Burgermaster-Segment 81'a bekannte Seg ment, welches eine den Windows-LDT 81'b "spiegelnde" Selektor tabelle 91, einen Arena-Pool 92 zum Verfolgen des freien Spei cherblocks im globalen Windows-Freispeicher 94 und Informatio nen 93 über das Burgermaster-Segment 81'a enthält.

Außerdem erzeugt das XIP-Management 82'a zur Systemini tialisierungszeit eine "leere" XIP-Taskmanagementdatenstruktur 87', um das Multitasking von XIP-Anwendungen 64' zu erleich tern. Wenn die XIP-Taskmanagementdatenstruktur 87' während des Betriebs belegt wird, enthält sie mehrere XIP-Taskdeskriptoren 204, einen pro XIP-Task, und zugehöriger XIP-Tasksegmentdes kriptorseiten 206, ebenfalls eine pro XIP-Task. Jeder XIP-Task deskriptor 204 enthält eine XIP-Task-ID bzw. einen XIP-Taskbe zeichner 220, der die XIP-Task identifiziert, eine XIP-Segment deskriptorseitenadresse 222, die die zugehörige XIP-Taskseg mentdeskriptorseite 206 lokalisiert, die Segmentanzahl des au tomatischen R/W-Datensegmentes 224 und die Arena-Adresse des Burgermasters und die Adresse des Selektortabelleneintrags für das automatische R/W-Datensegment 226 und 228. Jede XIP-Seg mentdeskriptorseite 206 enthält mehrere Tasksegmentdeskriptoren 230 der XIP-Anwendung 64'. Die XIP-Taskmanagementdatenstruktur 87' enthält außerdem globale Taskinformationen 202, wie z. B. einen Gesamt-Task-Zählwert 210, einen Tasksegmentdeskriptorseiten-Zählwert 212, einen Zeiger 214 auf den Deskriptor 204 der aktuellen Task, einen Selektorzählwert 216 der aktuellen Task und eine ID 218 für das automatische R/W-Datensegment der aktuellen Task. Diese Informationen ermöglichen zusammen, daß die zugehörigen Segmentdeskriptoren der vorab zugeordneten Segmentselektoren 83'b für eine "überlappte" Ausführung von mehreren XIP-Anwendungen 64' richtig berichtigt werden, wobei am oberen Ende der logischen Adreßräume 34 wirksam eine weitere Ebene der Virtualisierung erzeugt wird. Wie im folgenden detaillierter beschrieben wird, enthält das "Berichtigen" des vorgegebenen Bereichs der Segmentselektoren 83' eine direkte Berichtigung einiger zugehöriger Segmentdeskriptoren der vorab zugeordneten Segmentselektoren 83'b mit physischen Adressen des "Schreib- Einmal/Selten"-Mediums 18a, 18b oder 28, ein Aliasing einiger vorab zugeordneter Segmentselektoren 83'b und dynamisch zuge ordneter Segmentselektoren 85'b miteinander, und/oder ein Pseu do-Aliasing einiger vorab zugeordneter Segmentselektoren 83'b als "bedeutungsvolle fehlerhafte Zeiger" bzw. "meaningful bad pointers" oder MBPs. MBPs werden verwendet, um sich dem Windows-Merkmal zu widmen, daß vom globalen Windows-Freispei cher zugeordnete Speicherblöcke bewegbar sein können. MBPs wer den zur Zeit ihrer Bezugnahme vollständig zu ihren richtigen, dynamisch zugeordneten Alias-Selektoren aufgelöst. Die Verwen dung dieser Informationen wird weiter unten detaillierter beschrieben.

Der XIP-Initiator 82'b wird zur Windows^TM-Startzeit aufge rufen. Der XIP-Initiator 82'b erzeugt unter Verwendung eines XIP-Leersegmentes bzw. -Dummy-Segmentes 106e, vorzugsweise eines 64-K-Segmentes, ein Leermodul bzw. Dummy-Modul. Der XIP- Initiator 82'b ruft dann das XIP-Management 82'a auf, um einen XIP-Taskdeskriptor 204 und eine zugehörige XIP-Tasksegmentdes kriptorseite 206 für das XIP-Leersegment 106e zu erzeugen. Der XIP-Taskdeskriptor 204 und die zugehörige XIP-Tasksegmentdes kriptorseite 206 enthalten Informationen, die wenn sie auf die Segmentdeskriptoren des vorab zugeordneten Bereichs von Seg mentselektoren 83'b im Windows-LDT 81'b angewendet werden, be wirken, daß der ganze vorab zugeordnete Bereich von Segmentse lektoren 83'b auf das XIP-Leersegment 106e zeigt. Das XIP- Management 82'a wendet dann die enthaltenen Informationen ent sprechend an, wobei die gewünschte Bezugnahme des ganzen vorab zugeordneten Bereichs der Segmentselektoren 83'b auf das XIP- Leersegment 106e bewirkt wird.

Der XIP-Abbilder 82'c wird als Antwort auf das Einfügen einer PCMCIA-Karte 28 aufgerufen. Der XIP-Abbilder 82'c bildet die neu eingefügte PCMCIA-Karte 28 in einen physischen Adreßbe reich oder in mehrere physische Adreßbereiche ab, wenn er auf gerufen wird. Zur Vereinfachung der Implementierung kann der XIP-Abbilder 82'c bei Systemen, in denen es einen Bereich bzw. Bereiche von physischen Adressen gibt, die üblicherweise "ungenutzt" sind, die eingefügten PCMCIA-Karten auf einen oder mehrere vorgegebene physische Adreßbereiche abbilden. Das Ab bilden einer eingefügten PCMCIA-Karte in einen oder mehrere physische Adreßräume ist im Stand der Technik bekannt, daher wird der XIP-Abbilder 82'c nicht weiter beschrieben.

Der XIP-LADER 84' wird zur Ladezeit der XIP-Anwendung von dem Selbstladesegment 106a aufgerufen. Jedesmal wenn das Laden einer XIP-Anwendung 64' angefordert wird, wird das Selbstlade segment 106a geladen und ihm vom Windows-Kernel 66' gemäß dem Windows-Selbstlademerkmal die Steuerung übergeben. Der XIP- LADER 84' ändert bei dem Aufruf die Modultabelle der XIP-Anwen dung, wobei der vorab zugeordnete, vorgegebene Bereich der Seg mentselektoren 83' mit physischen Adressen des "Schreib-Ein mal/Selten"-Mediums 18 oder 28 berichtigt wird, und veranlaßt den Windows-Kernel 66' RAM für das automatische R/W-Datenseg ment 106d zuzuordnen, wodurch die XIP-Anwendung 64' pseudogela den wird. Der XIP-LADER 84' veranlaßt außerdem den Windows-Ker nel 66', die Ausführung der XIP-Anwendung 64' zu beginnen. Wenn die Ausführung beginnt, erhält der XIP-LADER 84' wieder die Steuerung über das Selbstladesegment 106a, welches wiederum das XIP-Management 82'a aufruft, damit das Berichtigen des vorgege benen Bereichs von Segmentselektoren 83' beendet wird. Als Ant wort erzeugt das XIP-Management 82'a den XIP-Taskdeskriptor 204 und die zugehörige XIP-Tasksegmentdeskriptorseite 206 für die XIP-Anwendung 64', und wendet die Informationen an, um die Seg mentdeskriptoren des vorab zugeordneten, vorgegebenen Bereichs von Segmentselektoren 83' zu berichtigen.

Der XIP-LADER 84' wird außerdem von dem Windows-Dienstpro gramm 70' (WERKZEUG-HILFE) während des Taskwechsels aufgerufen. Beim Aufruf überträgt der XIP-LADER 84' die Informationen an das XIP-Management 82'a. Als Antwort bestimmt das XIP-Manage ment 82'a, ob eine XIP-Task beteiligt ist. Wenn eine XIP-Task beteiligt ist, lagert das XIP-Management 82'a die richtigen Be richtigungsinformationen in die Segmentdeskriptoren des vorge gebenen Bereichs von Segmentselektoren 83'b ein.

Schließlich wird der XIP-Initiator 82'b als Antwort auf einen allgemeinen Speicherzugriffsfehler (general protection fault) oder GP-Fehler aufgerufen. Der XIP-Initiator 82'b be stimmt, ob der GP-Fehler dadurch verursacht wird, daß auf einen MBP verwiesen wird. Wenn der GP-Fehler von einer MBP-Referenz verursacht wird, zerlegt der XIP-Initiator 82'b die den Fehler auslösende Instruktion, um den Selektor zu erhalten. Der XIP- Initiator 82'b verwendet den Selektor 83' dann, um in die Seg mentdeskriptortabelle 52 zu indexieren und um die reale Seg mentselektoranzahl von dem Basisbereich 54 abzurufen, wo sie vorher von dem XIP-Management 82'a gespeichert wurde (wie spä ter beschrieben wird). Nach dem Abrufen der realen Segmentse lektoranzahl startet der XIP-Initiator 82'b die Instruktion un ter Verwendung des realen Segmentselektors 85' erneut.

Die Fig. 8-10, 11a-11b, 12a-12c, 13a-13b und 14 zeigen ein Ausführungsbeispiel der Operationslogik des XIP-Binders 78'a detaillierter. Wie es in Fig. 8 gezeigt ist, hat der XIP-Binder 78'a einen Operationsablauf 300 mit zwei Arbeitsgängen. In dem ersten Arbeitsgang liest der XIP-Binder 78'a die ausführbare. Datei der "RAM-gestützten" Anwendung 62', analysiert die "RAM- gestützte" Anwendung, insbesondere die Verschiebungselemente, und zeichnet die relevanten Informationen zum teilweisen Auflö sen der Referenzen auf, Schritt 302. In dem zweiten Arbeitsgang regeneriert der XIP-Binder 78'a die ausführbare Datei, indem er die Anwendung in eine XIP-Anwendung 64' transformiert, wobei die Verschiebungselemente teilweise aufgelöst werden, die ex ternen Referenzen ggf. umstrukturiert werden und die Informa tionstabellen berichtigt werden, Schritt 304. Zusätzlich kann der XIP-Binder 78'a, obwohl es nicht dargestellt ist, einen vorläufigen Schritt (vorläufige Schritte) zum Vorauswählen "ungeeigneter" ausführbarer Dateien enthalten. Zu den besonde ren Beispielen für "ungeeignete" ausführbare Dateien gehören solche Dateien mit Linkedit-Fehlern und Dateien, die das Selbstlademerkmal bereits verwenden.

Fig. 9 zeigt den Schritt "analysiere und zeichne auf" 302 detaillierter. Wie es dargestellt ist, ordnet der XIP-Binder 78'a zunächst die vorher beschriebene Arbeitsdatenstruktur 78'c zu und initialisiert sie (Schritt 306). Bei dem dargestellten Ausführungsbeispiel wird das "Erzeuge-Automatisches-R/W-Daten segment(DS)-Flag" 192 derart initialisiert, daß es lautet "automatisches R/W-DS-Erzeugung benötigt". Als nächstes lokali siert der XIP-Binder 78'a ein Segment 102b-102d (Schritt 307). Üblicherweise werden die Segmente 102b-102d in fortlaufender Reihenfolge lokalisiert. Der XIP-Binder 78'a ordnet dann einen Selektor aus dem vorgegebenen Bereich von Segmentselektoren 83' dem lokalisierten Segment 102b-102d zu und zeichnet die Zuord nung auf (Schritt 308). Üblicherweise werden Segmentselektoren 83' ebenfalls in fortlaufender Reihenfolge zugeordnet. Der XIP- Binder 78'a zeichnet außerdem die Segmentart 168 auf, d. h. Code oder Daten, Schritt 308. Wenn das Segment das automatische R/W- Datensegment 102d ist, ändert der XIP-Binder 78'a das "Erzeuge- Automatisches-R/W-DS-Flag" 192 derart, daß es "Erzeugung des automatischen R/W-DS nicht benötigt" angibt, Schritt 310.

Als nächstes bestimmt der XIP-Binder 78'a unabhängig von der Segmentart, ob das lokalisierte Segment 102b-102d Verschie bungselemente 154 aufweist (Schritte 311). Wenn das lokali sierte Segment 102d Verschiebungselemente 154 aufweist, ruft der XIP-Binder 78'a eines der Verschiebungselemente 154 ab, Schritt 312. Üblicherweise werden die Verschiebungselemente 154 auch in fortlaufender Reihenfolge abgerufen. Der XIP-Binder 78'a untersucht dann die vorher beschriebenen Verschiebungsele mentinformationen und kumuliert die relevanten Informationen, d. h. Anzahl der umstrukturierbaren Verschiebungselemente 172, Anzahl der Selektorverschiebungselemente 174 usw., Schritt 313. Nach der Verarbeitung der Verschiebungselemente 154 bestimmt der XIP-Binder 78'a, ob es weitere Verschiebungselemente 154 gibt, Schritt 314. Wenn es weitere Verschiebungselemente 154 gibt, wiederholt der XIP-Binder 78'a die Schritte 312 und 313, bis alle Verschiebungselemente 154 verarbeitet sind. Nachdem alle Verschiebungselemente 154 für das lokalisierte Segment 102b-102d verarbeitet worden sind, bestimmt der XIP-Binder 78'a, ob die "RAM-gestützte" Anwendung 62' weitere Segmente 102b-102d hat. Falls weitere Segmente 102b-102d noch verarbei tet werden müssen, wiederholt der XIP-Binder 78'a die Schritte 307-314, bis alle Segmente 102b-102d verarbeitet worden sind.

Fig. 10 zeigt den Schritt der "XIP-Anwendungserzeugung" 304 detaillierter. Wie es dargestellt ist, erzeugt der XIP-Binder 78'a zunächst die neue ausführbare XIP-Datei 64', Schritt 316. Es wird nun zu den Fig. 11a-11b gesprungen, die den Schritt 316 detaillierter zeigen. Der XIP-Binder 78'a bestimmt zunächst die Segmentgröße und das Wachstum der Verschiebungsdaten für das automatische R/W-Datensegment 106d, und zwar unter Verwendung der in der Arbeitssegmentinformationstabelle 164 aufgezeichne ten Informationen, Schritt 323. Der XIP-Binder 78'a kopiert dann die ausführbare Datei 62' der "RAM-gestützten" Anwendung bis zum Beginn der Segmenttabelle 110a-110e in die neue ausführbare XIP-Datei 64', die erzeugt wird, Schritt 324. Der XIP-Binder 78'a vergrößert außerdem die Segmenttabelle 112a, Schritt 325, lagert einen Segmenteintrag für das Selbstladeseg ment 78'b aus, Schritt 326, und kopiert die Segmenttabelle 112a in die ausführbare XIP-Datei 64', Schritt 327. Der XIP-Binder 78' kopiert außerdem die Ressourcen- und Modulreferenztabellen 112b-112c in die ausführbare XIP-Datei 64', Schritt 327 und fügt einen Eintrag für den XIP-LADER 84' zur Modulreferenzta belle 112c zu, Schritt 328. Der XIP-Binder 78' kopiert außerdem die Tabelle der importierten Namen 112d in die ausführbare XIP- Datei 64', Schritt 329, und fügt einen Eintrag für den XIP- LADER 84' zu der Tabelle der importierten Namen 112d hinzu, Schritt 330. Der XIP-Binder 78' kopiert außerdem die Eintrags tabelle und die nichtresidente Tabelle 112e-112f in die ausführbare XIP-Datei 64', Schritt 332, füllt zur Segmentausrichtung aus, Schritt 334, und kopiert Segmente und Verschiebungsdaten 116 in die neue ausführbare XIP-Datei 64', Schritt 335.

Als nächstes kopiert der XIP-Binder 78'a das automatische R/W-Datensegment 118s in die ausführbare XIP-Datei 64' oder er zeugt das automatische R/W-Datensegment 119a direkt, Schritt 336. Der XIP-Binder 78'a lagert vorzugsweise außerdem einen Si cherheitsblock 115c aus, Schritt 338. Der XIP-Binder 78'a la gert außerdem für jede zu erzeugende indirekte Referenz einen Platzhalter aus, Schritt 340, kopiert die Verschiebungsdaten 110c für das automatische R/W-Datensegment 102c in die ausführbare XIP-Datei 64', wobei der Verschiebungselement- Zählwert 152 berichtigt wird, Schritt 344, lagert die Verschiebungselemente für die indirekten Referenzen aus, Schritt 346, und füllt zur Segmentausrichtung auf, Schritt 348. Dann kopiert der XIP-Binder 78' den Rest der ausführbaren Datei 62' der "RAM-gestützten" Anwendung in die ausführbare XIP-Datei 64', Schritt 350, und füllt für die Segmentausrichtung auf, Schritt 352.

Als nächstes kopiert der XIP-Binder 78'a das Selbstladeseg ment 78'b in die ausführbare XIP-Datei 64', Schritt 354. Der XIP-Binder 78' bestimmt dann, ob an einem der Segmentselektoren aus dem vorgegebenen Bereich der Segmentselektoren 83' ein Aliasing bzw. eine Aliasnamensumsetzung zu dynamisch zugeord nete Segmentselektoren 85' während der Ausführung durchgeführt wird, Schritt 356. Wenn an einem oder mehreren der Segmentse lektoren 83' des vorgegebenen Bereichs ein Aliasing durchge führt wird, lagert der XIP-Binder 78'a Versionsinformationen und einen Aliasnamenszählwert 126, Schritt 358 und Patch-Räume für Alias-Selektoren 127, Schritt 360, aus.

Als nächstes lagert der XIP-Binder 78'a eine "karteneigene" Adreßtabelle aus, und zwar unabhängig davon, ob an einem der Segmentselektoren des vorgegebenen Bereichs der Segmentselekto ren 83' ein Aliasing durchgeführt wird, Schritt 362. Der XIP- Binder 78'a kopiert dann Verschiebungsdaten 120d des Selbstla desegmentes 78'b in die ausführbare XIP-Datei 64', wobei der Verschiebungszählwert 152 korrigiert wird, wenn an einem Seg mentselektor 83' des vorgegebenen Bereichs der Segmentselekto ren 83' ein Aliasing durchgeführt wird, Schritt 364. Schließ lich lagert der XIP-Binder 78'a ggf. Alias-Verschiebungsdaten elemente 154 für die Aliasnamen aus, Schritte 366-368.

Es wird nun wieder auf Fig. 10 Bezug genommen, in der der Schritt der "Erzeugung der XIP-Anwendung" dargestellt ist. Nach dem Erzeugen einer ausführbaren XIP-Datei 64', Schritt 316, holt der XIP-Binder 78'a ein Segment 106b-106d, Schritt 317. Üblicherweise werden Segmente 106b-106d in fortlaufender Rei henfolge abgerufen. Der XIP-Binder 78'a stellt die Segmentorte in dem abgerufenen Segment 106b-106d ein und korrigiert die Segmentlängeninformationen in der Segmenttabelle 117, Schritt 318.

Als nächstes bestimmt der XIP-Binder 78'a, ob das abgerufe ne Segment 106b-106d Verschiebungselemente 154 aufweist, Schritt 319. Wenn das abgerufene Segment 106b-106d Verschie bungselemente 154 aufweist, löst der XIP-Binder 78'a die Ver schiebungselemente auf, Schritt 320, welches weiter und detail lierter beschrieben wird. Nach dem Auflösen der Verschiebungs elemente 154 bestimmt der XIP-Binder 78'a, ob weitere Segmente 106b-106d verarbeitet werden müssen, Schritt 321. Wenn weitere Segmente 106b-106d verarbeitet werden müssen, wiederholt der XIP-Binder 78'a die Schritte 317-320 wiederholt, bis alle Seg mente 106b-106d verarbeitet worden sind.

Nachdem der XIP-Binder 78'a alle Verschiebungselemente 154 in allen Segmenten 106b-106d aufgelöst hat, führt er schließ lich Endkorrekturen an der ausführbaren XIP-Datei 64' aus, die ebenfalls weiter unten detaillierter beschrieben werden.

Fig. 12a-12c zeigen den Schritt des "Auflösens der Ver schiebungselemente" 320 detaillierter. Wie es dargestellt ist, ruft der XIP-Binder 78'a ein Verschiebungselement 154 des loka lisierten Segments 106a-106d ab, Schritt 374. Wie vorher be schrieben wurde, werden Verschiebungselemente 154 üblicherweise in fortlaufender Reihenfolge abgerufen. Der XIP-Binder 78'a be stimmt dann, ob das Verschiebungselement 154 mit einer internen Referenz verbunden ist, Schritt 376. Wenn das Verschiebungsele ment 154 mit einer internen Referenz verbunden ist, löst der XIP-Binder 78'a es dementsprechend auf, Schritt 378, ansonsten löst der XIP-Binder 78'a das Verschiebungselement 154 als eine externe Referenz auf, Schritt 380.

Es wird nun zu den Fig. 12b-12c gesprungen, in denen die Schritte 378 und 380 detaillierter dargestellt sind. Für eine interne Referenz bestimmt der XIP-Binder 78'a, ob das Referenz segment bewegbar ist, Schritt 396. Wenn das Referenzsegment nicht bewegbar oder fixiert ist, setzt der XIP-Binder 78'a einen Korrektur-Offset auf den Offset 162, der vom Verschie bungselement 154 angegeben wird, Schritt 398. Unabhängig davon, ob das Referenzsegment bewegbar ist, setzt der XIP-Binder 78'a den Korrekturselektor 196 in dem Fall eines nicht bewegbaren Referenzsegmentes auf den vorab zugeordnetenen Selektor 83' des Segmentes, der in dem Verschiebungselement 154 angegeben ist, oder schlägt in dem Fall eines bewegbaren Referenzsegmentes in der Segmenttabelle 113a unter Verwendung des angegebenen Ordi nalwertes 162 nach, der in dem Verschiebungselement 154 angegeben ist, Schritt 400.

Für eine externe Referenz bestimmt der XIP-Binder 78'a, ob das lokalisierte Segment 106a-106d das automatische R/W-Daten segment 106d ist, Schritt 402. Wenn das lokalisierte Segment das automatische R/W-Datensegment 106d ist, unternimmt der XIP- Binder 78'a keine weiteren Aktivitäten. Das Verschiebungsele ment 154 wird von dem Windows-Kernel 66' in der üblichen Weise aufgelöst, wenn es von dem XIP-LADER 84' aufgerufen wird, um dem automatischen R/W-Datensegment 106d RAM zuzuordnen. Wenn das lokalisierte Segment 106a-106d dagegen nicht das automati sche R/W-Datensegment 106d ist, löst der XIP-Binder 78'a die externen Referenzen mit dem Ordinalwert oder dem Namen einer Funktion aus der Modulreferenztabelle 113c auf, der mit Hilfe des angegebenen Indexes 162 in die Modulreferenztabelle 113c abgefragt worden ist, Schritte 404-406. Wenn das Verschiebungs element die Zeiger-Adreßart 156 hat, Schritt 407, setzt der XIP-Binder 78'a ferner das Indirekter-Kandidat-Flag 198, wel ches das Verschiebungselement 154 als einen umstrukturierbaren, externen Referenzkandidaten angibt, Schritt 408.

Es wird nun wieder auf Fig. 12a Bezug genommen. Nachdem die interne/externe Referenz verarbeitet worden ist, bestimmt der XIP-Binder 78'a, ob das additive Flag in der Verschiebungsrefe renzart 158 für das Verschiebungselement 154 gesetzt ist, Schritt 382. Wenn das additive Flag in der Verschiebungsrefe renzart 158 gesetzt ist, löscht der XIP-Binder 78'a das additi ve Flag, Schritt 384, liest den Offsetwert an dem angegebenen Patch-Standort 160, Schritt 386, und addiert den gelesenen Offsetwert zum korrigierenden Selektor oder Offset, je nachdem, ob die Adreßart 156 des Verschiebungselementes die Selek toradreßart ist, Schritte 388-392. Schließlich berichtigt der XIP-Binder 78'a die geeigneten Orte ohne Rücksicht darauf, ob das additive Flag gesetzt ist, Schritt 394.

Fig. 13a-13b zeigen den Schritt "Berichtige Ort(e)" 394 de taillierter. Wie es dargestellt ist, bestimmt der XIP-Binder 78'a, ob das Indirekter-Kandidat-Flag der externen Referenz ge setzt ist, Schritt 412. Wenn das Indirekter-Kandidat-Flag der externen Referenz gesetzt ist, erzeugt der XIP-Binder 78'a eine indirekte Referenz 125 mit den korrigierenden Selektor- und Offsetwerten 196-197. Der XIP-Binder 78'a bestimmt die Adresse der erzeugten indirekten Referenz 125 und speichert die Adresse in den Patch-Standort, Schritt 416. Wenn das Indirekter-Kandi dat-Flag der externen Referenz nicht gesetzt ist, bestimmt der XIP-Binder 78'a außerdem, ob die externe Referenz auf ein Codesegment gerichtet ist, Schritt 418. Wenn die externe Refe renz auf ein Codesegment gerichtet ist und die Verschie bungsadreßart 156 die Offsetart ist, speichert der XIP-Binder 78'a den Offsetwert in den Patch-Standort, Schritte 420-422. Wenn die externe Referenz jedoch auf ein Codesegment gerichtet ist und die Verschiebungsadreßart 156 die Selektorart ist, ve rwendet der XIP-Binder 78'a einen von den Segmentselektoren 83' des vorgegebenen Bereichs, um ein Aliasing des realen Selektors durchzuführen, der vom Windows-Kernel 66' dynamisch zugeordnet werden soll, Schritte 424-426. Wenn der Schritt 426 ausgeführt ist, speichert der XIP-Binder 78'a außerdem die Aliasnamen und Aliasinformationen in dem Patch-Raum für die Alias-Selektoren 127 bzw. Verschiebungsdaten für Aliasnamen 129, Schritt 428.

Wenn die externe Referenz nicht auf ein Codesegment gerich tet ist, führt der XIP-Binder 78'a die Schritte 430-454 für al le Patch-Standorte in der Patch-Standortkette aus. Der XIP-Bin der 78'a bestimmt zunächst, ob das Ende der Kette erreicht wurde, Schritt 430. Das Ende der Kette wurde erreicht, wenn das additive Flag der Verschiebungsart 158 eines Verschiebungsele mentes 154 gesetzt ist, oder ein vorgegebener Offsetwert (wie z. B. xFFFF) von einem Patch-Standort gelesen wurde. Wenn das Ende der Kette nicht erreicht wurde, liest der XIP-Binder 78'a den Operationscode und den Wert an dem Patch-Standort, Schritte 432-434. Als nächstes bestimmt der XIP-Binder 78'a, ob das additive Flag der Verschiebungsart 158 des Verschiebungselemen tes 154 gesetzt wurde, Schritt 438. Wenn das additive Flag ge setzt wurde, notiert der XIP-Binder 78'a, daß das Ende der Kette erreicht wurde, Schritt 440, bevor er mit den Schritten 442-454 fortfährt.

In den Schritten 442-444 überschreibt der XIP-Binder 78'a bedingt das vorausgehende bzw. führende Byte des Patch-Standor tes mit dem indirekten FAR-CALL- bzw. FERN-AUFRUF-Operations code und notiert, daß der ursprüngliche FAR-CALL entfernt wer den kann, wenn die Adreßart des Verschiebungselements 154 die Zeigeradreßart ist und mit einem FAR-CALL-Befehl verbunden ist. In den Schritten 446-448 erzeugt der XIP-Binder 78'a bedingt einen Alias-Selektor und speichert den Aliasnamen und die Aliasinformationen, wie es vorher beschrieben wurde, wenn die Adreßart des Verschiebungselementes 154 die Zeigeradreßart ist, jedoch nicht mit einer FAR-CALL-Instruktion verbunden ist.

Im Schritt 450 schreibt der XIP-Binder 78'a an den Patch- Standort, und zwar dementsprechend von einer Anzahl von Erwä gungen abhängig. Wenn die Verschiebungsadreßart 156 die Selek torart ist, schreibt der XIP-Binder 78'a den korrigierenden Se lektorwert in den Patch-Standort. Wenn die Verschiebungsadreß art 156 die Offsetart ist, schreibt der XIP-Binder 78'a den korrigierenden Offsetwert in den Patch-Standort. Wenn die Ver schiebungsadreßart 156 die Zeigerart ist und mit einem FAR-CALL verbunden ist, schreibt der XIP-Binder 78'a den korrigierenden Offsetwert in den Patch-Standort. Wenn die Verschiebungsadreß art 156 die Zeigerart ist und nicht mit einem FAR-CALL verbun den ist, schreibt der XIP-Binder 78'a die korrigierenden Selek tor- und Offsetwerte in den Patch-Standort.

Schließlich entfernt der XIP-Binder 78'a in den Schritten 452-454 das Verschiebungselement 154 unter der Bedingung, daß das Verschiebungselement 154 eine interne Referenz ist. Der XIP-Binder 78'a kehrt dann zum Schritt 430 zurück.

Fig. 14 zeigt den Schritt 390 der "Endkorrektur" detail lierter. Wie es dargestellt ist, korrigiert der XIP-Binder 78'a zunächst den Informationsblock 111e, Schritt 460. Alle Schnelladefelder in dem Informationsblock 111e werden gelöscht und die Anzahl der Segmenteinträge in dem Informationsblock 111e wird um Eins erhöht, um das neue Selbstladesegment 119d zu berücksichtigen. Das ursprüngliche Codeseg ment:Instruktionszeiger(CS:IP - code segment:instruction poin ter)-Paar in dem Informationsblock 111e wird an einem vorgege benen Ort des Selbstladesegmentes 119d zur späteren Verwendung zur Ausführungszeit gespeichert, und das CS:IP-Feld des Infor mationsblockes 111e wird auf den Eingangspunkt des Selbstlade segmentes 119d gesetzt. Alle Einträge in dem Informationsblock 111e, die Segmentnummern haben, werden um Eins erhöht, um das neue Selbstladesegment 119d zu berücksichtigen. Die Zeiger zu den Kopfzeilentabellen in dem Informationsblock 111e werden so eingestellt, daß sie den neuen Eintrag in der Segmenttabelle 113a, der Modulreferenztabelle 113b und in dem Namenstabellen wachstum berücksichtigen. Schließlich wird das Selbstlade-Flag in dem Informationsblock 111e gesetzt.

Als nächstes korrigiert der XIP-Binder 78'a die Segmentta belle 113a, Schritt 462. Der Eintrag für das automatische R/W- Datensegment in der Segmenttabelle 113a wird so eingestellt, daß deren Vergrößerung berücksichtigt wird und außerdem ihre Mindestzuordnungsgröße erhöht wird. In dem Eintrag wird ein Flag gesetzt, um anzuzeigen, daß das automatische R/W-Datenseg ment 119a Verschiebungsreferenzen 121a hat. Ähnliche Flags wer den in anderen Einträgen für die anderen Segmente 119b-119c ge setzt, um anzugeben, daß diese anderen Segmente 119b-119c keine Verschiebungsreferenzen 121b-121c haben, und die zugehörigen Verschiebungszählwerte in diesen Einträgen werden auf Null ge setzt. Der Eintrag für das Selbstladesegment 119d wird so ein gestellt, daß sein Offset, seine Länge und seine Flags richtig sind.

Der XIP-Binder 78'a korrigiert dann die Ressourcentabelle 113b, Schritt 464, so daß sie die neuen Orte aller Ressourcen in der ausführbaren XIP-Datei 64' angibt. Der XIP-Binder 78'c korrigiert außerdem das Selbstladesegment 119d, Schritt 466. Der in dem Informationsblock 111e gespeicherte CS:IP-Ort wird an einen bestimmten Ort in dem Selbstladesegment 119d geschrie ben. Der bestimmte Ort wird verwendet, wenn das Selbstladeseg ment 106d ausgeführt wird, um der XIP-Anwendung 64' die Steue rung zu übergeben. Der XIP-Binder 78'c korrigiert außerdem die Eintragstabelle 113e, Schritt 468. Der XIP-Binder 78'c durchläuft eine Schleife in der Eintragstabelle 113e, wobei er die Segmentart prüft, auf die Bezug genommen wird. Wenn ein Eintrag auf ein bewegbares Segment hinweist, wird seine Segmentnummer um Eins erhöht, um das neue Selbstladesegment 119d zu berücksichtigen. Wenn der Eintrag exportiert wird, wird der Eingangspunkt untersucht. Wenn der Code für "PUSH DS", "POP AX" oder "MOV AX, DS" gefunden wird, korrigiert der XIP-Binder 78'a den Eingangspunkt mit zwei NOP-Instruktionen bzw. Leerbefehlen. Diese Korrektur dupliziert, was der Windows- Kernel 66' (Lader) beim Laden einer Anwendung tut. Wenn ein Eintrag auf ein festes Segment hinweist, wird seine Segmentnummer in ähnlicher Weise um Eins erhöht, um das neue Selbstladesegment 119d zu berücksichtigen. Wieder wird der Eingangspunkt untersucht, wenn der Eintrag exportiert wird. Wenn der Code für "PUSH DS", "POP AX" oder "MOV AX, DS" gefunden wird, korrigiert der XIP-Binder 78'a auch den Eingangspunkt mit zwei NOP-Instruktionen bzw. Leerbefehlen. Wenn ein Eintrag dagegen auf eine in einem Modul definierte Konstante hinweist, unternimmt der XIP-Binder 78'a keine weiteren Aktionen.

Der XIP-Binder 78'a korrigiert dann die Verschiebungsdaten 121d des Selbstladesegments 119d, um die neue Referenz zu dem XIP-LADER 84' zu berücksichtigen, Schritt 470. Schließlich kor rigiert der XIP-Binder 78'a die Modulreferenztabelle 113c der art, daß sie auf den Anfang des Namens des XIP-Laders 84' in der Tabelle der importierten Namen 113d zeigt, Schritt 472.

Fig. 15-17, 18a-18c und 19-21 zeigen die von verschiedenen Laufzeitelementen ausgeführten Operationsschritte bei der Systeminitialisierung, beim Windows-Start, "Laden" einer XIP- Anwendung, Eingeben einer Task, Ausgeben einer Task und beim Stopp einer Task. Wie in Fig. 15 dargestellt ist, ordnet das XIP-Management 78'a, nachdem es die Steuerung erhalten hat, zur Systeminitialisierungszeit der Taskmanagementdatenstruktur 87' RAM zu, Schritt 476, veranlaßt dann, daß der vorgegebene Be reich der Segmentselektoren 83' sich selbst zugeordnet wird, Schritt 478. Wie vorher beschrieben wurde, fordert das XIP- Management 78'a den Windows-Kernel 66' wiederholt auf, Seg mentselektoren dem XIP-Management 78'a zuzuordnen, bis der vor gegebene Bereich der Segmentselektoren 83' zugeordnet ist. Das XIP-Management 78'a gibt dann die zugeordneten Segmentselekto ren 83' außerhalb des vorgegebenen Bereiches frei.

Wie in Fig. 16 dargestellt ist, erhält der XIP-Initiator 78'b, nachdem ihm die Steuerung übergeben wurde, vom Windows- Kernel 66' zur Windows^TM-Startzeit den Ort des Burgermaster- Segmentes 81'a, Schritt 482. Der XIP-Initiator 78'b erzeugt dann ein Leersegment 106e, vorzugsweise 64K groß, und veranlaßt den Windows-Kernel 66', dem Leersegment einen Segmentselektor 81'b zuzuordnen, Schritt 483. Der XIP-Initiator 78'b erzeugt außerdem unter Verwendung des Leersegmentes 106e ein Leermodul und erhält einen anderen Segmentselektor 85' vom Windows-Kernel 66', Schritt 484. Der XIP-Initiator 78'b schreibt außerdem ein Segmenttabellenbild in das Leermodul, Schritt 486.

Als nächstes informiert der XIP-Initiator 78'b das XIP- Management 78'a über beide Segmentselektoren 85', Schritt 488. Als Antwort berichtigt das XIP-Management 78'a die Segmentdes kriptoren aller Segmentselektoren 83' in dem vorgegebenen Be reich, damit sie auf das Leersegment 106e zeigen, Schritt 490. Dann bestimmt das XIP-Management 78'a den Selektortabellenein trags-Offset des Burgermasters für das Leersegment 106e, Schritt 492. Schließlich ze 13022 00070 552 001000280000000200012000285911291100040 0002019681256 00004 12903igt das XIP-Management 78'a allen Burgermaster-Selektortabelleneinträgen für den vorgegebenen Be reich der Segmentselektoren 83' den Offset des Segmentselektors 85' des Leersegmentes.

Die obigen Schritte werden durchgeführt, um ein bestimmtes Laufzeitverhalten von Windows^TM zu adressieren, insbesondere um sicherzustellen, daß eine bestimmte von Windows^TM durchgeführte Laufzeitprüfung trotz der neuen Verwendung des vorab zugeordne ten, vorgegebenen Bereichs der Segmentselektoren 83' noch durchlaufen wird.

Wie in Fig. 17 dargestellt ist, aktualisiert der XIP-LADER 84', nachdem er, wie vorher beschrieben wurde, die Steuerung vom Selbstladesegment 106a erhalten hat, zur "Lade"-Zeit der XIP-Anwendung die Modultabelle für die XIP-Anwendung 64', Schritt 506. (Der XIP-LADER 84' "registriert" sich selbst auch bei WERKZEUG-HILFE für Hinweise über Taskwechsel, wenn er als erster aufgerufen wird (dieser Schritt ist nicht dargestellt)). Der XIP-LADER 84' berührt dann alle Aliasnamen, wobei dies dazu führt, daß alle "Lade bei Aufruf"- und "Lade bei Anforderung"- Segmente und die Segmentdeskriptoren dieser Selektoren vom Windows-Kernel 66' in den Speicher geladen werden. Der XIP- LADER 84' läuft dann eine Schleife durch die Segmenttabelle der Modultabelle, wobei der vorab zugeordnete, vorgegebene Bereich der Segmentselektoren 83' für alle Segmente bis auf das automa tische R/W-Datensegment eingefüllt wird, Schritte 510-514. Der XIP-LADER 84' läuft dann wieder eine Schleife durch die Seg menttabelle der Modultabelle, wobei er veranlaßt, daß der Windows-Kernel 66' dem automatischen R/W-Datensegment 106d RAM zuordnet, ordnet dem automatischen R/W-Datensegment 106d einen Segmentselektor 85' zu, berichtigt die Segmentdeskriptoren des zugeordneten Segmentselektors 85' und löst alle Verschiebungs elemente 154 des automatischen R/W-Datensegments 106d auf, Schritte 516-518. Die Schritte 516-518 werden nach den Schrit ten 510-514 durchgeführt, um es dem Windows-Kernel 66' zu er möglichen, daß er alle Verschiebungselemente 154 des automati schen R/W-Datensegmentes 106d richtig auflösen kann.

Als nächstes kehrt der XIP-LADER 84' zum Windows-Lader zu rück, um die Taskerzeugung der XIP-Anwendung 64' zu beenden. Als Antwort ordnet der Windows-Kernel 66' den Bezeichner der XIP-Anwendung in der Taskwarteschlange an. Zu gegebener Zeit erhält das Selbstladesegment 106a wieder die Steuerung. Auf grund der bereits beschriebenen CS:IP-Berichtigung in dem Selbstladesegment 106a wird die Ausführungssteuerung sofort zu dem XIP-LADER 64' zurückübertragen. Der XIP-LADER 84' infor miert dann das XIP-Management 82'a von dem Taskstart und führt die Ausführung an dem ursprünglichen CS:IP fort, Schritte 522-524.

Wie in Fig. 18a gezeigt ist, erzeugt das XIP-Management 82'a, nachdem es von dem XIP-LADER 84' benachrichtigt wurde, zur Taskstartzeit einen Taskdeskriptor 204 und die zugehörige Tasksegmentdeskriptorseite 206, Schritt 206. Fig. 18b zeigt den Schritt 206 detaillierter. Das XIP-Management 82'a inkremen tiert den Taskzählwert 210 zunächst, Schritt 564. Dann bestimmt das XIP-Management 82'a, ob es freie Taskdeskriptoreinträge 204 gibt, Schritt 565. Wenn es keine freien Taskdeskriptoreinträge 204 gibt, ordnet das XIP-Management 82'a weitere freie Taskdes kriptoreinträge 204 zu und zugehörige Tasksegmentdeskriptorsei ten 206, Schritt 566. Nachdem das XIP-Management 82'a bestimmt hat, daß es freie Taskdeskriptoreinträge 204 gibt oder neue Deskriptoreinträge erzeugt hat, lokalisiert es den nächsten freien Taskdeskriptoreintrag 204 in der Taskmanagementdaten struktur 89' und speichert die Bezeichnung der beginnenden Task in den Eintrag, Schritte 567-568. Das XIP-Management 82'a loka lisiert dann die zugehörige freie Tasksegmentdeskriptorseite 206 und erzeugt Leersegmentdeskriptoren überall in der neu zu geordneten Tasksegmentdeskriptorseite 206, Schritte 570-572. Zum Schluß füllt das XIP-Management 82'a die Segmentdeskriptor seite 206 auf der Basis der Informationen in der Segmenttabelle der Modultabelle aus, Schritt 574.

Es wird wieder auf Fig. 18a Bezug genommen. Nachdem das XIP-Management 82'a den Taskdeskriptor 204 und die zugehörige Tasksegmentdeskriptorseite 206 erzeugt hat, setzt es die begin nende Task als aktuelle Task, Schritt 538. Das XIP-Management 82'a lokalisiert das Modul, Schritt 540, und ruft die Adresse des Selbstladesegmentes 106a und die Anzahl der Alias-Selekto ren ab, Schritte 542 und 544. Dann berechnet und speichert das XIP-Management 82'a den Selektorzählwert 216, Schritt 546. Au ßerdem identifiziert das XIP-Management das automatische R/W- Datensegment 106d der aktuellen Task im Bezeichner 218 und zeichnet es auf, Schritt 548. Als nächstes lokalisiert das XIP- Management 82'a den Selektortabelleneintrag des Burgermasters, Schritt 550, berechnet und speichert den "XIP-Selektor" des au tomatischen R/W-Datensegments, d. h. den "Alias-Selektor" in dem vorgegebenen Bereich der Segmentselektoren 83'. Das XIP-Manage ment 82'a bestimmt außerdem, ob der Objektzählwert für das Mo dul gleich 1 ist, Schritt 554. Wenn der Objektzählwert nicht gleich 1 ist, findet das XIP-Management gültige Segmentdes kriptoren von vorangegangenen Objekten und kopiert sie in den Windows-LDT, bevor es zu dem Schritt 558 weitergeht.

In jedem Fall löst das XIP-Management 82'a im Schritt 558 die Alias-Selektoren 83' zu deren richtigen dynamisch zugeord neten Selektoren 85' auf oder berichtigt die Alias-Selektoren 83' als bedeutungsvolle fehlerhafte Zeiger oder MBPs. MBPs wer den erzeugt, indem die reale Segmentselektornummer in dem Ba sisabschnitt 54 des Segmentdeskriptors 46 des bestimmten Seg mentselektors aus dem vorab zugeordneten, vorgegebenen Bereich der Segmentselektoren 83' angeordnet wird, und der Segmentdes kriptor 46 wird als TSS markiert. Da das Zugreifen auf einen TSS-Deskriptor einen allgemeinen Speicherzugriffsfehler er zeugt, kann dem XIP-Initiator 82'b auf diese Weise die Steue rung übertragen werden. Zum Schluß baut das XIP-Management 82'a den vorgegebenen Bereich der Selektoren für alle Segmente auf, Schritt 560, und lagert die Tasksegmentdeskriptorseite 206 der aktuellen Task ein, Schritt 562.

Fig. 18c zeigt den Schritt 560 detaillierter. Das XIP- Management 82'a ruft das erste Segment 106a-106d ab, Schritt 576. Das Segment 106a-106d wird üblicherweise in fortlaufender Reihenfolge erhalten. Als nächstes bestimmt das XIP-Management 82'a, ob das Segment 106a-106d das automatische R/W-Datenseg ment 106d ist. Wenn es nicht das automatische R/W-Datensegment 106d ist, setzt das XIP-Management 82'a das Basisfeld auf die Summe der Flash-Speicheradresse, des Offsets der XIP-Anwendung und des Segmentoffsets innerhalb der ausführbaren Datei, Schritt 580, setzt das Deskriptor-Flag auf "Code", Schritt 582, und setzt das Limit auf "Segmentgröße", Schritt 584. Wenn dage gen das lokalisierte Segment das automatische R/W-Datensegment 106d ist, kopiert das XIP-Management die Segmentdeskriptorin formationen des von dem Windows-Kernel 66' zugeordneten Seg mentselektors 35', Schritt 586. Vorzugsweise befreit das XIP- Management 82'a außerdem den von Windows zugeordneten Selektor, Schritt 588, und setzt den Segmentsektor auf Null, um seine Wiederverwendung zu verhindern, Schritt 590.

Wie in Fig. 19 dargestellt ist, bestimmt das XIP-Management 82'a zur Taskeingangszeit, nachdem es von dem XIP-LADER 84' in formiert wurde, ob die eingehende Task eine XIP-Task ist, Schritt 594. Wenn die eingehende Task keine XIP-Task ist, un ternimmt das XIP-Management 82'a keine weiteren Aktionen. Wenn die eingehende Task dagegen eine XIP-Task ist, sichert das XIP- Management 82'a die Adresse des Deskriptors der eingehenden Task als Zeiger 214, Schritt 596. Als nächstes speichert das XIP-Management 82'a die Arena-Adresse des Burgermasters in dem Selektoreintrag des Burgermasters für das automatische R/W-Da tensegment 106d, Schritt 598. Zum Schluß kopiert das XIP- Management 82'a die Tasksegmentdeskriptorseite der eingehenden XIP-Task in die Segmentdeskriptoren des vorab zugeordneten Be reichs der Segmentselektoren 83', Schritt 600.

Wie in Fig. 20 dargestellt ist, bestimmt das XIP-Management 82'a zur Taskausgangszeit, wenn es von dem XIP-LADER 84' infor miert worden ist, ob die abgehende Task eine XIP-Task ist, Schritt 604. Wenn die abgehende Task keine XIP-Task ist, unter nimmt das XIP-Management 82'a keine weiteren Aktionen. Wenn die abgehende Task dagegen die aktuelle XIP-Task ist, setzt das XIP-Management 82'a den aktuellen Taskdeskriptorzeiger 214 auf Null, Schritt 606. Als nächstes setzt das XIP-Management 82'a den Selektoreintrag des Burgermasters für das automatische R/W- Datensegment 106d auf die Burgermaster-Arena-Adresse des Leer segmentes 106e, Schritt 608. Zum Schluß kopiert das XIP-Manage ment 82'a die Tasksegmentdeskriptorseite des Leersegmentes in die Segmentdeskriptoren des vorab zugeordneten, vorgegebenen Bereichs der Segmentselektoren 83', Schritt 610.

Wie es in Fig. 21 gezeigt ist, bestimmt das XIP-Management 82'a zur Taskstoppzeit, wenn es von dem XIP-LADER 84' infor miert wurde, ob die stoppende Task die aktuelle XIP-Task ist, Schritt 614. Falls die stoppende Task die aktuelle XIP-Task ist, führt das XIP-Management 82'a die Schritte des Taskaus gangs aus, die vorher beschrieben wurden, und fährt dann mit dem Schritt 620 fort. Wenn die stoppende Task dagegen nicht die aktuelle XIP-Task ist, bestimmt das XIP-Management 82'a, ob die stoppende Task überhaupt eine XIP-Task ist, Schritt 618. Wenn die stoppende Task keine XIP-Task ist, unternimmt das XIP- Management 82'a keine weiteren Aktionen. Ansonsten geht das XIP-Management zu dem Schritt 620 über. Im Schritt 622 berei nigt das XIP-Management 82'a den Taskdeskriptor 204 und die zu gehörige Tasksegmentdeskriptorseite 206 der stoppenden Task, Schritt 620, dekrementiert den Taskzählwert, Schritt 622. Zu sätzlich aktualisiert das XIP-Management 82'a die Modultabelle entsprechend, Schritt 623.

Auf diese Weise wurde ein Verfahren und eine Einrichtung zum Ausführen einer Anwendung vom ROM, Flash-Speicher, o. dgl. am Platz beschrieben. Obwohl die vorliegende Erfindung anhand der oben dargestellten Ausführungsbeispiele beschrieben wurde, ist es für den Fachmann zu erkennen, daß die Erfindung nicht auf die beschriebenen Ausführungsbeispiele beschränkt ist. Die vorliegende Erfindung kann mit Modifikationen und Änderungen innerhalb des Erfindungsgedankens und Schutzbereichs der anlie genden Ansprüche ausgeführt werden. Daher ist die Beschreibung nur als Veranschaulichung zu verstehen und soll die vorliegende Erfindung nicht beschränken.

Claims

1. Computersystem (10) mit:
einem Speichermedium, das ein erstes Programm (78) spei chert, das eine Logik zum Lesen einer verschiebbaren aus führbaren Datei (62) eines zur Ausführung aus einem Speicher mit wahlfreiem Zugriff (RAM; 14, 16) vorgesehenen zweiten Programms und zum Umwandeln der verschiebbaren ausführbaren Datei (62) in eine am Platz ausführbare Datei (64) umfaßt, wobei die am Platz ausführbare Datei zur Ausführung aus ei nem Schreib-Einmal-(18a) oder Schreib-Selten(18b)-Speicher medium vorgesehen ist, in welches die am Platz ausführbare Datei gespeichert werden soll,
wobei das erste Programm (78) verschiebbare Elemente (103) in der verschiebbaren ausführbaren Datei (62) derart genügend auflöst, daß keine weiteren Schreiboperationen in die am Platz ausführbare Datei (64) erforderlich sind, bevor die am Platz ausführbare Datei am Platz ausgeführt werden kann, nachdem sie in das Schreib-Einmal/Selten-Speichermedi um (18) gespeichert worden ist,
wobei das erste Programm (78) die verschiebbaren Elemen te (103) genügend auflöst, indem es einen vorgegebenen Ab schnitt (83) einer Speichermanagementdatenstruktur (81) ei nes Betriebssystems verwendet, welches zur Verwaltung der Am-Platz-Ausführung des zweiten Programms verwendet werden soll, und sich darauf verläßt, daß der vorgegebene Abschnitt (83) der Speichermanagementdatenstruktur (81) bei Bedarf dem am Platz ausführenden zweiten Programm zur Verfügung ge stellt und zur Ausführungszeit mit den richtigen Speicher adressen berichtigt werden kann.

2. Computersystem nach Anspruch 1, dadurch gekennzeich net, daß die verschiebbaren Elemente (103) externe Referen zen (103b) enthalten, wobei das erste Programm (78) einige der externen Referenzen (103b) dadurch auflöst, daß diese externen Referenzen in indirekte externe Referenzen (107c, d) umstrukturiert werden, die durch einen Lese/Schreib-Datenbe reich (105b) des zweiten Programms gehen.

3. Computersystem nach Anspruch 1 oder 2, dadurch ge kennzeichnet, daß in dem Speichermedium außerdem ein drittes Programm (80) gespeichert ist, das eine Logik umfaßt, um die am Platz ausführbare Datei (64) des zweiten Programms auf einem Schreib-Selten-Speichermedium (18) zu installieren.

4. Computersystem nach einem der Ansprüche 1-3, dadurch gekennzeichnet, daß das erste Programm ein Umwandlerprogramm und das zweite Programm ein vorhandenes, für die Ausführung aus einem Speicher mit wahlfreiem Zugriff vorgesehenes Pro gramm ist.

5. Computersystem nach einem der Ansprüche 1-3, dadurch gekennzeichnet, daß das erste Programm ein Binder-Programm und das zweite Programm ein kompiliertes Programm ist.

6. Computersystem nach einem der Ansprüche 1-3, dadurch gekennzeichnet, daß der vorgegebene Abschnitt der Speicher managementdatenstruktur ein vorgegebener Bereich von Spei chersegmentselektoren einer Speichersegmentdeskriptortabelle ist.

7. Computersystem nach Anspruch 6, dadurch gekennzeich net, daß die verschiebbaren Elemente externe Referenzen ent halten, und das erste Programm externe "FAR CALL"- bzw. "FERN-AUFRUF"-Referenzen auflöst, indem diese externen FERN- AUFRUF-Referenzen in indirekte, externe FERN-AUFRUF-Referen zen über ein Lese/Schreib-Datensegment des zweiten Programms umstrukturiert werden.

8. Computersystem nach Anspruch 6, dadurch gekennzeich net, daß das erste Programm außerdem ein Selbstladeprogramm segment (106a) in das am Platz ausführende zweite Programm (64) einfügt, und das am Platz ausführende zweite Programm derart markiert wird, daß das Selbstladeprogrammsegment (106a) von dem Betriebssystem die Steuerung erhält, wenn das Betriebssystem in Erwiderung einer Anforderung zur Ausfüh rung des am Platz ausführenden zweiten Programms das am Platz ausführende zweite Programm zu laden versucht.

9. Computersystem nach Anspruch 6, dadurch gekennzeich net, daß in dem Speichermedium außerdem ein drittes Programm (80) gespeichert ist, das eine Logik umfaßt, um die am Platz ausführbare Datei des zweiten Programms auf einem Schreib- Einmal/Selten-Speichermedium (18) zu installieren.

10. Computersystem (10) mit: einem Speichermedium, welches ein erstes Programm (82) speichert, das eine Logik umfaßt, um einen vorgegebenen Ab schnitt (83) einer Speichermanagementdatenstruktur (81) ei nes Betriebssystems zur Systeminitialisierungszeit zu reser vieren, um den reservierten vorgegebenen Abschnitt (83) der Speichermanagementdatenstruktur (81) einem zweiten Programm (64) neu zuzuweisen, wenn das zweite Programm (64) am Platz ausgeführt werden soll, und um den neu zugewiesenen, vorge gebenen Abschnitt (83) der Speichermanagementdatenstruktur (81) mit den richtigen Speicheradressen eines Schreib-Ein mal/Selten-Speichermediums (18) zu berichtigen, in welchem das am Platz ausführende zweite Programm (64) gespeichert ist, wobei das Betriebssystem zur Verwaltung der Ausführung des zweiten Programms am Platz verwendet wird.

11. Computersystem nach Anspruch 10, wobei das erste Programm außerdem eine Logik (84) umfaßt, um zu veranlassen, daß Speicher (105b) mit wahlfreiem Zugriff sowohl für Lese- als auch für Schreib-Datenbereiche des am Platz ausführenden zweiten Programms (64) zugewiesen wird.

12. Computersystem nach Anspruch 10, wobei in dem Spei chermedium außerdem ein drittes Programm (86) gespeichert ist, welches eine Logik umfaßt, um eine Managementdaten struktur (87) für eine am Platz ausführende Task zu erzeugen und aufrechtzuerhalten, wobei die Managementdatenstruktur (87) Taskmanagementinformationen (89) enthält, um ein Multi tasking des am Platz ausführenden zweiten Programms (64) und weiterer am Platz ausführender Programme zu ermöglichen, die auf die gleiche Weise erzeugt wurden, wie das am Platz aus führende zweite Programm, wobei die Taskmanagementinforma tionen (89) die richtigen Speicheradressen des Schreib-Ein mal/Selten-Speichermediums (18) der verschiedenen am Platz ausführenden Programme enthalten, um bei einem Taskwechsel den vorgegebenen Abschnitt (83) der Speichermanagementdaten struktur (81) zu berichtigen.

13. Computersystem nach Anspruch 10, dadurch gekenn zeichnet, daß der vorgegebene Abschnitt der Speichermanage mentdatenstruktur ein vorgegebener Bereich von Speicherseg mentselektoren ist.

14. Computersystem nach Anspruch 13, dadurch gekenn zeichnet, daß das erste Programm eine Logik umfaßt, um ein Blind-Programmsegment und unter Verwendung des Blind-Pro grammsegmentes ein Blind-Programmmodul zu erzeugen, und um die Berichtigungslogik dann zu veranlassen, die zugehörigen Speichersegmentdeskriptoren derart zu berichtigen, daß der vorab zugewiesene Bereich der Speichersegmentselektoren vollständig auf das Blind-Programmsegment zeigt.

15. Computersystem nach Anspruch 13, dadurch gekenn zeichnet, daß das erste Programm von einem Selbstladesegment (106a), welches ein integraler Teil des am Platz ausführen den zweiten Programms (64') ist, die Steuerung erhält, wobei das Selbstladesegment (106a) von dem Betriebssystem die Steuerung erhält, wenn das Betriebssystem versucht, das am Platz ausführende zweite Programm in Erwiderung einer Anfor derung zur Ausführung des am Platz ausführenden zweiten Pro gramms zu laden.

16. Computersystem nach Anspruch 13, dadurch gekenn zeichnet, daß die Berichtigungslogik des ersten Programms eine Logik umfaßt, um ein Aliasing von einigen aus dem er neut zugewiesenen, vorgegebenen Bereich der Speichersegment selektoren zu von dem Betriebssystem dynamisch zugeordneten Speichersegmentselektoren durchzuführen und um einige aus dem erneut zugewiesenen, vorgegebenen Bereich der Speicher segmentselektoren als bedeutungsvolle fehlerhafte Zeiger pseudozuberichtigen, die Speicherzugriffsfehler verursachen, wenn sie von einem Befehl referenziert werden.

17. Computersystem nach Anspruch 16, dadurch gekenn zeichnet, daß in dem Speichermedium außerdem ein drittes Programm gespeichert ist, das eine Logik umfaßt, um einen von einer Referenz zu einem bedeutungsvollen fehlerhaften Zeiger verursachten Speicherzugriffsfehler zu bedienen, ein schließlich einer Logik, um den referenzierenden Befehl für einen Identifizierer des Speichersegmentselektors zurückzu übersetzen, wobei der Speichersegmentselektor berichtigt wird und der referenzierende Befehl erneut ausgegeben wird.

18. Computersystem nach Anspruch 17, dadurch gekenn zeichnet, daß in dem Speichermedium ein drittes Programm (86) gespeichert ist, das eine Logik umfaßt, um eine Manage mentdatenstruktur (87) einer am Platz ausführenden Task zu erzeugen und aufrechtzuerhalten, wobei die Managementdaten struktur (87) Taskmanagementinformationen (89) enthält, um ein Multitasking des am Platz ausführenden zweiten Programms (64) und weiterer am Platz ausführender Programme zu er leichtern, die auf die gleiche Weise erzeugt wurden, wie das am Platz ausführende zweite Programm, wobei die Taskmanage mentinformationen (89) die richtigen Adressen des Schreib- Einmal/Selten-Speichermediums (18) der verschiedenen am Platz ausführenden Programme enthalten, um die zugehörigen Speichersegmentdeskriptoren des vorgegebenen Bereichs (83) der Speichersegmentselektoren abwechselnd zu berichtigen.

19. Computersystem nach Anspruch 18, dadurch gekenn zeichnet, daß die Taskmanagementdatenstruktur-Erzeugungs- und -aufrechterhaltungs-Logik eine Logik zum Erzeugen eines Taskdeskriptoreintrages und eines Zeigers (214; 222) auf ei ne zugehörige Taskspeichersegmentdeskriptorseite für eine am Platz ausführende Task umfaßt, wenn die am Platz ausführende Task gestartet wird, und wobei der erzeugte Taskdeskriptor eintrag und die zugehörige Taskspeichersegmentdeskriptor seite zerstört werden, wenn die am Platz ausführende Task beendet wird, wobei der Taskdeskriptoreintrag beschreibende Basisinformationen über die beginnende ausführende Task und einen Zeiger auf die zugehörige Taskspeichersegmentdeskript orseite enthält, und wobei die zugehörige Taskspeicherseg mentdeskriptorseite Berichtigungsinformationen enthält, um den vorgegebenen Bereich der Speichersegmentselektoren für die Am-Platz-Ausführung der beginnenden am Platz ausführen den Task zu berichtigen.

20. Computersystem nach Anspruch 19, dadurch gekenn zeichnet, daß die Taskmanagementdatenstruktur-Erzeugungs- und -Aufrechterhaltungs-Logik außerdem eine Logik umfaßt, um Speicherraum einer ersten Tabelle zum Speichern von mehreren Taskdeskriptoreinträgen und einer zweiten Tabelle zum Spei chern von mehreren zugehörigen Taskspeichersegmentdeskript orseiten zuzuweisen und um die erste und die zweite Tabelle zu komprimieren.

21. Computersystem nach Anspruch 18, dadurch gekenn zeichnet, daß das erste Programm außerdem eine Logik umfaßt, um die in den Tasksegmentdeskriptorseiten gespeicherten In formationen in die zugehörigen Speichersegmentdeskriptoren des vorgegebenen Bereichs der Speichersegmentselektoren zur Taskeingangszeit und zur Taskausgangszeit einzulagern und aus diesen auzulagern, wenn eine am Platz ausführende Task ein- oder ausgeschaltet wird.

22. Computergestütztes Verfahren zur Erzeugung eines am Platz ausführbaren Programms in einem Computersystem, wobei:

a) eine verschiebbare ausführbare Datei eines Programms gelesen wird, die zur Ausführung aus einem Speicher mit wahlfreiem Zugriff heraus vorgesehen ist, in der verschieb baren ausführbaren Datei enthaltene verschiebbare Elemente analysiert werden und zur Auflösung dieser verschiebbaren Elemente benötigte Informationen verfolgt werden;
b) die verschiebbare ausführbare Datei in eine am Platz ausführbare Datei umgewandelt wird, die zur Ausführung aus einem Schreib-Einmal- oder Schreib-Selten-Speichermedium heraus vorgesehen ist, in welches die am Platz ausführbare Datei gespeichert werden soll,

wobei die verschiebbaren Elemente in der verschiebbaren, ausführbaren Datei derart aufgelöst werden, daß keine weite ren Schreiboperationen in die am Platz ausführbare Datei be nötigt werden, bevor die am Platz ausführbare Datei am Platz ausgeführt werden kann, wobei die verfolgten Informationen und ein vorgegebener Abschnitt einer Speichermanagementda tenstruktur eines zur Verwaltung der Ausführung des zweiten Programms am Platz verwendeten Betriebssystems verwendet werden, und wobei sich darauf verlassen wird, daß der vor gegebene Abschnitt der Speichermanagementdatenstruktur bei Bedarf dem am Platz ausführenden zweiten Programm zur Verfü gung gestellt und zur Ausführungszeit mit den richtigen Speicheradressen berichtigt werden kann.

23. Verfahren nach Anspruch 22, dadurch gekennzeichnet, daß die verschiebbaren Elemente externe Referenzen enthal ten, und wobei der Schritt (b) das Auflösen einiger externer Referenzen enthält, indem diese externen Referenzen in indi rekte externe Referenzen über einen Lese/Schreib-Datenbe reich des Programms umstrukturiert werden.

24. Verfahren nach Anspruch 22 oder 23, dadurch gekenn zeichnet, daß das Verfahren außerdem den Schritt (c) ent hält, daß die am Platz ausführbare Datei des Programms auf einem Schreib-Selten-Speichermedium installiert wird.

25. Computergestütztes Verfahren zur Ausführung eines Programms aus einem Schreib-Einmal/Selten-Speichermedium heraus, wobei:

a) ein vorgegebener Abschnitt einer Speichermanagement datenstruktur eines Betriebssystems zur Systeminitialisie rungszeit reserviert wird, wobei das Betriebssystem nachfol gend verwendet wird, um die Ausführung des Programms am Platz zu verwalten;
b) der reservierte, vorgegebene Abschnitt der Speicher managementdatenstruktur dem Programm neu zugewiesen wird, wenn das Programm am Platz ausgeführt werden soll; und
c) der vorgegebene Abschnitt der Speichermanagementda tenstruktur mit den richtigen Speicheradressen des Schreib- Einmal/Selten-Speichermediums berichtigt wird.

26. Verfahren nach Anspruch 25, dadurch gekennzeichnet, daß (d) veranlaßt wird, daß Speicher mit wahlfreiem Zugriff Lese- sowie Schreib-Datenbereichen des am Platz ausführenden zweiten Programms zugeordnet wird.

27. Verfahren nach Anspruch 25 oder 26, dadurch gekenn zeichnet, daß eine am Platz ausführende Taskmanagementdaten struktur erzeugt und aufrechterhalten wird, die Taskmanage mentinformationen enthält, um ein Multitasking des am Platz ausführenden Programms und weiterer am Platz ausführender Programme zu ermöglichen, die in der gleichen Weise wie das am Platz ausführende Programm erzeugt wurden, wobei die Taskmanagementinformationen die richtigen Speicheradressen des Schreib-Einmal/Selten-Speichermediums der verschiedenen am Platz ausführenden Programme enthalten, um den vorgegebe nen Abschnitt der Speichermanagementdatenstruktur abwech selnd zu berichtigen.