DE69400406T2

DE69400406T2 - System und methode zur lokalisierung von geteilten bibliotheken

Info

Publication number: DE69400406T2
Application number: DE69400406T
Authority: DE
Inventors: Andrew Heninger; Russell Nakano
Original assignee: Taligent Inc
Current assignee: Object Technology Licensing Corp
Priority date: 1993-04-05
Filing date: 1994-01-03
Publication date: 1997-03-27
Anticipated expiration: 2014-01-04
Also published as: EP0679273A1; JP3670278B2; CA2145671A1; JPH08508594A; EP0679273B1; WO1994023360A1; US5414854A; DE69400406D1; AU6082294A

Description

QUERVERWEISE AUF VERWANDTE PATENTANMELDUNGEN

Diese Anmeldung ist mit den folgenden US-Patentanmeldungen verwandt: (1) der Anmeldung mit dem Titel "Objektorientiertes Rahmenwerksystem" von Debra L. Orton, David B. Goldsmith, Christopher P. Moeller und Andrew G. Heninger, eingereicht am 23. Dezember 1992, und abgetreten an Taligent, Inc., deren Offenbarung hiermit als Referenz eingeschlossen wird; und (ii) der Anmeldung mit dem Titel "Objektorientiertes Betriebssystem" von Robert Dickinson, eingereicht am 22. Januar 1993, und abgetreten an Taligent, Inc., deren Offenbarung hiermit als Referenz eingeschlossen wird.

GEBIET DER ERFINDUNG

Diese Erfindung betrifft im allgemeinen das Laden gemeinsam benutzter Bibliotheken und insbesondere das Abbilden von Namen gemeinsam benutzter Bibliotheken mit Positionen gemeinsam benutzter physikalischer Bibliotheken durch die Verwendung von Suchobjekten.

HINTERGRUND DER ERFINDUNG

Eine Bibliothek stellt eine Sammlung von Daten und Codes dar, die an bestimmten Positionen gespeichert sind. Eine Bibliothek enthält nicht nur ältere Datenbestände, sondern empfängt auch jüngere Datenbestände. Somit kann die Anzahl der Datenbestände ständig zunehmen. Darüber hinaus sind bestehende Datenbestände dynamisch und unterliegen Veränderungen. Auch mehrfache Versionen einer Bibliothek können in einem Computersystem vorhanden sein.
Eine Bibliothek kann auch gemeinsam benutzt werden. Das heißt, eine Bibliothek kann gleichzeitig von mehreren Anwendungen oder Prozessen verwendet werden. Eine derartige Bibliothek wird als "gemeinsam benutzte Bibliothek" bezeichnet.
Wenn eine Anwendung oder ein Programm gestartet wird, ist es notwendig, alle gemeinsam benutzten Bibliotheken zu "laden", die für die Implementierung des Programms erforderlich sind. Ein Programm bezieht sich im allgemeinen auf den Namen einer gemeinsam benutzten Bibliothek. Daher müssen sowohl die gemeinsam benutzte Bibliothek, auf die innerhalb des Programms Bezug genommen wird, ebenso wie alle anderen gemeinsam benutzten Bibliotheken, von denen diese abhängig ist, gefunden werden, bevor der Ladevorgang ausgeführt werden kann.
Aktuelle Computersysteme sind nicht in der Lage, auf wirksame Weise die Positionen benötigter gemeinsam benutzter Bibliotheken aufgrund des Namens, auf welchen das Programm Bezug nimmt, zu ermitteln. Der Grund dafür liegt in der Tatsache, daß aktuelle Computersysteme nicht in der Lage sind, komplexe Suchvorgänge nach den Positionen gemeinsam benutzter Bibliotheken durchzuführen. Darüber hinaus sind aktuelle Computersysteme nicht in der Lage, zwischen Versionen und Kopien gemeinsam benutzter Bibliotheken zu unterscheiden. Desweiteren sind aktuelle Computersysteme nicht in der Lage, auf geeignete Weise die Kompatibilitätsattribute unterschiedlicher gemeinsam benutzter Bibliotheken auszugleichen.
Der Artikel "OS/2 Dynamic Link Libraries" von R. Duncan, im Programmer's Journal, Vol 7, Nr. 2, April 1989, Seiten 40-47, offenbart dynamisch verknüpfte OS/2-Bibliotheken, bei denen es sich im wesentlichen um Unterprogramm- Pakete handelt, welche zum Zeitpunkt des Ladens oder während der Ausführung an eine Anwendung angebunden werden. Die DLLs (dynamisch verknüpften Bibliotheken) enthalten Objektcodeversionen, die erzeugt werden, wenn der mit einem bestimmten Satz Unterprogramme verknüpfte Quellcode kompiliert wird. Der Objektcode wird mit dem Anwendungsquellcode verbunden, der in generierten Objektcode kompiliert und in der Folge mit den DLLs verbunden wird, um ein ausführbares Modul zu schaffen. Die Routinen in einer DLL sind für sofortige Ausführung geeignet und zum Zeitpunkt des Ladens oder der Ausführung einer Anwendung an diese gebunden. Sie werden daher als eine Erweiterung des Prozesses betrachtet. Der Verbinder baut die Namen der DLLs und Routinen in die Tabellen im Anfang der EXE-Datei ein, zusammen mit Zeigern, die auf die einzelnen Referenzen zu den DLLs im ausführbaren Code verweisen. Wenn ein Programm zur Ausführung geladen wird, überprüft der Systemlader die Nodulreferenztabelle des Dateianfangs, um zu bestimmen, welche DLL vom Prozeß verwendet werden wird. Wenn diese Bibliotheken nicht bereits geladen sind, ruft sich der Lader selbst auf rekursive Weise auf, um diese sowie alle anderen Bibliotheken, auf welche diese wiederum verweisen, in den Speicher zu laden. Der Lader geht immer davon aus, daß eine dynamische Bibliothek die Dateiendung "DLL" hat und daher in einem der Verzeichnisse gefunden werden kann, die in der Datei CONFIG.SYS angegeben sind. Während ein Programm läuft oder eine DLL in Verwendung steht, werden die Segment- und Eintrittspunkttabellen resident gehalten, so daß verwerfbare Segmente und nach Bedarf zu ladende Segmente leicht aufgefunden werden können, wenn sie benötigt werden.
Dieses bekannte System erfordert eine kontinuierliche Aktualisierung der Tabellen, die verwendet werden, um die DLLs aufzurufen. Es erfordert darüber hinaus die Verwendung bestimmter Dateinamenformate. Es ist nicht dafür geeignet, in einem objektorientierten Betriebssystem verwendet zu werden und komplexe Suchvorgänge für die Positionen gemeinsam benutzter Bibliotheken auszuführen, noch kann dieses bekannte System zwischen Versionen und Kopien gemeinsam benutzter Bibliotheken unterscheiden.
EP A 0 352 447 offenbart eine virtuelle Seitenschauvorrichtung zur Pflege benannter Datenobjekte in klassenbezogenen Datenräumen in einem virtuellen Speicher, die rasch von Anwenderprogrammen geladen werden kann. Die Datenobjekte identifizieren Datensätze, die sich an einem Datenplatz befinden, über einen Namen, der einen Klassennamen, einen Hauptnamen und einen Nebennamen umfaßt. Zum Laden eines Datenobjektes wird eine anwenderdefinierte Suchreihenfolge von Hauptnamen für alle Nebennamen innerhalb einer Klasse verwendet. Die "Objekte" und die "Klassen" dieser bekannten Vorrichtung sind keine "Objekte" und "Klassen" des objektorientierten Programmdesigns, sondern dienen einfach zum Laden der Daten in einer virtuellen Speicherumgebung. Somit ist die bekannte Vorrichtung auch nicht in der Lage, die Aufgaben der vorliegenden Erfindung zu lösen.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung beseitigt die zuvor erwähnten Mängel des Standes der Technik, indem sie ein Verfahren und eine Vorrichtung schafft, welche auf wirksame Weise die physikalischen Positionen gemeinsam benutzter Bibliotheken über die Namen der gemeinsam benutzten Bibliotheken sucht und findet.
Die vorliegende Erfindung, wie sie in den Patentansprüchen 1 und 11 festgelegt wird, arbeitet so, daß sie zuerst die Namen der gemeinsam benutzten Bibliotheken bestimmt, die für ein Programm notwendig sind, das gestartet wurde. Danach werden Suchobjekte verwendet, um eine physikalische Position zu suchen und zu finden, weiche den einzelnen bestimmten Namen entspricht. Innerhalb eines Teams können auch mehrere Suchobjekte festgelegt werden. Ein Team bezieht sich auf einen Adreßplatz und eine Vielzahl an Ausführungspfaden, die innerhalb des Adreßplatzes ausgeführt werden. Dadurch können physikalische Positionen durch Verwendung einer Sammlung von Suchobjekten in einer ausgewählten sequentiellen Reihenfolge gefunden werden. Suchobjekte können zum Beispiel nacheinander in der Reihenfolge verwendet werden, in der sie dem Team hinzugefügt wurden.
Nachdem das Suchobjekt eine geeignete physikalische Position gefunden hat, welche den einzelnen Namen der gemeinsam benutzten Bibliotheken entspricht, wird jede der gemeinsam benutzten Bibliotheken auf ihre entsprechende physikalische Position abgebildet. Danach kann der Inhalt der erhaltenen physikalischen Positionen der gemeinsam benutzten Bibliotheken für die Zwecke des Programms gefunden werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die zuvor genannten sowie andere Aspekte und Vorteile der vorliegenden Erfindung werden besser aus der nachfolgenden genauen Beschreibung der bevorzugten Ausführungsform der Erfindung unter Bezugnahme auf die begleitenden Zeichnungen ersichtlich, in denen:
Figur 1 ein Blockdiagramm eines Computersystems gemäß der vorliegenden Erfindung ist;
Figur 2 ein Flußdiagramm darstellt, welches den Logikfluß gemäß der vorliegenden Erfindung zeigt;
Figur 3 eine Klassenvererbungshierarchie für Suchobjekte gemäß der vorliegenden Erfindung zeigt;
Figur 4 ein Flußdiagramm darstellt, welches die Suche eines Suchobjektes nach einer benannten gemeinsam benutzten Bibliothek gemäß der vorliegenden Erfindung darstellt; und
Figur 5 ein Beispiel für gemeinsam benutzte Bibliotheken zeigt, die unterschiedliche Kompatibilitätsnummern nach einem Beispiel gemäß der vorliegenden Erfindung zeigt.

