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.
Neueste Kommentare
6 Kommentare zu Windows Phone 7: schnell wie Android, proprietärer als iOS
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
falsches Konzept
Ich habe win mobile schon benutzt als es noch "CE" hieß.
Aber das jetzige Konzept empfinde ich als unzumutbar.
Keine veränderbare Oberfläche. Keine nativen Programme. Keine Speicherkartenslots. Nur der Marketplace. Bechränktes Multitasking
Das sind alles Unverschämtheiten. Und diese Hub-Oberfläche ist mir extrem unsympatisch.
Mein nächstes Smartphone wird definitiv Android sein.
Microsoft wird im Smartphone-Sektor untergehen.
Telefon
Klasse das neue SmartPhone.
kann man damit auch telefonieren ;) – wurde nicht gezeigt?
Wie sieht es aus mit (selbst erstellten) Checklisten?
Was ist mit Zeitmanagement – Outlooksync – Termine anlegen einfach kopieren, etc..Spracheingabe für eMails?
Der ganze WebCram ist zwar schön, aber privat unbezahlbar – es sein denn man schmeißt sein Telefon und DSL-Anschluss zu Hause weg und macht nur noch alles mit dem Handy + Flatrate. Bei dem Tarif-Dschungel werde ich nie ein Handy online nutzen (es sei denn ich bräuchte es mal geschäftlich).
iOS nutzt kein Java
iOS verwendet als einzige und alleinige Programmiersprachen C, C++, JavaScript und Objective-C, wobei letztere die "Hauptspache" ist und sich drastisch von Java, C# und C++ unterscheidet. Es ist ja (je nach Lesart der Lizenzbedingungen) noch nicht mal erlaubt, ein etwa in Java geschriebenes Programm für iOS zu cross-compilieren, was das Übersetzen von oder nach Android enorm erschwert.
Managed Code ist gut
Ich verstehe die Abneigung gegenüber Managed Code nicht. Managed Code erhöht drastisch die Sicherheit, weil per Design alles in einer Sandbox läuft und Buffer-Overflows kaum möglich sind. Auch in Sachen Performance stehen Java/C# den nativen Applikationen kaum nach, zu mal man Managed Code ja auch nativ kompiliert laufen lassen kann.
Aus meiner Sicht wird Managed Code deutlich wichtiger in der Zukunft.
AW: Managed Code ist gut
Da gebe ich Ihnen völlig recht. Es gibt überhaupt keinen Grund, Abneigung gegen Managed Code zu haben. Mal abgesehen von der faktischen Unmöglichkeit, versehentlich Memory-Leaks oder Sicherheitslücken durch Buffer-Overflows zu erzeugen, lassen sich mit Managed Code Anwendungen sehr viel schneller erstellen (geringe Entwicklungszeit) , als das etwa in C oder C++ der Fall ist.
Sollten wenige Performance-Bottlenecks auftreten, dann kann man einige kleine Routinen immer noch in C oder gar Assembler entwicklen.
Problematisch ist aber, nur Managed-Code-Programme zu erlauben, da existierende native Anwendungen nur schwer portiert werden können. So hat Mozilla sein Fennec (=Firefox für Smartphone) für Windows Phone 7 wieder eingestellt, weil die Mozilla Codebase als nativer C-Code vorliegt.
Ein Verbot für native Anwendungen kommt viel zu früh, da
1) existierende Native-Code-Software (Flash, Fennec, Opera Mobile, SQLite, MySQL, etc.) nur schwer portiert werden kann.
2) Mit Java und .NET zwei unterschiedliche Managed-Code-Modelle vorliegen. MS sollte Visual J# wieder aufnehmen, um Java-Source in .NET-Bytecode zu übersetzen. Das würde Portierungen erleichtern.
Android macht mit Dalvik übrigens auch keinen Java-Bytecode. Es übersetzt zwar erst Java-Source-Code in Java-Bytecode. Der wird anschließend mit dem Assembler dx in Dalvik-Bytecode übersetzt, der wie native Prozessorbefehlssätze registerbasiert und nicht LIFO-Stack-basiert (Kellerautomat) ist wie Java-Bytecode. So ergibt sich eine schnellere Ausführungsgeschwindigkeit.
AW: AW: Managed Code ist gut
Eins der größten Probleme von Windows ist die Verpflichtung alles an Legacy mitzunehmen. Ohne diese Backward-Compatibility wäre das Betriebsystem heute schon sehr viel weiter als es ist.
Jetzt entscheided sich MS ein klaren Schnitt im Telefonbereich zu machen und wieder soll das nicht gut sein? Übergänge tun weh, ja. Aber diese Entscheidung ist richtig.