DE69230778T2 - Dynamische Programmverknüpfung zwischen Programmadressbereichen im Nicht-Überwachungsmodus - Google Patents

Description

HINTERGRUND DER ERFINDUNG 1. Gebiet der Erfindung:
• Die vorliegende Erfindung bezieht sich auf die Gebiete der verteilten Computersysteme, des verteilten Betriebssystems und der objekt-orientierten Programmierung. Insbesondere bezieht sich die vorliegende Erfindung auf das dynamische Queradreßraum-Verbinden von Programmcodesegmenten beim Programmstart und auf das dynamische Verbinden eines Programmcodesegmentes mit einem Prozeß.
2. Hintergrund:
• Heute erlauben die meisten modernen Computersysteme mit virtuellen Speichersystemen und Multiprocessing, daß mehr als ein Adreßraum zugleich aktiv ist. Die zentrale Verarbeitungseinheit (CPU) oder -einheiten schaltet/schalten zwischen den aktiven Adreßräumen mit hoher Geschwindigkeit. Ein Adreßraum ist eine Reihe von logischen Adressen, die eine Reihe von Speicherplätzen darstellen, in denen Programme und Daten gespeichert werden können.
• Adreßräume bilden eine Sicherheitsschutzebene für das Computersystem. Typischerweise kann ein Prozeß, der in einem Nicht-Supervisor-Modus in einem Adreßraum ausgeführt wird, nicht auf einen anderen Prozeß zugreifen, der in einem anderen Adreßraum ausgeführt wird, außer durch besondere, vom Betriebssystem bereitgestellte Mittel. Dies hindert einen Prozeß in einem Adreßraum, dessen Sicherheit gefährdet worden ist, daran, das ganze Computersystem zu beschädigen. Ein Prozeß ist eine Instanz eines Programms in der Ausführung.
• Auf der anderen Seite sind von einem Prozeß im Supervisor-Modus durchgeführte Operationen per Definition sicher. Das Eintreten in den Supervisor-Modus, bevor es einem Prozeß gestattet wird, Operationen an einem Adreßraum durchzuführen, sichert, daß die Systemsicherheit nicht gefährdet wird. Herkömmliche Betriebssysteme erfordern somit typischerweise, daß ein Prozeß in den Supervisor- Modus eintritt, ehe ein Programm dynamisch in einen Adreßraum geladen werden kann. Das Laden eines Programms in einen Adreßraum umfaßt das Erlangen von Speicher aus dem Betriebssystem und das Zuordnen des Binärcodes eines Programms zu dem erlangten Speicher.
• Falls das Programm aus mehreren nicht verbundenen Segmenten des Binärcodes besteht, und falls die Segmente des Binärcodes statisch nicht mitander verbunden worden sind, ehe die Ausführung des Programms in den Adreßraum geladen wird, müssen die Segmente des Binärcodes dynamisch miteinander verbunden werden, nachdem sie in den Adreßraum geladen worden sind, und ehe die Ausführung des Programms gestartet werden kann. Falls das Programm statisch verbunden worden ist, wird typischerweise nur ein "Segment" des Binärcodes geladen. Andernfalls wird mehr als ein Segment des Binärcodes geladen. Üblicherweise erfordern Betriebssysteme außerdem, daß der Prozeß das dynamische Verbinden im Supervisor-Modus oder in demjenigen Adreßraum durchführt, in dem der zu verbindende Programmcode angeordnet worden ist. Das Verbinden von Segmenten des Binärcodes umfaßt das Auflösen von Referenzen in einem Segment des Binärcodes, was Adressen in dem anderen erfordert.
• Ein dynamisch verbundenes Programm erfordert typischerweise ferner das Aufrufen einer Initialisierungsfunktion, ehe mit der Ausführung gestartet werden kann. Die Initialisierung baut die vom Programmiersprachen-Laufzeitsystem des verbundenen Programms erforderten Anfangszustände auf und ist notwendig für die korrekte Ausführung des verbundenen Programms.
• Das dynamische Queradreßraum-Verbinden im Supervisor- Modus war ursprünglich ein Teil des Multix-Betriebssystems und von TENIX. Da man aber fand, daß das dynamische Queradreßraum-Verbinden im Supervisor-Modus einen unangemessen hohen Mehraufwand zur Folge hatte, wurde es in den meisten Betriebssystemen weggelassen, bis es im UNIXTM System V (UNIXTM ist eine eingetragene Marke der Firma Unix Laboratory) wiedereingeführt wurde. Heute wird das dynamische Queradreßraum-Verbinden im Supervisor-Modus in OSF/1 angeboten. Eine nähere Beschreibung des dynamischen Queradreßraum-Verbindens im Supervisor-Modus unter diesen Betriebssystemen ist zu finden in E.I. Organick, The Multics System: An Examination of Its Structure, MIT Press, 1972, D.L. Murphy, Storage organization and management in TENIX, Proceedings of the Fall Joint Computer Conference, AFIPS, 1972, J.Q. Arnold, Shared Libraries on Unix System V, Summer Conference Proceedings, USENIX Association, 1986, und L.W. Allen, H.G. Singh, K.G. Wallace und M.B. Weaver, Program Loading in OSF/1, Proceedings of the USENIX Winter 1991 Conference, 1991.
• Das dynamische Verbinden innerhalb eines Adreßraumes im Nicht-Supervisor-Modus wurde im SunOS 4.1-Betriebssystem verfügbar, das von der Erwerberin der Rechte an der vorliegenden Erfindung, Sun Microsystems, InC. aus Mountain View, Kalifornien, angeboten wird (SunTM ist eine eingetragene Marke der Firma Sun Microsystems, Inc.). Unter SunOS 4.1 kann ein Prozeß, ohne daß er zuerst in den Supervisor-Modus eintreten muß, dynamisch gemeinsame Bibliotheken mit sich selbst verbinden, wenn er startet. Da das dynamische Verbinden im Nicht-Supervisor-Modus sich auf das Verbinden von gemeinsamen Bibliotheken zu dem Prozeß selbst beschränkt, kann folglich ein Prozeß mit gefährdeter Sicherheit nur den Adreßraum beinflussen, in dem der Prozeß ausgeführt wird. Eine nähere Beschreibung des dynamischen Verbindens unter SunOS 4.1 ist zu finden in R.A. Gingell, M. Lee, X.T. Dang und M.S. Weeks, Shared Libraries in SunOS, Proceedings of USENIX Summer 1987 Conference, 1987. Ein ähnliches Verfahren wird für das dynamische Verbinden in UNIXTM System V Release 4 angewandt, siehe System V Application Binding Interface, Prentice Hall, 1991.
• Wenn auch das Beschränken des dynamischen Verbindens über Adreßräume auf im Supervisor-Modus ausführende Prozesse oder auf Prozesse in dem Adreßraum, in dem der zu verbindende Programmcode lokalisiert ist, den Vorteil hat, daß ein Prozeß, der die Sicherheit gefährdet, nicht das ganze System gefährden kann, beschränkt dies stark den Umfang, in dem das dynamische Verbinden für die sichere Änderung des Ausführungsverhaltens eines Prozesses verwendet werden kann. Es ist daher erwünscht, einen im Nicht- Supervisor-Modus ausführenden Prozeß zu erlauben, ein dynamisches Verbinden über Adreßräume durchzuführen, ohne daß die Sicherheit des Systems gefährdet wird.
ZUSAMMENFASSENDE DARSTELLUNG DER ERFINDUNG
• Es ist daher die Aufgabe der vorliegenden Erfindung, die Fähigkeit des dynamischen Queradreßraum-Verbindens mit im Nicht-Supervisor-Modus ausführenden Prozessen ohne Gefährdung der Sicherheit des Computersystems vorzusehen.
• Es ist die Aufgabe der vorliegenden Erfindung, die Fähigkeit des dynamischen Queradreßraum-Verbindens eines Programmsegmentes einem Prozeß sowie Programmsegmenten beim Programmstart zur Verfügung zu stellen.
• Mit der vorliegenden Erfindung werden diese und andere Aufgaben dadurch gelöst, daß ein erster Programmcodemanager, der ein erstes Programmcodesegment für einen ersten im Nicht-Supervisor-Modus ausführenden Prozeß in einem ersten Adreßraum sicher zur Verfügung stellt, und ein Adreßraummanager zum Abbilden des ersten Programmcodesegmentes in einen zweiten Adreßraum und zum Verbinden des ersten Programmcodesegmentes mit entweder einem zweiten Programmcodesegment, wenn der zweite Adreßraum ein neuer Adreßraum ohne ausführenden Prozeß ist, oder mit einem zweiten Prozeß, wenn der zweite Adreßraum einen ausführenden Prozeß aufweist, vorgesehen sind.
• Für den Fall, daß der zweite Adreßraum ein neuer Adreßraum ohne ausführenden Prozeß ist, sieht die vorliegende Erfindung auch einen zweiten Programmcodemanager vor, der das zweite Programmcodesegment für den ersten Prozeß sicher zur Verfügung stellt. Der Adreßraummanager wird ferner verwendet, um in einer sicheren Art Zugriff auf den zweiten Adreßraum für den ersten Prozeß zur Verfügung zu stellen, und um das zweite Programmcodesegment in den zweiten Adreßraum abzubilden. Der erste Prozeß erzeugt eine Codetabelle und eine Symboladreßtabelle, ehe das erste und das zweite Programmcodesegment verbunden werden.
• Für den Fall, daß der zweite Adreßraum mindestens einen ausführenden Prozeß hat, wird der Adreßraummanager auch für das Bereitstellen einer Codetabelle für die Identifizierung, daß das erste Programmcodesegment nicht mit dem ersten Prozeß verbunden ist, sowie für das Bereitstellen von Symboladreßinformationen für das Erzeugen einer Symboladreßtabelle angewandt. Die Symboladreßtabelle wird für das Verbinden des ersten Programmcodesegmentes mit dem zweiten Prozeß im zweiten Adreßraum angewandt.
• Die Ausführung des zweiten Programmcodesegmentes oder des zweiten mit dem ersten Programmcodesegment verbundenen Prozesses wird durch das Übertragen der Kontrolle an eine Startadresse im zweiten Adreßraum eingeleitet. Insbesondere wird die Ausführung des zweiten mit dem ersten Programmcodesegment verbundenen Prozesses durch das Starten eines neuen Ausführungsthreads sowie durch das Übertragen der Kontrolle an die Startadresse einer Initialisierungsfunktion im zweiten Adreßraum eingeleitet. Die Initialisierungsfunktion wird durch den ersten Prozeß unter Verwendung der Symboladreßtabelle lokalisiert.
• Zusätzlich wird bei dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ein Authentisierungs manager eines Dritten vorgesehen, um den ersten Prozeß zu autorisieren, mit dem ersten und dem zweiten Programmcodesegment und dem zweiten Adreßraum versorgt zu werden. Die Codetabelle ist an einem vorher festgelegten Ort des Adreßraummanagers lokalisiert.
• Ferner werden der erste und der zweite Prozeß, das erste und das zweite Programmcodesegment, der erste und der zweite Adreßraum, der erste und der zweite Programmmanager, der Adreßraummanager und der Authentisierungsmanager eines Dritten in ihrer gegenwärtig bevorzugten Form auf eine objekt-orientierte Weise implementiert.
KURZBESCHREIBUNG DER ZEICHNUNGEN
• Die Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden aus der nachfolgenden ausführlichen Beschreibung des bevorzugten Ausführungsbeispiels der Erfindung unter Verweis auf die Zeichnungen hervorgehen, in denen
• Fig. 1 eine physikalische Ansicht der Hardwareelemente eines Netzwerkes von Computersystemen zeigt, das die Lehren der vorliegenden Erfindung einschließt.
• Fig. 2 eine logische Ansicht der Softwareelemente eines der in Fig. 1 veranschaulichten Computersysteme zeigt.
• Fig. 3 eine logische Ansicht eines Clientprozesses sowie mehrerer Objekte des in Fig. 1 veranschaulichten Netzwerkes von Computersystemen zeigt.
• Fig. 4 eine logische Ansicht eines Adreßraummanagers, eines Adreßraumobjektes, eines Programmcodemanagers, eines Programmcodesegmentobjektes und eines Authentisierungsmanagers der vorliegenden Erfindung in dem in Fig. 1 veranschaulichten Netzwerk von Computersystemen zeigt.
• Fig. 5 eine logische Ansicht eines Adreßraummanagers, eines Adreßraumobjektes, eines Namenskontextobjektes, eines Codetabellenobjektes und einer Symboladreßtabelle der vor liegenden Erfindung in dem in Fig. 1 veranschaulichten Netzwerk von Computersystemen als eine Alternativlösung zeigt, um eine Programmcodesegmentverknüpfung und Name-zu- Adreßinformationen für den Adreßraum vorzusehen.
• Fig. 6 das Verfahren der vorliegenden Erfindung für das dynamische Nicht-Supervisor-Modus-Queradreßraum-Verbinden eines Programmcodesegmentes beim Programmstart veranschaulicht.
• Fig. 7 das Verfahren der vorliegenden Erfindung für das dynamische Nicht-Supervisor-Modus-Queradreßraum-Verbinden eines Programmcodesegmentes mit einem Prozeß veranschaulicht.
BEZEICHNUNGEN UND TERMINOLOGIE
• Die nachfolgende ausführliche Beschreibung wird weitgehend in Form von auf einem Netzwerk von Computern ausgeführten Programmverfahren dargelegt. Diese verfahrensorientierten Beschreibungen und Darstellungen sind diejenigen Mittel, die von Fachleuten verwendet werden, um am effektivsten das Wesen ihrer Arbeit anderen Fachleuten zu vermitteln.
• Unter einem Verfahren wird hier und allgemein eine in sich logische Reihenfolge von Schritten verstanden, die zu einem gewünschten Ergebnis führt. Diese Schritte sind solche, die physikalische Manipulationen physikalischer Größen erfordern. Diese Größen nehmen in der Regel, aber nicht notwendigerweise die Form elektrischer oder magnetischer Signale an, die gespeichert, übertragen, kombiniert, verglichen und auf andere Weise bearbeitet werden können. Hauptsächlich wegen der herkömmlichen Praxis erweist es sich gelegentlich als günstig, auf diese Signale als Bits, Werte, Elemente, Symbole, Objekte, Zeichen, Ausdrücke, Zahlen usw. zu verweisen. Es sollte jedoch bedacht werden, daß all diese und ähnliche Begriffe den passenden physikali schen Größen zugeordnet sein sollen, und daß sie bloß bequeme, auf diese Größen angewandte Bezeichnungen sind.
• Auf die ausgeführten Manipulationen wird außerdem oftmals mit Begriffen, wie z. B. Addieren und Vergleichen, hingewiesen, die im allgemeinen mit mentalen, durch einen menschlichen Bediener ausgeführten Operationen in Verbindung gebracht werden. Eine solche Fähigkeit eines menschlichen Bedieners ist nicht erforderlich, und in den meisten Fällen auch nicht erwünscht, bei irgendeiner der hiernach beschriebenen Operationen, die einen Teil der vorliegenden Erfindung bilden; die Operationen sind Maschinenoperationen. Nutzbare Maschinen für das Ausführen der Operationen der vorliegenden Erfindung schließen digitale Mehrzweckcomputer oder andere ähnliche Einrichtungen ein. Auf jeden Fall sollte der Unterschied zwischen den Verfahrensoperationen beim Betreiben eines Computers und dem Berechnungsverfahren an sich bedacht werden. Die vorliegende Erfindung bezieht sich auf Verfahrensschritte bem Betreiben eines Computers für das Verarbeiten elektrischer oder anderer physikalischen Signale, um andere gewünschte physikalische Signale zu erzeugen.
• Die vorliegende Erfindung bezieht sich auch auf die für das Ausführen dieser Operationen erforderlichen Einrichtungen. Diese Einrichtungen können speziell für die erforderlichen Zwecke gebaut werden, oder sie können einen durch ein im Computer gespeichertes Computerprogramm selektiv aktivierten oder umkonfigurierten Mehrzweckcomputer umfassen. Die hier dargelegten Verfahren beziehen sich nicht ausschließlich auf einen speziellen Computer oder andere Einrichtungen. Insbesondere können verschiedene Allzweckmaschinen mit Verfahren verwendet werden, die gemäß den Lehren in dieser Beschreibung geschrieben sind, oder es kann sich herausstellen, daß es bequemer ist, spezialisiertere Einrichtungen für das Ausführen der erforderten Verfahrensschritte zu bauen. Die erforderliche Struktur für eine Vielfalt dieser Maschinen wird aus der nachfolgenden Beschreibung hervorgehen.
AUSFÜHRLICHE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
• Es werden ein Verfahren und Einrichtungen für einen in einem Nicht-Supervisor-Modus ausführenden Prozeß offenbart, der das dynamische Verbinden über Adreßräume hinweg durchführen soll. In der nachfolgenden Beschreibung werden zu Erläuterungszwecken spezielle Anzahlen, Materialien und Konfigurationen angegeben, um für ein gründliches Verständnis der vorliegenden Erfindung zu sorgen. Für einen Fachmann ist jedoch klar, daß die vorliegende Erfindung auch ohne die speziellen Einzelheiten ausgeführt werden kann. In anderen Fällen werden bekannte Systeme in schematischer oder in Blockdarstellungsform gezeigt, um die vorliegende Erfindung nicht unnotwendig undeutlich zu machen.
• Es wird jetzt auf Fig. 1 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine physikalische Ansicht eines Netzwerkes von Computersystemen veranschaulicht, das die Lehren der vorliegenden Erfindung einschließt, und das aus seinen Hardwareelementen aufgebaut ist. Das Netzwerk von Computersystemen 10 weist mindestens ein Computersystem 12a oder 12b auf. Falls mehr als ein Computersystem 12a oder 12b benutzt wird, werden die Computersysteme 12a und 12b durch ein Netzwerk 22 miteinander gekoppelt. Jedes Computersystem 12a oder 12b weist mindestens eine zentrale Verarbeitungseinheit (CPU) 14a oder 14b, eine Speichereinheit 16a oder 16b, eine Massenspeichereinheit 18a oder 18b und ein Eingabe/Ausgabe-Gerät 20a oder 20b auf. Die Merkmale dieser Hardwareelemente in jedem der Computersysteme 12a oder 12b, wie z. B. Geschwindigkeit und Größe, können unterschiedlich sein. Diese Hardwareelemente sind typischerweise in den meisten Mehrzweckcomputersystemen und in fast allen Spezialcomputersystemen vorhanden. Die verschiedenen, in jedem der Computersysteme 12a und 12b enthaltenen Hardwareelemente sollen stellvertretend für diese breite Gruppe von Datenverarbeitungssystemen stehen. Spezielle Beispiele geeigneter Datenverarbeitungssysteme, die die Rolle dieser Computersysteme 12a und 12b einnehmen können, schließen die von Sun Microsystems, Inc., Mountain View, Kalifornien, hergestellten Computersysteme ein. Andere Computersysteme mit ähnlichen Fähigkeiten können selbstverständlich einfach angepaßt werden, so daß sie die nachstehend beschriebenen Funktionen ausführen können.
• Es wird jetzt auf Fig. 2 Bezug genommen, in der ein Blockdarstellung gezeigt ist, die eine nach seiner Systemsoftware organisierte logische Ansicht eines der in Fig. 1 veranschaulichten Computersysteme veranschaulicht. Die Systemsoftware 30 umfaßt ein Betriebssystem 32, ein Dateisystem 34 und mindestens einen Sprachcompiler 36. Das Betriebssystem 32 stellt bekannte Betriebssystemdienste zur Verfügung, insbesondere die virtuelle Speicherverwaltung des Netzwerkes mit einem kohärenten Seiten-Cache-Speicher- Algorithmus, sowie eine objekt-orientierte Schnittstelle zum sicheren Abbilden von Dateien in Adreßräume für einen im Nicht-Supervisor-Modus ausführenden Prozeß. Das Dateisystem 34 stellt bekannte Dateisystemdienste, wie z. B. das Öffnen, Schließen, Lesen und Schreiben, zur Verfügung. Der Sprachcompiler stellt bekannte Compiler-Dienste, wie z. B. das Parsing und das Erzeugen von Befehlscodes, sowie bekannte Laufzeit-Bibliotheksdienste, wie z. B. mathematische Funktionen und Zeichenketten-Manipulationen, zur Verfügung. Auf dem Computersystem ausgeführte Anwendungen 38 nutzen die darunterliegenden von der Systemsoftware 32 - 36 angebotenen Systemdienste.
• Diese Systemsoftwareelemente sind, mit Ausnahme des Betriebssystems, typischerweise in den meisten Mehrzweckcomputersystemen und in fast allen Spezialcomputersystemen vorhanden. Die verschiedenen, in jedem der Computersysteme enthaltenen, nicht zum Betriebssystem gehörenden Systemsoftwareelemente sollen stellvertretend für diese breite Gruppe von Nicht-Betriebssystem-Systemsoftware stehen. Außerdem kann die auf jedem der Computersysteme angewandte Systemsoftware unterschiedlich sein, vorausgesetzt, daß sie äquivalente Funktionen anbieten und miteinander kommunizieren können. Nähere Beschreibungen des Betriebssystems mit virtueller Speicherverwaltung des Netzwerkes mit einem kohärenten Seiten-Cache-Speicher-Algorithmus sind in Yousef Khalidi, Hardware Support for Distributed Operating Systems, Ph.D. Thesis, Georgia Institute of Technology, 1988, zu finden.
• Es wird jetzt auf Fig. 3 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine logische Ansicht eines Clientprozesses, eines Objektmanagers und einer Vielzahl von Objekten auf dem in Fig. 1 veranschaulichten Netzwerk von Computersystemen veranschaulicht. In Fig. 3 sind ein Clientprozeß 42, ein Objektmanager 44 und eine Vielzahl von Objekten 46, 47 und 48 gezeigt. Ein Clientprozeß 42 ist ein Prozeß, der ein Objekt 46, 47 oder 48 verwendet. Jedes Objekt 46, 47 oder 48 ist eine Komponente, die Daten und Operationen, die aufgerufen werden können, um die Daten zu manipulieren, aufweist. Der Besitz eines Objektes 46, 47 oder 48 beinhaltet das Recht, auf das Objekt 46, 47 oder 48 zuzugreifen. Die Operationen in einem Objekt werden an dem Objekt 46, 47 oder 48 durch Senden von Aufrufen an das Objekt 46, 47 oder 48 aufgerufen. Ein Objektmanager 44 ist ein Adreßraum, in dem sich der Befehlscode für die Operationen des Objektes aufhält. Jedes Objekt 46, 47 oder 48 hat einen Objekttyp. Der Objekttyp definiert die Objektoperationen, die an den Objekten 46, 47 und 48 von diesem speziellen Typ durchgeführt werden können. Obwohl sie ein Teil eines Objektes sind, werden die Objektoperationen unabhängig von den Objekten 46, 47 und 48 selbst implemen tiert. Die Objekte 46, 47 oder 48 sind außerdem in einer Klassenhierarchie gemäß ihren Objekttypen organisiert, wobei es einem in einer Unterklasse organisierten Objekttyp gestattet wird, die für andere in der Oberklasse organisierte Objekttypen definierten und implementierten Objektoperationen zu erben. Jedes Objekt 46, 47 oder 48 ist eine Klasseninstanz einer Klasse. Eine nähere Beschreibung des objekt-orientierten Designs und der Programmiertechniken ist in B. Meyer, Object-oriented Software Construction, Prentice Hall, 1988, zu finden.
• Es es klar, daß das in Fig. 1 veranschaulichte Netzwerk von Computersystemen eine Vielzahl von Clientprozessen, Objektmanagern und Objekten aufweisen kann. Der in Fig. 3 gezeigte Clientprozeß 42, der in Fig. 3 gezeigte Objektmanager 44 und die in Fig. 3 gezeigten Objekte 46, 47 und 48 sollen stellvertretend für eine breite Gruppe dieser Clientprozesse, Objektmanager und Objekte stehen.
• Es wird jetzt auf Fig. 4 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die einen Adreßraummanager, ein Adreßraumobjekt, einen Programmcodemanager, ein Programmcodesegmentobjekt sowie einen vertrauensvollen Authentisierungsmanager eines Dritten der vorliegenden Erfindung veranschaulicht. Gezeigt ist ein Programmcodemanager 54, der eine objekt-orientierte Schnittstelle zu einem Clientprozeß 52 für den Zugriff auf ein Programmcodesegmentobjekt 60 zur Verfügung stellt, das dem in Fig. 3 veranschaulichten Blockdarstellung ähnlich ist. Das Programmcodesegmentobjekt 60 weist einen ausführbaren Binärcode eines Programms oder eines Programmsegmentes auf. In seiner gegenwärtig bevorzugten Form validiert der Programmcodemanager 54 die Zugriffsautorität des Clients unter Verwendung eines Vertrauensauthentisierungsmanagers 56 eines Dritten. Nähere Beschreibungen des Vertrauensauthentisierungsmanagers eines Dritten sind zu finden in Michael Burrows, Martin Abadi und Roger Needham, A Logic of Authentication, ACM Transactions an Computer Systems, 8(1), 1990, Seiten 18-36.
• In Fig. 4 wird darüberhinaus ein Adreßraummanager 58 gezeigt, der eine objekt-orientierte Schnittstelle zum Clientprozeß 52 für den Zugriff auf ein Adreßraumobjekt 62 zur Verfügung stellt. Ähnlich dem oben beschriebenen Programmcodemanager 54 in seiner gegenwärtig bevorzugten Form validiert der Adreßraummanager 58 die Zugriffsautorität des Clients unter Verwendung des Vertrauensauthentisierungsmanagers 56 eines Dritten.
• Das Adreßraumobjekt 62 weist einen (nicht gezeigten) Adreßraum auf und stellt eine objekt-orientierte Schnittstelle zum Ausführen beschränkter Operationen auf dem Adreßraum zugunsten von im Nicht-Supervisor-Modus ausführenden Clientprozessen zur Verfügung. Die beschränkten Operationen umfassen eine Operation zum Zurücksenden einer Liste von in den Adreßraum abgebildeten Speicherobjekten und der zugehörigen Basisadressen für die Speicherobjekte sowie eine Operation zum Abbilden eines Programmcodesegmentes und/oder einer Gruppe von Daten in den Adreßraum, die ein dem abgebildeten Speicher entsprechendes Speicherobjekt herstellt. Während einer Abbildungsoperation wird der Programmcode und/oder die Gruppe von Daten in großen Mengen in den Adreßraum eingefügt, und die Adressen des Adreßraumes werden mit dem Programmcode und/oder -daten assoziiert. Wie vorher beschrieben, werden während der Verbindungsoperation Referenzen in einem Programmcodesegment aufgelöst, die Adressen in einem anderen Programmcodesegment erfordern.
• Während einer Abbildungsoperation werden außerdem Symboladreßinformationen über ein Programmsegment aus dem Programmsegment durch den Zugriff auf diejenigen Speicherplätze erlangt, in denen das Programmsegment abgelegt ist. Die Symboladreßinformationen werden zum Erzeugen einer Symboladreßtabelle verwendet, die Name-zu-Adresse-Querverweis einträge für den Adreßraum aufweist. Die erzeugte Symboladreßtabelle wird wiederum zum Fördern des Verbindens eines Programmcodesegmentes mit einem anderen Programmcodesegment oder mit einem Prozeß verwendet, was nachstehend im Detail erörtert wird. Die Symboladreßinformationen weisen die im Programmsegment abgebildeten Namen und Adressen der Funktionen und der Daten auf.
• Die beschränkten, durch die objekt-orientierte Schnittstelle des Adreßraummanagers 58 in dem Adreßraum durchgeführten Operationen umfassen ferner eine Operation zum Gewinnen der verknüpften Programmsegmentinformationen des Adreßraumes aus der (nicht gezeigten) Codetabelle des Adreßraumes. Die verknüpften Programmsegmentinformationen werden verwendet, um zu entscheiden, ob ein Programmcodesegment bereits mit einem Clientprozeß im Adreßraum verbunden ist, was nachstehend im Detail beschrieben wird. Die Codetabelle weist Einträge für jedes verknüpfte Programmcodesegment für den Adreßraum auf. Jeder Eintrag umfasst die Basisadresse des verknüpften Programmcodesegmentes, die Größe und den Namen der abgebildeten Datei. Die Codetabelle weist außerdem ein Semaphor zum Sperren der Codetabelle auf, wenn die Codetabelle in Gebrauch ist. Die Operationen zur Protokollierung eines Programmcodesegmentes als im Adreßraum verbunden, zum Entfernen der Protokolleinträge, zur Bestätigung, ob ein Programmcodesegment schon im Adreßraum verbunden ist, zum Setzen und Löschen des Semaphors werden alle durch das Abbilden des mit der Codetabelle in den Adreßraum assoziierten Speicherobjektes sowie durch das Ansprechen auf den hier vorhandenen Speicher durchgeführt. In der gegenwärtig bevorzugten Form ist die Codetabelle an einem vorher bestimmten Speicherplatz im Adreßraum 62 lokalisiert.
• Es ist klar, daß das in Fig. 1 veranschaulichte Netzwerk von Computersystemen eine Vielzahl von Clientprozessen, Programmcodemanagern, Programmcodesegmentobjekten, Vertrauensauthentisierungsmanagern eines Dritten, Adreßraummanagern und Adreßraumobjekten aufweisen kann. Der in Fig. 4 gezeigte Clientprozeß 52, der in Fig. 4 gezeigte Programmcodemanager 54, der in Fig. 4 gezeigte Vertrauensauthentisierungsmanager 56 eines Dritten, der in Fig. 4 gezeigte Adreßraummanager 58, das in Fig. 4 gezeigte Programmcodesegmentobjekt 60 und das in Fig. 4 gezeigte Adreßraumobjekt 62 sollen stellvertretend für eine breite Gruppe dieser Clientprozesse, Objektmanager und Objekte stehen.
• Es wird jetzt auf Fig. 5 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine Alternativlösung zum Zugriff auf das verknüpfte Programmsegment und auf die Symboladreßinformationen veranschaulicht. Gezeigt ist ein Namenskontextobjekt 64, das eine objekt-orientierte Schnittstelle zum Zugriff auf die verknüpften Programmsegmentinformationen aus einem Codetabellenobjekt 66 und auf die Symboladreßinformationen aus einem Symboladreßtabellenobjekt 68 für einen im Nicht-Supervisor-Modus ausführenden Clientprozeß zur Verfügung stellt. Statt an einem vorher festgelegten Speicherplatz im Adreßraum lokalisiert zu sein, ist die Codetabelle im Codetabellenobjekt 66 lokalisiert. Statt die Symboladreßinformationen direkt aus dem abgebildeten Programmsegment zu erlangen und statt die Symboladreßtabelle zu erzeugen, werden in ähnlicher Weise die Symboladreßinformationen im Symboladreßtabellenobjekt 68 gehalten. Bei dieser Lösung unterstützt der Adreßraummanager 58 auch die Operationen zum Zugriff auf einen Namenskontext im Namenskontextobjekt 64.
• Das Namenskontextobjekt 64 weist einen (nicht gezeigten) Namenskontext mit Name-zu-Objekt-Querverweis-Einträgen für den Adreßraum auf. Das Namenskontextobjekt 64 unterstützt die Operationen zum Binden eines Objektes an einen Namen, zum Entfernen der Bindung an den Namen und zum Auflösen eines Namens für ein Objekt. Das Codetabellenobjekt 66 und das Symboladreßtabellenobjekt 66 werden aus dem Namenskontextobjekt 64 durch das Auflösen bekannter Namen für diese Objekte erhalten.
• Im Gegensatz zur oben beschriebenen, in Fig. 4 veranschaulichten Lösung hat die Codetabelle kein Semaphor. Die Codetabelle wird entfernt, wenn durch einen Clientprozeß zugegriffen wird, wobei verhindert wird, daß die Codetabelle von einem anderen Prozeß verwendet wird, wenn sie in Gebrauch ist. Das Codetabellenobjekt 66 unterstützt die Operationen zur Protokollierung eines Programmcodesegmentes als im Adreßraum verbunden, zum Entfernen der Protokolleinträge und zur Bestätigung, ob ein Programmcodesegment schon im Adreßraum verbunden ist.
• Die Symboladreßtabelle weist Name-zu-Adresse-Querverweis-Einträge für den Adreßraum auf. Darüber hinaus unterstützt das Symboladreßtabellenobjekt 68 die Operationen zum Querverweis eines Namens an eine Adresse, zur Entfernung eines Name-zu-Adresse-Querverweises und zum Auflösen eines Namens für eine Adresse im Adreßraum.
• Es wird jetzt auf Fig. 6 Bezug genommen, in der ein Ablaufdiagramm gezeigt ist, das das Verfahren der vorliegenden Erfindung für das dynamische Nicht-Supervisor-Modus- Queradreßraum-Verbinden von Programmcodesegmenten beim Programmstart veranschaulicht. Der Clientprozeß erhält zuerst ein neues Adreßraumobjekt ohne einen ausführenden Prozeß aus einem Adreßraummanager und erhält die Programmcodesegmentobjekte von einem oder mehreren Programmcodemanagern, Block 72 und 74. Wie oben beschrieben, wird bei dem bevorzugten Ausführungsbeispiel die Autorität des Clientprozesses zum Erlangen des neuen Adreßraumobjektes und des Programmcodesegmentobjektes unter Verwendung eines Vertrauensauthentisierungsmanagers eines Dritten validiert.
• Der Clientprozeß konstruiert danach eine Codetabelle und eine Symboladreßtabelle für den Adreßraum, Block 76. Der Clientprozeß aktualisiert außerdem den Namenskontext, falls die Namenskontextlösung verwendet wird. Der Client prozeß bildet daraufhin die Programmcodesegmente in den neuen Adreßraum und in seinen eigenen Adreßraum ab und verbindet diese miteinander in Bezug zu den Adressen im neuen Adreßraum, Block 78. Der Clientprozeß exportiert die Codetabelle in den Adreßraum, falls die Namenskontextlösung verwendet wird. Nachdem die Programmcodesegmente verbunden worden sind, beginnt der Clientprozeß die Ausführung des verbundenen Programmes durch das Übertragen der Kontrolle an die Startadresse des verbundenen Programmes im neuen Adreßraum, Block 80.
• Es wird jetzt auf Fig. 7 Bezug genommen, in der ein Ablaufdiagramm gezeigt ist, das das Verfahren der vorliegenden Erfindung für das dynamische Nicht-Supervisor-Modus- Queradreßraum-Verbinden eines Programmcodesegmentes mit einem Prozeß veranschaulicht. Der Clientprozeß erlangt zuerst einen Adreßraum mit einem ausführenden Prozeß, Block 84. Der Clientprozeß erlangt danach die Codetabelle für den Adreßraum, Block 88, mit oder ohne das vorherige Erlangen eines Namenskontexts, was davon abhängig ist, ob die Codetabelle, wie in Fig. 4 veranschaulicht, in einem vorher festgelegten Speicherplatz des Adreßraummanagers oder, wie in Fig. 5 veranschaulicht, in einem Codetabellenobjekt lokalisiert ist. In ähnlicher Weise wird, wie oben beschrieben wurde, bei dem bevorzugten Ausführungsbeispiel die Autorität des Clientprozesses zum Erlangen des neuen Adreßraums, der Codetabelle und ggf. des Namenskontexts unter Verwendung eines Vertrauensauthentisierungsmanagers eines Dritten validiert.
• Wenn die Codetabelle anzeigt, daß das Programmcodesegment nicht in den Adreßraum verbunden worden ist, gewinnt der Client daraufhin das Programmcodesegmentobjekt aus einem Programmcodemanager, Block 92, und erzeugt die Symboladreßtabelle für den Adreßraum, oder er gewinnt die Symboladreßtabelle, falls die Namenskontextlösung verwendet wird, Block 94. In ähnlicher Weise wird, wie oben beschrie ben wurde, bei dem bevorzugten Ausführungsbeispiel die Autorität des Clientprozesses zum Gewinnen des Programmcodesegmentes unter Verwendung eines Vertrauensauthentisierungsmanagers eines Dritten validiert.
• Der Clientprozeß bildet daraufhin das Programmcodesegment in den Adreßraum und in seinen eigenen Adreßraum ab und verbindet das Programmcodesegment relativ zu Adressen im ausführenden Prozeß, Block 96 und 98. Nachdem das Programmcodesegment mit dem ausführenden Prozeß verbunden worden ist, lokalisiert der Clientprozeß die Initialisierungsfunktion des Programmcodesegmentes, Block 100. Nachdem die Initialisierungsfunktion lokalisiert worden ist, startet der Clientprozeß einen neuen Ausführungsthread für den mit dem Programmcodesegment verbundenen ausführenden Prozeß und überträgt die Kontrolle an die Startadresse der Initialisierungsfunktion.
• Es ist klar, daß der Schritt des Gewinnens des Codetabellenobjekts des Adreßraumobjektes und des Feststellens, ob das Programmcodesegment bereits in den Adreßraum verbunden worden ist, Block 88 und 90, übersprungen werden kann, wenn der Clientprozeß weiß, ob das Programmcodesegment verbunden ist oder nicht. In der gleichen Weise kann der Schritt, mit dem das Adreßraumobjekt gewonnen wird, Block 66, übersprungen werden, falls der Clientprozeß das Adreßraumobjekt gewonnen hat.
• Es ist ebenfalls klar, daß das Verfahren der vorliegenden Erfindung für das in Fig. 7 veranschaulichte dynamische Nicht-Supervisor-Modus-Queradreßraum-verbinden eines Programmsegmentes mit einem Prozeß auch auf das dynamische Verbinden eines Programmsegmentes mit dem Clientprozeß selbst verwendet werden kann. Der Zieladreßraum ist der eigene Adreßraum des Clientprozesses und der Zielprozeß ist der Clientprozeß selbst.
• Es ist ferner klar, daß die vorliegende Erfindung nicht auf eine objekt-orientierte Weise ausgeführt werden muß. Die Elemente der vorliegenden Erfindung können an ihre nicht-objekt-orientierten Äquivalente angepaßt werden, und auf diese nicht-objekt-orientierten Äquivalente kann unter Verwendung bekannter Lösungen, wie z. B. Handles, zugegriffen werden.
• Obwohl die vorliegende Erfindung anhand eines gegenwärtig bevorzugten Ausführungsbeispiels beschrieben worden ist, ist es einem Fachmann klar, daß die Erfindung nicht auf das beschriebene Ausführungsbeispiel beschränkt ist. Das Verfahren und die Einrichtungen der vorliegenden Erfindung können mit Änderungen und Abänderungen im Rahmen der anliegenden Ansprüche ausgeführt werden. Die Beschreibung ist daher als erläuternd, und nicht als einschränkend für die vorliegende Erfindung zu betrachten.