GENAUE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM DER VORLIEGENDEN ERFINDUNG

COMPUTERSYSTEM

Eine repräsentative Hardwareumgebung wird in Figur 1 dargestellt, welche eine geeignete Hardwarekonfiguration einer Workstation 40 gemäß der vorliegenden Erfindung zeigt. Die Workstation 40 verfügt über eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, und eine Reihe von anderen Einheiten, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1 dargestellte Workstation 40 umfaßt einen Direktzugriffsspeicher 14 (RAM), einen Nur-Lese-Speicher 16 (ROM), einen E/A-Adapter 18 zum Anschluß von Peripheriegeräten, wie zum Beispiel Disketteneinheiten, am Bus 12, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 28, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus 12. Die Workstation 40 kann auch über einen Kommunikationsadapter 34 zum Anschluß der Workstation 40 an einem datenverarbeitenden Netzwerk 30 und einen Anzeigenadapter 36 für den Anschluß des Busses 12 an einem Anzeigegerät 38 verfügen.
Die vorliegende Erfindung arbeitet vorzugsweise innerhalb eines objektorientierten Betriebssystems, wie dies in der US-Patentanmeldung mit dem Titel "Objektorientiertes Rahmenwerksystem", eingereicht am 23. Dezember 1992, und in der Patentanmeldung "Objektorientiertes Betriebssystem", eingereicht am 22. Januar 1993, beschrieben wird. Beide diese Patentanmeldungen wurden an Taligent, Inc. abgetreten.

LOGIKAUSFÜHRUNG DER VORLIEGENDEN ERFINDUNG

Die vorliegende Erfindung umfaßt ein Rahmenwerk, das in Verbindung mit einem Computersystem zur Zeit der Ausführung eines Programmes zu verwenden ist, um gemeinsam benutzte Bibliotheken zu laden und diese miteinander zu verbinden. Ein solches Rahmenwerk bietet die Möglichkeit, den Namen einer gemeinsam benutzten Bibliothek, auf den von einem Programm verwiesen wird, mit den gemeinsam benutzten Bibliotheken zu verbinden, die beim Starten des Programms benötigt werden.
Jede gemeinsam benutzte Bibliothek wird durch einen festgelegten Namen gekennzeichnet und befindet sich innerhalb eines bezeichneten Namensplatzes. Eine gemeinsam benutzte Bibliothek hängt von einer beliebigen Anzahl anderer gemeinsam benutzter Bibliotheken ab bzw. ist mit diesen notwendigerweise verbunden. Ein Lademodul für gemeinsam benutzte Bibliotheken, entsprechend einer bestimmten gemeinsam benutzten Bibliothek, speichert: (i) den angegebenen Namen einer bestimmten gemeinsam benutzten Bibliothek; und (ii) die angegebenen Namen von gemeinsam benutzten Bibliotheken, von denen die bestimmte gemeinsam benutzte Bibliothek abhängt.
Jedesmal, wenn eine bestimmte gemeinsam benutzte Bibliothek gemäß einem Programm geladen wird, müssen auch alle anderen gemeinsam benutzten Bibliotheken, von denen die bestimmte gemeinsam benutzte Bibliothek abhängt, geladen werden. Dementsprechend wird auf ein Lademodul für gemeinsam benutzte Bibliotheken zurückgegriffen, um die Namen der für ein Programm zu ladenden gemeinsam benutzten Bibliotheken festzulegen. Da der Namensplatz für gemeinsam benutzte Bibliotheken global ist, sollte jeder gemeinsam benutzten Bibliothek ein ihr eigentümlicher Name gegeben werden, um sicherzustellen, daß die richtigen gemeinsam benutzten Bibliotheken miteinander verbunden werden. Die vorliegende Erfindung arbeitet unter der Voraussetzung, daß jede einzelne gemeinsam benutzte Bibliothek über einen derartigen einzigartigen Namen verfügt.
Damit ein Programm beim Starten ausgeführt wird, muß eine gemeinsam benutzte Bibliothek mit anderen gemeinsam benutzten Bibliotheken verbunden werden. Dieser Verbindungsvorgang findet statt, nachdem die entsprechenden gemeinsam benutzten Bibliotheken geladen wurden.
Ein Mechanismus, der als Lader bezeichnet wird, bestimmt zuerst die Namen der gemeinsam benutzten Bibliotheken, die geladen werden müssen. Der Lader muß danach über die physikalischen, gemeinsam benutzten Bibliotheken informiert werden, welche den Namen der festgelegten, gemeinsam benutzten Bibliotheken entsprechen. Die Positionen der physikalischen gemeinsam benutzten Bibliotheken umfassen typischerweise eine Computerfestplatte, RAM ("Direktzugriffsspeicher") und ROM ("Nur-Lese-Speicher") Der Lader bestimmt jedoch nicht, wo die Bibliotheken positioniert sind. Statt dessen verwendet der Lader Suchobjekte, um die Position der gemeinsam benutzten Bibliotheken zu bestimmen. Suchobjekte bilden Bibliotheksnamen auf Positionen physikalischer, gemeinsam benutzter Bibliotheken ab. Mit Hilfe der sich daraus ergebenden Abbildungsinformationen kann der Lader danach die entsprechenden gemeinsam benutzten Bibliotheken laden.
Bezugnehmend auf Figur 2 wird ein Flußdiagramm dargestellt, welches die Schritte des Verbindens einer gemeinsam benutzten Bibliothek mit einer anderen zeigt. Das Starten eines Programmes erfordert typischerweise das Laden von gemeinsam benutzten Bibliotheken und das Verbinden dieser miteinander. Dies wird in der Box 202 dargestellt. Danach werden die Namen der gemeinsam benutzten Bibliotheken bestimmt, welche für das gestartete Programm benötigt werden. Dies wird in der Box 204 dargestellt. Die Namen der gemeinsam benutzten Bibliotheken, die für ein Programm erforderlich sind, umfassen jene Namen, auf die von einem Programm verwiesen wird, sowie jene gemeinsam benutzten Bibliotheken, von denen das gestartete Programm oder die erwähnte gemeinsam benutzte Bibliothek abhängig sind. Solche Namen werden vom zuvor erwähnten Lademodul für gemeinsam benutzte Bibliotheken bestimmt.
Nachdem die Namen der gemeinsam benutzten Bibliotheken bestimmt sind, werden Suchobjekte verwendet, um die entsprechenden physikalischen Positionen der gemeinsam benutzten Bibliotheken zu finden, die den Namen entsprechen. Dies wird in der Box 206 dargestellt. Die Klasse TLibrarySearcher, die weiter unten genauer beschrieben wird, ist eine abgeleitete Klasse, welche die Schnittstelle für verwendete Suchobjekte definiert. Anhand der festgelegten Namen der gemeinsam benutzten Bibliotheken gelangt ein Suchobjekt zu den physikalischen, gemeinsam benutzten Bibliotheken, indem es den Suchanweisungen des Suchobjektes folgt.
Das Gelangen zu den entsprechenden physikalischen Positionen der gemeinsam benutzten Bibliotheken führt zu jener Abbildung, wie sie in der Box 208 dargestellt ist. Die Abbildung umfaßt die Bezeichnung der Namen der gemeinsam benutzten Bibliotheken mit den erhaltenen physikalischen Positionen der gemeinsam benutzten Bibliotheken. Danach werden die erhaltenen physikalischen, gemeinsam benutzten Bibliotheken geladen und miteinander verbunden. Dies wird durch die Bezugsnummern 210 bzw. 212 gezeigt.

