Mobile Systems III INFORMATIK

Michael Böhm 179
Der Kernel selbst hat keinerlei Abhängigkeit von diesen Erweiterungen und auf die Kernel
Extensions erhält keine Anwendung selbst den Zugriff. Damit nun die Anwendungen
korrekt funktionieren und die für sie vorgesehene Hardware benutzen, sind just diese Informationen
in den Treibern gespeichert. Diese können, um die Kontrolle über die Hardware
für bestimmte Anwendungen zu erhalten, beliebig installiert und deinstalliert werden. Die
Treiber bestehen aus zwei Teilen, einer Bibliothek, um die entsprechende API selbst anzusprechen
und mehreren Bibliotheken, um die Hardware nutzen zu können. Damit kann
die Kontrolle partiell vermittelt werden, ohne direkten Einfluss oder Schaden am Kernel
beziehungsweise dem Betriebssystem selbst vorzunehmen. An dieser Stelle soll noch einmal
näher auf die Kernel Side Library eingegangen werden. Es wurde ja bereits gesagt,
dass hier alle lebensnotwendigen Daten gespeichert sind. Diese Bibliotheken unterteilen
sich allerdings noch einmal in zwei verschiedene Typen. Zum einen gibt es den logical
device driver DLL (LDD) und zum anderen den physical device driver DLL (PDD). Die
logischen Treiber beinhalten sämtliche grundlegenden logischen Funktionen im Sinne von
I/O. Diese sind auch immer auf andere Systeme transportierbar. Der interessante Aspekt
sind die PDD, die jeweils auf das bestimmte Zielsystem zugeschnitten werden und die
vorhandenen Ressourcen mobilisieren können. Diese Dateien sind notwendig und müssen
verfügbar sein, aber durch die Zweiteilung muss man bei dem Portieren des Betriebssystems
auf einer andere Hardware-Plattform nur die entsprechenden PDD austauschen
und das System funktioniert in der gewünschten Umgebung. LDD und PDD sind hier als
polymorphic DLL realisiert und müssen in einem bestimmten Verfahren genutzt werden.
[8] Einzige Ausnahme aus der Prioritätscodierung ist der Screen Buffer. Das erscheint
auch logisch, wenn man bedenkt, dass die Bildschirmdarstellung sich nicht “hinten anstellen“
sollte. Die Lösung liegt im Direct Memory Access, der die Daten unmittelbar in das
LCD Display kopiert. Damit es an Schnelligkeit nicht mangelt, wurde der Screen Buffer
mit allen notwendigen Lese- und Schreibberechtigung auf alle Prozesse ausgestattet. Damit
werden Anwendungen über eine Graphic API schnell dargestellt. Folglich wird der
privileged mode umgangen und dieser Vorgang liegt außerhalb der Prioritätencodierung.
8.4.2 Application-Sicht
Symbian OS wurde als ein umfangreiches Betriebssystem geplant, welches alle Fähigkeiten
eines normalen Betriebssystem aufweist und dennoch in den Speicher eines Mobiltelefons
passen sollte. [8] Das setzt bestimmte Anforderungen voraus. Diese wurden nun bereits
genannt beziehungs-weise auch erläutert und teilweise auch diskutiert. Im Zusammenhang
des Aufbaus wird nun die zweite Sichtweise betrachtet. Diese Sicht beschäftigt sich vor
allem mit den Abhängigkeiten der Systemkomponenten. Es handelt sich allerdings um
einen Übergang und eine klare Trennung zwischen den Sichtweisen kann nicht vorgenommen
werden. So müssen zunächst noch einige tiefer gehende Erläuterungen vorangehen,
bevor man sich dem allgemeinen Aufbau aus der Application-Sicht zuwenden kann.
Server-Client Struktur
Symbian OS beinhaltet eine umfassende Sammlung an Bibliotheken, um möglichst viele
Industriestandards zu implementieren. Unter anderem TCP/IP, SSL, FTP und SMTP um
nur einige aus verschiedenen Bereichen zu nennen. Abbildung 4 zeigt einige Bereiche auf,