Claims (16)

1. In einem Netzwerk von Computersystemen (10) mit wenigstens einer zentralen Verarbeitungseinheit (CPU) (14), die einen Supervisor-Ausführungsmodus und einen Nicht-Supervisor-Ausführungsmodus aufweist, ein Verfahren, mit dessen Hilfe ein in dem Nicht-Supervisor-Modus ausführender erster Prozeß in einem ersten Adreßraum ein erstes Pogrammcodesegment mit einem zweiten Programmcodesegment in einem zweiten Adreßraum dynamisch verknüpft, während die Sicherheit des Computersystems aufrechterhalten bleibt, wobei das Verfahren die Schritte umfaßt:

a) Erlangen des ersten und des zweiten Programmcodesegments und des Zugriffs auf den zweiten Adreßraum aus einem ersten und einem zweiten Programmcodemanager bzw. einem Adreßraummanager (58) durch den ersten Prozeß, wobei der erste und der zweite Programmcodemanager und der Adreßraummanager (58) unter Verwendung irgendeines dritten Authentisierungsmanagers (56) den ersten Prozeß als zum Erlangen des ersten und des zweiten Programmcodesegments und des Zugriffs auf den zweiten Adreßraum autorisiert authentisieren;

b) Veranlassen, daß das gewonnene erste und zweite Programmcodesegment durch den ersten Prozeß unter Verwendung des Adreßraummanagers (58) in den ersten und zweiten Adreßraum abgebildet werden;