SUCHOBJEKTE

Objektorientiert ist eine Systemtechnik, welche aus einer Anzahl von Objekten besteht. Jedes Objekt, welches typischerweise einem tatsächlichen Gebilde entspricht, bietet eine Anzahl von Operationen und einen Zustand, der sich den Zustand jener Operationen merkt. Ein Personenobjekt würde zum Beispiel Informationen bezüglich einer Person besitzen, wie zum Beispiel deren Alter, Adresse, Telefonnummer, Beruf, und so weiter. Danach werden Operationen erzeugt, um auf diese Informationen zuzugreifen oder sie zu beeinflussen. Darüber hinaus können Operationen geschaffen werden, um ein Verhalten auszuüben, welches keine internen Informationen beeinflußt, wie zum Beispiel das Gehen.
Eine Klasse ist eine Definition, eine Vorlage oder eine Form, welche die Schaffung neuer Objekte ermöglicht. Die Objekte einer bestimmten Klasse verfügen über eine gemeinsame Vorlage. Die Merkmale einer Klasse können an eine weitere Klasse vererbt werden, die als Unterklasse bezeichnet wird. Eine Unterklasse erbt somit die Informationsstruktur und das Verhalten einer Klasse. Weitere Informationen und weiteres Verhalten können dann einer Unterklasse hinzugefügt werden.
Klassen, die in der Erbhierarchie unter einer Klasse liegen, werden als Nachfahren der Klasse bezeichnet. Klassen, die darüber liegen, werden Vorfahren genannt. Die Begriffe Nachfahren und Unterklassen sind somit wechselseitig austauschbar.
Bezugnehmend auf Figur 3 wird eine Hierarchie von Suchobjektklassen dargestellt. Die Klasse MCollectible 300 repräsentiert die Ausgangsklasse aller Suchobjekte. Das heißt, die Klasse MCollectible 300 ist jene Klasse, von der alle anderen Klassen abstammen. Die zwei wichtigsten Nachfahren der Klasse MCollectible 300 sind die Klasse TLibrarySearcher 302 und die Klasse TTeamHandle 308. Die Klasse TLibrarySearcher 302 hat zwei weitere Nachkommen, nämlich die Klasse TStandardLibrarySearcher und die Klasse TworkspaceSearcher, wie dies durch die Bezugsnummern 304 bzw. 306 dargestellt wird.
Die Klasse TStandardLibrarySearcher 304 legt ein Standard-Suchobjekt fest, welches nach physikalischen, gemeinsam benutzten Bibliotheken in einem einzigen Verzeichnis sucht. Da normalerweise mehr als ein Verzeichnis durchsucht werden muß, ist die Klasse TStandardLibrarySearcher 304 typischerweise nicht in der Lage, alle physikalischen, gemeinsam benutzten Bibliotheken in einem System zu finden. Desweiteren berücksichtigen Objekte der Klasse TStandardLibrarySearcher 304 nicht die Kompatibilität, wenn sie mit mehreren Kopien einer Bibliothek konfrontiert werden.
Demgemäß wird die Klasse TWorkspaceSearcher 306 geschaffen, um physikalische, gemeinsam benutzte Bibliotheken zu finden, an Stelle eines Suchobjektes, welches nach der Klasse TStandardLibrarySearcher 304 geschaffen wurde. Die Klasse TWorkspaceSearcher 306 macht es möglich, daß Suchobjekte von einer Workstation gebildet werden. Suchobjekte, welche von der Klasse TWorkspaceSearcher 306 festgelegt werden, sind in der Lage, in mehr als nur einem Verzeichnis zu suchen, und sie sind auch in der Lage, bei Bedarf die Kompatibilität zu berücksichtigen.
Objekte, welche von der Klasse TLibrarySearcher 302 abgeleitet werden, können eine beliebig komplexe Suche durchführen. Solche Objekte können zum Beispiel: (i) Dateiattribute berücksichtigen, (ii) ein Wörterbuch oder eine Datenbank mit Bibliotheken pflegen; und (iii) mit den Bibliotheksinstallationsprozeduren interagieren. Eine Unterklasse von TLibrarySearcher 302, nämlich die Klasse TStandardLibrarySearcher 304 und die Klasse TWorkspaceSearcher 306, können auch geschaffen werden, um im System zu prüfen, ob eine Version einer gemeinsam benutzten Bibliothek bereits in Verwendung steht.
Bezugnehmend auf Figur 4 wird ein Flußdiagramm dargestellt, welches den Logikfluß einer Suche nach einer gemeinsam benutzten Bibliothek zeigt. Zuerst wird ein Suchobjekt mit dem Namen einer gemeinsam benutzten Bibliothek dargestellt. Ausgehend von dieser genannten, gemeinsam benutzten Bibliothek, die dargestellt wird, wird eine Suche nach der Position der gemeinsam benutzten Bibliothek durchgeführt. Dies wird durch die Bezugsnummer 400 angezeigt.
Eine Suche nach der genannten Bibliothek zeigt entweder: (i) daß mehrere Kopien der gemeinsam benutzten Bibliotheken vorhanden sind; (ii) daß keine Position dem Namen der gemeinsam benutzten Bibliothek entspricht; oder (iii) eine Kopie der gemeinsam benutzten Bibliothek. Diese Ergebnisse werden durch Boxen dargestellt, welche die Bezugsnummern 402, 410 bzw. 420 haben.
Wenn eine gemeinsam benutzte Bibliothek nicht gefunden wird, gibt das Suchobjekt "NULL" aus, wie dies in der Box 412 zu sehen ist. Wenn nur eine Kopie der gemeinsam benutzten Bibliothek gefunden wird, wird diese gemeinsam benutzte Bibliothek an den Lader zurückgegeben, wie dies in der Box 422 veranschaulicht ist.
Wenn jedoch mehrere Kopien der gemeinsam benutzten Bibliothek gefunden werden, ist eine weitere Analyse notwendig, bevor eine Kopie zurückgegeben werden kann. Eine solche weitere Analyse beginnt zuerst mit einer Bestimmung, ob die Kompatibilitätsnummern der Kopien der gemeinsam benutzten Bibliothek bestimmt werden können. Dies wird in der Box 404 dargestellt. Wenn die Kompatibilitätsnummern der Kopien der gemeinsam benutzten Bibliothek bestimmt werden können, wird die Kopie der gemeinsam benutzten Bibliothek mit der höchsten Kompatibilitätsnummer zurückgegeben. Dies wird in der Box 406 dargestellt.
Wenn die Kompatibilitätsnummer der Kopien der gemeinsam benutzten Bibliothek nicht bestimmt werden kann, ist ein weiteres Auswahlverfahren erforderlich. Ein derartiges weiteres Auswahlverfahren kann eine Bestimmung umfassen, ob eine der Kopien der gemeinsam benutzten Bibliothek derzeit an einer anderen Stelle geladen ist. Schließlich sollte dieses weitere Auswahlverfahren eine ausgewählte Kopie der gemeinsam benutzten Bibliothek zurückgeben, wie dies in der Box 416 dargestellt ist.
Zurückgegebene Kopien von gemeinsam benutzten Bibliotheken, wie dies in den Boxen 406, 416 und 422 dargestellt ist, werden mit dem Namen der gemeinsam benutzten Bibliothek abgebildet. Dies wird in Box 430 dargestellt. Danach werden die abgebildeten Informationen dem Lader offenbart.
Kompatibilität ist eine Dateisystemeigenschaft gemeinsam benutzter Bibliotheken, welche Dateien sind. Die Kompatibilität wird über eine Kompatibilitätsnummer gemessen, wobei eine Kopie einer gemeinsam benutzten Bibliothek mit der höchsten Kompatibilitätsnummer sehr wahrscheinlich mit anderen abhängigen, gemeinsam benutzten Bibliotheken kompatibel ist. Dementsprechend gibt ein Suchobjekt die Kopie einer gemeinsam benutzten Bibliothek mit der höchsten Kompatibilitätsnummer zurück. Ein Suchobjekt ist dazu immer in der Lage, wenn eine gemeinsam benutzte Bibliothek eine Datei ist, da Dateien stets Zugriff auf Kompatibilitätsnummern bieten. Gemeinsam benutzte Bibliotheken, die keine Dateien sind, bieten jedoch in manchen Fällen keinen Zugriff auf die Kompatibilitätsnummer einer Kopie. In einem solchen Fall ist das Suchobjekt nicht in der Lage, eine Kopie mit dem höchsten Kompatibilitätsgrad festzustellen.
Gemeinsam benutzte Bibliotheken werden hintereinander geladen, wenn zwei Bedingungen erfüllt sind. Zum ersten gibt ein Suchobjekt die Kopie mit der höchsten Kompatibilitätsnummer zurück. Zum zweiten werden, wenn an Positionen, an denen ein Suchobjekt eine Suche durchgeführt hat, ein konsistenter Satz an gemeinsam benutzten Bibliotheken vorhanden ist, diese Bibliotheken geladen.
Bezugnehmend auf Figur 5 wird ein Beispiel von drei Bibliotheken mit unterschiedlichen Kompatibilitätsnummern bildhaft dargestellt. Nehmen wir an, es werden drei Bibliotheken mit den Bezeichnungen A, B und C geladen. Die Bibliothek A mit der Kompatibilitätsnummer 1 ("Bibliothek (A,1)", dargestellt durch die Bezugsnummer 502) hängt von der Bibliothek B mit der Kompatibilitätsnummer 2 ("Bibliothek (B,2)", dargestellt durch die Bezugsnummer 504) und der Bibliothek C mit der Kompatibilitätsnummer 2 ("Bibliothek (B,2)", dargestellt durch die Bezugsnummer 506) ab. Die Bibliothek B mit der Kompatibilitätsnummer 3 ("Bibliothek (B,3)", dargestellt durch die Bezugsnummer 510) hängt von der Bibliothek C mit der Kompatibilitätsnummer 3 ("Bibliothek (C,3)", dargestellt durch die Bezugsnummer 508) ab. Die Bibliothek (B,2) 504 hängt von der Bibliothek (C,2) 506 ab. Die Bibliothek (C,2) 506 und die Bibliothek (C,3) 508 hängen jedoch von keinen anderen Bibliotheken ab.
Wenn der Lader versucht, die Bibliothek (A,1) 502 zu laden, muß er auch eine Kopie der Bibliotheken laden, von denen die Bibliothek (A,1) 502 abhängig ist. Die geladenen Kopien müssen eine Kompatibilitätsnummer aufweisen, die gleich oder größer ist als die Kompatibilitätsnummer der abhängigen gemeinsam benutzten Bibliothek. Dementsprechend kann ein Lader folgendes laden: (i) die Bibliothek (B,2) 504 oder die Bibliothek (B,3) 510; und (ii) die Bibliothek (C,2) 506 und die Bibliothek (C,3) 508. Die Bibliothek (B,3) 510 muß jedoch mit der Bibliothek (C,3) 508 geladen werden. Die Bibliothek (C,2) 506 reicht nicht aus, um die Abhängigkeit der Bibliothek (B,3) 510 zu befriedigen.
Ein Suchobjekt oder eine Mehrzahl an Suchobjekten wird die Bibliothek (A,1) 502, die Bibliothek (B,2) 504, die Bibliothek (B,3) 510, die Bibliothek (C,2) 506 und die Bibliothek (C,3) 508 finden. Wenn ein Suchobjekt die Kopie mit der höchsten Kompatibilitätsnummer zurückgibt, gibt es die Bibliothek (A,1) 502, die Bibliothek (B,3) 510 und die Bibliothek (C,3) 508 zurück. Diese drei Bibliotheken werden dann geladen werden, weil alle Abhängigkeiten erfüllt sind.
Wenn ein Suchobjekt nicht die zuvor erwähnten drei Bibliotheken zurückgeben würde, wäre das Laden wahrscheinlich nicht möglich. Ein Suchobjekt könnte zum Beispiel die Bibliothek (A,1) 502, die Bibliothek (B,3) 510 und die Bibliothek (C,2) 506 zurückgeben. In einem solchen Fall würden die Bibliotheken nicht geladen werden, weil die Abhängigkeit der Bibliothek (B,3) 510 von der Bibliothek (C,3) 508 nicht zufriedengestellt ist. Um diese Situation zu vermeiden, muß ein Suchobjekt die Kopie einer Bibliothek mit der höchsten Kompatibilitätsnummer zurückgeben. Dies kann natürlich nur dann gelingen, wenn das Suchobjekt auf die Kompatibilitätsnummer einer gemeinsam benutzten Bibliothek zugreifen kann.

