-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die
Erfindung betrifft ein Betriebssystem, in dem Echtzeit-Anwendungsprogramme
laufen können,
ein Steuerungsverfahren hierfür
sowie ein Verfahren zum Laden von DLLs (Dynamic Link Libraries),
und spezieller betrifft sie die Steuerung von Echtzeit-Anwendungsprogrammen
in einem Betriebssystem, in dem der Anwendungsprogramm-Speicherraum
und der Kernel-Speicherraum als verschiedene Speicherräume zugeordnet
sind und bei dem ein eine Eingabe/Ausgabe-Vorrichtung steuernder
Vorrichtungstreiber im Kernel-Speicherraum installiert ist.
-
2. Beschreibung der einschlägigen Technik
-
Herkömmlicherweise
sind der Anwendungsprogramm-Speicherraum und der Kernel-Speicherraum
als verschiedene Speicherräume
zugeordnet, und in vielen Fällen
verfügt
ein Betriebssystem, in dem ein Vorrichtungstreiber zum Steuern einer
Eingabe-/Ausgabe-Vorrichtung
im Kernel-Speicherraum installiert ist, über keine Funktion eines Echtzeit-Betriebssystems
(nachfolgend als RTOS(Real-Time Operating System)-Funktion bezeich net).
Daher kann selbst dann, wenn viele nützliche Anwendungsprogramme
nur in einem derartigen Betriebssystem laufen, eine die RTOS-Funktion
benötigende
Anwendung, d.h. eine Echtzeit-Anwendung, in einem derartigen Betriebssystem
nicht laufen, solange nicht die RTOS-Funktion bereitgestellt ist,
und außerdem kann
eine die RTOS-Funktion benötigende
Anwendung nicht mit anderen nützlichen
Anwendungsprogrammen genutzt werden.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Wenn
die RTOS-Funktion in ein derartiges Betriebssystem eingeschlossen
ist, wird diese manchmal als Vorrichtungstreiber installiert. In
diesem Fall kann, da der Austausch eines Vorrichtungstreibers durch
das Betriebssystem verwaltet wird, der Vorrichtungstreiber nicht
ausgetauscht werden, solange nicht die Einschränkungsbedingungen des Betriebssystems
erfüllt
sind. Daher kann die RTOS-Funktion nicht leicht ausgetauscht werden.
-
Außerdem ist
ein derartiges Betriebssystem nicht zum Laden von Anwendungssoftware
zur Ausführung
in den Kernelraum konzipiert. So ist eine Maßnahme zum Laden einer Echtzeit-Anwendung, die
die RTOS-Funktion nutzt, in den Kernelraum und zum Starten derselben
darin erforderlich. Wünschenswerterweise
wird eine derartige Funktion nicht nur als RTOS-Funktion sondern
auch als Funktion getrennt von dieser implementiert.
-
Angesichts
der oben beschriebene Probleme ist durch die Erfindung ein Betriebssystem
geschaffen, bei dem ein Anwendungsprogramm-Speicherraum und ein
Kernel-Speicherraum als verschiedene Speicherräume eingestellt sind und ein
Vorrichtungstreiber zum Steuern einer Eingabe/Ausgabe-Vorrichtung
im Kernel-Speicherraum installiert ist, wobei ein Echtzeit- Betriebssystem und
ein Echtzeit-Anwendungsprogramm als DLL konfiguriert sind. Der bereitgestellte
Vorrichtungstreiber, der DLLs lädt, liest
das Echtzeit-Betriebssystem und die Echtzeit-Anwendung in den Kernelraum
ein, er führt
eine Umverlegung für
diese aus, er löst
externe Bezugnahmen derselben auf und er startet sie. Auf diese Weise
sind durch die Erfindung ein Betriebssystem und ein Steuerungsverfahren
für dieses
geschaffen, die die RTOS-Funktion in einem Betriebssystem ohne diese
RTOS-Funktion verfügbar
machen und das Laden derselben und von Echtzeit-Anwendungen, die
als DLLs konfiguriert sind, als mehrere DLLs ermöglichen.
-
Zur
Verwendung dann, wenn eine Bibliothek noch nicht geladen ist, die
ein Symbol enthält,
auf das extern durch eine DLL Bezug genommen wird, ist durch die
Erfindung ein Verfahren zum automatischen Laden einer erforderlichen
DLL durch Lesen derselben, Ausführen
einer Umverlegung derselben, Auflösen externer Bezugnahmen auf
diese sowie Starten derselben geschaffen.
-
Alternativ
ist durch die Erfindung ein Verfahren zum Spezifizieren einer Liste
zu ladender DLLs, zum Lesen der spezifizierten DLLs, zum Ausführen einer
Umverlegung derselben und zum Auflösen externer Bezugnahme auf
diese sowie zum Starten der DLLs in einer in der Liste spezifizierten
Abfolge geschaffen, um die Ladefunktion zu implementieren, die eine
explizite Spezifizierung der Lade- und Startsequenzen der erforderlichen
DLLs erlaubt. Die Liste verfügt über keine
Datenstruktur, und sie kann die Form eines Arrays einnehmen.
-
Außerdem erlaubt
die Erfindung, wenn externe Bezugnahmen aufgelöst werden, dass nur das Echtzeit-Betriebssystem
und eingeschränkte
Echtzeit-Anwendungen auf die Symbole des Kernel-Speicherraums des
Betriebssystems Bezug nehmen, und es verhindert einen Aufruf der
Kernelfunktion des Betriebssystems, die nicht durch eine Echtzeit-Anwendung
aufgerufen werden sollte.
-
Außerdem wird
bei der Erfindung ein Bereich des Kernel-Speicherraums, in den der
Befehlscodeabschnitt und der nur lesbare, initialisierte Datenabschnitt
geladen werden, als nur lesbarer Bereich eingestellt, nachdem das
Echtzeit-Betriebssystem und eine Echtzeit-Anwendung in den Kernelraum
gelesen wurden. Dies gewährleistet
Schutz gegen eine ungültige
Schreiboperation.
-
Der
erfindungsgemäße Vorrichtungstreiber liest
eine DLL sowie andere DLLs, auf die die DLL Bezug nimmt, in den
Kernelraum, er stellt die Adressinformation auf Grundlage der Umverlegungs(Neuanordnungs)information
ein, er löst
die externen Bezugnahmen auf, er erhält Symbolinformation, die die Startfunktion
anzeigt, und er startet die Startfunktion.
-
Außerdem ermittelt
der erfindungsgemäße Vorrichtungstreiber,
ob die DLL einen Echtzeit-Betriebssystem oder einer speziellen Betriebssystemanwendung
entspricht, und wenn dies der Fall ist, erlaubt er es der Bibliothek,
auf die Symbole des Kernels des Betriebssystems zuzugreifen, d.h.,
er erlaubt es der Bibliothek, eine Kernelfunktion aufzurufen.
-
Außerdem stellt
der erfindungsgemäße Vorrichtungstreiber
durch die Operation der Speicherverwaltungstabelle, nachdem das
Echtzeit-Betriebssystem und eine Echtzeit-Anwendung in den Kernelraum
geladen wurden, einen Bereich im Kernel-Speicherraum, in den der
Befehlscodeabschnitt und der nur lesbare, initialisierte Datenabschnitt
geladen werden, als nur lesbaren Bereich ein.
-
Außerdem ist
der erfindungsgemäße Vorrichtungstreiber
auf einem Aufzeichnungsträger
aufgezeichnet.
-
Durch
die RTOS-Funktion und Echtzeit-Anwendungen, die als DLLs konfiguriert
sind, liest der erfindungsgemäße Vorrichtungstreiber,
der DLLs lädt,
eine DLL sowie andere DLLs, auf die die DLL Bezug nimmt, in den
Kernelraum, er stellt die Adressinformation auf Grundlage der Umverlegungs(Neuanordnungs)information
ein, er löst
die externen Bezugnahmen auf, er erhält Symbolinformation, die eine
Startfunktion anzeigt, und er startet die Startfunktion. Die RTOS-Funktion
und Echtzeit-Anwendungen sind leicht zu erstellen; die einzige Bedingung
besteht darin, sie als DLLs aufzubauen.
-
Da
DLLs, auf die Bezug genommen wird, ausgewählt werden und rekursiv geladen
werden, werden die DLLs, auf die Bezug genommen wird, dadurch automatisch
geladen, dass einfach die DLL der höchstrangigen Echtzeit-Anwendung
spezifiziert und geladen wird. Der Vorteil dieses Verfahrens besteht darin,
dass eine Prozedur zum Spezifizieren jeder DLL weggelassen werden
kann und die DLLs mit einer geeigneten Abfolge gestartet werden.
-
Indessen
können,
wenn die zu ladenden DLLs strikt verwaltet werden müssen, alle
zu ladenden DLLs vorab spezifiziert werden, und es kann die Abfolge
spezifiziert werden, mit der sie zu starten sind. Dies verhindert
einen Fehler, wie er ansonsten auftreten könnte, wenn die DLLs mit einer
unerwarteten Abfolge gestartet werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
ein Diagramm, das einen Anwendungs-Speicherraum 1, einen
Kernel-Speicherraum 8 und darin gespeicherte Softwarekomponenten
gemäß der Erfindung
zeigt.
-
2 ist
ein Blockdiagramm, das ein Computersystem zeigt.
-
3 ist
ein Diagramm, das die Struktur einer DLL zeigt.
-
4 ist
ein Flussdiagramm, das eine Prozedur zeigt, wie sie von einem DLLs
ladenden Vorrichtungstreiber zum Laden von DLLs verwendet wird.
-
5 ist
ein Diagramm, das die Struktur von Umverlegungsinformation zeigt.
-
6 ist
ein Diagramm, das die Struktur von Exportierinformation zeigt.
-
7 ist
ein Diagramm, das die Struktur von Importierinformation zeigt.
-
8 ist
ein Flussdiagramm, das eine Prozedur zum Starten der Startfunktion
von DLLs zeigt.
-
9 ist
ein Flussdiagramm, das die Operation eines zweiten Vorrichtungstreibers
zeigt, der DLLs lädt.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
Die 1 ist
ein Diagramm, das einen Anwendungs-Speicherraum 1, einen
Kernel-Speicherraum 8 und in diesen Speicherräumen installierte Software
gemäß der Erfindung
zeigt. Diese Speicherräume
sind in einem RAM 103 eines im Blockdiagramm der 2 dargestellten
Computersystems vorhanden. Eine CPU 101 muss über eine
Speicherverwaltungseinheit (MMU) verfügen, die in der 2 nicht
dargestellt ist, um den Anwendungsprogramm-Speicherraum und den
Kernel-Speicherraum als getrennte Speicherräume zu behandeln. Die 1 zeigt
nur die Komponenten in Zusammenhang mit der Erfindung. Tat sächlich ist
auch ein Hauptmodul vorhanden, das die Kernelfunktion, verschiedene Vorrichtungstreiberfunktionen
sowie andere Funktionen implementiert. Gemäß der 1 enthält der Kernel-Speicherraum 8 einen
DLLs ladenden Eingabe/Ausgabe-Vorrichtung 3 gemäß der Erfindung
sowie einen diesem zugeordneten DLL-Speicherbereich 7.
Der DLL-Speicherbereich 7 enthält eine durch den DLLs ladenden
Vorrichtungstreiber 3 spezifizierte und geladene DLL 4,
eine Sekundär-DLL 5, auf
die die spezifizierte und geladene DLL 4 Bezug nimmt, und
eine tertiäre
DLL 6, auf die die zweite DLL 5 Bezug nimmt.
-
Die 2 zeigt
ein Computersystem z.B. zur NC-Steuerung der Hauptwelle oder des
Vorschubstangemechanismus einer Werkzeugmaschine. Ein Servomotor 112 wird
durch eine Regelungseinheit 111 angesteuert, die Positionen
der Hauptwelle und anderer Vorschubstangen werden durch einen Positionsdetektor 113 erfasst,
und die Regelungseinheit 111 führt eine Positionsregelung
mit hoher Genauigkeit aus. Die Regelungseinheit 111 ist über einen Systembus 106,
an den eine Bedienkonsolen-I/F(Schnittstellen)-Einheit 109 und
eine Anzeigesteuereinheit 107 angeschlossen sind, mit der
CPU 101 verbunden. Die Bedienkonsolen-I/F-Einheit 109, die
mit einer durch den Bediener der Werkzeugmaschine bedienten Bedientafel 110 verbunden
ist, liefert einen gewünschten
Bearbeitungsbefehl an die CPU 101. Der Bearbeitungszustand
der Werkzeugmaschine wird von der Anzeigesteuereinheit 107 an eine
Anzeigeeinheit 108 geliefert, damit der Bediener immer
den aktuellen Zustand der NC-Steuerung überwachen kann.
-
Mit
dem oben beschriebenen Systembus 106 sind auch ein ROM 102,
der RAM 103 und eine Festplatten-I/F 104 verbunden.
Die Festplatten-I/F 104 liest Daten von einer Festplatte 105 und
schreibt Daten auf diese. Auf einen Befehl von der CPU 101 hin
werden gewünschte
Steuerdaten von den Speichern gelesen, und es werden erforderliche
vergangene Daten geschrieben.
-
Wie
oben beschrieben, betrifft die Erfindung das durch die CPU 101 und
den RAM 103, wie sie in der 2 dargestellt
sind, gesteuerte Betriebssystem.
-
Die 3 zeigt
ein Diagramm, das die Struktur einer Microsoft-DLL (DLL: Dynamic
Link Library) zeigt, wie aus "Microsoft
Portable Executable and Common Object File Format Specification" (Microsoft Corp.)
entnommen und zusammengefasst. Die folgende Beschreibung beruht
auf der Struktur dieser DLL.
-
Die
DLLs werden zunächst
als Dateien auf der Festplatte (HD) 105 gespeichert. Im Allgemeinen nimmt
ein Anwendungsprogramm auf DLLs Bezug und sie werden in einen Anwendungs-Speicherraum geladen.
Dieser Ladejob wird im Allgemeinen durch das Betriebssystem oder
eine in diesem vorhandene Bibliothek ausgeführt. Demgegenüber liest
der DLLs ladende Vorrichtungstreiber 3 gemäß der Erfindung diese
Bibliotheken in den Kernel-Speicherraum 8, und er startet
die Startfunktion.
-
Die 4 ist
ein Flussdiagramm, das die vom DLLs ladenden Vorrichtungstreiber 3 zum
Laden von DLLs ausgeführte
Prozedur zeigt. Der Betrieb des DLLs ladenden Vorrichtungstreibers 3 wird
nachfolgend unter Bezugnahme auf dieses Flussdiagramm beschrieben.
-
Der
DLLs ladende Vorrichtungstreiber 3 startet den Betrieb
auf einen Befehl von Steuerungssoftware 2 für den DLLs
ladenden Vorrichtungstreiber hin (S1).
-
Als
Erstes liest der DLLs ladende Vorrichtungstreiber 3 einen
PE-Kopf 202 (3) einer spezifizierten DLL
in den DLL-Speicherbereich 7 (S2). Der PE-Kopf enthält die Anzahl
der Sektionen und die Größe eines
Optionskopfs. Der Optionskopf, der Teil des PE-Kopfs ist, enthält Information,
die zum korrekten Laden einer DLL erforderlich ist, wie Versionsinformation,
die Größe eines
Stapelspeichers, die Position einer Exportiertabelle innerhalb der
Datei sowie die Position einer Importiertabelle innerhalb derselben.
-
Als
Nächstes
liest der Vorrichtungstreiber 3 einen Sektionskopfabschnitt 203 (S3).
Der Sektionskopf enthält
die Sektionsnamen und die Größen der in
einem Bildabschnitt 204 gespeicherten Sektionen, wie diejenigen
der Importierinformation, der Exportierinformation und der Umverlegungsinformation.
Als Nächstes
liest der Vorrichtungstreiber 3 den Bildabschnitt 204 (S4).
Der Bildabschnitt ist in Sektionen unterteilt, von denen jede in
einen geeigneten freien Bereich im Speicher 103 gelesen
wird. Auf diese Weise werden der PE-Kopf 202, der Sektionskopf 203 und
das Bild 204 gelesen, und die spezifizierte und geladene
DLL 4 wird in den DLL-Speicherbereich 7 geladen.
Es ist zu beachten, dass der Abschnitt .text (Befehlscode, ".text" ist der Sektionsname;
diese Notation wird auch in der folgenden Beschreibung verwendet)
und der Abschnitt .rdata (nur lesbare, initialisierte Daten), die
im Bildabschnitt enthaltene Sektionen sind, dadurch als nur lesbar
eingestellt werden, dass in der durch die oben beschriebene MMU
verwalteten Speicherverwaltungstabelle 'nur lesbar' spezifiziert wird. Durch Eintragen
von 'nur lesbar' auf diese Weise
wird eine ungültige
Schreiboperation für
diese Bereiche verhindert, und es kann eine korrekte Maßnahme ergriffen
werden.
-
Als
Nächstes
führt der
Vorrichtungstreiber 3, auf Grundlage der im Abschnitt .reloc
gespeicherten Umverlegungsinformation eine Umverlegung der Adressinformation,
wie sie im im Abschnitt .text gespeicherten Befehlscode enthalten
ist, der im Abschnitt .daten gespeicherten initialisierten Daten
und der im Abschnitt .rdata gespeicherten nur lesbaren, initialisierten
Daten aus (S5). Die Umverlegung betrifft die Ein stellung der Differenz
zwischen einer Adresse, wie sie angenommen wird, wenn die DLL erzeugt
wird und einer Adresse im Speicher 103, an der Daten tatsächlich geladen
werden. Genauer gesagt, wird die Adressendifferenz zwischen diesen zwei
Adressen zum Inhalt des Speichers, in dem die Adressinformation
gespeichert ist, addiert oder davon subtrahiert. Die 5 zeigt
die Struktur der Umverlegungsinformation. Es wird nur die Umverlegungstabelle
als Umverlegungsinformation erstellt. Die Struktur der Umverlegungstabelle
ist die Folgende. Die erste Spalte enthält den Typ des Umverlegungsverfahrens,
und die zweite Spalte enthält
einen Versatzwert, der die Speicheradresse anzeigt, wo die Daten
umverlegt wurden. Die Tabelle verfügt über soviele Zeilen wie Adressen
umzuverlegen sind.
-
Als
Nächstes
wird die im Abschnitt .edata gespeicherte Exportierinformation registriert,
damit andere DLLs auf Symbole Bezug nehmen können (S6). Die 6 ist
ein Diagramm, das die Struktur der Exportierinformation zeigt. Die
Exportierinformation beinhaltet eine Exportiertabellenadresse, eine
Adressentabelle, eine Namenszeigertabelle, eine Ordinalzahltabelle
und eine Namenstabelle. Die Exportiertabellenadresse ist Information,
die anzeigt, wo die folgenden Tabellen zugeordnet sind. Die Adressentabelle
ist eine Tabelle, die Exportieradressen in der Ordinalzahlabfolge
enthält.
Die Namenszeigertabelle und die Ordinalzahltabelle sind paarig.
Das Lesen einer Adresse entsprechend einem Symbol (Name) erfordert
ein Durchsuchen der Namenszeigertabelle, in der Symbole (Namen),
auf die extern Bezug genommen wird, gespeichert sind, nach dem Namen;
das Auslesen der Ordinalzahl mit dem Arrayindex des gefundenen Namens
als Index der Ordinalzahltabelle; und das Lesen der Adressentabelle
auf Grundlage dieser Ordinalzahl. Es ist zu beachten, dass in der Adressentabelle
gespeicherte Adressinformation aus Adressen besteht, wie sie zum
Link-Zeitpunkt angenommen werden. Daher muss, wie oben bei der Beschreibung
des Abschnitts .reloc (Umverlegungsinformation) beschrieben, die
Differenz zur Adresse der tatsächlich
in den Speicher 103 gelesenen Daten eingestellt werden.
-
Als
Nächstes
führt der
DLLs ladende Vorrichtungstreiber 3 eine Importierverarbeitung
auf Grundlage der im Abschnitt .edata gespeicherten Importierinformation
aus. Die 7 ist ein Diagramm, das die Struktur
der Importierinformation zeigt. Wenn eine DLL auf ein Symbol Bezug
nimmt, das durch irgendeine andere DLL exportiert wurde, erfolgt
die Importierverarbeitung zum Korrigieren der Adressinformation
in der Bezugstabelle auf eine Adresse, die dem exportierten Symbol
zugeordnet ist. Wenn zu diesem Zeitpunkt die andere DLL noch nicht
geladen ist, ist die Exportierinformation zu dieser DLL noch nicht
registriert und daher kann nicht auf das Symbol Bezug genommen werden.
Daher muss die DLL geladen werden. Diese Verarbeitung wird dadurch
ausgeführt,
dass die Verarbeitung für
die andere DLL beginnend mit dem Schritt S1 ausgeführt wird,
d.h. durch Ausführen
einer rekursiven Aufrufverarbeitung. In diesem Fall sucht der Vorrichtungstreiber 3 an
einer vorbestimmten Stelle auf der Festplatte 105, die ein
Hilfsspeicher ist, nach der anderen Bibliothek und er lädt die entsprechende
DLL. Daher wird die (abhängige)
DLL, auf die Bezug genommen wurde, automatisch geladen, ohne dass
die zu ladende DLL spezifiziert wird.
-
Als
Ergebnis der rekursiven Verarbeitung wird die DLL, auf die durch
die spezifizierte und geladene DLL 4 direkt Bezug genommen
wird, als sekundäre
DLL 5 geladen, eine DLL, auf die durch die sekundäre DLL Bezug
genommen wird, wird als tertiäre DLL 6 geladen,
und eine DLL, auf die durch die n-te DLL Bezug genommen wird, wird
als (n+1)-te DLL geladen, wobei alle in den DLL-Speicherbereich 7 geladen
werden. Obwohl die spezifizierte und geladene DLL 4, die
Sekundär-DLL 5 und die
Tertiär-DLL 6 in
der 1 zusammenhängend
dargestellt sind, werden sie nicht immer in zusammenhängende Bereiche
geladen, sondern sie werden manchmal im tatsächlichen Speicher in getrennte
Bereiche geladen.
-
Wenn
die durch die Steuerungssoftware 2 für den DLLs ladenden Vorrichtungstreiber
spezifizierte DLL eine Echtzeit-Anwendung ist, ist eine DLL mit RTOS-Funktion
als eine der DLLs, auf die Bezug genommen wird, enthalten. Daher
wird die DLL mit RTOS-Funktion mit der Echtzeit-Anwendung geladen.
-
Alternativ
kann der Fall vorliegen, dass die Steuerungssoftware 2 für den DLLs
ladenden Vorrichtungstreiber, vor dem Laden einer Echtzeit-Anwendung,
den DLLs ladenden Vorrichtungstreiber 3 mit einer DLL mit
spezifizierter RTOS-Funktion betreibt und dann diese DLL mit RTOS-Funktion
vor der Echtzeit-Anwendung startet und lädt. Durch diese Vorgehensweise
wird als Erstes die RTOS-Funktion gestartet, und nachdem die Systemoperation
stabil wurde, kann die Echtzeit-Anwendung geladen und gestartet
werden.
-
Wenn
die zu ladende DLL ein Echtzeit-Betriebssystem oder eine spezielle
Echtzeit-Anwendung ist, kann auf die Symboltabelle 9 der
Kernelfunktion des Betriebssystems Bezug genommen werden. Dies ermöglicht es,
dass nur das Echtzeit-Betriebssystem
und eingeschränkte
Echtzeit-Anwendungen die Kernelfunktion des Betriebssystems, die
normalerweise nicht aufgerufen werden kann, aufrufen, wodurch verhindert
wird, dass andere Echtzeit-Anwendungen einen ungültigen Aufruf an die Funktion
ausgeben.
-
Schließlich registriert
der DLLs ladende Vorrichtungstreiber 3 die Startadresse
der geladenen DLL (S8). Das Symbol 'main',
das von außen
zugänglich
zu machen ist, findet sich in der Exportierinformation der DLL,
und die diesem Symbol entsprechende Adresse wird als Startadresse
eingestellt. Der Symbolname muss nicht 'main' sein,
sondern es kann ein anderer Symbolname sein, sondern es kann ein
anderer Symbolname sein. Wenn dieses Symbol nicht gefunden wird,
muss die DLL nicht gestartet werden, und daher muss die Startadresse
nicht registriert werden. Das Laden der DLL endet mit diesem Schritt
(S9).
-
Wie
oben beschrieben, werden durch Ausführen der Schritte S1 bis S9
eine spezifizierte DLL, die Sekundär-DLL, auf die durch die spezifizierte
DLL Bezug genommen wird, und die (n+1)-te DLL, auf die durch die
n-te (n = 2, 3, 4,...) DLL Bezug genommen wird, geladen. Wenn durch
die spezifizierte DLL oder die n-te Bibliothek auf mehrere Bibliotheken
Bezug genommen wird, existieren mehrere (n+1)-te DLLs.
-
Als
Nächstes
wird unter Bezugnahme auf das Flussdiagramm in der 8 die
Prozedur zum Erhalten von Symbolinformation, die die Startfunktionen
anzeigt, und zum Starten der Startfunktionen in der umgekehrten
Reihenfolge, in der die DLLs geladen sind, beschrieben. Nachdem
alle DLLs geladen sind, werden sie gestartet (S11). Als Erstes wird
die im Schritt 8 der Ladeprozedur als Erste registrierte Startadresse
erhalten (S12). Als Nächstes
wird an der im Schritt S12 gelesenen Startadresse eine Ausführung gestartet
(S13). Diese ist ein Funktionsaufruf und die Startfunktion wird
unmittelbar beendet. Es erfolgt eine Ermittlung dahingehend, ob
alle im Schritt 8 registrierten Startadressen verarbeitet
sind oder nicht, und wenn sie verarbeitet sind, wird die Prozedur
beendet (S14). Wenn Startadressen registrieren, die noch nicht verarbeitet
wurden, wird die als Nächste
im Schritt 8 registrierte Startadresse erhalten (S15),
und die Steuerung geht zum Schritt S13 zurück, um die Prozedur zu wiederholen.
Es ist zu beachten, dass die Abfolge, mit der im Schritt S8 DLLs registriert
werden, die umgekehrte Abfolge ist, mit der die DLLs geladen werden,
und dass, wenn die DLLs mit dieser Abfolge gestartet werden, sie
in der umgekehrten Abfolge, mit der sie geladen wurden, gestartet
werden. Dies bedeutet, dass abhängige
DLLs gestartet werden und eine Vorbereitung auf sie früher erfolgt.
Es wurde die Operation eines ersten Vorrichtungstreibers beschrieben,
der DLLs lädt.
Die DLLs werden gestartet, nachdem sie alle geladen wurden, da die
Möglichkeit
besteht, dass sie voneinander abhängig sind. Wenn die DLLs gestartet
werden, bevor alle geladen sind, könnte die Funktion einer noch nicht
geladenen Bibliothek aufgerufen werden.
-
Als
Nächstes
wird unter Bezugnahme auf das Flussdiagramm in der 9 die
Operation eines zweiten Vorrichtungstreibers beschrieben, der eine andere
Prozedur zum Laden von DLLs verwendet.
-
Der
DLLs ladende Vorrichtungstreiber 3 startet die Operation
auf einen Befehl von der Steuerungssoftware 2 für den DLLs
ladenden Vorrichtungstreiber hin (S21). Der Name der ersten DLL,
die in der Liste von DLLs enthalten sind, die von der Steuerungssoftware 2 für den DLLs
ladenden Vorrichtungstreiber weitergeleitet und spezifiziert werden,
wird in einer Variablen d11 gespeichert (S22). Die Echtzeit-Steuerungsfunktion
wird durch Spezifizieren einer Echtzeit-Anwendung und der RTOS-Funktion
für diese
Liste implementiert.
-
Als
Nächstes
liest der Vorrichtungstreiber 3 den PE-Kopf der durch die
Variable d11 spezifizierten DLL (S23), er liest den Sektionskopf
(S24), er liest das Bild (S25), er führt die Umverlegung aus (S26), und
er registriert die Exportierinformation (S27). Die Schritte S23
bis S27 entsprechen den Schritten S2 bis S6, und ihre Operationen
sind denen bei den oben genannten Schritten ähnlich, weswegen eine wiederholte
Beschreibung hier weggelassen wird.
-
Wenn
die spezifizierten DLLs geladen sind, geht die Steuerung an einen
Schritt S30 über.
Andernfalls wird der Name der nächsten
spezifizierten DLL in die Variable d11 eingetragen (S29), und die Steuerung
geht an den Schritt S23 zurück,
um die DLL zu laden.
-
In
den folgenden Schritten S30 bis S33 wird die Importierverarbeitung
für alle
DLLs ausgeführt. Die
Importierverarbeitung im Schritt S31 ist dieselbe wie die im Schritt
S7, mit der Ausnahme, dass dann, wenn auf ein durch irgendeine andere
DLL exportiertes Symbol Bezug genommen wird, die andere Bibliothek
nicht rekursiv geladen wird, da sie gemäß der Liste bereits geladen
ist. Die Schritte S30, S32 und S33 bilden eine Schleifensteuerungsverarbeitung zum
Ausführen
der Importierverarbeitung für
alle DLLs.
-
Als
Nächstes,
in Schritten S34 bis S37, startet die Ausführung an der Startadresse der
Startfunktion aller DLLs. Im Schritt S35 wird das Symbol 'main', auf das von außen zugegriffen
werden kann, in der Exportierinformation der DLL d11 aufgefunden, und
die Ausführung
startet mit der dem Symbol entsprechenden Adresse als Startadresse.
Die Schritte S36 und S37 bilden eine Schleifensteuerungsverarbeitung
zum Starten der Ausführung
aller DLLs ab der Startadresse der Startfunktion. Es wurde die Operation
des zweiten Vorrichtungstreibers beschrieben. Wie beim ersten Vorrichtungstreiber
können
der Befehlscodespeicher und der Sektionsspeicher für nur lesbare,
initialisierte Daten als Festwertspeicher definiert werden.
-
Obwohl
die bisherige Beschreibung dasjenige betrifft, was als bevorzugte
Ausführungsformen der
Erfindung angesehen wird, ist es zu beachten, dass daran verschiedene
Modifizierungen vorgenommen werden können, und die beigefügten An sprüche sollen
alle derartige Modifizierungen abdecken, die in den wahren Grundgedanken
und Schutzumfang der Erfindung fallen.