c) Gewinnen von Verknüpfungsinformationen des ersten und des zweiten Programmcodesegments durch den ersten Prozeß unter Verwendung des abgebildeten ersten und zweiten Programmcodesegments in dem ersten Adreßraum und Verbinden des abgebildeten ersten Programmcodesegments in dem zweiten Adreßraum mit dem abgebildeten zweiten Programmcodesegment in dem zweiten Adreßraum durch den ersten Prozeß unter Verwendung der gewonnenen Verbindungsinformationen; und

d) Übertragen der Ausführungskontrolle durch den ersten Prozeß an eine Startadresse in dem zweiten Adreßraum.

2. Das Verfahren nach Anspruch 1, wobei der Schritt c) die Schritte umfaßt:

c.1) Erzeugen einer Codetabelle in dem zweiten Adreßraum durch den ersten Prozeß, die Verknüpfte-Programmcodesegment-Informationen des zweiten Adreßraums aufweist;

c.2) Gewinnen von Namen und zugehörigen Adreßinformationen für den zweiten Adreßraum aus den in dem ersten Adreßraum abgebildeten ersten und zweiten Programmcodesegmenten durch den ersten Prozeß;

c.3) Erzeugen einer Symboladreßtabelle in dem zweiten Adreßraum durch den ersten Prozeß, die die gewonnenen Namen und zugehörigen Adressen aufweist; und