TEAMATTRIBUTE VON SUCHOBJEKTEN

Suchobjekte werden in ein Team gestellt. Jedes Team verfügt über eine Liste mit einem oder mehreren Suchobjekten, auf die der Lader zurückgreift, wenn er eine mit dem Team zusammenhängende gemeinsam benutzte Bibliothek lädt. Die Anzahl der Suchobjekte, welche in einem Team enthalten sein können, ist nicht beschränkt. Wenn ein neues Team geschaffen wird, kann eine Sammlung von Suchobjekten in das Konstruktorobjekt geleitet werden, wie dies innerhalb der Klasse TTeamHandle (beschrieben in Figur 3 durch die Bezugsnummer 308) gebildet ist. Die Sammlung von Suchobjekten wird dann dem neuen Team hinzugefügt.
Innerhalb eines Teams sind zwei Arten von Suchobjekten vorhanden, die von der Klasse TLibrarySearcher 302 abgeleitet sind. Zum ersten werden Suchobjekte allen Teams hinzugefügt, die geschaffen werden. Diese werden als "Systemsuchobjekte" bezeichnet. Zum zweiten können Suchobjekte geschaffen werden, die nur bestimmten Teams hinzugefügt werden. Diese werden als teamspezifische Objekte bezeichnet. Wenn auf ein Team zugegriffen wird, werden sowohl die teamspezifischen Suchobjekte als auch die Systemsuchobjekte in den Adreßraum des Teams geströmt Daher müssen die Unterklassen von TLibrarySearcher 302, TStandardLibrarySearcher 304 und TWorkspaceSearcher 306, Strömungsoperatoren aufweisen.
Der Lader benutzt die Sammlung an Suchobjekten innerhalb eines Teams, um Bibliotheksnamen auf Bibliothekspositionen oder Module abzubilden. Danach werden die gemeinsam benutzten Bibliotheken in den Adreßraum des Teams gestellt. Der Lader benutzt vorzugsweise die Suchobjekte in der LIFO- Ordnung (Letzte-Eingabe/erste-Ausgabe). Das heißt, die Suchobjekte werden in der Reihenfolge verwendet, in der sie dem Team hinzugefügt wurden. Dementsprechend wird das zuletzt hinzugefügte Suchobjekt als erstes verwendet. Suchobjekte werden in der LIFO-Reihenfolge nacheinander verwendet, bis eine gemeinsam benutzte Bibliothek gefunden wird. Wenn keines der Suchobjekte die gemeinsam benutzte Bibliothek finden kann, unterbricht der Lader den Ablauf, da er nicht fortfahren kann. Als Reaktion auf diese Ablaufunterbrechung können Suchobjekte einem Team hinzugefügt werden, nachdem auf das Team zugegriffen wurde. In der Folge hinzugefügte Suchobjekte können jedoch nur gemeinsam benutzte Bibliotheken finden, die dynamisch in den Adreßraum des Teams geladen wurden, nachdem die Suchobjekte hinzugefügt worden sind.
Vorzugsweise verwendet der Lader Suchobjekte in der LIFO-Ordnung, da davon ausgegangen wird, daß die zuletzt hinzugefügten Suchobjekte bereits vorhandene Suchobjekte außer Kraft setzen sollen. Somit wird die Sammlung an Teamsuchobjekten immer verwendet, bevor ein Standardsuchobjekt, definiert nach der Klasse TStandardLibrarySearcher 304, verwendet wird. So kann es zum Beispiel zwei Versionen einer gemeinsam benutzten Bibliothek X im System geben. Ein Standardsuchobjekt bildet die Bibliothek X auf eine erste Version der Bibliothek X ab. Ein Suchobjekt, definiert nach der Klasse TWorkspaceSearcher 306, würde sie jedoch auf eine zweite Version der Bibliothek X abbilden. Wenn das arbeitsplatzdefinierte Suchobjekt vor dem Standardsuchobjekt angewandt wird, wird die Bibliothek X auf die zweite Version der Bibliothek X abgebildet. Dementsprechend wird die richtige Version der Bibliothek X in den Adreßraum des Teams geladen, da das arbeitsplatzdefinierte Suchobjekt vor dem Systemsuchobjekt zur Suche herangezogen wird.
Alternativ dazu wird der gleiche Effekt erzielt, wenn ein temporäres Teamsuchobjekt festgelegt wird. Ein temporäres Suchobjekt kann in einem Aufruf an "TLibrary:: Loadlibrary for Library X" festgelegt werden. Das Team verwendet somit das temporäre Suchobjekt für die Dauer des Aufrufs, um die richtige Version der Bibliothek X zu laden. Temporäre Suchobjekte sind besonders dann nützlich, nachdem ein Team gestartet wurde. Dies ist deshalb der Fall, weil temporäre Suchobjekte der Sammlung von Teamsuchobjekten nicht hinzugefügt werden. Ganz im Gegenteil wirkt sich das Hinzufügen eines Suchobjektes zu einem Team ungünstig auf die Verwendung des Teams hinsichtlich anderer gemeinsam benutzter Bibliotheken aus. Somit sollte ein temporäres Bibliothekssuchobjekt verwendet werden, wenn Bibliotheken dynamisch in ein laufendes Team geladen werden.
Ein Systemsuchobjekt, welches mit allen Teams verbunden ist, wird von einem Lader nur dann verwendet, wenn alle teamspezifischen Suchobjekte bereits verwendet wurden. Somit werden die Suchobjekte in der folgenden Reihenfolge verwendet: (i) teamspezifische Suchobjekte; (ii) Systemsuchobjekte; und (iii) Standardsuchobjekte. Da die vorliegende Erfindung Systemobjekte in der LIFO-Reihenfolge verwendet, wirkt sich ein hinzugefügtes Systemsuchobjekt desweiteren nur auf das Laden jener gemeinsam benutzter Bibliotheken aus, die geschaffen wurden, nachdem dieses dem System hinzugefügt wurde.
Ein Systemsuchobjekt kann für eine Anwendung hinsichtlich aller Teams eines Systems oder hinsichtlich eines einzelnen, bestimmten Teams hinzugefügt werden.. Wenn ein Systemsuchobjekt für eine Anwendung hinsichtlich aller Teams hinzugefügt wird (durch Aufruf von "TLibrarySearcher::AddSystemSearcher"), wird das Systemobjekt auch für alle in der Folge geschaffenen Teams angewandt.
Wenn jedoch ein Suchobjekt für eine Anwendung hinsichtlich eines Teams hinzugefügt wird (durch Aufruf von "TTeamHandle::AddLibrarySearcher"), wird das neu geschaffene Suchobjekt nur für Bibliothekssuchen durch dieses Team angewandt.
Vorzugsweise dürfen Suchobjekte nicht entfernt werden, wenn sie einmal einem Team hinzugefügt wurden. Dies gilt für den Fall, daß es sich bei dem hinzugefügten Suchobjekt um ein teamspezifisches Suchobjekt handelt, ebenso wie für den Fall, daß es sich dabei um ein Systemsuchobjekt handelt. Diese Einschränkung gilt deshalb, weil ein Suchobjekt ein globales Betriebsmittel ist, welches von allen Tasks eines Teams gemeinsam benutzt wird. Das Entfernen eines Teamsuchobjektes hinsichtlich eines Tasks würde ungünstige Auswirkungen auf einen anderen Task haben, der von diesem Suchobjekt abhängig ist. Angenommen, zwei unabhängige Tasks ("Task 1" und "Task 2") im selben Team haben dasselbe hinzugefügte Suchobjekt. Im Falle, daß das Suchobjekt vom Task 1 entfernt wird, nimmt Task 2 trotzdem noch weiterhin an, daß sich das Suchobjekt an seinem Platz befindet. Somit sollten beide Tasks eine identische Liste der Suchobjekte erhalten. Vorzugsweise sollten temporäre Suchobjekte verwendet werden, wenn ein Suchobjekt nur hinsichtlich eines bestimmten Tasks verwendet werden muß, damit das Suchobjekt nicht einem Team hinzugefügt werden muß.
Die vorliegende Erfindung führt auch eine Analyse durch, um zu bestimmen, ob ein Suchobjekt, welches einem Team hinzugefügt werden sollte, bereits im Team vorhanden ist. Wenn ein Suchobjekt einem Team hinzugefügt wird, in dem ein Duplikat des Suchobjektes bereits vorhanden ist, wird die zweite Kopie des Suchobjektes nicht hinzugefügt. Das bereits im Team vorhandene Duplikatsuchobjekt wird jedoch an das Ende der Liste der Teambibliothekssuchobjekte gestellt. Dies geschieht deshalb, weil Suchobjekte am Ende einer Suchobjektliste eines Teams zuerst vom Team verwendet werden.
Die vorliegende Erfindung analysiert den Suchobjekttyp, um doppelt vorhandene Suchobjekte zu entdecken. So führt die C++-Programmiersprache zum Beispiel einen Vergleich durch die Ausführung eines "Is Equal"-Verfahrens ("Ist Gleich"-Verfahren) durch. Daher müssen alle TLibrary- Searcher- 302 Unterklassen das Isequal-Verfahren oder ein ähnliches Verfahrens außer Kraft setzen.
Eine Unterklasse von TLibrarySearcher 302 kann in einer gemeinsam benutzten Bibliothek enthalten sein. Damit jedoch ein Lader eine bestimmte gemeinsam benutzte Bibliothek finden kann, darf diese bestimmte Bibliothek nicht die Unterklasse TLibrarySearcher 302 enthalten, die notwendig ist, um sie zu finden. Somit muß sich eine TLibrarySearcher- 302 Unterklasse an einem Platz außerhalb einer gemeinsam benutzten Bibliothek befinden, der von der Unterklasse TLibrarySearcher 302 durchsucht werden muß. In anderen Worten: eine gemeinsam benutzte Bibliothek, welche eine TLibrarySearcher- 302 Unterklasse enthält, muß sich an einem Platz befinden, wo sie gefunden werden kann, ohne von der TLibrarySearcher- 302 Unterklasse abhängig zu sein, die sie enthält.
Eine Möglichkeit, um sicherzustellen, daß der Lader eine bestimmte gemeinsam benutzte Bibliothek finden kann, welche eine TLibrarySearcher- 302 Unterklasse enthält, besteht darin, die bestimmte gemeinsam benutzte Bibliothek dorthin zu geben, wo sie von einem Standardsystemsuchobjekt gefunden werden kann. Die Klasse TStandardLibrarySearcher 304, welche das Standardsuchobjekt definiert und mit jedem Team verbunden ist, kann immer eine bestimmte gemeinsam benutzte Bibliothek finden. Ein neu geschaffenes Team kann sich daher nur auf ein Standardsystemsuchobjekt verlassen, bis ein Arbeitsplatzsuchobjekt, wie es von der Klasse TWorkspaceSearcher 306 definiert wird, dem Team hinzugefügt wird. Jedesmal, wenn ein Suchobjekt einem Team hinzugefügt wird, muß das Team die gemeinsam benutzte Bibliothek laden, welche das Suchobjekt enthält. Dies erfolgt einfach durch die Verwendung von Systembibliothekssuchobjekten und gegebenenfalls teamspezifischen Suchobjekten, welche dem Team bereits hinzugefügt wurden.
Vorzugsweise wird nur eine Kopie einer gemeinsam benutzten Bibliothek in den Adreßraum eines Teams geladen. Wenn der Lader im Zusammenhang mit einem einzigen Team eine bestimmte gemeinsam benutzte Bibliothek mehr als einmal entdeckt, nimmt er an, daß die momentan geladene gemeinsam benutzte Bibliothek die richtige ist. Dementsprechend benutzt der Lader nicht einmal ein Suchobjekt, um die Duplikatbibliothek zu finden. Wenn die Sammlung an Suchobjekten eines Teams modifiziert wird und "LoadLibrary" aufgerufen wird, um eine Bibliothek zu laden, die sich bereits im Adreßraum des Teams befindet, würde das modifizierte Team eine andere Version der Bibliothek zurückgeben. Somit wird der Aufruf von LoadLibrary nicht den gewünschten Effekt haben, da die alte Version der Bibliothek im Adreßraum des Teams bleibt.
Unterschiedliche Teams, die sich auf derselben Workstation befinden, können unterschiedliche Kopien derselben gemeinsam benutzten Bibliothek verwenden. Teams, welche unterschiedliche Kopien derselben gemeinsam benutzten Bibliothek verwenden, müssen jedoch nicht Objekte eines anderen Teams durch einen gemeinsam benutzten Speicher gemeinsam benutzen, selbst wenn die Objektklasse in der gemeinsam benutzten Bibliothek definiert wird. Statt dessen muß sich ein gegebenes Team auf die Verwendung jener Objekte beschränken, die zum gegebenen Team gehören. Wenngleich Teams, die unterschiedliche Versionen einer gemeinsam benutzten Bibliothek verwenden, keine Objekte gemeinsam benutzen können, ist es den Teams doch gestattet, Objekte, deren Klassen in der gemeinsam benutzten Bibliothek definiert sind, zueinander zu strömen.
Eine Ausführungsform der vorliegenden Erfindung, welche vom Erfinder entwickelt wurde, ist im Anhang dieser Patentanmeldung dargelegt. Dadurch soll die detaillierte Logik der vorliegenden Erfindung erklärt werden. Kritische Elemente der einzelnen Abschnitte der Ausführungsform werden ebenso näher erklärt.

