-
Technisches
Gebiet
-
Die vorliegende Erfindung bezieht
sich allgemein auf Betriebssysteme und insbesondere auf Betriebssysteme,
die über
einen effizienten Mechanismus zur Änderung der Benutzerschnittstellensprache verfügen.
-
Hintergrund
der Erfindung
-
Ressourcen liegen als binäre oder
nicht binäre
Daten, z. B. in Textdateien vor. In Windows NT® und alten anderen Betriebssystemen
der Windows®-Produktfamilie
treten Ressourcen als binäre Daten
auf. Ressourcendaten können
sich in ausführbaren
Dateien von Anwendungen befinden, so dass es sich bei der ausführbaren
Datei um eine binäre Datei
handelt, die Code- und Ressourcendaten enthält. Die durch die Codierung
definierten Prozesse können
die Ressourcen in ihren eigenen ausführbaren binären Dateien oder in anderen
ausführbaren Dateien
verwenden. Von derartigen Prozessen genutzte Ressourcen können sich
auch in reinen Ressourcendateien befinden, wie z. B. in „dynamic
link libraries" (DLL-Dateien). Ressourcen treten entweder als Standard-
oder als nutzerdefinierte Ressourcen auf. Die Daten in einer Standard-Ressource
beschreiben ein Symbol, einen Zeiger, ein Menü, ein Dialogfeld, ein Bitmuster,
eine erweiterte Metadatei, eine Schriftart, eine Beschleunigertabelle,
einen Mitteilungstabelleneintrag, einen Zeichenkettentabelleneintrag
oder eine Version. Eine nutzerdefinierte Ressource beinhaltet Daten,
die von einer spezifischen Anwendung benötigt werden. Die von Betriebssystemprozessen
benötigten
Ressourcen können
unterschiedlich verwaltet werden. Viele dieser Ressourcen enthalten
sprachspezifische Wörter, Symbole,
Formatierungsdaten usw. Normalerweise wird durch das vom Nutzer
gewählte
Installationspaket des Betriebssystems eine bestimmte Sprache vorgegeben.
Wenn die Software-Sprache Englisch ist, werden nur für die englische
Sprache spezifische Ressourcen zusammen mit dem Betriebssystem installiert.
Dies ist sinnvoll, da bei einer vollständigen Installation der Ressourcen
für sämtliche
Sprachen viel Speicherplatz auf der Speicherplatte belegt werden
würde.
Die Beschränkung
auf eine einzige Sprache für
das Betriebssystem ist auch deshalb sinnvoll, weil sich die Ressourcen
so je nach Bedarf schnell in den Speicher laden und aus diesem wieder
löschen lassen.
Es gibt bei weitem zu viele Res sourcen, als dass es möglich wäre, diese
jederzeit im Speicher bereitzuhalten. Um das Laden und Entfernen
von Ressourcen aus dem Speicher so zu handhaben, dass nicht unnötig Speicher
belegt wird, können
der Code, der den aufrufenden Prozess erzeugt, sowie die für diesen
Prozess erforderlichen Ressourcen, in derselben binären Datei
abgelegt werden. Bei Aufruf eines Prozesses können eine binäre Datei,
die den Code für
diesen Prozess beinhaltet, sowie die zugehörigen Ressourcen in den Speicher
geladen oder dem Prozess anderweitig zugänglich gemacht werden. Bei
Beendigung des Prozesses werden die Ressourcen und Codierungsbereiche
einer solchen Datei aus dem Speicher entfernt oder anderweitig unzugänglich gemacht.
Bei den binären
Dateien kann es sich um ausführbare
Programme, dynamic link libraries (DLL-Dateien), Gerätetreiber
usw. handeln. Würden
die Programme usw. mit allen zur Verfügung stehenden Sprachenressourcen
geladen, würde
zu viel Speicherplatz belegt werden.
-
Im Folgenden wird anhand eines Beispiels erläutert, wie
ein Betriebssystem mit diesen Ressourcen umgeht. Zuerst wird ein
Ressourcensuchprogramm, eine Funktion des Betriebssystems, eingesetzt,
um eine Kennzeichnung für
den Datenblock der spezifischen. Ressource zu erzeugen. Ein Prozess,
der auf eine Ressource zugreifen muss, sendet die Kennzeichnung
des Ressourcenmoduls, den Namen und die Typenbezeichnung der Ressource
sowie optional eine Sprach-ID an das Suchprogramm. Die Sprach-ID
verweist innerhalb der durch die Kennzeichnung des Ressourcenmoduls
bezeichneten Ressourcen auf eine bestimmte, sprachspezifische Ressource.
Das Suchprogramm sendet eine Kennzeichnung zurück, die auf den Datenblock
der spezifischen Ressource verweist, so dass der Prozess ein Ressourcenladeprogramm
aufrufen kann, um die Ressource in den Speicher zu laden. Der Prozess teilt
dem Ressourcenladeprogramm die Ressourcenkennzeichnung und die Ressourcenmodulkennzeichnung
mit, woraufhin das Ladeprogramm die Ressource in den Speicher lädt und eine
Kennzeichnung an den Speicherblock zurücksendet, der die Ressource enthält. Der
Prozess kann die Ressource nun nutzen. Das Betriebssystem kann andere
Vorrichtungen einsetzen, um Speicherplatz freizugeben, wenn der
Prozess, der das Laden der Ressource veranlasst hat, diese nicht
mehr benötigt,
beendet wurde oder wenn andere Umstände dies erfordern. Hierbei
handelt es sich nur um ein Beispiel für die Art und Weise, in der ein
Betriebssystem Ressourcen zugänglich
macht. Andere Mechanismen machen Ressourcen auf andere Weise zugänglich,
indem z. B. Meldungstexte in einem Ausgabepuffer abgelegt werden
oder indem mit einem einzigen Funktionsaufruf eine Kennzeichnung
an Res sourcendaten gesendet und sofort zurückgesendet wird usw. Allen
diesen Mechanismen ist gemeinsam, dass sie eine Ressource entweder
im Speicher, in einer Plattendatei oder einem anderen Speichersystem
suchen und dem Prozess, der die Ressource anfordert, diese zur Verfügung stellen. Dieser
Schritt kann das Laden einer Datei von einer Platte in den Speicher
oder aber nur die Ausgabe einer Kennzeichnung oder die Bereitstellung
einer anderen Vorrichtung umfassen, um dem Prozess die Ressource
zur Verfügung
zu stellen. Die Datei (Geräte-
oder Channel-Datei) mit der Ressource kann sich in derselben Datei
befinden wie der Code, der den aufrufenden Prozess definiert; sie
kann jedoch auch in einer anderen Datei vorliegen. Bei dieser anderen Datei
kann es sich um eine Datei mit Code oder um eine reine Ressourcendatei
handeln. Ein Prozess muss eine nicht mehr benötigte Ressource nicht unbedingt
gezielt aus dem Speicher entfernen.
-
Angesichts der gesunkenen Preise
für Plattenspeicher
kann es in manchen Fällen
sinnvoll sein, dasselbe Betriebssystem für den Nutzer sichtbar mit mehreren
sprachspezifischen Ressourcen zu installieren. Hierdurch könnten Nutzer
mit verschiedenen Muttersprachen denselben Computer benutzen. Der Nutzer
würde sich
am Computer anmelden und die gewünschte
Sprache wählen,
so dass ihm während seiner
Sitzung alle ressourcenbasierten Leistungsmerkmale des Betriebssystems
in der gewählten Sprache
angezeigt würden.
Allerdings ist es bei Betriebssystemen, die Ressourcen unter Nutzung
der oben beschriebenen Mechanismen verwalten, ausgesprochen problematisch,
das Betriebssystem so anzupassen, dass sich verschiedene Benutzerschnittsteilensprachen
einstellen lassen. Auf die hierbei auftretenden Schwierigkeiten
wird im Folgenden eingegangen.
-
Eine Möglichkeit, ein Betriebssystem
mehrsprachenfähig
zu machen, könnte
darin bestehen, verschiedene binäre
Dateien für
jede Sprache vorzusehen. Wenn man jedoch bedenkt, dass ein komplexes
Betriebssystem über
etwa eintausend binäre
Dateien mit sprachspezifischen Ressourcen verfügt und es wünschenswert ist, viele verschiedene
Sprachen zu unterstützen,
dann wird deutlich, dass eine sehr große Zahl binärer Dateien installiert werden
müsste. Dabei
wäre es
zum einen sehr aufwändig,
die Auswahl der Sprache durch den Benutzer zu ermöglichen;
andererseits wäre
die Datenredundanz in den vielen Dateien enorm hoch, da es erforderlich
wäre, alle
nicht sprachspezifischen Dateien für jede unterstützte Sprache
zu duplizieren. Dabei müssten
nicht nur die nicht sprachspezifischen Ressourcen, sondern auch
sämtliche
Codierungsbereiche dupliziert werden.
-
Eine andere Möglichkeit bestünde darin,
die binären
Dateien des Betriebssystems jedes Mal neu zu installieren, wenn
ein Nutzer mit einer anderen Muttersprache sich am Computer anmeldet.
Diese Möglichkeit
ist jedoch uninteressant, da die Neuinstallation jedes Mal sehr
viel Zeit beanspruchen würde.
-
Eine weitere Möglichkeit bestünde darin,
die verschiedenen sprachspezifischen Ressourcen in jede binäre Datei
einzubauen. Hierdurch würde
die bei der ersten Möglichkeit
auftretende Datenredundanz vermieden, da jede binäre Datei
nur die jeweiligen sprachspezifischen Ressourcen hinzufügen würde. Allerdings
müsste
hierzu jede binäre
Datei umcodiert werden, so dass es sich hierbei auch nicht um eine
elegante Lösung
handelt. Eine ähnliche
Lösung wird
derzeit in sehr begrenztem Umfang realisiert. Manche binäre Dateien
beinhalten alternative Ressourcen, wobei jede Ressource von der
Sprache oder dem Land des Nutzers abhängt. Die Codierungsbereiche
dieser binären
Dateien definieren Prozesse, die auf Grund von „Vermutungen" im Hinblick auf
die bevorzugte Sprache für
die jeweilige Ressource eine andere Ressource aufrufen. Diese Vermutung
beruht auf der Einstellung einiger Systemparameter, wie zum Beispiel
dem Datumsformat. Wenn zum Beispiel das russische Datumsformat gewählt wurde,
werden die als russisch gekennzeichneten Ressourcen geladen.
-
Es existiert mindestens ein Betriebssystemtyp,
der eine Sprachauswahl in begrenztem Umfang ermöglicht. Dieses Betriebssystem
besitzt für
jede Sprache eigene Textdateien. Wenn ein Prozess eine Textdateiressource
in einer bestimmten Sprache benötigt,
ruft das Betriebssystem die entsprechende Datei auf. Der Nutzer
kann die von ihm gewünschte Standardsprache über eine
Systemvariable einstellen. Wie bereits erwähnt, unterstützt derzeit
mindestens ein Betriebssystem (Windows®) in begrenztem Umfang die Erstellung
sprachspezifischer Bibliotheken, wie z. B. Textmeldungen (WO 94/11811).
Die Systemvariable wird bei der Installation des Betriebssystems über die
Locale eingestellt und kann von den unter dem Betriebssystem laufenden
Anwendungen genutzt werden, um Meldungen in der gewählten Nutzersprache
auszugeben (Hinweis: Bei der Locale handelt es sich nicht um eine
Spracheinstellung, sondern um eine Mischung aus Sprach- und Standorteinstellung).
Hierzu muss der Prozess (die Anwendung) allerdings die sprachenspezifische
Ressource korrekt erkennen und wissen, wo sich diese befindet. Als Modell
für eine
Konvertierung wären
hierfür
umfangreiche Umcodierungen erforderlich.
-
Keines der Betriebssysteme nach dem
derzeitigen Stand der Technik bietet einen automatischen Mechanismus
zur Unterstützung
mehrerer Sprachen. Ferner verfügt
keines der aktuellen Betriebssysteme über ein Verfahren, um den effizienten Aufbau
von binären
Dateien beizubehalten, bei denen Ressourcen und Codierungsbereiche
in derselben Datei vorliegen. Die oben erläuterten einfachen Umwandlungen
erscheinen durch die zur Erzielung der gewünschten Funktionalität erforderliche
Datenredundanz übermäßig teuer
und/oder aufwändig. Eine
Umwandlung, die sich leicht implementieren ließe, müsste sich wahrscheinlich deutlich
von den Verfahren unterscheiden, die von den Betriebssystemen nach
dem derzeitigen Stand genutzt werden.
-
In einem Betriebssystem nach dem
derzeitigen Stand der Technik wird bei einer herkömmlichen Operation
eine binäre
Datei 20 geladen (1).
Die binäre
Datei 20 enthält
einen Codierungsabschnitt 10 und einen Ressourcenabschnitt 30 und
kann eine beliebige Datei des Betriebssystems oder eines Fremdsystems
sein. So könnte
es sich bei der binären
Datei 20 um eine ausführbare
binäre
Datei, eine dynamic link library (DLL) oder einen Gerätetreiber
handeln. Der Ressourcenabschnitt 30 kann einige der vom Codierungsabschnitt
genutzten Ressourcen enthalten und zwar insbesondere solche Ressourcen,
die für
die Prozesse erforderlich sind, welche durch den Codierungsabschnitt 10 erzeugt
werden, und die aus dem Speicher entfernt werden, wenn die durch
den Codierungsabschnitt 10 definierten Prozesse nicht mehr
benötigt
werden. Mit anderen Worten: Bei den Ressourcen 30 handelt
es sich um die Ressourcen, die von den im Codierungsbereich definierten
Prozessen 10 benötigt
werden können
und die nach Beendigung der Prozesse nicht mehr im Speicher gehalten
werden müssen.
Bei der binären
Datei 10 zum Beispiel könnte
es sich um eine Kernressource oder eine Anwendung handeln, die mit
dem Betriebssystem mitgeliefert wird, wie z. B. ein einfaches Textverarbeitungsprogramm.
Nach Beendigung des Textverarbeitungsprogramms würden die vom Textverarbeitungsprogramm
benötigten
Ressourcen nicht mehr gebraucht. Die binäre Datei 20 mit dem
Codierungsbereich 10 und dem Ressourcenbereich 30 würde aus
dem Speicher gelöscht.
Natürlich
könnte
der Codierungsbereich 10 andere Ressourcen aus anderen Dateien
und auch andere Prozesse nutzen. Die Ressourcen 86 und
der auf diese Ressourcen zugreifende Code 55 könnten auch
jeweils in verschiedenen Dateien (Dateien 25 und 22)
vorliegen (2). So könnte eine
Ressource 85, die durch eine Anwendung 55 aufgerufen
wird, welche wiederum durch einen Codeab schnitt 50 definiert
ist, in einer reinen Ressourcen-DLL oder einer gesonderten Datei 25 vorliegen,
die außerdem
den Code 70 und die Ressource 60 umfasst. Die
Anwendung 55 befindet sich in diesem Beispiel in einer
Datei, die auch die Ressource 40 beinhaltet. Mit Hilfe
der Typbezeichnung und dem Namen der Ressource kann eine andere Vorrichtung
des Betriebssystems die Ressource lokalisieren. Die Verwaltung der
Ressourcen (Laden und Löschen)
erfolgt mittels eines Ressourcenladeprogramms.
-
3 veranschaulicht,
wie Ressourcen durch einen Prozess 110 und unter Einsatz
eines Ressourcenladeprogramms 130 und eines Ressourcensuchprogramms 135 aufgerufen
werden. Bei dem Ressourcenladeprogramm handelt es sich um eine Einrichtung
des Betriebssystems, die über
eine Ressourcenmodul- und eine Ressourcenkennzeichnung den Zugriff
auf einen Ressourcendatenpunkt 125 ermöglicht. Die Ressourcenmodulkennzeichnung
gibt an, wo der anhand der Ressourcenbezeichnung identifizierbare
Ressourcendatenpunkt zu finden ist, und wird vom Ressourcensuchprogramm
erzeugt. Dem Ressourcensuchprogramm 135 werden der Name
und die Typenbezeichnung der Ressource sowie eine Sprach-ID (optional)
angegeben, woraufhin das Ressourcensuchprogramm eine Ressourcenmodulkennzeichnung
ausgibt. Befindet sich die Ressource in einem anderen Modul als
dem, das den Aufruf ausgelöst
hat, muss dem Ressourcensuchprogramm auch die Kennzeichnung dieses
Moduls mitgeteilt werden. Der Ressourcentyp kann zum Beispiel auf
ein Bitmuster, einen Bewegungszeiger, eine Schriftartressource,
eine Menü-Ressource,
einen Zeichenkettentabelleneintrag usw. verweisen.
-
Das Ressourcenladeprogramm lädt die spezifizierte
Ressource in den Speicher. Hierfür
sind eine Ressourcen- sowie eine Ressourcenmodulkennzeichnung erforderlich.
Die Ressourcenmodulkennzeichnung bezeichnet das Modul, dessen ausführbare Datei
die Ressource beinhaltet. Die Ressourcenkennzeichnung bezeichnet
die zu ladende Ressource. Das Ressourcenladeprogramm 130 sendet
an den Speicherblock mit den ressourcenbezogenen Daten eine Kennzeichnung
zurück.
Die Darstellung in 3 gilt
sowohl für
die in 1 als auch für die in 2 gezeigte Situation. Beispiele
für die
oben genannten Funktionen finden sich in der Dokumentation zu den
Windows®-Anwendungsprogrammierungs-Schnittstellen
FindResource und LoadResource. Die Ressource kann außerdem bei
einer vorherigen Operation sowie im Rahmen eines Ressourcenaufrufs
(s. oben) geladen werden. So kann unter Windows® der Aufruf von LoadLibrary
dazu führen,
dass ein Modul in den Speicher geladen wird.
-
4 zeigt
ein allgemeines Schema dazu, wie in einem Betriebssystem Ressourcen
aufgerufen werden können.
Ein Ressourcenverwaltungsprogramm 230 wird von einem Prozess 210 verwendet, um
auf einen Ressourcendatenpunkt 220 zuzugreifen. Das Ressourcenverwaltungsprogramm 230 kann
aus mehreren verschiedenen Vorrichtungen des Betriebssystems bestehen
(vgl. hierzu 3). Der
Prozess teilt dem Ressourcenverwaltungsprogramm 230 mit,
welche Ressource benötigt
wird und wo sie sich befindet, und gibt dabei zum Beispiel den Namen
der Ressource, den Identifizierer eines Moduls 250 und
sonstige Informationen an. Das Ressourcenverwaltungsprogramm 230 muss
vielleicht die Ressource 220, die sich möglicherweise
in Modul 250 befindet, in den Speicher laden, oder es müssen anderen
Verfahren genutzt werden, damit der Prozess 210 auf die
Daten 240 zugreifen kann. Der Prozess 210 erhält eine
Kennzeichnung, eine Adresse, einen Zeiger usw., um auf die Ressource 220 zugreifen
zu können.
Das wichtigste Merkmal des in 4 dargestellten
Ablaufs besteht darin, dass der Prozess die erforderliche Ressource
erkennt und das Betriebssystem ihm den Zugriff auf diese Ressource ermöglicht.
Die Ressource kann sich auf einer Speicherplatte oder einem anderen über ein
Netzwerk angebundenen Computer befinden, sofern ein Kommunikationsanschluss
oder ein anderer Mechanismus vorhanden ist, um die vom aufrufenden
Prozess angeforderten Daten auf den Computer zu übertragen. Das Betriebssystem
kann die Ressource bei einer entsprechenden Anfrage auf ein anderes
Speichermedium übertragen
(z. B. von der Speicherplatte in den Arbeitsspeicher), bevor der
Prozess auf die Ressource zugreifen kann.
-
Zusammenfassende
Darstellung der Erfindung
-
Ein Betriebssystemschema stellt Komponenten
zur Ressourcenverwaltung bereit, die über Merkmale verfügen, welche
die Verwaltung mehrerer Sprachen ermöglichen, ohne dass hierfür spezifische Befehle
von den Prozessen erforderlich sind, die auf die Ressourcen zugreifen
müssen.
Hierdurch können vom
Betriebssystem mehrere Sprachen unterstützt und die vorhandenen Ressourcen
und ausführbaren binären Dateien
unverändert
weitergenutzt werden. Auf diese Weise kann der Nutzer eine Benutzerschnittstellensprache
wählen,
so dass das Ressourcenladeprogramm Aufrufe automatisch an die jeweilige
sprachspezifische Ressource umleitet.
-
In der folgenden Beschreibung ist
das „Laden
von Daten in den Speicher" nicht wörtlich zu verstehen, d. h.
es werden nicht etwa Daten aus einer Datei genommen und im Spei cher
abgelegt. In dem von der vorliegenden Endung betrachteten Kontext eines
Betriebssystems erfolgt das Laden von Daten in den physikalischen
Speicher durch Funktionen der unteren Betriebsystemebene. Für jeden
Prozess steht virtueller Speicherplatz zur Verfügung, der dem physikalischen
Speicher nicht entspricht. Wenn daher in der folgenden Beschreibung
vom Laden und Löschen
von Daten die Rede ist, so sind diese Formulierungen in einem weiteren
Sinne zu verstehen und beziehen sich auf sämtliche Betriebssystemfunktionen,
die dafür
sorgen, dass Prozesse auf Daten zugreifen können. Aus Sicht der Ressourcen
aufrufenden Prozesse macht es im Hinblick auf die Wechselwirkungen
mit Vorrichtungen des Betriebssystems keinen Unterschied, ob die
Ressourcen einer oder mehrerer Sprachen zu verwalten sind. Die Betriebssystemkomponenten
für die
Suche nach Ressourcen und deren Zuweisung zu den jeweiligen Prozessen werden
dynamisch so verändert,
dass ein Pfad zu einem Ressourcenmodul mit einer alternativen Sprache
erzeugt wird. Der Pfad kann als Reaktion auf einen Sprachenidentifizierer
und eine optionale Modulkennzeichnung angelegt werden, die von dem
aufrufenden Prozess angegeben werden, sowie in Reaktion auf eine
systemweite nutzerspezifische Einstellung der Sprache für die Benutzerschnittstelle.
Statt der gegebenenfalls vom Prozess gelieferten Modulkennzeichnung
wird der Pfad zu der Ressource mit der alternativen Sprache verwendet.
Durch dynamische Erzeugung der Modulkennzeichnung lässt sich das
Betriebssystem erweitern, ohne dass Veränderungen an dauerhaften Betriebssystemeinrichtungen vorgenommen
werden müssen,
um eine Wechselbeziehung zwischen den von den aufrufenden Prozessen
verwendeten, grundlegenden Modulkennzeichnungen und den alternativen
Ressourcenmodulen herzustellen. Da die Erzeugung der Nachschlagetabelle
dynamisch erfolgt, wird sie automatisch zu dem Zweck erstellt, Schritte
einzusparen, und ist stets aktuell. Wenn das Betriebssystem um neue
Module ergänzt
wird, können
alternative Sprachmodule hinzugefügt und der Algorithmus ohne
zentrale Systemverwaltung zur Erzeugung alternativer Modulkennzeichnungen
eingesetzt werden. Solange der Name eines neuen Moduls nicht mit
dem eines vorhandenen Moduls unvereinbar ist, können das neue Module und alle
Codes, die dieses Modul verwenden, oder alle binären Dateien, die einen Codebereich
und Ressourcen beinhalten, zum Betriebssystem hinzugefügt werden,
ohne dass an zentraler Stelle Änderungen
erforderlich sind. Das System lädt
die Module mit alternativen Sprachen automatisch und für den Nutzer
und die aufrufenden Prozesse nachvollziehbar ein und gibt sie nach
Bedarf wieder frei. Ressourcen mit alternativen Sprachen befinden
sich in Modulen (vorzugsweise in dynamic link libraries oder, im Windows®-Sprachgebrauch,
DLL- Dateien), die
jeweils durch einen eindeutigen Pfad und Modulnamen nach folgendem
Muster gegeben sind:
<module_path>\mui\<language_ID>\<module_name>
-
Mit anderen Worten: Das Betriebssystem lädt ein Ressourcenmodul
mit einer alternativen Sprache aus einem sprachspezifischen Teilinhaltsverzeichnis
des Ladepfads des ursprünglichen
Moduls. Pfad- und Modulname werden dabei dynamisch und unter Verwendung
des ursprünglichen
Modulnamens erzeugt, der von dem aufrufenden Prozess angegeben wird.
Das Pfadelement <language_ID> kann aus einem kurzen
sprachspezifischen Code bestehen. Denkbar wäre beispielsweise die Verwendung
der Standardsprachenkürzel
nach ISO 639 sowie einer Untersprachenkennung oder einer Win32-Sprachen-ID einschließlich der
primären
und sekundären
Komponenten. Die Spezifizierung alternativer Sprachen kann unterschiedlich
stark ausgeprägt
sein. So können
z. B. auf einer bestimmten Spezifizierungsstufe die Spracheinstellungen
Französisch
(Frankreich), Französisch
(Schweiz) oder Französisch
(Kanada) angefordert werden, während auf
einer niedrigeren Stufe die Spezifizierung „Französisch" ausreicht. Damit eine
stabile Ressourcenmodulkennzeichnung erzeugt werden kann, muss der
Algorithmus eventuell zahlreiche Schritte umfassen, damit die systemweite
Einstellung einer bestimmten Benutzerschnittstellensprache mit dem vom
System her zur Verfügung
stehenden Spezifikationsgrad für
diese Sprache vereinbar ist. Wenn der Nutzer bei der Anmeldung am
System beispielsweise die Spracheinstellung Französisch (Schweiz)
vornimmt, wird für
alle ausführbaren
Prozesse eine vom Nutzer definierbare Variable eingestellt, die
besagt, dass für
die Spracheinstellung Französisch (Schweiz)
spezifische Ressourcen zu verwenden sind. Der Algorithmus des Ressourcenladeprogramms
(oder des Bibliotheksladeprogramms), durch die Ressourcen mit alternativen
Sprachen erzeugt werden, muss auch mit Situationen umgehen können, in
denen nur eine ähnliche,
aber nicht die gleiche Spracheinstellung möglich ist. Wenn beispielsweise
im Betriebssystem nur die Spracheinstellungen Französisch sowie
mehrere andere primäre Spracheinstellungen,
nicht jedoch Französisch (Schweiz)
zur Verfügung
stehen, sollte der Algorithmus bei einem entsprechenden Aufruf die
Ressourcen für
Französisch
laden und nicht eine Standardspracheinstellung, die sich von der
vom Nutzer auf Systemebene vorgenommenen Spracheinstellung, die
von der Nutzersprachen-ID im System angezeigt wird, stärker un terscheidet.
Daher lassen sich für
den Algorithmus zahlreiche Näherungsstufen
definieren, wie im Folgenden gezeigt wird.
-
Der Algorithmus kann zunächst prüfen, ab
in dem durch „<module_path>\" spezifizierten Modulpfad
ein Teilinhaltsverzeichnis vorhanden ist, dessen Identifizierer
mit der aktuellen Nutzersprachen-ID, d. h. mit dem Namen „\mui\<language_ID>\" identisch ist. Wenn
der erste Test fehlschlägt,
kann der Algorithmus weiterhin prüfen, ob unter „<module_path>\" ein Teilinhaltsverzeichnis
mit einem Identifizierer vorhanden ist, der mit der primären Sprach-ID
identisch ist, welche der gewählten
Nutzersprachen-ID entspricht und demzufolge den Namen „\mui\<primary_language_ID>\" trägt. Wenn
keine entsprechende Nutzersprachen-ID für das System gefunden wird,
kann der Algorithmus zur Wahl eines entsprechenden Teilinhaltsverzeichnisses
eine Ersatzeinstellung verwenden und sich an Nutzerpräferenzen
orientieren, die Aufschluss darüber
geben, an welchem Ort sich der Nutzer befindet. Hierzu gehören z. B.
Datums- und Währungseinstellungen.
Alternativ kann auch ein sprachneutrales Ressourcenmodul aufgerufen
werden. Andere Schritte, die in beliebiger Reihenfolge ausgeführt werden
können,
sind beispielsweise die Auswahl eines Teilinhaltsverzeichnisses
mit einem alternativen Ressourcenmodul, das einer definierten Standardsprache
zugeordnet ist, die Wahl einer Ersatzsprache, die zwar nicht mit
der gewählten
Nutzersprache identisch ist, aber an der wahrscheinlichen Locale
des Nutzers verwendet wird. Wenn beispielsweise die Spracheinstellung Französisch (Kanada)
gewählt
wurde, doch weder Französisch
(Kanada) noch Französisch
zur Verfügung
stehen, sollte Englisch (Kanada) gewählt werden, sofern die entsprechenden
Ressourcen vorhanden sind. Durch die Identifizierung der bestmöglichen alternativen
Ressourcen gemäß einem
System aus Prioritäten
können
die Spracheinstellungen stärker spezifiziert
werden. Wird das Betriebssystem ausschließlich mit primären Sprachen
(z. B. Englisch, jedoch nicht Englisch [Großbritannien], Englisch [Kanada]
usw.) ausgeliefert, hat der Nutzer die Möglichkeit, später spezifischere
Spracheinstellungen hinzuzufügen,
und die gewünschte
Sprachauswahl des Nutzers wird transparent und automatisch vollzogen.
-
Zur Beschleunigung der Verarbeitung
wird die durch dynamische Erzeugung der einzelnen Modulpfade erzielte
Abbildungszuordnung in einer Nachschlagetabelle gespeichert. Wenn
ein aufrufender Prozess dieselbe Ressource aufruft, wird das alternative
Ressourcenmodul über
die Nachschlagetabelle schneller gefunden als durch die dynami sche Erzeugung
eines Pfads. Die Ergebnisse der dynamischen Erzeugung einer ID für ein alternatives
Ressourcenmodul werden gespeichert, so dass die oben beschriebenen
Schritte des robusten Algorithmus nicht bei jedem Ressourcenaufruf
wiederholt werden müssen.
-
Außerdem wird eine Säuberungstabelle
erzeugt, die das abgeänderte
Ressourcenladeprogramm dabei unterstützt, Ressourcen zu laden und
in Abhängigkeit
von den Systemanforderungen Speicherkapazitäten freizugeben. In der Säuberungstabelle
werden die geladenen alternativen Ressourcenmodule sowie die zugehörigen aufrufenden
Prozesse angegeben. Bei Beendigung des aufrufenden Prozesses kann
so beispielsweise das entsprechende Modul aus dem Speicher gelöscht werden.
-
Das Betriebssystem protokolliert
durch die Erzeugung von Einträgen
in einer Ladeprogrammdatentabelle, welche Ressourcen geladen und
gelöscht werden.
Die Ladeprogrammdatentabelle gibt an, welche Prozesse Ressourcenmodule
angefordert haben, so dass diese Module nach Beendigung des Prozesses
oder bei Vorliegen entsprechender Systemanforderungen aus dem Speicher
entfernt werden können.
Bei Modulen, die z. B. in Windows NT® direkt von Anwendungen mit
Hilfe der Funktion LoadLibraryEx geladen werden, kann es sein, dass
die Identität
des Moduls dem oben beschriebenen Ressourcenladeprogramm nicht „bekannt"
ist. Dies bedeutet, dass gegebenenfalls kein Eintrag in der Ladeprogrammdatentabelle
erzeugt wird. In diesem Fall besteht die Möglichkeit, dass die Vorrichtung
für das Laden
des Ressourcenmoduls (z. B. LoadLibrary) eine Anfrage nach einer
Ressource mit einer alternativen Sprache stellt und statt des von
der Anwendung angeforderten Moduls das alternative Ressourcenmodul
lädt. Wenn
die Anwendung oder der Prozess keine Vorrichtung des Betriebssystems
zur Erzeugung eines Eintrags in der Ladeprogrammdatentabelle nutzt,
muss das Modul erst geladen werden, wenn die Anwendung oder ein
anderer Prozess eine Ressource über
das Ressourcenladeprogramm aufrufen.
-
Bei der vorliegenden Erfindung handelt
es sich gemäß der Patentansprüche um ein
Verfahren, das von einem Betriebssystem genutzt wird. Das Verfahren
leitet einen Aufruf von einem aufrufenden Prozess für einen
ersten Ressourcendatenpunkt in einer ersten binären Datei um, die eine ausführbare Codierung,
die den aufrufenden Prozess definiert, und Ressourcendaten enthält. Der
aufrufende Prozess wird in der Codierung definiert. Das Verfahren
umfasst die folgenden Schritte: Speichern eines Sprachenidentifi zierers
in einer Variable unabhängig
von dem aufrufenden Prozess; wenn eine zweite binäre Datei,
die dem Sprachenidentifizierer und ebenso dem ersten Ressourcendatenpunkt
oder der ersten binären
Datei entspricht, vorhanden ist: (1) dynamisches Erzeugen eines
Pfades zu der zweiten binaren Datei in Reaktion auf den Sprachenidentifizierer
und dem ersten Ressourcendatenpunkt bzw. der ersten binären Datei;
(2) Erzeugen einer Zugriffsmöglichkeit für den aufrufenden
Prozess zu einem alternativen Ressourcendatenpunkt in der zweiten
binären
Datei anstatt zu dem ersten Ressourcendatenpunkt.
-
Kurzbeschreibung der Abbildungen
-
1 ist
die schematische Darstellung einer binären Datei, die einen Codierungsbereich
umfasst, durch die der Prozess definiert wird, welcher die im Ressourcenbereich
derselben binären
Datei enthaltenen Ressourcendaten aufruft.
-
2 ist
die schematische Darstellung zweier binärer Dateien, von der eine Codierungsdaten
umfasst und Ressourcendaten beinhalten kann, aber nicht muss, während die
zweite binäre
Datei Ressourcendaten umfasst und Codierungsdaten beinhalten kann,
aber nicht muss. Dabei definiert die Codierung der ersten Datei
einen Prozess, der die Ressourcen der zweiten Datei aufruft.
-
3 ist
die schematische Darstellung eines Ressourcenlade- und eines Ressourcensuchprogramms,
die von einem Ressourcenlokalisierungsvorgang gemäß einer
Ausführungsart
nach dem bisherigen Stand der Technik genutzt werden.
-
4 veranschaulicht
allgemein einen Ressourcenlokalisierungsvorgang, der von einem Prozess
auf einem Computer ausgelöst
wird, und zeigt in diesem Zusammenhang eine schematische Darstellung
eines Ressourcenverwaltungsprogramms.
-
5 zeigt
schematisch einen Prozess zum Aufruf eines Ressourcendatenpunkts
in einem Betriebssystem, der im Vergleich zu dem in 3 dargestellten Prozess, welcher dem
derzeitigen Stand der Technik entspricht, verändert wurde.
-
Detaillierte Beschreibung
der Ausführungen
-
In 5 ist
ein Prozess zum Aufrufen eines Ressourcendatenpunkts durch ein Betriebssystem dargestellt,
der im Vergleich zu dem in 3 dargestellten
Prozess, welcher dem bisherigen Stand der Technik entspricht, verändert wurde.
Dabei wurden die unter Bezugnahme auf 3 beschriebenen Vorgänge innerhalb
des Ressourcenladeprogramms 130 und des Ressourcensuchprogramms 135 abgeändert, um
den in 5 dargestellten
Prozess zu erzielen. Allgemein gesagt wird durch den in 5 dargestellten Vorgang
ein Aufruf eines Prozesses, der an eine bestimmte Ressource gerichtet
ist, an eine Ressource mit alternativer Sprache umgeleitet, so dass
der Prozess statt der diesem Prozess standardmäßig zugeordneten Ressource
eine Ressource erhält,
die zu der gewählten
Spracheinstellung für
die Benutzeroberfläche
passt. Bei einer Ausführungsart werden
nur dann alternative Ressourcen aufgerufen, wenn durch den Prozess
keine Angaben im Hinblick auf die zu ladende Sprache gemacht werden.
Mit anderen Worten: Ein Prozess versucht eine Ressource zu laden,
unabhängig
von der Sprache, die mit dieser Ressource verbunden ist. Bei dem
System nach dem bisherigen Stand der Technik würde das Ressourcenladeprogramm
die Ressourcendaten entweder aus dem Ressourcenbereich des Moduls
selbst oder aus einem externen, durch den Prozess spezifizierten
Modul laden. Bei der vorliegenden Ausführungsart eines mehrsprachigen
Benutzerschnittstellensystemslädt
das Ressourcenladeprogramm alternative Ressourcen, wenn der Prozess
keine bestimmte Sprache und keine sonstige Klassifizierung in Bezug auf
die aufgerufene Ressource vorgegeben hat. Wie bei der Ausführungsart
nach dem bisherigen Stand der Technik (3) fordert der Prozess eine Speicherkennzeichnung
von dem Ressourcensuchprogramm 320 an. In diesem Fall handelt
es sich jedoch um eine Kennzeichnung, die auf eine Ressource mit alternativer
Sprache verweist, wenn eine solche vorhanden ist. Das Ressourcensuchprogramm
versucht, eine Ressource zu finden, auf die die ID 335 der
gewählten
Benutzerschnittstellensprache verweist. Die ID 335 der
eingestellten Benutzerschnittstellensprache ist eine nutzerspezifische
Einstellung. Die ID für
die Benutzerschnittstellensprache 335 kann z. B. eingestellt
werden, wenn der Nutzer sich am System anmeldet und aus einer Pickliste
eine Spracheinstellung wählt.
Anschließend
wird die ID 335 für
die gewählte
Benutzerschnittstellensprache so lange gespeichert, bis eine andere
Spracheinstellung vorgenommen wird.
-
Ein Prozess 310 fordert
eine Speicherkennzeichnung für
eine Ressource an, indem er einem Ressourcensuchprogramm 320 Namen
und Typ der Ressource mitteilt. Wenn die Ressource sich in einem
anderen Modul befindet, als dem, durch den der aufrufende Prozess 310 definiert
ist. wird dem Ressourcensuchprogramm auch die Ressourcenmodulkennzeichnung
mitgeteilt. Wenn die Modulkennzeichnung nicht versandt wird, hat
das Ressourcensuchprogramm die Modulkennzeichnung bereits in der
Ladeprogrammdatentabelle gefunden, weil das Modul nicht nur die
vom Prozess aufgerufenen Ressourcendaten, sondern auch die Codierung
enthält, durch
die der Prozess definiert ist. Wie im Abschnitt „Hintergrund der Erfindung"
erläutert,
werden Ressourcenlade- und Ressourcensuchprogramme häufig dazu
verwendet, um auf Ressourcendaten zuzugreifen, die in derselben
binären
Datei wie die Codierung vorliegen, durch die der aufrufende Prozess
definiert ist. Es ist auch möglich,
dass der Prozess eine sprachspezifische Ressource aufruft und der
Vorgang zur Befolgung des Aufrufs Schritte umfasst, die außerhalb
der vorliegenden Erfindung liegen und mit Verfahren erfolgt, die
dem bisherigen Stand der Technik entsprechen (siehe hierzu z. B.
eine Beschreibung von LoadResource unter http://www.microsoft.com/msdu/).
Im letztgenannten Fall kann dem Ressourcensuchprogramm eine Sprach-ID
mitgeteilt werden.
-
Das Betriebssystem wird so abgeändert, dass
es nun eine Tabelle mit alternativen Ressourcenmodulkennzeichnungen 323 führt, die
zuvor durch Aufrufe an das Ressourcensuchprogramm 320 erzeugt
wurden. Wenn nun ein anderer Prozess bereits eine Ressource aus
demselben Modul aufgerufen hat und das Modul bereits einem alternativen Ressourcenmodul
zugeordnet wurde, lässt
sich die Kennzeichnung des alternativen Ressourcenmoduls schnell
der Tabelle mit den Kennzeichnungen der alternativen Ressourcenmodule 323 entnehmen. Wenn
für die
Ressource noch kein Eintrag vorliegt, erzeugt das Betriebssystem
dynamisch einen Pfad zu dem alternativen Ressourcenmodul. Hierzu
wird ein Algorithmus 325 verwendet. Der Algorithmus 325 kann
auf Annahmen im Hinblick auf die Organisation von Ressourcendateien
beruhen, die angeben, ob für die
spezifizierte Ressource eine Ressourcendatei mit einer alternativen
Sprache vorhanden ist oder nicht. Bei der vorliegenden Ausführungsart
befinden sich die Ressourcendateien mit alternativen Sprachen in Teilinhaltsverzeichnissen
der Pfade der angeforderten Module. Dabei unterscheiden sich die
alternativen Ressourcendateien durch ihre Dateinamen, die jeweils
einem eindeutigen Sprachenidentifizierer zugeordnet sind.
-
In jedem sprachenspezifischen Teilinhaltsverzeichnis
sind Ressourcendateien mit alternativen Sprachen gespeichert, die
jeweils nach dem ursprünglichen
Modul benannt sind:
<module_path>\mui\language_ID>\<module_name>
-
Mit anderen Worten: Das Betriebssystem lädt eine
Ressourcendatei mit einer alternativen Sprache aus einem sprachspezifischen
Teilinhaltsverzeichnis, welches unter dem Ladepfad des ursprünglichen
Moduls abgelegt ist. Lautet der Pfad des ursprünglichen Moduls bei einem nicht
mehrsprachenfähigen
System „<path 1 >\<filename 1>", so lautet der Pfad für das Modul
mit der alternativen Sprache entsprechend „<path 1>\mui\<language
ID 1>\<filename 1>", wenn man annimmt,
dass die ID der gewählten
Spracheinstellung 335 „language ID 1" heißt.
-
Ressourcen mit alternativen Spracheinstellungen
können
in vielfältiger
Weise organisiert sein. Wenn man die Ressourcendaten in einzelnen, sprachspezifischen
Modulen ablegt, die jeweils dem ursprünglichen Modul (also dem Modul,
das normalerweise bei einem einsprachigen Betriebssystem angefordert
würde)
entsprechen, sind – anders,
als wenn sich bei jedem Ressourcenmodul die Ressourcendaten der
verschiedenen Sprachen jeweils in einem einzigen Modul befänden – keine
weiteren Speicherkapazitäten
erforderlich.
-
Angesichts der zur Speicherung von
Modulen verwendeten Pfadstruktur, ist es ausgesprochen einfach,
einen Pfad zum Aufruf von Modulen mit alternativen Sprachen einzurichten,
der zum einen der jeweiligen Sprache, welche durch die Sprach-ID 335 angegeben
wird, und zum anderen dem ursprünglich aufgerufenen
Modulnamen und dem zugehörigen Pfad
entspricht. Dieser Pfad wird von dem Ressourcensuchprogramm 320 zur
Ausgabe einer Ressourcenkennzeichnung verwendet. Die Erzeugung einer Ressourcenkennzeichnung
erfolgt nach dem bisherigen Stand der Technik. Der einzige Unterschied
besteht darin, dass die Ressourcenkennzeichnung den Aufruf in diesem
Fall an einen Ressourcendatenpunkt 350 umleitet, der einem
Teilinhaltsverzeichnis des ursprünglichen
Modulpfads zugeordnet ist. In 5 befand
sich der Ressourcendatenpunkt 350 in einem alternativen
Ressourcenmodul für
die „binäre Datei
2", wobei die gewählte
Spracheinstellung (ID) für die Benutzerschnittstelle „language
ID 2" war. Pfad- und Modulname werden dynamisch und unter Verwendung
des Namens des ursprünglichen
Moduls erzeugt, das von dem aufrufenden Prozess angefordert wird.
Das Pfadelement <language_ID> kann aus einem kurzen
sprachspezifischen Code bestehen. Denkbar wäre beispielsweise die Verwendung
der Standardsprachenkürzel
nach ISO 639 sowie einer Untersprachenkennung oder einer Win32-Sprachen-ID
einschließlich
der primären
und sekundären
Komponenten. Bei einer bevorzugten Ausführungsart der Erfindung ist
der Algorithmus so robust, dass er – basierend auf der Annahme,
dass eine alternative Ressource zu den aufgerufenen Daten vorhanden
ist – nicht
nur einfach einen Pfad anlegt. Alternative Sprachen können aufgerufen
und dabei unterschiedlich stark spezifiziert werden. Es ist ferner
möglich,
dass keine Ressourcen mit alternativen Spracheinstellungen zur Verfügung stehen
oder dass zwar eine alternative Ressource vorhanden ist, diese sich
aber in anderen Punkten als die Spracheinstellung von der ursprünglichen
Ressource unterscheidet. Der Algorithmus und die mit ihm zusammenhängenden
Prozesse sind robust genug, um derartige Situationen so gut wie
das einfache Szenario in 5 zu
bewältigen..
-
Der Nutzer kann eine sehr spezifische
Spracheinstellung für
die Benutzerschnittstelle wählen wie
z. B. Französisch
(Schweiz) oder Französisch (Kanada).
Der Algorithmus kann zahlreiche Schritte umfassen, um eine auf der
Systemebene für
die Benutzerschnittstelle gewählte
Sprache mit einem bestimmten Spezifikationsgrad mit den vom System
zur Verfügung
gestellten alternativen Ressourcen abzustimmen, die einen anderen
Spezifikationsgrad für diese
Sprache aufweisen. Wenn der Nutzer bei der Anmeldung am Betriebssystem
beispielsweise Französisch
(Frankreich) als Sprache für
die Benutzerschnittstelle wählt,
ist möglicherweise
nicht genau diese, sondern nur eine ähnliche Spracheinstellung verfügbar. Zur
Bewältigung
derartiger Situationen können
der Algorithmus und die mit ihm zusammenhängenden Prozesse gemäß einer
integrierten hierarchischen Schrittfolge vorgehen, die nachstehend beschrieben
wird.
-
Zuerst kann der Algorithmus prüfen, ob
in dem angegebenen Modulpfad „<module_path>\mui\" ein Teilinhaltsverzeichnis
vorhanden ist, dessen Identifizierer mit der aktuellen Nutzersprachen-ID,
d. h. mit dem Namen „\<language_ID>\" identisch ist. Wenn
der erste Test fehlschlägt,
kann der Algorithmus prüfen,
ob unter „<module_path>\" ein Teilinhaltsverzeichnis
mit einem Identifizierer vorhanden ist, der mit der primären Sprach-ID
identisch ist, welche der gewählten
Nutzersprachen-ID entspricht und demzufolge den Namen „\<primary_language_ID>\" trägt. Wenn
keine entsprechende Nutzersprachen-ID für das System gefunden wird,
kann der Algorithmus zur Wahl eines ent sprechenden Teilinhaltsverzeichnisses
eine Ersatzeinstellung verwenden und sich dabei an Nutzerpräferenzen
orientieren, die z. B. Aufschluss darüber geben, an welchem Ort sich
der Nutzer befindet. Hierzu gehören
beispielsweise Datums- und Währungseinstellungen.
Alternativ kann auch ein sprachneutrales Ressourcenmodul aufgerufen werden.
Andere Schritte, die in beliebiger Reihenfolge ausgeführt werden
können,
sind beispielsweise die Auswahl eines Teilinhaltsverzeichnisses
mit einem alternativen Ressourcenmodul, das einer definierten Standardsprache
zugeordnet ist, und – wenn die
vom Nutzer gewählte
Sprach-ID nicht zur Verfügung
steht – die
Wahl einer vorgegebenen Ersatzsprache, die zwar nicht mit der gewählten Nutzersprache
identisch ist, aber an der wahrscheinlichen Locale des Nutzers verwendet
wird. Wenn beispielsweise die Sprach-ID für Französisch (Kanada) gewählt wurde,
doch die entsprechenden Ressourcen nicht zur Verfügung stehen,
würde Englisch
gewählt werden,
sofern die entsprechenden Ressourcen vorhanden sind. Durch den oben
beschriebenen Vorgang zur Erkennung bevorzugter alternativer Ressourcen
gemäß einem
System aus verschiedenen Prioritäten
lassen sich alternative Sprachressourcen stärker spezifizieren. Wird das
Betriebssystem ausschließlich
mit primären
Sprachen (z. B. Englisch, jedoch nicht Englisch [Großbritannien],
Englisch [Kanada] usw.) ausgeliefert, hat der Nutzer die Möglichkeit,
später
spezifischere Spracheinstellungen hinzuzufügen, und die gewünschte Sprachauswahl
des Nutzers wird transparent und automatisch vollzogen.
-
Normale Aufrufe von Ressourcen für eine bestimmte
Sprache, wie z. B. Aufrufe mit der Windows®-Funktion FindeResourceEx werden
durch die oben beschriebene Funktionalität nicht beeinträchtigt.
Wenn der aufrufende Prozess eine bestimmte Sprach-ID anfordert,
würde der
oben beschriebene Mechanismus zum Aufruf von Modulen mit alternativen
Sprachen den Aufruf nicht an ein anderes Ressourcenmodul umleiten.
-
Nachdem der Algorithmus für die Pfaderzeugung 325 einen
Ressourcenpfad festgelegt hat, kann die identifizierte Datei Versions-
und anderen Integritätsprüfungen unterzogen
werden, bevor sie für
den Zugriff durch den aufrufenden Prozess freigegeben wird. Wenn
das alternative Ressourcenmodul 370 als Ergebnis der in 5 dargestellten Prozesse
erneut in den Speicher geladen oder durch den Aufruf an das Ressourcensuchprogramm 320 anderweitig
zugänglich
gemacht wird, kann ein neuer Eintrag in der Tabelle mit alternativen
Ressourcenmodulkennzeichnungen 323 angelegt werden. Schließlich kann
eine Kennzeichnung an den aufrufenden Prozess ausgegeben werden, damit
dieser auf die aufgerufene Ressource zugreifen kann. Der letztgenannte
Vorgang kann einen Schritt durch eine andere Funktion, das Ressourcenladeprogramm 330,
umfassen, das die Daten in den Speicher lädt und an den Prozess eine Kennzeichnung
zur Nutzung der Daten ausgibt.
-
Wenn in 5 und der zugehörigen Beschreibung gesagt wird,
dass das Modul in den Speicher geladen wird, so muss dieser Ladevorgang
nicht explizit durch das Ressourcensuchprogramm und nicht einmal
durch das Ressourcenladeprogramm erfolgen. Die einzige Bedingung,
die erfüllt
sein muss, besteht darin, dass dem Prozess die richtigen Daten zur
Verfügung
gestellt werden. Das Betriebssystem kann die tatsächlichen
Datenverschiebungen mit Hilfe seiner Eingabe-/Ausgabe- und Speicherverwaltungsvorrichtungen
vollziehen. Entscheidend bei dem unter Bezugnahme auf 5 beschriebenen Vorgang
ist, dass der Aufruf eines Prozesses an eine Ressource, für die sprachspezifische
alternative Ressourcen vorhanden sind, automatisch und für den aufrufenden
Prozess transparent umgeleitet wird. Infolgedessen muss die Codierung,
durch die der Prozess definiert ist, nicht abgeändert werden, um das Betriebssystem
mehrsprachenfähig
zu machen. In 5 und
den zugehörigen
Anmerkungen wird der Vorgang zur Umleitung von Datenaufrufen im
Zusammenhang mit Ressourcen beschrieben, die Teil binärer Dateien
sind, welche auch ausführbare Codierungen
enthalten. Dasselbe Grundprinzip kann erweitert werden und ist auch
auf für
den Zugriff auf Daten in reinen Ressourcendateien (z. B. DLL-Dateien)
anwendbar.
-
Wenn in der vorangehenden Beschreibung davon
die Rede ist, dass ein Prozess einen Aufruf zum Laden oder Entfernen
von Daten aus dem Speicher ausgibt, ist dieser Schritt im weitesten
Sinne so zu verstehen, dass die Daten in dem Adressenraum des Prozesses
abgebildet werden. Dies liegt daran, dass die Betriebssystemvorrichtungen
zur Abbildung von Eingängen/Ausgängen dazu
führen,
dass die konkreten Begriffe in Bezug auf das Laden von Daten von
der Speicherplatte in den Arbeitsspeicher unscharf sind. Mit anderen
Worten: Bei aktuellen Betriebssystemen kann ein Prozess in bestimmten Schritten
auf Daten zugreifen, ohne dabei explizit an den Schritten zum Laden
der Daten in den Speicher beteiligt zu sein, da diese konkreten
Schritte vom Eingangs-/Ausgangssystem
und den virtuellen Speicherverwaltungsfunktionen des Betriebssystems transparent
verwaltet werden können.
-
Bei dem oben beschriebenen Vorgang
wird das alternative Ressourcenmodul gegebenenfalls als einfache
Datei im Adressraum des aufrufenden Prozesses abgebildet. Die Details,
die dem Abbildungsvorgang zu Grunde liegen, gehören zum bisherigen Stand der
Technik. In Windows® erfolgt
die Abbildung beispielsweise durch einen Code, der eine Betriebssystemfunktion
mit dem Namen LoadLibrary definiert.