c.4) Verbinden des in dem zweiten Adreßraum abgebildeten ersten Programmcodesegments mit dem in dem zweiten Adreßraum abgebildeten zweiten Programmcodesegment durch den ersten Prozeß unter Verwendung der gewonnenen Namen und zugehörigen Adressen.

3. Das Verfahren nach Anspruch 2, wobei, der erste Prozeß, das erste und das zweite Programmcodesegment, der erste und der zweite Adreßraum, der erste und der zweite Programmcodemanager, der Adreßraummanager (58) und der dritte Authentisierungsmanager (56) auf eine objektorientierte Weise implementiert werden.

4. In einem Netzwerk von Computersystemen (10) mit wenigstens einer zentralen Verarbeitungseinheit (CPU) (14), die einen Supervisor-Ausführungsmodus und einen Nicht-Supervisor-Ausführungsmodus aufweist, ein Verfahren, mit dem ein in dem Nicht-Supervisor-Modus in einem ersten Adreßraum ausführender erster Prozeß dynamisch ein erstes Programmcodesegment mit einem zweiten Prozeß in einem zweiten Adreßraum verbindet, während die Sicherheit des Computersystems aufrechterhalten bleibt; wobei das Verfahren die Schritte umfaßt:

a) Erlangen des ersten Programmcodesegments und des Zugriffs auf den zweiten Adreßraum von einem ersten Programmcodemanager bzw. einem Adreßraummanager (58) durch den ersten Prozeß, wobei der erste Programmcodemanager und der Adreßraummanager (58) unter Verwendung eines dritten Authentisierungsmanagers (56) den ersten Prozeß als zum Erlangen des ersten Programmcodesegments und des Zugriffs auf den zweiten Adreßraum autorisiert authentisieren;

