Windows Embedded

Allgemeines

Die derzeitigen GoPal-Geräte laufen unter dem Betriebssystem Microsoft Windows CE.

Eine Übersicht aller Embedded Betriebssysteme von Microsoft findet man unter:

http://www.microsoft.com/windowsembedded/en-us/default.mspx

Spezielles zu Microsoft Windows Embedded CE findet sich unter:

http://www.microsoft.com/windowsembedded/en-us/products/windowsce/default.mspx

Die von Microsoft Windows CE unterstützten Prozessoren sind MIPS, SH4, x86 und ARM. Die GoPal-Geräte haben eine CPU mit ARM-Core.

Lizenz

Sieht man sich den Funktionsumfang, die mitgelieferten DLLs und Applikationen, etc. an, nachdem man im Explorer in das /Windows-Verzeichnis des GoPal-Gerätes bei einer ActiveSync-Verbindung reingeschaut hat, so kann man mit etwas Recherche-Arbeit erkennen, dass hier die Core Runtime License und nicht die wesentlich umfangreichere Professional Runtime License verwendet wird.

Diese Einschränkung ist dafür verantwortlich, dass eine Reihe von Pocket-PC-Programmen oder Windows-CE-Applikationen, die auf anderen Geräten entwickelt wurden, nicht laufen können, selbst wenn hardware-technisch das Portable Navigation Device in der Lage wäre, das Programm laufen zu lassen. Gerade hier steckt manchmal eine Menge Frust für den GoPal-Besitzer begraben, solange dieser Lizenz-Unterschied noch nicht verstanden ist.

Die billigere Core Runtime License wird auf Navigationsgeräten durch die Hersteller bevorzugt verwendet, besonders wenn es nicht vorgesehen ist, dass der Endbenutzer auf die Shell des Betriebssystems zugreifen darf und dadurch einen erweiterten Funktionsumfang nutzen kann. Das haben übrigens andere Navigationslösungen mit GoPal gemeinsam.

Eine Professional Runtime License findet man eher bei z.B. Mobiltelefonen bei denen die grafische Microsoft-Shell mit bekanntem Start-Button etc. auch für die Benutzung durch den Endanwender vorgesehen ist.

Da nur selten ein Endbenutzer auf eine Core Runtime License vollen Zugriff hat (sondern halt auf eine Professional Runtime License), existieren vermehrt Windows Embedded CE Programme im Freeware, Open Source und kommerziellen Umfeld, die Bibliotheken, bzw. API-Funktionen verwenden, die auf den GoPal-Geräten so erst mal nicht vorhanden sind.

Graphische Windows Shell oder Explorer

In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:

• ShowTaskBar V1.1
• Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:
  • Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,
  • Mit Task Managern, z.B. Task-Manager V1.0, 1.4.5
• Mit Remote Registry Editor (Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices) unter HKLM\init einen Hilfprogramm wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten
• Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)
  • Kann die mal jemand auflisten und sagen auf welchem Gerät und Software-Version die gelten?
  • Ab GoPal 4.1 kann man im Hauptmenü oben in das "o" von Gopal klicken (dreimal wiederholen) und dadurch wird der Explorer gestartet. Achtung dieser Trick funktioniert nicht bei Centrality Geräten.

Dynamic Linked Libraries nachinstallieren

Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.

Es geht aber noch weiter: häufig haben DLLs untereinander Abhängigkeiten, so dass nicht nur eine DLL nachinstalliert werden muss, sondern sich ein Ratenschwanz an Nachinstallationen hinterherzieht.

Im Bereich eingebetteter Systeme wird im Gegensatz zum PC-Desktop-Bereich das abstrahierte Betriebssystem mit einer Adaptionsschicht zur Hardware-Plattform gemeinsam entwickelt. Beides gemeinsam wird als Board-Support-Package (kurz: BSP) bezeichnet. Solche Plattformanpassungen und die höhere Flexibilität Betriebssystem-Features im Windows CE rein oder raus zu konfigurieren, führen dazu, dass einge Kern-DLLs von Windows CE sehr an die Hardware-Plattform oder die Betriebssystem-Feature-Wahl angepasst sind. Anzunehmen, eine core.dll des einen Windows CE-Gerätes läuft (problemlos) auf einem anderen Gerät, geht dadurch im Allgemeinen deutlich schief.

Nachdem es oft einfach nur laufen soll, man aber die originalen Microsoft DLLs rechtlich nicht wirklich verwenden darf, oder auch nur die Nachinstallation mit Rattenschwanz zu aufwändig ist, gab es bisher auch noch einen anderen Ansatz, um ein nicht lauffähiges Programm einfach laufen zu lassen: Man programmiert die fehlende DLL einfach selbst und kennt ja aus dem Microsoft Developer Network oder durch entsprechende Analyse der originialen DLL die Schnittstellenbeschreibung (Vorsicht! Wieder ein Rechtsverstoß, wenn das als Reverse Engineering ausgelegt wird). Dass der Aufruf klappt, ist dabei wichtig. Ob der Inhalt der aufgerufenen Funktion stimmt, ist erst mal sekundär.

Typisches Beispiel, dass so etwas praktiziert wird, ist die aygshell.dll. Davon kann man mit etwas Suche im Netz der Netze viele Varianten finden. Gemeinsam haben sie die gleiche Schnittstelle. Nur die Implementierung weicht häufig untereinander ab. Also führt es zu unterschiedlichem Erfolg, ob und wie das zugehörige Programm läuft. Das die Mistkiste dann nicht genau das macht, was sie soll, liegt dann nicht an Microsoft, sondern an demjenigen, der die abgespeckte Aygshell nur an seine eigenen Bedürfnisse angepasst hat und bloß nicht mehr machen wollte. So zum richtigen Download an fester Adresse mit Homepage findet man solch eine Aygshell.dll freilich nicht. Das machen so CE-Entwickler mehr inoffiziell für sich selbst. Ob das rechtlich wieder ok ist, die Aygshell.dll so nachzuäffen und/oder weiterzugeben bleibt fragwürdig. Mir sind aber auch keine Gerichtsentscheidungen hierzu bekannt. Irgendwie ist das aber auch alles in allem noch sehr "unsauber".

Das Tool, das man benutzt, um die DLL-Abhängigkeiten von Executables (ausführbaren Dateien) und weiteren DLLs zu sehen, nennt sich übrigens Dependency Walker. Ein Dependency Walker geht in statischer Analyse die ausführbaren Programmanteile durch und zeigt fehlende wie auch erfüllte Abhängigkeiten zu Bibliotheksfunktionen an. Dadurch braucht man also nicht mehr raten, welche DLL eigentlich fehlt.

Tipp & Fazit: Wer programmieren kann, programmiert lieber selbst. Wer ein Programm einfach nur verwenden mag, sollte nach einer Version Ausschau halten, die zu Gerät, BSP und der Lizenz des Betriebssystems passt.