ANHANG: BEVORZUGTE AUSFÜHRUNGSFORM DER VORLIEGENDEN ERFINDUNG

SOURCE CODE. //Class TLibrarySearcher derived from base class MCollectible class TLibrarySearcher: public MCollectible
{ ...
public _TLibrarySearcher();
virtual TMappableDataContainer *CreateContainerandfindlibrary( constTTcxt&LibraryName, constCompatibilityNumber desired Release) =0;
virtual Boolean IsEqual(const MCollectible*) const = 0;
//the following public methods are for use only by the workspace.
static void AddSystemLibrarySearcher(TLibrarySearcher &);
static TIterator *CreateSystemLibrarySearcherIterator();
protected:
TLibrarySearcher();
TLibrarySearcher(const TLibrary Searcher&);
TLibrarySearcher& operator = (const TLibrary Searcher &);
virtual TStream& operator»=(TStream& toWhere) const;
virtual TStream& operator«=(TStream& fromWhere);
//Subclass Library Searcher used by the run time during System boot.
//Not intended for subclassing.
ClassTStandardLibrarySearcher : public TLibrarySearcher
{ ...
public:
virtual TStandardLibrarySearcher();
TStandardLibrarySearcher();
TStandardLibrarySearcher(const
TStandardLibrarySearcher &);
virtual TMappableDataContainer * CreateContainerAndFindLibrary(const
TText &LibraryName, const CompatabilityNumber desiredRelease);
virtual Boolean IsEqual(const TLibrary Searcher *) const;
TStandardLibrarySearcher & operator=(const TStandardLibrarySearcher &);
virtual TStream & operator»=(TStream& toWhere) const;
virtual TStream & operator«=(TStream& fromWhere);
}
//Excerpt of TTeamHandle. These are the methods of TTeamHandle //that use TLibrary Searcher
class TTeamHandle: public MCollectible
{ ...
TTeamHandle(const TTaskProgram &whatToRun,
const TorderedCollection & Library Searchers);
virtual void AddLibrarySearcher(TLibrarySearcher &);
virtual TIterator *CreateLibrarySearcherIterator();

COMMENTS ON SOURCE CODE:

//Class TLibrarySearcher derived from base class MCollectible

TLibrarySearcher() : Destruktor

TMappableDataContainer*CreateContainerandfindLibrary (constT Text&Libraryname.constCompatibilityNumberdesiredRelease):

Suche nach der Bibliothek mit dem angegebenen Namen: gib einen TMappableDataContainer für diese Bibliothek zurück. Der Aufrufer besitzt den Speicher für den TMappableDatacontainer. Wenn ein Bibliothekssucher mehrere Kopien einer gemeinsam benutzten Bibliothek findet, muß er entscheiden, welche Kopie er zurückgibt. Er sollte bei seiner Entscheidung auch berücksichtigen, welche Kopie(n) der Bibliothek gerade von den laufenden Teams geladen werden. Er sollte auch die angeforderte Kompatibilitätsnummer der gemeinsam benutzten Bibliothek berücksichtigen. Wenn der Sucher auf die Kompatibilitätsnummer einer gemeinsam benutzten Bibliothek zugreifen kann (die Kompatibilitätsnummer ist eine Eigenschaft gemeinsam benutzter Bibliotheken, welche Dateien sind), sollte er prüfen, ob die Kompatibilitätsnummer der gemeinsam benutzten Bibliothek, die er zum Zurückgeben in Betracht zieht, größer oder gleich ist wie die gewünschte Kompatibilitätsnummer. Gibt NULL zurück, wenn die Bibliothek nicht gefunden wurde. Dieses Verfahren muß von allen TLibrarySearcher-Unterklassen außer Kraft gesetzt werden.
Boolean IsEqual(constMCollectible*): Gib WAHR zurück, wenn die zwei Bibliothekssucher gleich sind; gib andernfalls FALSCH zurück.
Die folgenden Methoden können NUR vom Arbeitsplatz aufgerufen werden: static AddSystemLibrarySearcher(const TLibrarySearcher &) : Füge einen Bibliothekssucher der globalen Liste von Bibliothekssuchern hinzu, die automatisch von Teams geerbt werden, wenn diese geschaffen werden. Diese Funktion betrifft nur Teams, die geschaffen wurden, nachdem sie aufgerufen wurde; sie hat keine Auswirkungen auf bereits bestehende Teams.
static TIterator*CreatesystemLibrarySearcherIterator () : Erzeugt einen Iterator für die Systembibliothekssucher. Der Iterator gibt Zeiger zu den TLibrarySearcher-Unterklasseobjekten zurück. Der Aufrufer besitzt den Speicher für den Iterator. Der Iterator besitzt den Speicher für jene TLibrarySearcher, die er zurückgibt. Der Iterator gibt die Systembibliothekssucher in der Reihenfolge zurück, in der sie verwendet werden würden. Eine kIteratorOutOfSync-Ablaufunterbrechung erfolgt, wenn ein Systembibliothekssucher von einem anderen Pfad hinzugefügt wird, während der aktuelle Pfad die Systembibliothekssucher wiederholt.
//Von der Bearbeitungszeit während des Systemstarts verwendeter Unterklassebibliothekssucher. //Nicht zur Unterklassifizierung gedacht.
TStandardLibrarySearcher () : Konstruktor
TStandardLibrarySearcher () : Destruktor
TMappableDataContainer*CreateContainerandfindLibrary (constT Text &Libraryname, const CompatibilitynumberdesiredRelease) : Suche nach der Bibliothek mit dem angegebenen Namen im Verzeichnis "Gemeinsam benutzte Bibliotheken" auf der Festplatte und gib einen TMappableDataContainer für jene Bibliothek zurück: gib NULL zurück, wenn die Bibliothek nicht gefunden wird. Dieser Bibliothekssucher berücksichtigt in seiner Entscheidung nicht die geforderte Kompatibilitätsnummer. Der Aufrufer besitzt den Speicher für das TmappableDataContainer-Objekt.
BooleanIsEqual (constMCollectible*) : Gib WAHR zurück, wenn die zwei Standardbibliothekssucher gleich sind: gib andernfalls FALSCH zurück.
Wenngleich die Erfindung anhand einer bevorzugten Ausführungsform in einer spezifischen Systemumgebung beschrieben wurde, kann der Fachmann erkennen, daß die Erfindung mit Modifizierungen in anderen und unterschiedlichen Hardware- und Softwareumgebungen innerhalb des Geistes und Umfanges der nachfolgenden Patentansprüche ausgeführt werden kann.

Claims

1. In einem Betriebssystem ein Verfahren zur Lokalisierung von Programmbibliotheken, die von verschiedenen Anwendungen oder Prozessen gemeinsam benutzt werden und die durch Namen identifiziert und in einem Speicher (14, 20) eines Computers enthalten sind und auf Anforderung geladen werden, nachdem ein Anwendungsprogramm oder ein Prozeß gestartet worden ist,

gekennzeichnet durch die folgenden Schritte:

(a) Identifizierung einer Vielzahl von Namen gemeinsam benutzter Bibliotheken (502, 510), die von gestarteten Anwendungsprogrammen oder Prozessen benötigt werden, und von weiteren gemeinsam benutzten Bibliotheken (504, 506, 508), von denen die besagten gemeinsam benutzten Bibliotheken abhängig sind (204);

(b) Suchen nach und Erlangung einer Vielzahl von Speicherplätzen entsprechend den besagten identifizierten Namen der gemeinsam benutzten Bibliotheken durch Verwendung von wenigstens einem aus einer Vielzahl von Suchobjekten, die in einem objekt-orientierten Betriebssystem enthalten sind;

(c) Bestimmung durch besagte Suchobjekte, ob nur eine Kopie einer gemeinsam benutzten Bibliothek existiert oder ob eine Vielzahl von Kopien der besagten gemeinsam benutzten Bibliotheken (402, 420) existieren und, wenn mehrere Kopien existieren, Festlegung einer Kompatibilitätsnummer der besagten gemeinsam benutzten Bibliotheken und Auswahl derjenigen der besagten gemeinsam benutzten Bibliotheken, welche die höchste Kompatibilitätsnummer enthält;

(d) Abbilden der besagten Vielzahl von Namen der gemeinsam benutzten Bibliotheken auf besagte Vielzahl von gemeinsam benutzten Bibliotheken in besagtem Speicher durch Verwendung der in den besagten Suchobjekten (430) enthaltenen Logik.

2. Ein Verfahren gemäß Anspruch 1, worin eine oder mehrere der besagten Vielzahl von gemeinsam benutzten Bibliotheken im Versäumnisfalle benutzt werden.

3. Ein Verfahren gemäß Anspruch 1, worin eine oder mehrere der besagten Vielzahl von gemeinsam benutzten Bibliotheken in einer Gruppe angeordnet werden.

4. Ein Verfahren gemäß Anspruch 3, worin die in einer Gruppe angeordneten Suchobjekte aufeinanderfolgend in einer Letzte-Eingabe/erste-Ausgabe-Ordnung (LIFO) gespeichert werden.

5. Ein Verfahren gemäß Anspruch 4, worin die Letzte-Eingabe/erste-Ausgabe-Ordnung (LIFO) zur Anwendung kommt, wenn jedes der Suchobjekte zu besagter Gruppe hinzugefügt wird.

6. Ein Verfahren gemäß Anspruch 1, worin nur einer der besagten Vielzahl von Speicherplätzen wahlweise belegt werden für jede der besagten Vielzahl von Namen gemeinsam benutzter Bibliotheken.

7. Ein Verfahren gemäß Anspruch 1, enthaltend die Schritte:

(e) Hinzufügen einer Vielzahl von Suchobjekten zu einen vorbestimmten Speicherplatz;

(f) Identifizieren der Namen von besagter Vielzahl von Namen gemeinsam benutzter Bibliotheken, die mit einer bestimmten Bibliothek verbunden sind;

(g) aufeinanderfolgende Verwendung der besagten Vielzahl von Suchobjekten, die zu dem vorbestimmten Speicherplatz hinzugefügt worden sind, zur Belegung einer Vielzahl von Speicherplätzen entsprechend der besagten Vielzahl von Namen gemeinsam benutzter Bibliotheken; und

(h) Abbilden besagter Vielzahl von gemeinsam benutzten Bibliotheken auf besagte Vielzahl von belegten Speicherplätzen.

8. Ein Verfahren gemäß Anspruch 7, enthaltend den Schritt des Ausschlusses einer oder mehrerer Suchobjekte vom Hinzufügen zu besagtem vorbestimmten Speicherplatz, wenn ein Duplikat von einer oder mehreren der besagten Vielzahl von Suchobjekten in besagtem Speicherplatz existiert.

9. Ein Verfahren gemäß Anspruch 7, worin eine oder mehrere der besagten Vielzahl von Suchobjekten zu einer Vielzahl von vorbestimmten Speicherplätzen hinzugefügt werden.

10. Ein Verfahren gemäß Anspruch 7, worin besagte Vielzahl von Suchobjekten aufeinanderfolgend verwendet werden basierend auf der Ordnung, in welcher besagte Vielzahl von Suchobjekten zu besagtem vorbestimmten Speicherplatz hinzugefügt worden sind.

11. Eine Einrichtung zur Lokalisierung von gemeinsam benutzten Bibliotheken in einem Computer, der einen Speicher (14, 20) aufweist und von einem Betriebssystem gesteuert wird, besagte gemeinsam benutzte Bibliotheken sind durch Namen identifiziert und in einem Speicher des Computers enthalten und werden auf Anforderung geladen werden, nachdem ein Anwendungsprogramm oder ein Prozeß gestartet worden ist,

gekennzeichnet durch:

(a) ein objekt-orientiertes Betriebssystem zur Steuerung von besagtem Computer (10) und besagten Speichern (14, 20);

(b) eine Vielzahl von Bibliotheken-Suchobjekten (302, 304), die Logik enthalten zum Suchen und Erlangen von Speicherplätzen entsprechend den durch Namen identifizierten gemeinsam benutzten Bibliotheken und zur Abbildung einer Vielzahl von Namen der gemeinsam benutzten Bibliotheken zu einer Adresse in einem Speicher, wo die besagte gemeinsam benutzte Bibliothek gespeichert wird;

(c) Mittel (204) zur Identifizierung in besagtem Speicher des besagten Computers einer Vielzahl von Namen gemeinsam benutzter Bibliotheken (502), die von gestarteten Anwendungsprogrammen oder Prozessen benötigt werden, und von weiteren gemeinsam benutzten Bibliotheken (504, 506, 508), von denen die besagten gemeinsam benutzten Bibliotheken abhängig sind (204);

(d) Mittel (400) zum Suchen nach und Belegen von einer Vielzahl von Speicherplätzen entsprechend den besagten identifizierten Namen der gemeinsam benutzten Bibliotheken durch Verwendung der besagten Logik in besagten Suchobjekten;

(e) Mittel (406) Bestimmung durch besagte Suchobjekte, ob nur eine Kopie einer gemeinsam benutzten Bibliothek existiert oder ob eine Vielzahl von Kopien der besagten gemeinsam benutzten Bibliotheken (402, 420) existieren und&sub1; wenn mehrere Kopien existieren, Ermittlung derjenigen Kopie der besagten gemeinsam benutzten Bibliotheken, welche die höchste Kompatibilitätsnummer enthält; und

(f) Mittel (430) zur Abbildung der besagten Vielzahl von Namen der gemeinsam benutzten Bibliotheken auf besagte Vielzahl von gemeinsam benutzten Bibliotheken in besagtem Speicher durch Verwendung der in den besagten Suchobjekten (430) enthaltenen Logik.

12. Eine Einrichtung gemäß Anspruch 11, worin eine oder mehrere der besagten Vielzahl von gemeinsam benutzten Bibliotheken im Versäumnisfalle benutzt werden.

13. Eine Einrichtung gemäß Anspruch 11, worin eine oder mehrere der besagten Vielzahl von gemeinsam benutzten Bibliotheken in einer Gruppe angeordnet werden.

14. Eine Einrichtung gemäß Anspruch 13, worin die in einer Gruppe angeordneten Suchobjekte aufeinanderfolgend in einer Letzte-Eingabe/erste-Ausgabe-Ordnung (LIFO) gespeichert werden.

15. Eine Einrichtung gemäß Anspruch 14, worin die Letzte-Eingabe/erste-Ausgabe-Ordnung (LIFO) zur Anwendung kommt, wenn jedes der Suchobjekte zu besagter Gruppe hinzugefügt wird.

16. Eine Einrichtung gemäß Anspruch 11, worin nur einer der besagten Vielzahl von Speicherplätzen wahlweise belegt werden für jede der besagten Vielzahl von Namen gemeinsam benutzter Bibliotheken.

17. Eine Einrichtung gemäß Anspruch 11, enthaltend:

(e) Mittel zum Hinzufügen einer Vielzahl von Suchobjekten zu einen vorbestimmten Speicherplatz;

(f) Mittel zur Bestimmung der besagten Vielzahl von Namen gemeinsam benutzter Bibliotheken, die mit einer bestimmten Bibliothek verbunden sind;

(g) Mittel zur aufeinanderfolgende Verwendung der besagten Vielzahl von Suchobjekten, die zu dem vorbestimmten Speicherplatz hinzugefügt worden sind, zur Belegung einer Vielzahl von Speicherplätzen entsprechend der besagten Vielzahl von Namen gemeinsam benutzter Bibliotheken; und

(h) Mittel zum Abbilden besagter Vielzahl von gemeinsam benutzten Bibliotheken auf besagte Vielzahl von belegten Speicherplätzen.

18. Eine Einrichtung gemäß Anspruch 17, enthaltend Mittel zum Ausschlusses einer oder mehrerer Suchobjekte vom Hinzufügen zu besagtem vorbestimmten Speicherplatz, wenn ein Duplikat von einer oder mehreren der besagten Vielzahl von Suchobjekten in besagtem Speicherplatz existiert.

19. Eine Einrichtung gemäß Anspruch 17, worin eine oder mehrere der besagten Vielzahl von Suchobjekten zu einer Vielzahl von vorbestimmten Speicherplätzen hinzugefügt werden.

20. Eine Einrichtung gemäß Anspruch 17, worin besagte Vielzahl von Suchobjekten aufeinanderfolgend verwendet werden basierend auf der Ordnung, in welcher besagte Vielzahl von Suchobjekten zu besagtem vorbestimmten Speicherplatz hinzugefügt worden sind.