b) Veranlassen, daß das gewonnene erste Programmcodesegment durch den ersten Prozeß unter Verwendung des Adreßraummanagers (58) in dem zweiten Adreßraum abgebildet wird;

c) Gewinnen von Verknüpfungsinformationen des ersten Programmcodesegments durch den ersten Prozeß unter Verwendung des abgebildeten ersten Programmcodesegments in dem zweiten Adreßraum, Aktualisieren einer Symboladreßtabelle des zweiten Adreßraums durch den ersten Prozeß unter Verwendung der gewonnenen Verknüpfungsinformationen und Verbinden des in dem zweiten Adreßraum abgebildeten ersten Programmcodesegments mit dem zweiten Prozeß in dem zweiten Adreßraum durch den ersten Prozeß unter Verwendung der Verknüpfungsinformationen in der aktualisierten Symboladreßtabelle des zweiten Adreßraums; und

d) Übertragen der Ausführungskontrolle auf eine Startadresse in dem zweiten Adreßraum durch den ersten Prozeß.

5. Das Verfahren nach Anspruch 4, wobei der Schritt c) die Schritte umfaßt:

c.1) Gewinnen einer Codetabelle aus dem zweiten Adreßraum durch den ersten Prozeß, die Verknüpfte-Programmcodesegment-Informationen des zweiten Adreßraums aufweist, und Aktualisieren der Codetabelle durch den ersten Prozeß;

