Windows Phone 7: schnell wie Android, proprietärer als iOS

Neben der höheren Performance von nativen Anwendungen geht es auch um die Portierbarkeit und Zugriff auf bestimmte Low-Level-Funktionen des Betriebssystems. Ein Hersteller, der eine Anwendung in C++ für iOS und Android bereits vorliegen hat, muss erheblichen Aufwand betreiben, um sie zu Silverlight zu portieren.

Bei bestehenden Managed-Code-Anwendungen stehen Entwickler vor der Situation, dass iOS und Android auf Java setzen, während Microsoft Silverlight, .NET und XNA anbietet. Falsch wäre es, Microsoft dafür alleine den „schwarzen Peter“ zuzuschieben. Java-Erfinder Sun hatte Microsoft seinerzeit die Verbreitung seines Java-JIT-Compilers untersagt und dies in einem mehrere Jahre dauernden Prozess gerichtlich durchgesetzt. Google hingegen hatte die Möglichkeit, mit Dalvik eine eigene Java-Plattform und einen eigenen JIT-Compiler zu entwickeln.

Wenig bekannt ist, dass Microsoft als Nachfolger für Visual Basic 4.0 die Projekte „Vegas B“ und „Vegas J“ gestartet hatte, wobei B für Basic und J für Java steht. Vegas J sollte bestehende Visual-Basic-Programme in Java-Bytecode übersetzen. Als sich ein Sieg Suns vor Gericht abzeichnete, kam Microsoft mit der eigenen Managed-Code-Plattform .NET.

Allerdings hat Microsoft sein Produkt Visual J# nicht mehr weiterverfolgt. J# übersetzt Java-Sourcecode-Programme in .NET-CLR-Code. Ein solcher Compiler hätte Entwicklern helfen können, Programme für Android und iOS leichter zu Windows Phone 7 zu portieren.

Spekulationen über die Security von CE 6.0

Über die Gründe, warum Microsoft keine nativen Anwendungen erlaubt, kann derzeit nur spekuliert werden. Als Hauptgrund wird die mangelnde Security in Windows CE 6.0 vermutet. Microsoft hatte in einer Powerpoint-Präsentation aus dem Jahre 2006 erläutert, dass Access Control Lists später nachgerüstet werden sollen. Das ist bis heute nicht geschehen. Produkt-Manager Sullivan, dessen Position im Marketing angesiedelt ist, konnte gestern auf die Fragen von ZDNet zu dieser Problematik keine Antworten geben, versprach aber einen kompetenten Kontakt zu vermitteln.

Eine native Anwendung kann vermutlich auf alle Dateien, etwa das Adressbuch, ohne Kontrolle zugreifen und „nach Hause telefonieren“. iOS und Android basieren beide auf Unix und können auch nativen Anwendungen den Zugriff auf Hauptspeicher und Dateien anderer Anwendungen verbieten, solange das Telefon nicht „gerootet“ wurde.

Als problematisch muss auch angesehen werden, dass Microsoft seine interne Datenbank nicht für die Nutzung durch andere Anwendungen freigibt. Eine Datenbank ist beispielsweise wichtig für Entwickler, die Twitter- und Facebook-Applikationen bereitstellen, um die Nachrichten offline zu speichern. Zwar bietet Windows Phone 7 einen "Push-Layer", für den Developer einen Provider schreiben können, damit wird das Telefon jedoch nur über den Eingang neuer Nachrichten informiert. Die Datenspeicherung muss der Entwickler komplett selbst umsetzen.

Hauptproblem ist dabei wieder das Verbot von nativen Anwendungen. Frei verfügbare Datenbanken, die für Mobiltelefone geeignet sind, etwa SQLite, können nicht genutzt werden, da sie als native Anwendung konzipiert sind. Als Ausweg könnte die Open-Source-Datenbank Perst von McObject dienen, die kürzlich als .NET-Datenbank für Windows Phone 7 portiert wurde.