-
Die
vorliegende Erfindung betrifft ein Verfahren zum Zugreifen auf Daten
in einer Rechenvorrichtung und insbesondere ein Verfahren zum Zugreifen
auf Daten, die in einer dynamischen Verknüpfungsbibliothek (dynamik links
library) in der Rechenvorrichtung aufbewahrt werden. Die vorliegende
Erfindung betrifft auch eine durch das Verfahren gesteuerte Rechenvorrichtung.
-
Der
Ausdruck Rechenvorrichtung, wie er hier verwendet wird, ist ausgedehnt
auszulegen um irgendeine Form von elektrischer Vorrichtung abzudecken
und schließt
Datenaufzeichnungsvorrichtungen wie eine digitale Standbild- oder Videokamera
irgendeines Formfaktors, Computer irgendwelcher Arten oder Formen
einschließlich
handhaltbaren und Personalcomputern, und Kommunikationsvorrichtungen
irgendeines Formfaktors einschließlich Mobiltelefonen, Smart-Telefonen, Kommunikatoren,
die Kommunikationen, Bildaufzeichnungen und/oder Wiedergabe und
Rechenfunktionalität
innerhalb einer einzelnen Vorrichtung verbinden, und irgendwelche
Arten von drahtlosen und verdrahteten Informationsvorrichtungen
ein.
-
Die
meisten Rechenvorrichtungen arbeiten gesteuert durch ein Betriebssystem.
Das Betriebssystem kann als die Software betrachtet werden, die
allen Programmen ermöglicht,
auf der Rechenvorrichtung abzulaufen, und kann ein Schlüssel für eine größere Betriebseffizienz
und leichtere Anwendungsentwicklung sein.
-
Ein
Betriebssystem organisiert bzw. managt die Hardware- und Software-Ressourcen
der Rechenvorrichtung. Jene Ressourcen schließen solche Dinge wie die zentrale
Verarbeitungseinheit (CPU), den Speicher, den Plattenspeicherraum
falls eine Platte einen Teil der Rechenvorrichtung bildet oder im Zusammenhang
mit ihr verwendet wird, ein. Als solches stellt das Betriebssystem
eine stabile konsistente Art für
auf der Rechenvorrichtung ablaufende Anwendungen bereit, um die
Hardware-Ressourcen der Rechenvorrichtung zu handhaben ohne dass
die Anwendung alle Details der physikalisch für die Hardware verfügbaren Ressourcen
kennen muss.
-
Diese
Aufgabe des Managens der Hardware- und Software-Ressourcen ist sehr wichtig, weil verschiedene
Programme und Eingabeverfahren sich um die Aufmerksamkeit der CPU
bemühen,
und Speicher, dauerhafte Speicher und Eingabe/Ausgabe-Ressourcen (I/O-Ressourcen)
für ihre
eigenen Zwecke wünschen.
In dieser Eigenschaft stellt das Betriebssystem sicher, dass jedes
Anwendungsprogramm mit den nötigen
Ressourcen versehen wird aber schenkt immer den der Vorrichtung
verfügbaren
endlichen physikalischen Ressourcen angemessene Beachtung. Ein Anwendungsprogramm
kann als ein vollständiges,
eigenständiges Programm
betrachtet werden, das unmittelbar für den Benutzer der Vorrichtung
eine spezifische Funktion ausführt.
-
Eine
andere Aufgabe, die durch das Betriebssystem ausgeführt werden
kann, ist die des Bereitstellens einer konsistenten Anwendungsprogramm-Schnittstelle
oder ausführbaren
Schnittstelle (API). Dies ist insbesondere wichtig, wenn es nicht
mehr als einen speziellen Typ von Computer gibt, der das Betriebssystem
verwendet, oder wenn die den Computer bildende Hardware dauernd
offen für
Veränderungen
ist. Dies ist insbesondere der Fall, wenn das Kernbetriebssystem
einige unterschiedliche Benutzer hat wie es typischerweise bei Computervorrichtungen
in der Form von Drahtloskommunikationsvorrichtungen wie Smart-Telefonen
auftreten kann.
-
Bei
jenen Vorrichtungen ist es für
verschiedene Vorrichtungshersteller und Vorrichtungslieferanten nicht
unüblich,
gewisse Komponenten eines Kernbetriebssystems als gemeinsame Komponenten
zu verwenden, aber andere Komponenten des Kernbetriebssystems auf
ihre jeweiligen Vorrichtungserfordernisse zuzuschneiden. Es wird
betont, dass eine Unterscheidung zwischen einem Anwendungsprogramm
und einem Betriebssystem ist, dass Anwendungen im "Benutzermodus" (nicht-privilegierten
Modus) laufen während
ein Betriebssysteme und zugehörige
Hilfsprogramme gewöhnlich
im "Überwachermodus" (Privilegiertenmodus)
ablaufen. Demnach gibt es selbst in dem obigen Smart-Telefonbeispiel
gewisse wichtige Komponenten des Betriebssystems, die häufig als
Kernel-Komponenten bezeichnet werden, die ausschließlich im "Überwachermodus" bewahrt werden.
-
Eine
konsistente Anwendungsprogramm-Schnittstelle (API bzw. Application
Program Interface) ermöglicht
es einem Anwendungsprogramm für
eine Rechenvorrichtung, auf einer anderen Rechenvorrichtung desselben
Typs abzulaufen, obwohl der Speicherumfang oder die Speicherqualität auf beiden
Vorrichtungen unterschiedlich sind. Selbst wenn eine spezielle Rechenvorrichtung
einzigartig ist, kann das Betriebssystem sicherstellen, dass Anwendungsprogramme
weiterhin ablaufen können,
wenn Hardware-Erweiterungen und Aktualisierungen vorgenommen werden,
weil das Betriebssystem und nicht das Anwendungsprogramm für das Handhaben
bzw. Managen der Hardware und der Verteilung ihrer Ressourcen zuständig ist.
-
Um
die effiziente Nutzung der Vorrichtungsressourcen fortzuführen, können gewisse
Funktionen und Module, die für
eine Anzahl von Anwendungsprogrammen gemeinsam sind, in der Form
einer Bibliothek gespeichert werden, so dass jene Funktionen und
Module nur einmal gespeichert werden und nicht in jedem der Anwendungsprogramme,
mit dem sie benutzt werden, repliziert werden. Die Inhalte der Bibliothek
werden demnach selektiv mit den Anwendungsprogrammen verknüpft, wenn
jene geladen werden und ablaufen statt dass sie innerhalb der individuellen
Anwendungsprogramme selbst kompiliert werden. Es folgt, dass derselbe Block
von Bibliothekscode, der eine Funktion oder ein Modul repräsentiert,
zwischen verschiedenen Aufgaben geteilt werden kann bzw. gemeinsam
benutzt werden kann, um auf der Vorrichtung abzulaufen statt dass
jede Aufgabe Kopien der Routinen, die sie verwendet, enthält.
-
Jene
Bibliotheken werden dynamisch mit den Anwendungsprogrammen verknüpft wenn
die Programme ablaufen und demnach sind Bibliotheken allgemein als
dynamische Verknüpfungs-Bibliotheken
(DLLs, vom englischsprachigen Ausdruck: dynamic link libraries)
bekannt. Demnach sehen die meisten modernen Computerbetriebssysteme
eine dynamische Verknüpfungs-Bibliothekseinrichtung
vor, die das Bereitstellen gewisser ausführbarer Prozeduren und Funktionen
in Form einer Bibliothek ermöglichen,
die getrennt ist von den Anwendungsprogrammen, die auf der Rechenvorrichtung
ausgeführt
werden. Typischerweise ist ein Anwendungsprogramm dynamisch mit
der Bibliothek in Echtzeit verknüpft,
so dass das Anwendungsprogramm ein oder mehrere der Prozeduren und
Funktionen, die durch die Bibliothek exportiert sind, aufrufen kann.
Exportierte Prozeduren werden allgemein als Eintrittspunkte in eine
Bibliothek bezeichnet.
-
Anders
als ein reguläres
Anwendungsprogramm, das allgemein von Beginn an ausgeführt wird,
kann in eine DLL an irgendeinem Eintrittspunkt eingetreten werden.
Es gibt zwei Hauptarten, diese Eintrittspunkte in eine DLL zu identifizieren.
Die erste Option ist, auf die Eintrittspunkte durch Namen Bezug
zu nehmen. Die zweite Option ist, auf die Eintrittspunkte durch
Ordinalzahlen Bezug zu nehmen. Diese letztere Option wird häufig als
Funktionsordinalabbildung oder Funktionsordinalverknüpfung bezeichnet.
Namen sind potentiell lang verglichen mit Ordinalzahlen und erfordern
zusätzlichen
Code für
ihre Definition. Daher wird die Verwendung von Namen allgemein als
Verschwendung von Nurlesespeicher-Ressourcen (ROM) und Ressourcen
von Speicher mit wahlfreiem Zugriff (RAM-Ressourcen) der Rechenvorrichtung
wenn verglichen mit Ordinalzahlen betrachtet. Ordinalverknüpfung der
Zugangspunkte wird demnach in gewissen Betriebssystemen vorgezogen und
speziell in jenen zur Verwendung in Smart-Telefonen, weil jene Arten
von Rechenvorrichtung sehr eingeschränkte physikalische Ressourcen
haben, verglichen mit jenen, die in Desktop- oder tragbaren PC-Vorrichtungen
verfügbar
sind, und demnach die effiziente Nutzung von Code von äußerster
Wichtigkeit ist.
-
DLLs
stellen daher eine Weise bereit, durch die Anwendungsprogramme in
modularem Format bereitgestellt werden können, so dass die Funktionalität leichter
aktualisiert und wiederverwendet werden kann. Sie kann auch beim
Reduzieren von Speicherüberhang
helfen, wenn einige Anwendungen gleichzeitig dieselbe Funktionalität verwenden,
weil sie obwohl jede Anwendung mit einer Kopie der Daten versehen
ist, den Code teilen können.
Zudem ermöglicht
es das dynamische Verknüpfen
einem Modul, nur die Information, die zum Lokalisieren einer exportierten
DLL-Funktion zum Zeitpunkt des Ladens oder des Ablaufenlassens erforderlich ist,
einzuschließen.
-
Es
gibt ein zunehmendes Erfordernis für Betriebssysteme, eine Kombination
an Kompatibilität
mit Kundenspezifigkeit bereitzustellen. Dies ist insbesondere der
Fall beim Smart-Telefon-Betriebssystemen
wie dem Betriebssystem Symbian OS (Marke), das von Symbian Limited,
London, England, bereitgestellt wird. Typischerweise wird ein solches
Betriebssystem Handapparateherstellern zugeführt, die darauf folgend zusätzliche
Vorrichtungsfunktionalität
für den
durch das Betriebssystem gesteuerten Betrieb vorsehen. Dies bedeutet,
dass ein Betriebssystem dieses Typs binäre Kompatibilität in ihren
APIs aufrecht erhalten muss während es
gleichzeitig zulässt,
dass abgeleitete Plattformen und Produkte innovative und unterscheidende
Funktionalität
zu jenen APIs hinzufügen,
um das Betriebssystem kundenspezifisch zu gestalten für die Erfordernisse
der jeweiligen Handapparatehersteller.
-
Mit
dem Koordinieren der DLL-Eintrittspunkte gehen jedoch Schwierigkeiten
einher, wenn ein Betriebssystem dieses Typs sich von einer Ausgabe
zu der nächsten
weiterentwickeln.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung wird ein Verfahren des
Betreibens einer Rechenvorrichtung mit einem Betriebssystem und
einer dynamischen Verknüpfungsbibliothek
bereitgestellt, die eine Vielzahl von Funktionen enthält, auf
die ein ausführbares
Programm zugreifen kann, dadurch gekennzeichnet, dass jede Funktion
in der dynamischen Verknüpfungsbibliothek
einer Ordinalzahl zugeordnet ist und das Verfahren umfasst:
Bereitstellen
einer dynamischen Verknüpfungsbibliothek
als einen ersten Teil und einen Erweiterungsteil, wobei der erste
Teil und der Erweiterungsteil jeweils eine oder mehrere der Vielzahl
von Funktionen enthalten; Veranlassen des ausführbaren Programms, mit Hilfe
der zugeordneten Ordinalzahlen direkt zu Funktionen in dem ersten
Teil Verknüpfungen
vorzunehmen; und Veranlassen des ausführbaren Programms, indirekt über eine
weitere, zusätzliche
Funktionen enthaltende Bibliothek zu Funktionen des Erweiterungsteils
Verknüpfungen
vorzunehmen.
-
Gemäß einem
zweiten Aspekt der Erfindung wird eine Rechenvorrichtung bereitgestellt,
die eingerichtet ist um in Übereinstimmung
mit dem oben definierten Verfahren betrieben zu werden.
-
Gemäß einem
dritten Aspekt der Erfindung wird eine Computersoftware bereitgestellt,
die eingerichtet ist, um eine Rechenvorrichtung zu veranlassen,
in Übereinstimmung
mit dem oben definierten Verfahren zu arbeiten.
-
Bevorzugte
Merkmale der Erfindung werden in den abhängigen Ansprüchen dargelegt.
-
Eine
Ausführungsform
der vorliegenden Erfindung wird nun in lediglich beispielhafter
Weise unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben,
in denen zeigt:
-
1 schematisch
ein Diagramm einer Smart-Telefonplattform-Weiterentwicklung;
-
2 ein
Diagramm zum schematischen Zeigen, wie ein Konflikt zwischen Ordinalzahlen
einer DLL mit paralleler Plattformweiterentwicklung aufkommen kann;
-
3 ein
Diagramm zum schematischen Zeigen, wie eine Anwendung in einem Smart-Telefon
auf Originalfunktionen von einer DLL zugreifen kann;
-
4 ein
Diagramm zum Zeigen, wie eine DLL in Übereinstimmung mit dem Verfahren
der vorliegenden Erfindung bereitgestellt werden kann; und
-
5 ein
Diagramm zum Zeigen, wie eine Anwendung auf eine Funktion von einer
modifizierten DLL unter Verwendung einer DLL-Erweiterung zugreifen
kann, die in Übereinstimmung
mit dem Verfahren der vorliegenden Erfindung bereitgestellt wird.
-
Bezug
nehmend auf 1 wird ein Beispiel einer typischen
Entwicklung eines Smart-Telefons gezeigt. Aus Gründen der Klarheit wird diese
Entwicklung in der Form eines Familienbaums dargestellt. Die Figur
zeigt einen kleinen Teil des Entwicklungs-"Familienbaums", aber der Schlüsselpunkt in Bezug auf dieses
Beispiel ist, dass es nicht einen einzigen linearen Entwicklungspfad
von einer Ausführung
einer Einheit zu der nächsten gibt.
Aus dem Beispiel der 1 kann gesehen werden, dass
das Betriebssystem sich von der OS-Version X zu der OS-Version X + 1 entwickelt.
Aber parallel hierzu entwickelt sich die Vorrichtungsplattform,
die typischerweise die Vorrichtungsbenutzer-Schnittstelle sein kann,
von der Plattform Y zu der Plattform Y + 1, wobei die Plattform
Y auf der Betriebssystemsversion bzw. OS-Version X beruht und die
Plattform Y + 1 auf der OS-Version X + 1 beruht. Das Produkt A entwickelt
sich zu dem Produkt B und jene basieren beide auf Plattform Y. Das
Produkt B entwickelt sich dann zu der Version 2 des Produkts B,
aber diese basiert auf der Plattform Y + 1. Dies kommt daher, dass
bei demselben Entwicklungslevel das Erfordernis zum Hinzufügen von
Funktionalität
zu der Basisplattform vorgelegen hat.
-
Es
gibt ein zusätzliches
Erfordernis des Aufrechterhaltens dieser Funktionalität in zukünftigen
Versionen dieses Levels der Familie. Dies bedeutet, dass es mehrere
Wege gibt, durch die das funktionale Wachstum auftreten kann. Beispielsweise
muss ein spezielles Produkt zusätzliche
Funktionalität
von dem OS-Übergang,
von dem Plattformübergang
und von seinem Produktvorgänger übernehmen.
-
Mehrere
Funktionsvererbungswege verursachen eine unmittelbare Plattformfragmentierung
wenn das Betriebssystem zum Exportieren von Funktionen von der DLL
ein Ordinalzahlen-Verknüpfungsschema
verwendet. Bei diesem Schematyp wird jede von dem DLL exportierte
Funktion sequentiell nummeriert. Eine Client-Anwendung der DLL ruft
die Funktionen zum Exportieren durch diese Ordinalzahl auf. Das
Nachschauen zwischen Funktionen und Ordinalzahlen kann durch eine
Definitionsdatei (.DEF) der betreffenden Anwendung definiert sein.
Dieses sequentielle Nummerierungsschema bedeutet jedoch, dass wenn
zwei Parteien ohne voneinander zu wissen jeweilige Funktionshinzufügungen zu
demselben API vornehmen, die Funktion, die durch jede Partei hinzugefügt wird,
mit derselben Ordinalzahl versehen wird (am Ende des benutzten Ordinalzahlenbereichs).
Dies bedeutet, dass Programmcode, der gegenüber dem DLL gebildet wird und
durch eine erste der zwei Parteien (Partei Eins) modifiziert wird,
diese Ordinalzahl verwenden wird, um auf die Funktionalität zuzugreifen,
von der gedacht wird, dass sie bei der betreffenden Ordinalzahl in
der Version der Plattform existiert, die durch die Partei Eins entwickelt
worden ist.
-
Das
Problem beginnt jedoch, wenn dieser Programmcode irgendeinmal gegen
die Version der Plattform abläuft,
die von der anderen der beiden Parteien (Partei Zwei) entwickelt
worden ist, da die Funktion bei dieser Ordinalzahl, die durch die
Partei Eins entwickelt worden ist, nicht dieselbe ist wie die Funktion
bei derselben Ordinalzahl, wie sie von der Partei Zwei entwickelt
worden ist. Sobald dieses Problem in einem herausgegebenen Produkt
aufgetreten ist, gibt es keinen Weg, es zu korrigieren ohne die
binäre
Kompatibilität
in der einen oder anderen Plattform zu zerstören. 2 zeigt,
was vorkommt, wenn eine API unabhängig von zwei Parteien parallel
erweitert wird, und wie der resultierende Ordinalzahlenraum nicht
aufgelöst
werden kann.
-
Die
Benutzung von Mehrfachwegen der funktionalen Vererbung zeigt kein
Problem, solange jede API einen einzelnen Vererbungsweg hat. In
der Praxis bedeutet dies einen einzelnen Inhaber für jede API.
Einem Inhaber ist es erlaubt, zu einer jeweiligen API hinzuzufügen; Niemandem
sonst. Dies bedeutet, dass die API sich in einer linearen Weise
weiterentwickelt. Wenn beispielsweise das Symbian OS (Marke) Betriebssystem als
ein Beispiel genommen wird, würden
DLLs, deren Inhaber Symbian ist, nur durch Symbian erweiterbar sein und
würde nicht
durch Entwickler von Derivat-Plattformen oder Produkten erweiterbar
sein. In der Praxis ist dieses Ideal, niemandem außer dem
Inhaber der Schnittstelle zu erlauben, Erweiterungen zu der Schnittstelle hinzuzufügen, nicht
vereinbar mit dem zunehmenden Bedarf des Bereitstellens von einer
Kundenanpassung von Plattformen und Produkten eines gemeinsamen
Kernbetriebssystems.
-
Wegen
des fortgesetzten Bedarfs, neue Produkte zu entwickeln und jene
in dem kürzestmöglichen Zeitrahmen
in den Markt zu bringen, ist es relativ üblich, dass verschiedene Produkte
von einer ersten Partei entwickelt werden, jedoch Funktionalität zu Schnittstellen
hinzugefügt
werden, deren Inhaber eine oder mehrere Parteien sind. Beispielsweise
könnte
dies auftreten, wenn eine durch eine Partei entwickelte Plattform eine
API zu einer oder mehreren Bibliotheken hinzufügt, die einer anderen Partei
gehören,
oder wenn ein Produkt eine API zu einer oder mehreren Plattform-Bibliotheken
hinzufügt,
das Problem ist in allen Fällen
dasselbe.
-
Es
wird betont, dass das Problem das ist, dass die Kompatibilität mit der
zugrunde liegenden Plattform zerstört ist. In jedem Fall würde das
Produkt dem derzeitigen Betriebssystem/der Benutzerschnittstellenplattform
(OS/UI) kompatibel sein. Das Problem ist, dass wenn basierend auf
einer späteren
Version dieser OS/UI-Plattform, wenn die zukünftige Version des Produkts
gemacht wird, diese nur entweder mit der neuen Version der Plattform
oder der vorangehenden Version des Produkts kompatibel sein kann
aber nicht mit beiden. Das Erfordernis ist jedoch, dass die Kompatibilität mit beiden
wesentlich ist, um die Plattform nicht zu fragmentieren. Eine solche
Fragmentierung würde
das Betriebssystem stark schädigen
und seine Wiederherstellung würde
sehr schwierig werden.
-
Demnach
kann ein Bereitsteller eines Betriebssystems (OS-Bereitsteller) sich einem Szenario gegenübersehen,
in dem:
- – der
OS-Bereitsteller wesentliche Funktionalität zu seinen APIs in neuen Versionen
des OS hinzufügt
(in legitimierter Weise)
- – Benutzerschnittstellen-
bzw. UI-Plattformbereitsteller spürbare Funktionalität zu ihren
APIs in neuen Versionen hinzufügen
(in legitimierter Weise)
- – Produkthersteller
Funktionalitäten
zu den OS- und UI-Plattform-APIs
in ihren Produkten hinzufügen
und dies ist nicht in unbegründeter
Weise zu erwarten, weil jene Produkte eine Differenzierung und Flexibilität von der
Plattform erfordern.
-
Weil
jedoch die funktionalen Hinzufügungen
durch jede der obigen Parteien am Ende des Ordinalzahlenbereichs
zugeführt
werden, werden die funktionalen Hinzufügungen des Produktherstellers
in demselben Ordinal-Raum sein wie die UI-Plattformhinzufügungen, die von dem UI-Plattformbereitsteller
vorgesehen werden, welche wiederum in demselben Ordinal-Raum sein
werden wie die zusätzlichen
Funktionalitäten,
die von dem OS-Bereitsteller vorgesehen werden. Demnach gibt es
ein Konfliktpotential innerhalb des Ordinal-Raums eines unbekannten
Umfangs und von einer unbekannten Quelle. Der Grund, weshalb der
Umfang unbekannt ist, ist dass ein Großteil der Arbeit, der an einer
Plattform durch den Produkthersteller vorgenommen wird, um neue
Produkte zu realisieren, nicht notwendigerweise für jeden
der OS- oder UI-Plattformbereitsteller sichtbar ist.
-
In
der Realität
wird diese Situation nicht zerstörerisch
bis zwei Produkte oder Software-Entwicklungswerkzeuge (SDKs bzw.
Software Development Kits), durch die die Produkte entwickelt werden,
im Markt mit Konflikt-Ordinalzahlen verfügbar werden. Bis zu dieser
Zeit ist es möglich,
Produkte und SDKs zu korrigieren, die noch nicht im Markt freigegeben
werden.
-
Demnach
versucht die vorliegende Erfindung, ein System bereitzustellen,
das den Benutzer des Systems in die Lage versetzt, Funktionalitäten zu APIs
in einer sicheren ausdehnbaren Weise hinzuzufügen ohne die zukünftige Kompatibilität zu gefährden. Auf
diese Weise könnte
eine dritte Partei Funktionalität
zu einer existierenden API und insbesondere zu einer API, die durch
eine Ordinalzahl verknüpft
ist, in einer Weise hinzufügen,
die die zukünftige
Weiterentwicklung dieser API nicht gefährdet. Ein zweites Ziel ist,
dass irgendwelche zukünftige
Weiterentwicklung der Ursprungs-API, die nicht auftreten wird, die
von der dritten Partei hinzugefügte
Funktionalität
nicht gefährden
wird.
-
Die
vorliegende Erfindung ist auf irgendeine Situation anwendbar, bei
der eine dritte Partei Funktionalität zu einem existierenden API
hinzufügen
muss, welches nicht dieser Partei gehört. Es wird anwendbar, wenn
der Inhaber einer API diese API ausdehnt weil durch Definition der
Inhaber derjenige ist, der die API wartet. Die vorliegende Erfindung
kann auch zum Entfernen weiteren Konfliktpotentials benutzt werden,
wenn bereits Hinzufügungen
zu einer API durch eine dritte Partei vorgenommen worden sind.
-
3 zeigt
eine Anwendungsverknüpfung
zu Originalfunktionen (Original Functions), die gegenüber einer
Bibliothekserweiterung (LIB) einer Plattform-DLL gespeichert werden.
Die Anwendung verwendet die Funktionen, die in der DLL gespeichert
werden, über
die LIB-Datei-Ordinalzahlen. Wenn die Anwendung eine Originalfunktion
1 aufruft, wird eine Verknüpfung
zu der Ordinalzahl 1 der Bibliothekserweiterung bereitgestellt, welche
wiederum die durch die Originalfunktion1 bereitgestellte Funktionalität zur Benutzung
durch eine Anwendung exportiert; und so weiter für die verbleibenden bei anderen
Ordinalzahlen in der DLL gespeicherten Originalfunktionen. Dies
ist ein bekanntes Muster von DLL-Verknüpfung und wird beispielsweise
in dem Symbian OS (Marke) Betriebssystem verwendet.
-
4 zeigt,
wie ein Erweiterungs-DLL-Muster (Extension DLL) durch eine Anwendung
für irgendwelche
Produkthinzufügefunktionen
verwendet werden kann, die zu den Originalfunktionen hinzugefügt worden sind,
welche von der Plattform-DLL bereitgestellt werden. Diese Produkthinzufügungen werden
von der Plattform-DLL über
zusätzliche
Ordinalzahlen 6 und 7 exportiert. Diese zusätzlichen Ordinalzahlen 6 und
7 sind jedoch nicht direkt mit der Anwendung verknüpft sondern über die
Erweiterungs-DLL.
Auf die Erweiterungs-DLL wird über
eine Erweiterungs-Bibliothek
zugegriffen, die die Ordinal-Adressen für die Erweiterungs-DLL bereit hält in ähnlicher
Weise wie der Zugriffsweg für
die Plattform-DLL. Mit der vorliegenden Erfindung ist es der Anwendung
nicht erlaubt, die zusätzlichen
Ordinalzahlen von der Plattform-DLL direkt zu benutzen. Aber, wie
aus 4 gesehen werden kann, ist es der Anwendung erlaubt,
die Originalfunktionen 1 bis 5 durch ihr direktes Exportieren von
der Plattform-DLL zu benutzen. Dies gilt, weil die Originalfunktionen
sowohl dem Betriebssystem als auch der Anwendung als von der DLL über jeweilige
Ordinalzahlen 1 bis 5 zur Benutzung durch die Anwendung exportierbar
bekannt sind.
-
Viele
Betriebssysteme werden nun unter Verwendung eines Objekt-orientierten
Programmiercodes wie z. B. C++ beschrieben. Im Zusammenhang mit
einem solchen System ist eine bevorzugte Art, das Verfahren der
vorliegenden Erfindung zu erlangen, die Produktzusatzfunktionen
als private Mitglieder von Klassen zu implementieren. Dies bedeutet,
dass der C++-Compiler den Client-Code zum Benutzen der Erweiterungs-DLL wirksam
machen wird. Zudem ist es im Stand der Technik wohlbekannt, dass Änderungen
zum ursprünglich durch
eine andere Partei geschriebenen Code auf ein Minimum beschränkt sein
sollten. Demnach braucht die Erweiterungs-DLL unter Einhaltung der üblichen
Vorgehensweise dieser Technik folgend nicht nur als ein Adapter
zum Verknüpfen
der Plattform-DLL bereitgestellt zu werden sondern kann auch eingerichtet
sein, um die Mehrzahl des Zusatzcodes zu enthalten, der zum Bereitstellen
der Zusatzfunktionalität
für die
Anwendungsprogramme erforderlich ist. Zudem kann die Erweiterungs-DLL
in einer Weise vorgesehen sein, dass sie nicht spezifisch ist für eine einzelne
Plattform-DLL. Demnach ist zu sehen, dass eine einzelne "Product Extension"-DLL (Produkterweiterungs-DLL)
in dem ROM der Rechenvorrichtung vorgesehen sein kann, aber diese einzelne
Erweiterungs-DLL eingerichtet ist, um die Schnittstelle zu der zusätzlichen
Funktionalität
von mehr als einer und vielleicht selbst zu allen Plattform-DLLs
vorzusehen. Daher wird betont, dass das Verfahren der vorliegenden
Erfindung nicht auf das Bereitstellen einer jeweiligen Erweiterungs-DLL
für jede
Plattform-DLL beschränkt
ist. Es folgt, dass ein Produkthersteller wählen kann, eine einzelne Erweiterungs-DLL
zum Bereitstellen einer Verknüpfung
zu einigen Plattform-DLLs hinzuzufügen, oder die zusätzliche
Funktionalität
(Erweiterungsfunktionen) durch Anordnen der Erweiterungs-DLL als
eine tatsächliche
Erweiterung zu einer existierenden Produkt-DLL vorgesehen sein kann.
-
Alternativ
können
die Erweiterungsfunktionen in einer Weise gruppiert sein, die keinen
Zusammenhang mit der Anordnung der Ursprungsplattform-DLLs beinhaltet.
-
In
der in 4 gezeigten Anordnung ist daher die Anwendung
der dritten Partei mit den Ordinalzahlen 1 bis 5 Performance.lib,
der Bibliothekserweiterung der Plattform-DLL, und die Ordinalzahlen 1 & 2 von der extension.lib,
d. h. der Bibliothekserweiterung der Erweiterungs-DLL, verknüpft. Sofern
es die Anwendung betrifft, sind die Ordinalzahlen 6 & 7 von Platform.lib
nicht sichtbar. Als ein Ergebnis braucht das SDK (d. h., software
development kit) einer dritten Partei für das Produkt nicht einmal
die erweiterte Version von Platform.lib zu enthalten. Daher ist
es mit der vorliegenden Erfindung möglich, die Ursprungsversion
(Ordinalzahlen 1 bis 5) der Bibliothekserweiterung Platform.lib
in dem SDK zu ersetzen und nur die erweiterte Version (Ordinalzahlen
1 bis 7) der Bibliothek für
die Plattformentwicklung zu verwenden. Dies bedeutet, dass es für durch
die dritte Partei erzeugten Code keine Möglichkeit gibt, die zusätzlichen
Ordinalzahlen 6 und 7 zu verwenden.
-
5 zeigt
eine spätere
Version der Plattform, wenn der Inhaber der Plattform-DLL irgendwelche
weitere Kernfunktionalität
zu der API der Plattform-DLL hinzugefügt hat. In diesem Fall sind
Ordinalzahlen 6 & 7 nun
durch den Inhaber beim Hinzufügen
der neuen Funktionen verwendet worden. Es würde zu Problemen führen, wenn
die Anwendung, die zu dieser Platform-DLL verknüpft ist, Produkthinzufügungen (Product
Addition) 1 und 2 bei jenen Ordinalzahlen erwarten würde, wie
in der in 4 gezeigten Plattformversion,
weil Ordinalzahlen 6 und 7 nun jeweils zum Exportieren von Inhaberhinzufügungen (Owner
Additions) 1 und 2 verwendet werden. In diesem Fall werden die Probleme
jedoch vermieden, da die Produkthinzufügefunktionen Produkthinzufügung 1 und
2 immer über
die Erweiterungs-DLL aufgerufen werden. Demnach ist es für jene Funktionen
akzeptabel, sich jeweils zu einer abweichenden Ordinalposition zu
bewegen. In 5 werden Produkthinzufügungen jeweils
von Ordinalzahlen 6 & 7
zu Ordinalzahlen 8 & 9
bewegt. Die einzige Komponente des Systems, die zu den Ordinalzahlen
für die
Produkthinzufügungen
1 und 2 verknüpft
ist, ist die Erweiterungs-DLL und demnach muss diese neu aufgebaut
werden. Es sind keine Code-Änderungen
erforderlich, sondern lediglich eine Neuverknüpfung, um die Erweiterungs-DLL
auf die neuen Ordinal-Positionen 8 und 9 zu verweisen, die für das Exportieren
der Produkthinzufügungen
1 und 2 zu der Anwendung verwendet werden. Weil der Anwendungscode
der dritten Partei zu der Bibliothekserweiterung extension.lib verknüpft und jene
Ordinalzahlen dieselben bleiben, braucht der Code der dritten Partei
nicht neu aufgebaut zu werden.
-
Ein
Beispiel von Programmcode zum Implementieren der Ausführungsform
der vorliegenden Erfindung, wie in 5 gezeigt,
kann der Folgende sein. Es wird darauf hingewiesen, dass das folgende
Beispiel eine relativ einfache Angabe davon ist, wie der Quellencode
zum Implementieren der vorliegenden Erfindung erzielt werden kann.
-
Der
folgende Code-Auszug zeigt, wie eine Funktion zu einer Header-Datei
einer Plattform DLL hinzugefügt
werden könnte.
In diesem Beispiel werden zwei Funktionen zu dem Header hinzugefügt. Die öffentliche Erweiterungsfunktion
ExtensionFunction wird in der Erweiterungs-DLL bzw. Extension.DLL
implementiert. Sie wird demnach nicht von Platform.dll exportiert,
sondern von Extension.dll. Die private DoExtensionFunction wird
in der Platform-DLL implementiert und demnach wird sie von der Plattform-DLL exportiert.
Diese Funktion ist privat gemacht, so dass der Compiler den Code
einer dritten Partei davon abhält,
diese Funktion durch ihren Ordinalzahlenexport aufzurufen.
-
Die
Implementierung in der Plattform DLL dient dem Hinzufügen des
Codes für
DoExtensionFunction. Dies sollte das Minimum an Code enthalten,
der für
diese Erweiterungsfunktion, die in der DLL einzuschließen ist,
erforderlich ist, so dass der Umfang der erforderlichen Änderung
minimiert wird. Diese Funktion wird in Platform.lib exportiert.
-
Die
Implementierung in der extension.dll dient hauptsächlich dem
Zulässigmachen
eines Rufs durch die private DoExtensionFunction in der Plattform-DLL.
DoExtensionFunction ist privat, so dass sie nur innerhalb derselben
Klasse aufgerufen werden kann. Beachte, dass das Aufrufen von DoExtensionFunction
umgeben wird von anderem Code, der nicht in der Plattform-dll sein
muss und demnach hier implementiert ist zum Minimieren des Einflusses
auf die Plattform-DLL.
-
Vorzugsweise
sollte der Code auch sicherstellen, dass nur essentielle Änderungen
zu der Plattform-DLL vorgenommen werden. Daher sollte die gesamte übrige Funktionalität vorzugsweise
in der Erweiterungs-DLL implementiert werden. Dies liefert den zusätzlichen
Vorteil, dass die Gefahr des Zusammenprallens von Funktionalität, welche
von aufeinander folgenden Änderungen
an der Plattform herrühren,
verringert wird und demnach eine zukünftige Integration näherer Plattformen
weniger schwierig ist.
-
Auch
wenn irgendwelche Erweiterungsfunktionen in der Plattform-DLL vorgesehen
sind, sollten diese vorzugsweise als private Funktionen ausgestaltet
werden. Dies macht es schwieriger für eine dritte Partei, versehentlich
eine Erweiterungsfunktion in der Original-API zu verwenden statt
in der Erweiterungs-DLL. Der Compiler wird dann dabei helfen, die
Regel, die eingerichtet worden ist, durchzusetzen.
-
Zudem
wird auch vorgezogen, dass ein öffentlich
freigegebenes SDK nur Ursprungs-LIB-Dateien wie zugeführt einschließen sollte.
Dies würde
bedeuten, dass der Code einer dritten Partei nicht möglicherweise irgendwelche
Plattformzusatzordinalzahlen aufrufen könnte, da sie nicht in den LIB-Dateien
vorliegen. Eine dritte Partei würde
daher keine Wahl haben, als auf die Erweiterungsfunktionalität über die
Erweiterungs-DLL zuzugreifen und demnach würden keine Kompatibilitätsprobleme
mit zukünftigen
Plattformen auftreten.
-
Durch
Privatmachen von Erweiterungsfunktionen und durch das Ausschließen der
modifizierten Bibliotheken von dem SDK wird verhindert, dass Code
einer dritten Partei die von dem Bereitsteller der Plattform-DLL
erstellten Produktzusatzfunktionen aufruft. Es ist jedoch auch vorzuziehen,
sicherzustellen, dass der ROM-Code innerhalb einer Vorrichtung ebenfalls
die Erweiterungs-DLLs verwendet. Demnach müssen beim Einschränken des
SDK auf die Ursprungs- LIB-Dateien
nicht nur dritte Parteien die Erweiterungs-DLL verwenden, um auf
die Zusatzfunktionen zuzugreifen, sondern der gesamte Code, d. h.,
der ROM-Code, der nachfolgend in die Vorrichtung eingearbeitet wird.
Obwohl ROM-Code zu einigen Zukunftszeitpunkten gegenüber neuen
LIB-Dateien neu aufgebaut werden kann, ist es vorzuziehen und höchst wünschenswert,
die binäre Kompatibilität dort,
wo es möglich
ist und jederzeit während
der Lebensdauer irgendeiner speziellen Vorrichtung zu maximieren.
Dem folgt, dass diese Kompatibilität ermöglicht wird, wenn die Erweiterungs-DLL
der vorliegenden Erfindung in der obigen Weise verwendet wird.
-
Obwohl
die vorliegende Erfindung unter Bezugnahme auf spezielle Ausführungsformen
beschrieben worden ist, wird ersichtlich, dass Modifikationen vorgenommen
werden können
während
der Schutzbereich der vorliegenden Erfindung, wie er durch die beiliegenden
Ansprüche
definiert wird, nicht verlassen wird. Obwohl beispielsweise das
Verfahren der vorliegenden Erfindung unter Bezugnahme auf DLLs mit
Ordinalzahlenverknüpfung
beschrieben worden ist, kann es auch mit DLLs verwendet werden,
die durch Namen verknüpft
sind. Zudem können
die Zusatzfunktionen zur Benutzung durch ein Anwendungsprogramm
teilweise innerhalb der Plattform-DLL vorgesehen sein und teilweise
innerhalb der Erweiterungs-DLL, und die Erweiterungs-DLL kann in
diesem Fall eingerichtet sein, um ein Verknüpfen zu einer zusätzlichen
Funktion in irgendeiner der Plattform-DLL oder der Erweiterungs-DLL
selbst zu veranlassen. Zudem kann die vorliegende Erfindung, obwohl die
vorliegende Erfindung unter Bezugnahme auf eine Rechenvorrichtung
in Form eines Smart-Telefons beschrieben worden ist, auch in anderen
Formen von Rechenvorrichtungen verwendet werden wie tragbaren oder
Tisch-PCs, persönliche
Digital-Assistenten (PDAs) oder allgemeinen Computersystemen.