c.2) Gewinnen von Aktualisierungen für Namen und zugehörige Adressen des zweiten Adreßraums durch den ersten Prozeß unter Verwendung des in dem Adreßraum abgebildeten ersten Programmcodesegments und Modifizieren der Symboladreßtabelle des zweiten Adreßraums durch den ersten Prozeß unter Verwendung der gewonnenen Aktualisierungen;

c.3) Verbinden des in dem zweiten Adreßraum abgebildeten ersten Programmcodesegments mit dem zweiten Prozeß in dem zweiten Adreßraum durch den ersten Prozeß unter Verwendung der aktualisierten Namen und zugehörigen Adressen des zweiten Adreßraums; und

wobei der Schritt d) das Lokalisieren einer Initialisierungsfunktion in dem zweiten Adreßraum durch den ersten Prozeß unter Verwendung der Symboladreßtabelle in dem zweiten Adreßraum und das Aufrufen der lokalisierten Initialisierungsfunktion durch den ersten Prozeß umfaßt.

6. Das Verfahren nach Anspruch 5, wobei der erste und der zweite Prozeß, das erste Programmcodesegment, der erste und der zweite Adreßraum, der erste Programmcodemanager, der Adreßraummanager (58) und der dritte Authentisierungsmanager (56) auf eine objekt-orientierte Weise implementiert werden.

