Wer sich für ein Telefon mit Windows Phone 7 entscheidet, bekommt das Microsoft-Pendant zu Apples iPhone. Alle Telefone werden dieselbe Oberfläche mit den Windows-Phone-7-Tiles erhalten. Die Handys werden keine Speicherkarten besitzen und Anwendungen können nur über Microsofts Marketplace bezogen werden. Das Multitasking ist stark eingeschränkt.
Die größten Defizite mit Windows Phone 7, etwa fehlende Unterstützung für native Anwendungen und Nutzungsverbot für die interne Datenbank, betreffen vor allem Entwickler. Als normaler Anwender ist man davon indirekt betroffen, wenn Entwickler den großen Aufwand scheuen, ihre Apps zu Windows Phone 7 zu portieren.
Wie viele Apps tatsächlich in Microsofts Marktplace landen werden, lässt sich nicht vorhersagen. Auf die Menge kommt es aber auch gar nicht an, sondern darauf, welche. So basiert der eingebaute Browser auf der Internet-Explorer-7-Codebase, die nicht gerade für Geschwindigkeit und Kompatibilität mit Standards wie CSS bekannt ist. Hier wäre Microsoft gut beraten, Alternativen zuzulassen. Ein Browser müsste jedoch als native Anwendung realisiert werden, um das Geschwindigkeitsproblem lösen zu können.
Zudem können Entwickler nicht auf bestehende .NET-Implementierungen zurückgreifen. Bestehende Open-Source-Browser wie Mozilla, Apple Webkit oder Chromium sind in C oder C++ geschrieben. Wer einen .NET-Browser entwickeln will, muss bei Null anfangen.
Insgesamt lässt sich festhalten, dass Microsoft mit Windows Phone 7 aus technischer Sicht in die Oberklasse der Smartphones aufgestiegen ist. Die bestehenden Beschränkungen, etwa limitiertes Multitasking, Anwendungsinstallation nur aus dem Microsoft Marketplace und Verbot von Speicherkarten, sind eine bewusste Entscheidung Microsofts, sich eher an Apple als an Google zu orientieren. Lediglich die Nichtverfügbarkeit von nativen Anwendungen legt den Verdacht nahe, dass Microsoft bei der Security des Basisbetriebssystems CE 6.0 in der nächsten Version deutlich nachbessern muss, um native Apps erlauben zu können.
Eine Technologieführerschaft im Smartphone-Segment mag man Microsoft allerdings nicht zugestehen. Die Konzepte sind größtenteils vom iPhone übernommen. Ob Windows Phone 7 in Zukunft in einem Atemzug mit iOS und Android genannt wird oder zusammen mit Betriebssystemen wie Bada und MeeGo in die Kategorie „Sonstige“ fällt, wird sich zeigen. Das hängt weniger von der Technik, sondern mehr von einem erfolgreichen Marketing ab.
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.