7. Das Verfahren nach Anspruch 4, wobei

der Schritt (b) ferner das Veranlassen, daß das erste Programmcodesegment in den ersten Adreßraum durch den ersten Prozeß unter Verwendung des Adreßraummanagers (58) abgebildet wird, umfaßt; und

der erste Prozeß stattdessen die Verknüpfungsinformationen des ersten Programmsegments unter Verwendung des in dem ersten Adreßraum abgebildeten ersten Programmcodesegments gewinnt.

8. Das Verfahren nach Anspruch 7, wobei der Schritt c) die Schritte umfaßt:

c.1) Gewinnen einer Codetabelle aus dem zweiten Adreßraum durch den ersten Prozeß, die Verknüpfte-Programmcodesegment-Informationen des zweiten Adreßraums aufweist, und Aktualisieren der Codetabelle in dem zweiten Adreßraum durch den ersten Prozeß;

c.2) Gewinnen von Aktualisierungen für Namen und zugehörige Adressen des zweiten Adreßraums durch den ersten Prozeß unter Verwendung des in dem ersten Adreßraum abgebildeten ersten Programmcodesegments und Modifizieren der Symboladreßtabelle des zweiten Adreßraums durch den ersten Prozeß unter Verwendung der gewonnenen Aktualisierungen;

c.3) Verbinden des in dem zweiten Adreßraum abgebildeten ersten Programmcodesegments mit dem zweiten Prozeß in dem zweiten Adreßraum durch den ersten Prozeß unter Verwendung der aktualisierten Namen und zugehörigen Adressen des zweiten Adreßraums; und

wobei der Schritt d) das Lokalisieren einer Initialisierungsfunktion in dem zweiten Adreßraum durch den ersten Prozeß unter Verwendung der Symboladreßtabelle in dem zweiten Adreßraum und das Aufrufen der lokalisierten Initialisierungsfunktion durch den ersten Prozeß umfaßt.

9. Eine Einrichtung in einem Netzwerk von Computersystemen (10) mit wenigstens einer zentralen Verarbeitungseinheit (CPU) (14) mit einem Supervisor-Ausführungsmodus und einem Nicht-Supervisor-Ausführungsmodus, wobei die Einrichtung einem in dem Nicht-Supervisor-Modus in einem ersten Adreßraum ausführenden ersten Prozeß dazu dient, dynamisch ein erstes Programmcodesegment mit einem zweiten Programmcodesegment in einem zweiten Adreßraum zu verbinden, während die Sicherheit des Computersystems aufrechterhalten bleibt, aufweisend:

a) einen mit dem ersten Prozeß gekoppelten Authentisierungsmanager (56) eines Dritten zum Authentisieren, daß der erste Prozeß autorisiert ist, das erste und das zweite Programmcodesegment und den Zugriff auf den zweiten Adreßraum zu erlangen;

b) einen mit dem Authentisierungsmanager (56) eines Dritten und dem ersten Prozeß gekoppelten ersten und zweiten Programmcodemanager zum Bereitstellen des ersten bzw. zweiten Programmcodesegments an den ersten Prozeß, nachdem der erste Prozeß als zum Erlangen des ersten und zweiten Programmcodesegments autorisiert authentisiert worden ist;

c) ein mit dem Authentisierungsmanager (56) eines Dritten und mit dem ersten Prozeß gekoppelten Adreßraummanager (58) zum Bereitstellen eines Zugriffs auf den zweiten Adreßraum für den ersten Prozeß, nachdem der erste Prozeß als zum Zugreifen auf den zweiten Adreßraum autorisiert authentisiert worden ist, und zum Abbilden des ersten und des zweiten Programmcodesegments in den ersten und zweiten Adreßraum bei Anforderung des ersten Prozeß; und

wobei der erste Prozeß das erste Programmcodesegment in dem zweiten Adreßraum mit dem zweiten Programmcodesegment in dem zweiten Adreßraum unter Verwendung der Verknüpfungsinformationen verbindet, die aus dem in den ersten Adreßraum abgebildeten ersten und zweiten Programmcodesegment gewonnen wurden, nachdem er das erste und das zweite Programmcodesegment und den Zugriff auf den zweiten Adreßraum erlangt und das erste und das zweite Programmcodesegment veranlaßt hat, in den ersten und zweiten Adreßraum unter Verwendung des Adreßraummanagers (58) abgebildet zu werden, und wobei die Ausführung des verbundenen ersten und zweiten Programmcodesegments durch den ersten Prozeß gestartet wird, indem die Ausführung von dem ersten Prozeß an eine Startadresse in dem zweiten Adreßraum übertragen wird.

10. Die Einrichtung nach Anspruch 9, wobei

die gewonnenen Verknüpfungsinformationen Namen und zugehörige Adressen des zweiten Adreßraums umfassen, die durch den ersten Prozeß aus dem ersten und zweiten Programmcodesegment, die in dem ersten Adreßraum abgebildet sind, abgeleitet sind; und

der erste Prozeß ferner eine Symboladreßtabelle und eine Codetabelle in dem zweiten Adreßraum erzeugt, wobei die Symboladreßtabelle die abgeleiteten Namen und zugehörigen Adressen des zweiten Adreßraums aufweist und wobei die Codetabelle verknüpfte Programmcodesegmentinformationen des zweiten Adreßraums aufweist.

11. Die Einrichtung nach Anspruch 10, wobei der erste Prozeß, das erste und das zweite Programmcodesegment, der erste und der zweite Adreßraum, der erste und der zweite Programmcodemanager, der Adreßraummanager (58) und der Authentisierungsmanager (56) eines Dritten auf eine objekt-orientierte Weise implementiert sind.

12. Eine Einrichtung in einem Netzwerk von Computersystemen (10) mit wenigstens einer zentralen Verarbeitungsarbeit (CPU) (14) mit einem Supervisor-Ausführungsmodus und einem Nicht-Supervisor-Ausführungsmodus, wobei die Einrichtung einem in dem Nicht-Supervisor-Modus in einem ersten Adreßraum ausführenden ersten Prozeß dazu dient, dynamisch ein erstes Programmcodesegment mit einem zweiten Prozeß in einem zweiten Adreßraum zu verbinden, während die Sicherheit des Computersystems aufrechterhalten bleibt, aufweisend:

a) einen mit dem ersten Prozeß gekoppelten Authentisierungsmanager (56) eines Dritten zum Authentisieren des ersten Prozesses als zum Erlangen des ersten Programmcodesegments und des Zugriffs auf den zweiten Adreßraum autorisiert;

b) einen mit dem Authentisierungsmanager (56) eines Dritten und mit dem ersten Prozeß gekoppelten ersten Programmcodemanager zum Bereitstellen des ersten Programmcodesegments an den ersten Prozeß nach Authentisierung des ersten Prozesses als zum Erlangen des ersten Programmcodesegments autorisiert unter Verwendung des Authentisierungsmanagers (56) eines Dritten;

c) einen mit dem Authentisierungsmanager (56) eines Dritten gekoppelten Adreßraummanager (58) zum Bereitstellen eines Zugriffs auf den zweiten Adreßraum für den ersten Prozeß nach Authentisierung des ersten Prozesses als für einen Zugriff auf den zweiten Adreßraum autorisiert unter Verwendung des Authentisierungsmanagers (56) eines Dritten, und wobei das erste Programmcodesegment in dem ersten und dem zweiten Adreßraum bei Anforderung des ersten Prozesses abgebildet wird; und

wobei der erste Prozeß das erste Programmcodesegment in dem zweiten Adreßraum mit dem zweiten Prozeß in dem zweiten Adreßraum unter Verwendung aktualisierter Verknüpfungsinformationen in einer Symboladreßtabelle des zweiten Adreßraums verknüpft, die mit Aktualisierungen modifiziert sind, die aus dem in dem zweiten Adreßraum abgebildeten ersten Programmcodesegment abgeleitet sind, nachdem das erste Programmcodesegment und der Zugriff auf den zweiten Adreßraum erlangt worden sind und das erste Programmcodesegment veranlaßt wurde, unter Verwendung des Adreßraummanagers (58) in den zweiten Adreßraum abgebildet zu werden, und wobei die Ausführung des mit dem ersten Programmcodesegment verknüpften zweiten Prozesses durch den ersten Prozeß gestartet wird, indem die Ausführung von dem ersten Prozeß an eine Startadresse in dem zweiten Adreßraum übertragen wird.

13. Die Einrichtung nach Anspruch 12, wobei

die aktualisierten Verknüpfungsinformationen aktualisierte Namen und zugehörige Adressen in der Symboladreß tabelle des zweiten Adreßraums umfassen, die durch Aktualisierungen von Namen und zugehörigen Adressen modifiziert sind, die durch den ersten Prozeß aus dem in dem zweiten Adreßraum abgebildeten ersten Programmsegment abgeleitet wurden; und

wobei der erste Prozeß die Kontrolle an den mit dem ersten Programmsegment verknüpften zweiten Prozeß überträgt, indem eine Initialisierungsfunktion in dem zweiten Adreßraum aufgerufen wird, wobei die Initialisierungsfunktion unter Verwendung der Symboladreßtabelle lokalisiert wird.

14. Die Einrichtung nach Anspruch 13, wobei der erste und der zweite Prozeß, das erste Programmcodesegment, der erste und der zweite Adreßraum, der erste Programmcodemanager, der Adreßraummanager (58) und der Authentisierungsmanager (56) eines Dritten auf eine objektorientierte Weise implementiert sind.

15. Die Einrichtung nach Anspruch 12, wobei

der erste Prozeß ferner bewirkt, daß das erste Programmcodesegment in dem ersten Adreßraum unter Verwendung des Adreßraummanagers (58) abgebildet wird; und

der erste Prozeß die Verknüpfungsinformationen des ersten Programmsegments unter Verwendung des statt dessen in dem ersten Adreßraum abgebildeten ersten Programmcodesegments ableitet.

16. Die Einrichtung nach Anspruch 15, wobei

die aktualisierten Verknüpfungsinformationen aktualisierte Namen und zugehörige Adressen in der Symboladreßtabelle des zweiten Adreßraums umfassen, die durch Aktualisierungen von Namen und zugehörigen Adressen modifiziert sind, die durch den ersten Prozeß aus dem in den ersten Adreßraum abgebildeten ersten Programmsegment gewonnen sind; und

wobei der erste Prozeß die Kontrolle an den mit dem ersten Programmsegment verknüpften zweiten Prozeß überträgt, indem eine Initialisierungsfunktion in dem zweiten Adreßraum aufgerufen wird, wobei die Initialisierungsfunktion unter Verwendung der Symboladreßtabelle lokalisiert wird.